Published on: 2011-08-18T17:36:05+00:00
The discussion revolves around the concern of waiting less than six blocks before leaving unconfirmed status in Bitcoin transactions. Some individuals consider three blocks to be sufficient for confirmation, while others propose implementing a placeholder or trust rating system to address the issue. The idea of a semi-trusted "bitcoin backbone" where miners connect with each other is also discussed as a potential solution.One potential attack on the Bitcoin network that is mentioned involves a double-spend transaction. The attacker sends conflicting transactions to different nodes simultaneously, making it challenging for nodes to identify and reject the double-spend. To counteract this attack, it is suggested that nodes should relay new transactions received via blocks normally to increase awareness and prevent the acceptance of double-spending transactions.Another attack pattern described involves an attacker running multiple sybil nodes to create network partitions and exploit mining power. By creating conflicting transactions and isolating certain partitions, the attacker can withdraw funds from MoronBank without requiring any hash power. The author suggests that adding manually configured peerings could mitigate this attack and encourages major miners to participate.The context also presents a proposal to modify the reporting of confirmations during a chain split. It suggests subtracting one from each confirmation reported if a majority of peers relayed a block that split the chain. To avoid breaking existing code, the author proposes adding a floating-point 'confidence' measure alongside the integer confirmation value to gauge reliability based on factors like trusted peers, confirmations, and blockchain forks.Concerns are raised about receiving blocks with transactions that have not been broadcasted to the network, which can happen legitimately for new users. Additionally, the question of reporting the number of confirmations differently during a chain split is discussed as a potential safety enhancement.An email conversation between Gavin Andresen and Joel highlights lessons learned from a recent Bitcoin attack. These include not accepting 1-confirmation transactions, being well-connected, not trusting information from a single peer, and watching out for peers attempting to deceive.Lastly, a variation of the 'Finney attack' is mentioned, where an attacker establishes a direct connection with a target by observing which nodes are earliest to broadcast transactions. The attacker then creates a transaction and adds it to a block they are mining. Once another block is mined, the attacker broadcasts their block to the target, potentially leading to a fork in the blockchain. The lessons from this attack emphasize not accepting 1-confirmation transactions, being well-connected, and not relying solely on information from one peer.
Updated on: 2023-08-01T02:16:35.915412+00:00