Code Review: The Consensus Critical Parts of Segwit by Peter Todd [combined summary]



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

Published on: 2016-07-04T23:27:15+00:00


Summary:

In a discussion about the implementation of Segregated Witness (SegWit) on the Bitcoin network, one issue raised is the odd result that occurs when a transaction spends a witness output with an unknown version. Surprisingly, this transaction is valid even if it doesn't have any witnesses. One suggestion is to leave these unknown witness programs as any-one-can-spend without looking at the witness. However, this creates a special case in the code, allowing spending of a witness output without a witness.There is a debate about whether to allow the use of 160-bit commitments for multisig transactions, which may require 256-bit security. The argument is that using shorter hash and pubkey for storing a small amount of Bitcoin could save bytes. However, concerns are raised about potential hash collisions and the reuse of signatures for different signature hashes. To address this, tagged hashing is proposed as a way to ensure that signatures cannot be reused in different contexts. XORing the magic tag prior to its use is suggested as sufficient for signature applications.Unfortunately, this method is not compatible with timestamping schemes like OpenTimestamps, which rely on all operations being cryptographically secure. Another concern is the difficulty of adding new commitments with soft forks. It is pointed out that anything after 38 bytes in the reserve value of a 32-byte hash has no consensus meaning, making it inefficient to add new commitments with softforks.In an email exchange between Johnson Lau and Bitcoin developer Peter Todd, various issues related to SegWit implementation are discussed. They discuss the possibility of allowing users to choose a less secure 160-bit commitment if their use-case doesn't require the full 256-bit security level. Additionally, the maximum size of serialized witness scripts is debated, with the constraint being set at 520 bytes. Lastly, there is a mention of concern about hash collision, although it is unclear how it could be possible.Overall, the discussion revolves around the complexities and potential vulnerabilities of implementing Segregated Witness on the Bitcoin network, with various suggestions and concerns being raised by different participants. The goal is to find solutions that ensure the security and efficiency of transactions while avoiding any potential issues or conflicts.


Updated on: 2023-08-01T18:44:26.625038+00:00