I've watched a lot of Cryptocurrency lectures on how they work and I think I am about 75% of the way of understanding completely how they work. One question has been bothering me though.
When a miner solves a block, he gets a block reward made out of thin air. For Bitcoin this is currently around 12.5 BTC. What dictates this specific amount of money? Is the the locally ran software? If so, can't that be tampered with? Does the miner ask other clients what the current block reward amount is? If so how does it know it's being fed the right updated information?
Same goes for the number of zeroes found on the hash. If a miner finds a hash value like 00000000000000000000000000000000000000000000000000000000010101111110110101010101 he would then check how many zeroes it starts with. Let's say the current solve requires 30 zeroes. Who makes that rule? How is it updated? At what points does it change from 30 -> 31? Who makes that decision to increase or decrease it. What if one computer thinks it's 29 and not 30. What stops people from gaming the system?
Same with block sizes. What stops miners from sending blocks with increased maximum sizes? Would clients reject the block if they don't match a certain size? If so, how do they know what are the maximum amount of transactions? Who told them?
A single miner can tamper with a block as much as they want, changing block award or difficulty or double-spending, but such a block will not be accepted by the rest of the network.
Bitcoin network needs a consensus to accept a specific block. As long as more than half of the nodes of the network are "good" ones, the tampered block will be rejected.
This functionality is implemented by Bitcoin P2P protocol.
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 just read that the Bitcoin nonce is 4-bytes, meaning there are ~4 billion possibilities for the nonce.
Is there a scenario in Bitcoin where given all the nonces, you can't produce a hash/solution for the cryptographic puzzle where you need a value that begins with the necessary # of zeros?
In other words, if you need 11 beginning zeros to solve the puzzle, perhaps no nonce will yield this.
If this case existed, my presumption is you'd need to select different transactions for the block you're mining given that these are selected by the miner.
It'd be great to get some clarity on this as I haven't seen it addressed anywhere.
Not only is this possible, it happens all the time.
So, here's how it works: when a golden nonce isn't found during mining -- when all possibilities are brute forced -- the date of the block is updated to a new time and the mining process starts anew.
Changing the date/time of the block changes the hashing algorithm solution so the miner has to brute force all of the nonces (a 32 bit value) again using the new date/time.
So, I’m studying Paxos and the Professor made this question:
Assume that acceptors do not change their vote. In other words, if they vote for value v in round i, they will not send learn messages with value different from v in larger rounds. Show that Paxos does not work any more (it can reach a livelock).
I’ve reasoned about this for the entire day, but I’m not understanding how can the livelock arises and so my colleagues.
Does anyone have a clue?
Assume there were network failures such that every acceptor accepted a different value. Without the ability to change their value in future rounds, no progress could ever be made and you have a "livelock".
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 have been reading a lot of the posts on here and surfing the web, but maybe I am not asking the right question. I know that Redis is currently Master/slave until Cluster becomes available. However, I was wondering if someone can tell me how I would want to configure Redis logistically to meet my needs (or if its not the right tool).
Scenerio:
we have 2 sites on opposite ends of the US. We want clients to be able to write at each site at a high volume. We then want each client to be able to perform reads at their site as well. However we want the data to be available from a write at the sister site in < 50ms. Given that we have plenty of bandwidth. Is there a way to configure redis to meet our needs? our writes maximum size would be on the order of 5k usually much less. The main point is how can i have2 masters that are syncing to one another even if it is not supported by default.
The catch with Tom's answer is that you are not running any sort of cluster, you are just writing to two servers. This is a problem if you want to ensure consistency between them. Consider what happens when your client fails a write to the remote server. Do you undo the write to local? What happens to the application when you can't write to the remote server? What happens when you can't read from the local?
The second catch is the fundamental physics issue Joshua raises. For a round trip you are talking a theoretical minimum of 38ms leaving a theoretical maximum processing time on both ends (of three systems) of 12ms. I'd say that expectation is a bit too much and bandwidth has nothing to do with latency in this case. You could have a 10GB pipe and those timings are still extant. That said, transferring 5k across the continent in 12ms is asking a lot as well. Are you sure you've got the connection capacity to transfer 5k of data in 50ms, let alone 12? I've been on private no-utilization circuits across the continent and seen ping times exceeding 50ms - and ping isn't transferring 5k of data.
How will you keep the two unrelated servers in-sync? If you truly need sub-50ms latency across the continent, the above theoretical best-case means you have 12ms to run synchronization algorithms. Even one query to check the data on the other server means you are outside the 50ms window. If the data is out of sync, how will you fix it? Given the above timings, I don't see how it is possible to synchronize in under 50ms.
I would recommend revisiting the fundamental design requirements. Specifically, why this requirement? Latency requirements of 50ms round trip across the continent are usually the sign of marketing or lack of attention to detail. I'd wager that if you analyze the requirements you'll find that this 50ms window is excessive and unnecessary. If it isn't, and data synchronization is actually important (likely), than someone will need to determine if the significant extra effort to write synchronization code is worth it or even possible to keep within the 50ms window. Cross-continent sub-50ms latency data sync is not a simple issue.
If you have no need for synchronization, why not simply run one server? You could use a slave on the other side of the continent for recovery-only purposes. Of course, that still means that best-case you have 12ms to get the data over there and back. I would not count on
50ms round trip operations+latency+5k/10k data transfer across the continent.
It's about 19ms at the speed of light to cross the US. <50ms is going to be hard to achieve.
http://www.wolframalpha.com/input/?i=new+york+to+los+angeles
This is probably best handled as part of your client - just have the client write to both nodes. Writes generally don't need to be synchronous, so sending the extra command shouldn't affect the performance you get from having a local node.