Published on: 2011-11-12T17:38:06+00:00
The context revolves around dispute mediation and the development of a dispute mediation protocol. The author suggests using a toy protocol and UI design for testing purposes to identify the necessary steps and their order in the protocol. Feedback is provided on the format being used, questioning if it represents a subset of the regular bitcoin transaction format and suggesting the serialization of a Bitcoin CTransaction structure with the txins containing the output scripts.There is a discussion on Bitcoin Improvement Proposals (BIPs) and their types, namely "standards track," "informational," and "process." It is argued that a credible standards track BIP cannot be created without an end-to-end implementation. Designing technical decisions in isolation could lead to undesirable user experiences. A working implementation provides confidence in the code's functionality. Informational BIPs are deemed less useful as they only summarize the author's views. It is suggested that design discussions should take place on the mailing list instead of creating informational BIPs.Alan Reiner published BIP 0010 to encourage collaboration and improve it. However, adoption by others has been limited. Mike Hearn advises against creating BIPs without actual implementations and suggests discussing designs on the mailing list. He also shares thoughts on escrow transactions and proposes revisiting the topic once he can perform a mediated transaction.The purpose of BIP 0010 is to create a standard for multi-signature transactions. The proposal offers a solution before developers start asking questions about it. The inclusion of txout scripts in txin scripts is critical for adoption, as it works for lightweight clients and enables offline wallets/signing when transporting a large blockchain is not feasible. JSON is suggested for dynamic information with optional fields, while the core benefit follows PGP messages: compact and easy-to-identify blocks of text. BIP 0010 is seen as optimal as a building block for higher-level protocols, and ideas for competing ideas can be added to it.The creation of a separate peer-to-peer (p2p) network for off-band information is suggested instead of involving the blockchain. Including arbitrary content in the scriptSig of a Bitcoin transaction raises concerns, as miners and nodes may remove the extra information, resulting in unreliable communication. Another protocol is recommended for gathering signatures.Gavin Andresen suggests using the P2P network to distribute signatures and discusses the idea of broadcasting complete transactions with extra signatures. This could be done through an escrow transaction, and parties involved can monitor the blockchain for proposed spend transactions. Concerns about spamming bogus transactions and the importance of knowing each other's public keys upfront are raised.There is a discussion on the validity of "half" transactions and introducing constraints to avoid incomplete transactions. Gavin Andresen argues against allowing partially-signed transactions on the main Bitcoin P2P network due to the potential for spamming. Formats and protocols for gathering signatures are mentioned as part of future development, with Alan's BIP10 being considered the next piece of the puzzle.Gavin Andresen discusses the issues with partially-signed transactions, stating that a transaction with only one signature cannot be relayed across the network until it has enough signatures. He suggests that these transactions should be sent between clients using another protocol, as they are not valid transactions on their own. Gavin also mentions the need for increasing the byte limit in the standard multi-signature proposal to accommodate 3-signatures transactions.Alan Reiner's BIP 10 is mentioned as the next piece of the puzzle, with formats and protocols for gathering signatures still in the TODO category. There are concerns about partially-signed transactions being on the main Bitcoin P2P network, as there is no way to prevent spamming of bogus partial transactions. Gavin believes that partially-signed transactions should not belong on the main Bitcoin P2P network due to this issue.The discussion on the Bitcoin-development mailing list focuses on enabling super-lightweight clients that only sign transactions without needing the blockchain. Michael Grønager proposes a solution for multisig transactions where client1 issues a transaction with one signature, and client2 adds the second signature before retransmitting it. However, there are concerns about the validity of the first transaction and the lack of information in TxIns to determine input values for dumb tx-signers with no blockchain.Alan Reiner's proposal in BIP 0010 aims to address this issue by providing a standardized http/https RESTful API or HTTP/JSON or protocol buffers and raw sockets for third-party services to host a service for exchanging information. However, there is a minor problem with TxIns not containing the value of TxOuts they are spending, making it difficult for dumb tx-signers to determine the transaction fee or how much money is in each TxIn they are signing.
Updated on: 2023-08-01T02:38:38.578014+00:00