Author: shiva sitamraju 2017-09-12 12:06:40
Published on: 2017-09-12T12:06:40+00:00
The Bitcoin-dev mailing list had two discussions recently. The first involved Johnson Lau and Mark Friedenbach discussing Merkle branch verification and tail-call semantics for generalized MAST. Johnson expressed concerns about the design as it requires "unclean stake," which is invalid in BIP141. They also discussed SigOp counting, which was lost due to the script's execution. Mark suggested having a unified global limit that combines all factors, including sigops and hashed bytes. In the second discussion, Thomas Voegtlin proposed an extended serialization format for BIP-32 wallets. Shiva Sitamraju expressed concern over privacy implications of the birth-date field and the complete derivation path. Thomas replied that the different versions do not have the same address as per bip173. The debate on the issue included whether the OutputType field should be present only if depth==0x00 or at all times. Andreas Schildbach, Pavol Rusnak, and Thomas Voegtlin weighed in on the issue.Another discussion focused on Mark Friedenbach's proposal to update the fast Merkle-tree spec to use a different IV. This would prevent attacks where innocent scripts could be replaced by malicious ones before funds are sent to the MAST. The attack requires a collision between double-SHA256(innocuous) and fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || r1) || r0), where innocuous is a Bitcoin Script that is between 32 and 55 bytes long. Finally, there was talk about whether to add an extended serialization format for BIP-32 wallets. Some suggest adding an OutputType field for wallets that do not follow BIP43, while others suggest omitting the field in cases where script types are mixed. Thomas Voegtlin suggested that this value should be user visible, as users need to combine several master public keys when creating wallets with multisig scripts and all master keys should be of the same type. It was also noted that good security for Bitcoin is not defined by constant upgrading, and efforts should be put into backporting fixes/workarounds. Altcoin maintainers are encouraged to contribute back to their upstream to help keep up with security fixes. Sergio Demian Lerner mentioned the policy of publishing vulnerabilities in Bitcoin only after more than 80% of the nodes have upgraded. Critical vulnerabilities will be patched immediately without disclosing the actual problem, and non-critical ones may require a wait of years before publication.
Updated on: 2023-06-12T18:36:39.578342+00:00