Published on: 2013-12-18T06:03:53+00:00
In a discussion on the Bitcoin mailing list, Troy Benjegerdes sought feedback on merging different forks using distributed version control systems. However, Gregory Maxwell pointed out that Bitcoin already automatically merges forks by pulling in novel non-conflicting transactions contained in the fork and including them in the next blocks.The conversation then turned to the hard upper limit for the number of coins in Bitcoin, which raises issues for miners who try to support an islanded network. A potential solution is using freicoin-like demurrage, which would impact new coinbase based on the percentage of hashing power on the other side of the fork. This proposal is complex and not as secure or reliable as initially imagined.Troy Benjegerdes discusses the concept of merging two different forks in cryptocurrency, similar to how it is done in distributed version control systems. He poses a hypothetical scenario where he and his friends are "islanded" from the rest of the internet for a week but still want to trade Bitcoin. In this scenario, a miner would look at the forked blockchain and include both chains if no double-spends were detected. However, if there is a merge conflict due to a buggy client or a transaction resulting in a double-spend before disconnect, then a MERGE request with a transaction fee sufficient to cover reconciling the double-spends would be broadcasted to incentivize miners to do extra work to merge.Luke expresses concern about the incentives of this proposal, stating that it may give miners reasons to avoid including transactions and people reason to double-spend. Additionally, the email does not address how to deal with the subsidy - whether both miners get it or not.The Bitcoin community is discussing whether a “merge” block is necessary for trading transactions offline. Transactions can be traded offline as long as there are no secretly double-spending coins that are sent to the Blockchain. When the connection to the Bitcoin network is re-established, transactions are transmitted, while any transactions that derive from the double-spent one become invalid. If any merge conflict arises, it would require human interaction, and bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, and incentivize a miner to do some extra work to merge. There is no need for a "merge" block, as transactions can be traded offline and then transmitted when the connection to the Bitcoin network is restored.In an email thread from 2013, Troy Benjegerdes expressed his interest in receiving feedback on distributed version control systems. He specifically mentioned the usefulness of being able to merge two different forks. However, it was noted that the system already automatically merges forks by pulling in all novel non-conflicting transactions and including them in the next blocks. The context does not provide any further information on this automatic process or the specific version control system being referred to.The author seeks feedback on the equivalent of merging forks in distributed version control systems for Bitcoin or other cryptocurrencies. They pose a scenario where they are 'islanded' from the internet but still want to trade Bitcoin, and suggest that local miners could facilitate this until reconnected. The author further explains the concept of Merge transactions, wherein a miner looks at a forked blockchain and includes both chains if no double-spends exist. However, in case of a buggy client or a double-spend transaction, a merge conflict arises, requiring human intervention. To address this issue, the author suggests broadcasting a MERGE request with a transaction fee sufficient to cover reconciling the double-spends and incentivizing a miner to do extra work to merge.
Updated on: 2023-08-01T06:52:15.215473+00:00