Published on: 2013-07-18T16:09:54+00:00
In an email exchange on July 18, 2013, Peter Todd suggests using the OP_DEPTH instruction to eliminate the risk of funds getting stuck in limbo. This opcode returns the current depth of the script's execution stack and can validate certain operations. However, Jeff Garzik raises concerns about scripts no longer being stateless due to the introduction of OP_DEPTH.Jeremy Spilman proposes a negotiation between the user and Arbitration Provider (AP) to determine escrow amounts, fee payments, and the duration of funds being tied if the AP doesn't close the channel. The implementation of OP_DEPTH can be done as part of a script v2 using the soft-fork mechanism outlined by Peter Todd. It is also suggested that MAST support should be implemented at the same time.A member on the Bitcoin-development mailing list commends Jeremy and Peter for creating a design that does not rely on replacement to work. This approach is seen as a solution to scalability issues without compromising security. However, Jeremy points out that the proposal could still have malleability weaknesses, where a miner changing the TxID of TX1 could invalidate the user's refund.The proposed sequence for Bitcoin channels involves multiple steps, such as creating unsigned transactions, negotiating escrow amounts, and setting lock times. The alternative to transaction replacement is having a trusted third party close the channel based on the latest transaction sent by the user. Concerns are raised about attackers and the need for mutual defense actions.Gavin Andresen suggests weakening the non-standard test to allow a window of time before transactions are deemed untrustworthy. He also mentions other technical issues that need to be addressed, such as implementing a memory-limited pool and child-pays-for-parent fees.Discussions about denial-of-service (DoS) attacks include proposals to incorporate bandwidth into contracts and implement fidelity bonds for security guarantees. The processing speed of ECDSA on modern cores and the possibility of double-spending in Bitcoin are also mentioned.In another email exchange, Peter Todd discusses the limitations and potential issues with transaction replacement on the Bitcoin network. Mike Hearn suggests ways to mitigate DoS attacks related to transaction replacement, such as limiting the number of chances for each input to do a replacement. The importance of protecting against DoS attacks without sacrificing features is debated.John Dillon questions Gavin Andresen's stance on Bitcoin security, while others defend his efforts to resist DoS attacks and improve testing and payment protocol implementation. The concept of high-frequency trading using transaction replacement is discussed, along with proposals to mitigate associated risks.Mike Hearn proposes a way to mitigate the risks of transaction replacement, suggesting that handling DoS as a prioritization problem and allowing someone to force CPU/bandwidth usage without disrupting normal transactions.The discussion on re-activating the replacement feature on Bitcoin's main network includes suggestions for developers to utilize and build apps demonstrating its usefulness and developing prototypes before re-activation.
Updated on: 2023-08-01T04:40:35.555673+00:00