Baby bottle washer liquid for car
47 comments
Buy liquid silicone
It has been a few weeks since we published the Bitcoin-NG whitepaper , and we have received quite a bit of feedback from the community. In this technical post, we want to review some of the insights that people offered, go over some overlooked advantages of Bitcoin-NG, and address some of the concerns that were raised. We skip all background, which is briefly described in our previous post and detailed in our working paper.
There are some distinct benefits to Bitcoin-NG compared to Bitcoin, besides higher throughput and lower latency. Resilience to natural mining power fluctuations: The rate at which Bitcoin commits transactions to its blockchain can vary drastically over time, depending on the mining power in the system.
Fluctuations in mining power occur due to fluctuations in difficulty and exchange rate. In contrast in Bitcoin-NG, the last leader can continue to generate microblocks at the same rate. The system also maintains average fairness. Only the frequency of leader choice fluctuates, just as in Bitcoin, but without consequences to the overall throughput of the system. Healthier incentives for propagating transactions: Our colleagues have noted that there are no strong incentives for the regular Bitcoin network to propagate transactions.
The current network works mostly as a result of altruistic participants. In contrast, a miner in Bitcoin-NG will earn more on a transaction if it generates the block after it, therefore it has more incentive to publish it for others to place in the chain.
While this is not an absolute solution to all incentivization problems noted by our colleagues Babaioff et al. We discuss the concerns that were raised in various forums, including the wizards IRC channel. Overall, the concerns that were raised apply equally to regular Bitcoin itself or stem from misunderstandings. In all cases, Bitcoin-NG provides stronger guarantees than regular Bitcoin.
It has been noted that, in Bitcoin-NG, a user can deviate from the prescribed fee distribution plan. This concern amounts to saying "I can pay someone on the side. In general in distributed system design, we care about behaviors by a user that can lead to problems for the system or for other users. If a Byzantine actor can do something that has bad consequences for that particular Byzantine actor or for his cronies, that is a good thing.
It means the right people got punished. For a behavior to rise to the level of a real concern, that behavior would have to affect others. And this particular behavior points to a case where NG is doing the right thing. Side markets can form around any system, including Bitcoin Core. For instance, a Bitcoin Core user can pay miners today to get his low-priority transaction mined earlier.
Further, Bitcoin Core miners can deviate from the prescribed protocol at their own loss at any time for any reason or for no reason at all -- e. Not only is this particular deviation benign and uninteresting to note, but it would come at a loss of incentive for the subsequent miner to build on the affected microblock which would carry less in transaction fees and therefore hurt both the user and the miner who engaged in it. This self-limiting behavior does not lead to a gain on the part of the "attacker," does not lead to a loss for anyone, and does not constitute a successful attack.
Hal Finney noted early on that an attacker can defraud a Bitcoin merchant who accepts 0-confirmation transactions. To do this, the attacker sends a payment transaction to the merchant, who accepts it and delivers the goods. Unbeknownst to the merchant, the attacker, perhaps in cahoots with a miner, issues a second transaction that spends the same cash, thus depriving the optimistic merchant who accepted the 0-conf transaction of the payment.
In Bitcoin Core, replace-by-fee can make this worse, as it allows the attacker to pay the miner a higher fee to include his transaction. Bitcoin-NG offers much better protection against the Finney attack. Recall that 0-confirmation transactions in Bitcoin are totally insecure, but many merchants feel compelled to take them to support instance service and shoulder the risk of a Finney attack. Since Bitcoin Core spends much of its time in an idle state in between blocks, for 10 minutes at a time on average, not accepting a 0-conf might mean loss of business.
In Bitcoin-NG, however, there exists a much better mechanism for supporting instant transactions. An NG merchant never deals with 0-conf transactions, never cares about unconfirmed transactions, and places no weight on mempool contents. Instead, NG merchants wait until transactions are issued in a microblock, plus the network propagation delay. At that point, the transaction has been vetted by the current miner and seen by subsequent miners.
As in Bitcoin, the protocol may still revert as the blockchain reorganizes, but the chances of this happening drop exponentially with increasing numbers of confirmations. Anyone selling high value items, who would have waited for 6 confirmations in Bitcoin, should still wait for 6 confirmations under Bitcoin-NG. But an NG microblock offers strictly stronger guarantees than a 0-confirmation in Bitcoin.
Recall that Bitcoin-NG captures transactions in microblocks, which are issued in rapid succession by a leader. A malicious leader can issue microblocks intended to deceive the merchants, by first pretending to pay the merchant, but secretly building a second, alternative chain of microblocks on the side, and making this chain available to a colluding, subsequent miner.
This colluding miner then bases his next key block on the alternative chain, causing losses for merchants. This attack is analogous to a malicious miner in Bitcoin who builds a block to fool 1-confirmation merchants, issues the block, fools the merchants, but then issues a competing block rooted at the same height as the original block.
Such a miner would lose his original Bitcoin block, its reward and its fees. Similarly, a miner engaging in a microblock fork in Bitcoin-NG will lose his block reward and fees. Merchants in Bitcoin-NG selling high-value items should wait for 6 or more confirmations, just as they do in Bitcoin, for the reasons described in Satoshi's white paper. Merchants selling very large numbers of low-value items should cap the sum total risk they face by waiting for additional confirmations when the amount outstanding is over their risk tolerance.
Overall, the end of the blockchain is indeed subject to reorganization in both Bitcoin and Bitcoin-NG, and merchants need to follow appropriate risk-management strategies and wait for the right number of confirmations in both systems. As noted by Matt Corallo and Glenn Willen in the Bitcoin-dev list, as well as others, presence in a microblock is not as strong as a first confirmation in face of a motivated double-spending attacker with mining power.
Safe from the poison mechanism, such an attacker can consistently mine directly on the previously key-block, and double-spend transactions in the microblocks it has pruned. The well-provisioned attacker will consistently lose all transaction fees this way, and succeed only at a rate proportional to its size. Therefore, this attack is not a likely threat. However, since it is a theoretical possibility, we are exploring a game-theoretic analysis of this question involving 1-confirmation blocks, starting with modeling of the attacker's incentives.
At the moment, Bitcoin miners can, under some circumstances, have some say over the composition of blocks. Specifically, if a Bitcoin mining pool supports GetBlockTemplate, a miner can determine which transactions go into a block. To be realistic, GetBlockTemplate has seen limited adoption to date, and confers no benefit to cloud miners, where the miner is dependent on the mining pool operator for access to the outside Internet and the transactions available in the mempool.
Nevertheless, because NG separates the process of electing the leader from the process of vetting transactions, miners do not directly control which transactions go into microblocks. It is possible for a mining pool operator to be elected leader and then to pick transactions not favored by its constituent miners. If NG is deployed and this turns out to be a concern, we expect the API between the pool operator and the miners to be expanded such that the miners would direct the pool operator on which transactions to include in microblocks.
To our pleasant surprise, much of the Bitcoin-NG discussion has been positive. This post has discussed the various concerns, illustrated their analogues in Core, and shown that in all cases, NG offers better guarantees than Core. Further, NG offers better resilience to natural mining power fluctuations and healthier incentives for propagating transactions.
The key novelty in NG is that it turns block generation upside down: There are certain occasions in distributed systems where there is something to be gained without having to compromise on something else, and this is one of them -- by turning the block formation process on its head, NG sidesteps the block size and block interval debate entirely, yet achieves better properties than the Bitcoin variants that have been suggested so far.
My Research Interests are distributed systems and algorithms, specifically distributed storage algorithms, the distributed aspects of Bitcoin, and reliable aggregation in distributed sensor networks. Hacker and professor at Cornell, with interests that span distributed systems, OSes and networking. Unshackling Blockchains bitcoin blocksize bitcoin-ng November 09, at Overlooked Benefits There are some distinct benefits to Bitcoin-NG compared to Bitcoin, besides higher throughput and lower latency.