Published on: 2019-09-18T21:21:56+00:00
Pieter Wuille, a Bitcoin developer, has expressed his preference for not allowing P2SH wrapped Taproot in a bitcoin-dev discussion. The reason behind this is that Taproot's main benefit is better privacy and homogeneity, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses could increase the number of places where a user may be characterized and identified. Although Segwit was designed to support both, disallowing P2SH would require slightly more complex validation code. Wuille believes that keeping P2SH support would increase the number of combinations software needs to test, which may not be necessary given the progress made in bech32 adoption.The Bitcoin community is currently discussing the implementation of Taproot, a soft fork proposal that aims to improve privacy and homogeneity by making all outputs and cooperative spends indistinguishable from each other. The proposal includes various ideas such as using Merkle branches to hide unexecuted branches in scripts, enabling key aggregation/thresholds within one input through Schnorr signatures, and improving the signature hashing algorithm. Preliminary construction and signing tests have been done in the Python framework, and an initial reference implementation of the consensus changes can be found on Github.Some members of the community prefer not to support P2SH-nested Taproot, as most services now support sending to native SegWit addresses, which would increase the number of places that a user may be characterized and potentially identified.In another discussion, Elichai Turkel proposed adding to John Newbery's proposal of using implicit even/odd only public keys and tweaked public keys in taproot. Pieter Wuille pointed out the need for a bit in the control block to convey whether a negation was necessary to make certain values even, even if the public keys have implied-even Y coordinates. Wuille suggested moving this bit to be the first OP_CODE of the tapscript itself to simplify the structure and separate the tapscript+leaf version from the control block. This suggestion was supported by other participants in the discussion.There is also a conversation about P2P rules and the Unserialize code, specifically in compat/assumptions.h, serialize.h, and other Unserialize_impl implementations. The discussion highlights that the encoding being discussed is unsupported/invalid rather than equivalent/non-canonical. There is mention of MAX_SIZE, which is approximately 33.5M, and how ReadCompactSize throws "size too large" if the return value exceeds this limit. The individual who made the initial comment acknowledges missing the MAX_SIZE value during their review of the code.A proposal has been made to expand the input_index of the transaction digest for taproot signatures from 2 bytes to 4 bytes, which would better support proof-of-reserves via taproot signatures. This change would also allow more UTXOs to be included in the proof tx and signed with a signature that commits to all inputs, including the invalid placeholder. Another proposal suggests increasing the 'input_index' of the transaction digest to handle larger transaction sizes. It is considered a mistake to mix limits from the block layer into the transaction layer of consensus rules. The var-integer field for the number of inputs and outputs in a transaction may look like it should allow up to 2^64-1 inputs, but due to P2P rules, these values are immediately taken modulo 2^32 after decoding.Russell O'Connor proposed changing the specification of Tapscript to require an empty stack upon completion instead of containing a single non-false value. This change would remove a potential malleability vector and simplify development. Pieter Wuille commented on the potential benefits and suggested requiring the last element of the stack to be 0x01 to align with MINIMAL_IF semantics. However, it was ultimately decided that the proposed changes were not necessary and would cause more confusion than benefit.Overall, the Taproot proposal aims to improve privacy and homogeneity in Bitcoin transactions by making outputs and cooperative spends indistinguishable and hiding unexecuted branches in scripts. The proposal includes various ideas such as key aggregation/thresholds, improved signature hashing algorithm, and extensibility through leaf versions. Different discussions are taking place regarding P2SH-nested Taproot, P2P rules, transaction digest for taproot signatures, and Tapscript specification.A proposed Taproot softfork, introduced by Bitcoin developer Pieter Wuille, includes various ideas to enhance the functionality and privacy of Bitcoin transactions. The BIP drafts outline transaction input spending rules, changes to Script inside spends, and a Schnorr signature proposal. The reference implementation of the consensus changes can be found on GitHub.One aspect of the discussion involves the use of unknown discrete logarithms to ensure better privacy. By blinding a known constant with a random value, an internal key can be created that provably remains unknown.
Updated on: 2023-08-02T00:47:13.477592+00:00