Serialised P2SH HD chains [combined summary]



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

Published on: 2014-12-04T21:10:14+00:00


Summary:

Jeffrey Paul inquired about the use case for generating multiple Pay-to-Script-Hash (P2SH) addresses with a single token, specifically in the context of enabling payments to individuals without them needing to have their computer on during transactions. He also questioned the assumption that multisig participants would never change their keys or cycle them. The response mentioned that the solution depends on the framework and that miners are currently limited to using only one address, even if they wanted to avoid address reuse.On December 4, 2014, Luke Dashjr raised a query about whether there was work being done on a serialization format to convey P2SH HD chains. He suggested using a simple series of tokens to generate multiple P2SH addresses paying to a multisig script. Luke-Jr explained that this serialization format could be useful when the payee is not online and could help avoid explicitly specifying scriptPubKey formats. This idea was similar to his considerations for generalized stealth addresses, which also aimed to avoid explicitly specifying scriptPubKey formats.Luke Dashjr, a Bitcoin developer, further discussed the need for a serialization format to convey P2SH HD chains for recurring payments. He proposed using a series of tokens indicating either an HD chain or literal script content to generate multiple P2SH addresses paying to a multisig script. The author also suggested the use of a bitcoin URI pointing to a payment request generating URL as a more practical option for long-term payments. It was recommended to set an expiry time for practical usage.The author mentioned the creation of a Javascript program to print minimal protobufs to base64 for multisig and regular pay to address outputs. Additionally, the author suggested building specialized one-off SPV wallets using bitcoinj and provided a video tutorial on customization. The author also discussed the possibility of creating a GUI that allows users to build a base64 encoded payment protocol request supporting HD iteration for one or more keys. This GUI could serve as a starter project and act as a watching wallet to track mining payouts over time.There was interest expressed in creating a shared HD wallet format that would allow different devices to generate new addresses using standardized HD multisig chain-description formats. However, there were still many details to be worked through before having a concrete proposal. Another individual proposed a solution involving a simple series of tokens indicating either an HD chain or literal script content to convey P2SH HD chains.A group in San Diego was working on a standardized HD multisig chain-description format that multiple wallets could understand. This format aimed to create a 2-of-3 multisig wallet using different devices running different wallet software. The chain-description file would be shared with third parties for auditing, receive-only wallets, and recurring payments. However, more details needed to be addressed before presenting a concrete proposal.Luke Dashjr's inquiry about a serialization format to convey P2SH HD chains prompted Gavin Andresen to respond, stating the need for an expiration date or means of determining if the payment recipient is still operational. Gavin referred to a previous discussion on extending the payment protocol for recurring transactions and suggested providing a URL for accessing PaymentRequests when making a payment or offering an array of PaymentRequests for future payments.In conclusion, the author seeks information on a serialization format for conveying P2SH HD chains for recurring payments. The proposal involves generating a single token to generate multiple P2SH addresses paying to a multisig script using a series of tokens indicating HD chains or literal script content. However, questions remain regarding whether this proposed solution adequately covers all reasonable use cases.


Updated on: 2023-08-01T10:55:26.137353+00:00