A very practical question in Blockchain: How does one actually go about putting data into the blockchain, i.e. the digital ledger used by Bitcoin? Is there an API/SDK/open source library one can use? Does it require a wallet? What is the data size limits? Does it cost money? Can anyone provide some pointers in this area?
Related
I want to create a tokenomics database.
I want to build a bot to automate data collection that answers for each token on the blockchain some of the questions asked and answered in this article.
I am a total newbie when it comes to blockchain. So, I have some basic questions.
Where is this information located? How did the author discover the numbers he quotes? Is there an API one could use to collect this information? (See update.)
Update: In writing this question, I discovered this Etherscan API. How might one leverage that API to obtain the tokenomics data I want?
Source [emphasis mine]
There will only ever be 21,000,000 bitcoin, and they’re released at a rate that gets cut in half every four years or so. Roughly 19,000,000 already exist, so there are only 2,000,000 more to be released over the next 120 years.
What about Ethereum? The circulating supply is around 118,000,000, and there’s no cap on how many Ether can exist. But Ethereum’s net emissions were recently adjusted via a burn mechanism so that it would reach a stable supply, or potentially even be deflationary, resulting in somewhere between 100-120m tokens total. Given that, we shouldn’t expect much inflationary pressure on Ether either. It could even be deflationary.
Dogecoin has no supply cap either, and it is currently inflating at around 5% per year. So of the three, we should expect inflationary tokenomics to erode the value of Doge more than Bitcoin or Ethereum.
The last thing you want to consider with supply is allocation. Do a few investors hold a ton of the tokens which are going to be unlocked soon? Did the protocol give most of its tokens to the community? How fair does the distribution seem? If a bunch of investors have 25% of the supply and those tokens will unlock in a month, you might hesitate before buying in.
I was going through the Ethereum White Paper and it was mentioned that the scripting language implemented in bitcoin blockchain has a limitation of value-blindness and Blockchain-blindness (point 2 and 4 in the paper). I am finding it hard to comprehend what this means. It would be great if someone could help understand this with an example.
Value Blindness:
There is no way for a UTXO script to provide
fine-grained control over the amount that can be withdrawn. For
example, one powerful use case of an oracle contract would be a
hedging contract, where A and B put in $1000 worth of BTC and after 30
days the script sends $1,000 worth of BTC to A and the rest to B. This
would require an oracle to determine the value of 1 BTC in USD[Note
3], but even then it is a massive improvement in terms of trust and
infrastructure requirement over the fully centralized solutions that
are available now. However, because UTXO are all-or-nothing, the only
way to achieve this is through the very inefficient hack of having
many UTXO of varying denominations (eg. one UTXO of 2k for every k up
to 30) and having O pick which UTXO to send to A and which to B.
Blockchain-blindness
UTXO are blind to certain blockchain data such as the nonce and
previous block hash. This severely limits applications in gambling,
and several other categories, by depriving the scripting language of a
potentially valuable source of randomness.
I am fairly new to the bitcoin and blockchain technology and have recently started reading about it. So my understanding and the question bellow may not be very accurate.
As I have understood so far, proof of work is the basic building block for a bitcoin block chain and because of it, an attacker will have to produce more than 50% of the total compute power (i.e control more than 50% of the nodes)
in order to manipulate the block chain by being able to produce longest block chain consistently.
Now bitcoin guys were bit lucky as they were the first and nobody paid attention in there early days. Once bitcoin gathered momentum, number of honest nodes become predominant and system became inherently secure.
But now, how someone can start a new public blockchain (for completely different application) safely ? Because, if a new blockchain is floated with few mining nodes,
any attacker can come with more compute nodes and hijack the blockchain as there are small number of honest nodes.
it depends on what you want to do. There are many implementations of Blockchain, each of them has its objective. Bitcoin was the first implementation of Blockchain. Bitcoin is a cryptocurrency and like Bitcoin, there have been developed many other cryptocurrencies.
However, the Blockchain technology would be useful to many things: for example, to control the vote in a distributed way in the elections. Because of that, there are many implementations of Blockchains.
Hyperledger Fabric is a private Blockchain, where the acces to it must be controled
Ethereum is a public Blockchian to transfer assets. Anyone could create his tokens and start using them through the Ethereum network. So, you will use an existing Chain and attackers couldn't hijack you. I think that this would be a great start. If I were you, I'd continue reading this.
To avoid the attack you are describing (51% attack), where existing miners hijack a new network there are a couple ways to avoid this.
Merge Mining
The smaller chain includes block data in the larger chain (e.g. Bitcoin) so the blocks are mined with the hashpower of the larger network.
Change the hashing algorithm
For Bitcoin, two rounds of SHA256 is the hashing algorithm. Because there is so much mining power, it is possible to get attacked fairly easily because Bitcoin miners can just point their existing miners to the small network long enough to execute an attack, and then switch back. This happened to Bitcoin Gold recently. So, use something other than SHA256 where there is already a lot of hashpower in terms of hardware out there.
I am analyzing several Sentiment Analysis algorithms to classify and prioritize call center calls.
I have been trying to look for this type of data on the web, but found nothing.
Ideally I would like to have several two-way conversations, preferably regarding baking or insurance industry.
The idea is to process this data in order to see if the customer is hangry, and needs a fast reply, or if he hasn't much urgency.
Any help is greatly appreciated.
I'm planning to develop a small J2ME utility for viewing local public transport schedules using a mobile phone. The data part for those is mostly a big bunch of numbers representing the times when the buses arrive or leave.
What I'm trying to figure out is what is the best way to store that data. The representation needs to
be considerably small (because of persistent storage limitations of a mobile phone)
fit into a single file (for the ease of updating the schedule database afterwards over HTTP) fit into a constant number of files, i.e. (routes.dat, times.dat, ..., agencies.dat), and not (schedule_111.dat, schedule_112.dat, ...)
have a random access ability (unserializing the whole data object into memory would be just too much for a mobile phone :))
if there's some library for accessing that data format, a Java implementation should be present
In other words, if you had to squeeze a big part of GTFS-like data into a mobile device, how would you do that?
Google Protocol Buffers seemed like a good candidate for defining data but it didn't have random access.
What would you suggest?
Persistent storage on J2ME is a tricky business; see this related question for more general background: Best practice for storing large amounts of data with J2ME
In my experience, J2ME persistent storage tends to work best/most reliably with many small records rather than a few monolithic ones. Think about how the program is going to want to access the data, then try to store it in those increments in the J2ME persistent store.
I'd generally recommend decoupling your client-server protocol for downloading updates from the on-device storage format. You can change the latter with every code update, but you're pretty much stuck supporting a client-server protocol forever, unless you want to break older clients out in the field.
Finally, I know there are some people on the Transit Developers group who have built offline transit apps in J2ME, so it's worth asking for tips there.
I made app like this and I used xml-s generated with php. This enabled us to have a single provider for 3 presentation layers which were:
j2me app
website for mobile phones
usual website
We used xslt to convert xml to html on websites and kXML - very light pull parser to do it on j2me app. This worked well even on very old phones with b/w screens and small amounts of memory.
Besides on j2me there is no concept of file. You have the db in which you can store information.
This is a link to "mobile" website.
http://mobi.krakow.pl/rozklady/
and here to the app:
http://www.mobi.krakow.pl/rozklady/j2me/rjk.jar
This is in polish, but I think it's not hard to figure out what's this and that.
If you want, I can provide you with more help and advice or if this is a commercial product then I think we can figure out something too ;)
I think your issue is requirement 2.
Updating 10MB of data just because 4 digits changed somewhere in the middle of the file seems highly inefficient.
Spliting the data into several files allows for a better update granularity that will be well worth the added code complexity.
Real-time public transport schedules are usually modified one bus/train/tram line at a time.