Discussion related to pull 349 and pull 319 (escrow transactions) [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2011-08-08T00:21:48+00:00


Summary:

In an email exchange, Bobby Groff discusses the possibility of mining non-standard transactions in under an hour with 30%+ mining power. He acknowledges that propagation is a factor to consider and mentions that the IsStandard part of the patch is uncontroversial and can be implemented quickly. However, the focus on maturity/bugfixes may delay the full patch. Groff expresses hope that building secure deposit systems will improve trust in the ecosystem and assures that he has included a significant amount of unit tests and can add more if needed.On August 3, 2011, an email thread began discussing the implementation of IsStandard transactions. The idea was that if Eligius mining and other pools were open to the concept, over 30% of mining power could be upgraded to allow for these transactions to be mined in under an hour. However, the discussion also highlighted the importance of propagation and the vulnerability of non-standard transactions to double spending by standard transactions. It was suggested to split the pull request 319 into two separate requests: one for the IsStandard change and another for adding the full escrow feature set. This approach would ensure that when the escrow patch is added to the mainline client, the network would be capable of handling its transactions. There seemed to be no reason to block on the other pull.Bitcoin developer Gregory Maxwell has created a multiple signature escrowed transaction system that he believes should be added to the client soon. However, more testing and discussion are needed before implementation. One challenge with adding this feature is that it requires a new transaction type, which cannot be deployed until an updated isStandard is widely used in the network. Maxwell also identifies an issue with multisig validation due to redundancy in script length coding opcodes. This redundancy allows scripts to be coded in multiple ways, but the signature validation code does not always match the original coding, causing validation failures. Pull request 349 on the Bitcoin Github repository implements a new feature for multiple signature escrowed transactions. It has been tested on a private network and works well but requires additional testing and discussion before being added to the client.To address the challenge of the new transaction type, the author suggests separating out the IsStandard part of the patch and releasing it in version 0.4. However, this implementation exposes an issue with multisig validation caused by redundancy in script length coding opcodes. The pull request contains a candidate fix for this issue by excluding the length opcodes from comparison. However, this fix carries a risk of creating differences in how nodes validate transactions, potentially leading to lasting forks. An alternative solution would be to define that OP_PUSHDATA* cannot be used to push smaller lengths that could be more efficiently encoded with direct length opcodes. This solution would align with current behavior and carry no severe split risk. Alternatively, modifying the templating code to ensure it codes the template in the same way as the original would be beneficial if similar issues exist for other elements besides length coding.


Updated on: 2023-08-01T02:09:25.657038+00:00