Published on: 2014-03-12T16:57:28+00:00
In an email exchange on March 12, 2014, Bitcoin core developers Mike Hearn and Jeff Garzik raised concerns about the handling of partially signed and multisig transactions within bitcoind. They discussed how the raw transaction API does not adjust fees if the signature pushes the transaction to a higher fee level, which could cause issues for app developers relying on this functionality. They also mentioned a proposed raw transaction API call by developer sipa that would automatically calculate fees and other details.The conversation highlighted the need for careful documentation of this aspect of the raw transaction API and suggested that the raw transaction API and Bitcoin Core wallet should not be used to hold customer funds. It was emphasized that SPV is not secure enough for businesses unless they run their own full node, and users should consider using Bitcoinj or something else instead of the raw transaction API.To avoid problems with fees, it was suggested that developers may need to implement a fee loop in their own apps, where they create a transaction with an estimated fee level, add signatures, and submit. If the transaction is rejected for low fees, they would need to increment and try again until successful.The discussion also covered the calculation of transaction size for partially signed transactions and the use of placeholders in transaction scripts to avoid miscalculating the fee based on the final size.CoinVault's use of a partially signed transaction format was mentioned, and it was suggested to use placeholders in the transaction scripts as bitcoinj does to avoid miscalculating the fee based on the final size.The importance of planning and specifying the user experience for fully interoperable "multisig" implementations was highlighted. It was suggested to design the UI in terms of people with social network integration and to avoid exposing end users to the concept of a key for a "group account for an organization".Different companies and developers were mentioned in relation to their plans and implementations regarding HD wallets and multisig transactions. Armory plans to introduce a wallet "bundle" that includes all wallets protected by the same backup, while Jean-Pierre Rupp is working on using BIP-0032 HD wallets for his multisig system. The haskoin-wallet supports regular and multisig accounts and uses synced trees rooted at the extended pubkeys of participants.The discussion also touched on the practicality of implementing a wallet that uses stealth addresses for change and the ongoing work towards the adoption of HD wallets in the Bitcoin community. Many popular end user wallets are expected to support HD wallets soon.The release of bip32 features in Electrum was postponed due to ongoing discussions with Trezor and bitcoinj developers. MultiBit plans to release HD code within two months, and Hive and Haskoin are also committed to HD. However, it was noted that building anything on top of HD is premature until major user wallets and bitcoind have basic support.The context argues that the current state of HD in Bitcoin is overhyped without any code to back it up. It suggests that it is premature to build anything on top of HD until major user wallets and bitcoind have basic support. The Waiting For Godot situation is mentioned, including examples of Bitcoin Wallet failing to rotate addresses and a stalled attempt to add a simple RPC.In another email exchange, Gavin Andresen and Jeff Garzik discuss the assumption of HD wallets in multisig transactions. They disagree on assuming HD capability, with Garzik stating that current multisig wallets don't match this assumption and there is a lack of infrastructure for HD. However, Andresen suggests that if a remote party is involved in a multisig and speaks the necessary protocols, it is reasonable to assume they are HD-capable. The conversation emphasizes the need to do multisig correctly from the beginning and discusses the challenges and potential benefits of using HD wallets.Another email exchange between Garzik and Drak explores the idea of assuming each party in a transaction uses HD wallets. Drak supports this idea as it simplifies things, but Garzik points out that it assumes a different reality from the current one. They agree that transitioning to multisig wallets requires careful consideration and proper protocols.The discussion also covers the establishment of multisig wallets, gathering signatures for multisig spends, and leaving a multisig wallet. It is suggested that BIP32 HD public keys should be used to ensure privacy from the beginning of establishing multisig wallets. Different protocols may be needed for multi-person shared wallets, escrows, and "wallet protection service" wallets. The gathering of signatures could utilize the PaymentRequest message and a partially-signed Payment message. There may also be a need for a protocol to leave a multisig wallet.The feasibility of using BIP10 for multisig and coinjoin is discussed, with Alan Reiner expressing his opinion on the deficiencies of BIP10 and suggesting building something new that is flexible and extensible. Gavin Andresen shares his experience with standardization and suggests that multisig wallets are still in the early stages of development.
Updated on: 2023-08-01T07:54:17.445173+00:00