Payment protocol for onion URLs.



Summary:

In this context, the author discusses bounties and their signatories. He refers to a bounty for which John has offered 1BTC as reward and another for which he has offered 4BTC as a reward. The 1BTC bounty is a P2SH output with a redeemScript that hashes to the expected value and is a 2-of-3 multisig with three pubkeys expressed as addresses. The vanity address makes it easy to guess who one of the signatories is. The author wonders if reusing keys for signing is bad form. John mentions wanting to disambiguate bounties, perhaps through a bounty-specific pubkey. The author is not sure how that is better than just referencing the address of the output or the TxID in a 'Table of Bounties'. The author also asks if John keeps pubkeys for the signatories he wants to appoint and reuses the same pubkey to create these multi-sigs or has to ask for a new one each time.The author imagines that from the signatories' perspective, a wallet receiving or importing the p2sh, tracking these outputs as "yours," and even more, which contract/bounty they correspond to, and finally a usable way to accumulate signatures and ultimately spend the output to the bounty winner is a long way off.The context then shifts to a discussion between John and Gregory Maxwell about limitations of the payment protocol as speced. Gregory mentions that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. John thinks this is a great idea and offers 1BTC as a reward for completing the task. He trusts either Jeff Garzik or Peter Todd to evaluate the finished product, or possibly someone else's.


Updated on: 2023-06-07T18:47:50.523541+00:00