Published on: 2013-10-31T00:44:01+00:00
In an email thread, Jeremy Spilman discusses the risks of reusing keys for signing and notes that it is bad form to do so. He suggests that John should have gotten separate public keys for the purpose of his bounty, rather than placing demands on people who haven't consented. Disambiguating bounties was also discussed, with the issue being that if further funds are sent to the bounty address, it's unclear how to handle those funds.The possibility of creating a Python script to do signature accumulation and signing was mentioned, but there hasn't been much demand yet to fully polish UIs. It was noted that blockchain.info had added multisig escrow support in the past but removed it due to near-zero usage.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 specified. 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.In an email dated October 28, 2013, Adam Back expressed his opinion on payment protocols and PGP signing. He mentioned that many topics related to payment protocol were discussed a year ago when it was first being designed. According to him, the right way to tackle governments getting bogus certs issued is certificate transparency, and all other suggestions tend to boil down to "handwaving" that does not solve the problem.Back stated that the evidence from the Snowden case reinforces the strength of the CA system, and we did not see stories about bulk usage of fake certificates. Back argued that the increased usage of SSL was a game-changer for intelligence agencies. They compile databases of private keys they obtain in various ways to solve SSL. When the FBI wanted access to LavaBit, they tried to obtain their private keys rather than push a convenient "give me a fake cert" button. When Lavabit had to hand over its key, GoDaddy revoked its certificate because industry policies forced their hand, which doesn't have a get-out clause for the FBI.Back acknowledged that government-issued fake certs are floating about somewhere due to the scale of hacking. However, he stated that demanding perfection in a system that handles security for over a billion people and tens of millions of operators is unreasonable. He suggested that all we can ask for is that the system is being improved, which initiatives like cert transparency aim to do. Back concluded by asking to call time on discussions as they long ago ceased to have any value.In an email exchange on the Bitcoin-development mailing list, Adam Back expressed concern over the use of X.509 in Bitcoin's payment protocol due to its susceptibility to corruption attacks and potential for security nightmares. Instead, Back suggests using bitcoin keys to sign payment messages, which can be associated with X.509 if desired. He also proposes a "pollution" of Bitcoin main with X.509 to avoid binding to Tor.Gregory Maxwell responds that the x.509 in the payment protocol is used for authentication and non-repudiation, not confidentiality, and that the payment protocol is extensible to support namecoin-provided keys and GPG authenticated messages. However, he notes that these would require a fair amount of code and may not be worth doing at this time.
Updated on: 2023-08-01T06:20:18.137209+00:00