* [Bitcoin-development] Payment protocol for onion URLs.
@ 2013-10-26 3:31 Gregory Maxwell
2013-10-26 3:41 ` Luke-Jr
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Gregory Maxwell @ 2013-10-26 3:31 UTC (permalink / raw)
To: Bitcoin Development
One limitation of the payment protocol as speced is 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.
A tor hidden service (onion site) is controlled by an RSA key.
It would be trivial to pack a tor HS pubkey into a self-signed x509
certificate with the cn set to foooo.onion.
If we specified in the payment protocol an additional validation
procedure for [base32].onion hosts that just has it hash and base32
encode the pubkey (as tor does) then the payment protocol could work
seamlessly with tor hosts. (Displaying that the payment request came
from "foooo.onion"). I believe that the additional code for this
would be trivial (and I'll write it if there is support for making
this a standard feature).
This would give us an fully supported option which is completely CA
free... it would only work for tor sites, but the people concerned
about CA trechery are likely to want to use tor in any case.
Thoughts?
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-26 3:31 [Bitcoin-development] Payment protocol for onion URLs Gregory Maxwell @ 2013-10-26 3:41 ` Luke-Jr 2013-10-26 4:06 ` Gregory Maxwell 2013-10-26 3:55 ` Gavin Andresen ` (2 subsequent siblings) 3 siblings, 1 reply; 10+ messages in thread From: Luke-Jr @ 2013-10-26 3:41 UTC (permalink / raw) To: bitcoin-development On Saturday, October 26, 2013 3:31:05 AM Gregory Maxwell wrote: > One limitation of the payment protocol as speced is 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. > > A tor hidden service (onion site) is controlled by an RSA key. > > It would be trivial to pack a tor HS pubkey into a self-signed x509 > certificate with the cn set to foooo.onion. > ... > Thoughts? Is there any point to additional encryption over tor (which afaik is already encrypted end-to-end)? Is there a safe way to make this work through tor entry nodes/gateways? It'd be nice to have a way to support namecoin-provided keys too... Luke ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-26 3:41 ` Luke-Jr @ 2013-10-26 4:06 ` Gregory Maxwell 2013-10-28 12:14 ` Adam Back 0 siblings, 1 reply; 10+ messages in thread From: Gregory Maxwell @ 2013-10-26 4:06 UTC (permalink / raw) To: Luke-Jr; +Cc: Bitcoin Development On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr <luke@dashjr•org> wrote: > Is there any point to additional encryption over tor (which afaik is already > encrypted end-to-end)? Is there a safe way to make this work through tor entry > nodes/gateways? The x.509 in the payment protocol itself is for authentication and non-repudiation, not confidentiality. It's used to sign the payment request so that later there is cryptographic evidence in the event of a dispute: "He didn't send me my alpaca socks!" "Thats not the address I told you to pay!" "He told me he'd send my 99 red-balloons, not just one!" "No way, that was the price for 1 red-balloon!" Just using SSL or .onion (or whatever else) gets you confidentiality and authentication. Neither of these things get you non-repudiation. > It'd be nice to have a way to support namecoin-provided keys too... The payment protocol is extensible, so I hope that someday someone will support namecoin authenticated messages (but note: this requires namecoin to support trust-free SPV resolvers, otherwise there is no way to extract a compact proof that can be stuck into a payment request) and GPG authenticated messages. But those things will require a fair amount of code (even fixing the namecoin protocol in the nmc case), and GPG could be done just by externally signing the actual payment request like you'd sign any file... and considering the sorry state of their _practical_ usability, I don't think they're worth doing at this time. By contrast, I _think_ the tor onion support would require only a relatively few lines of code since it could just be the existing x.509 mechanism with just a simple special validation rule for .onion, plus a little tool to repack the keys. I think it would easily be more widely used than namecoin (though probably both would not really be used, as gavin notes). w/ Gavin's comments I'll go check in with the tor folks and see if anyone has ever though of doing this before and if there is already a canonical structure for the x.509 certs used in this way. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-26 4:06 ` Gregory Maxwell @ 2013-10-28 12:14 ` Adam Back 2013-10-28 13:21 ` Mike Hearn 0 siblings, 1 reply; 10+ messages in thread From: Adam Back @ 2013-10-28 12:14 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development I think its a mistake relying directly on X509, its subject to corrpution attacks, involves ASN.1 and enough openSSL X.500 encoding abiguity (or other code base) to be a security nightmare. Why not make the payment messages signed by bitcoin keys. If someone wants to associate with X.509 they can put a bitcoin address on their SSL site. If someone can get into your site deeply enough to modify your SSL served code and you're trying to run ecommerce you have other problems. Never the less if they care they can clear sign the bitcoin addr with xmlsig and their X.509 private key, and/or with PGP and a WoT. I think its smarter to pollute bitcoin main with X509. Make a little helper util if there are not enough xmlsig tools that you cant pick one up opensource for multiple languages. This then avoids the binding to Tor - you can publish a bitcoin address authenticated anyway you like. Eg tahoe-LAFS auth/integrity, i2p, tor, pgp - you name it. Maybe I voice this opinion a bit late in the cycle, but I think it would do bitcoin a favor otherwise its a camels nose in the tent into the TLAs that control their own X.509 CAs, or issue NSL letters for CA private keys, or forged certs. It's all happening and thanks to Snowden we now have even more evidence... Adam On Fri, Oct 25, 2013 at 09:06:48PM -0700, Gregory Maxwell wrote: >On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr <luke@dashjr•org> wrote: >> Is there any point to additional encryption over tor (which afaik is already >> encrypted end-to-end)? Is there a safe way to make this work through tor entry >> nodes/gateways? > >The x.509 in the payment protocol itself is for authentication and >non-repudiation, not confidentiality. > >It's used to sign the payment request so that later there is >cryptographic evidence in the event of a dispute: >"He didn't send me my alpaca socks!" "Thats not the address I told you to pay!" >"He told me he'd send my 99 red-balloons, not just one!" "No way, >that was the price for 1 red-balloon!" > >Just using SSL or .onion (or whatever else) gets you confidentiality >and authentication. Neither of these things get you non-repudiation. > >> It'd be nice to have a way to support namecoin-provided keys too... > >The payment protocol is extensible, so I hope that someday someone >will support namecoin authenticated messages (but note: this requires >namecoin to support trust-free SPV resolvers, otherwise there is no >way to extract a compact proof that can be stuck into a payment >request) and GPG authenticated messages. > >But those things will require a fair amount of code (even fixing the >namecoin protocol in the nmc case), and GPG could be done just by >externally signing the actual payment request like you'd sign any >file... and considering the sorry state of their _practical_ >usability, I don't think they're worth doing at this time. > >By contrast, I _think_ the tor onion support would require only a >relatively few lines of code since it could just be the existing x.509 >mechanism with just a simple special validation rule for .onion, plus >a little tool to repack the keys. I think it would easily be more >widely used than namecoin (though probably both would not really be >used, as gavin notes). > >w/ Gavin's comments I'll go check in with the tor folks and see if >anyone has ever though of doing this before and if there is already a >canonical structure for the x.509 certs used in this way. > >------------------------------------------------------------------------------ >October Webinars: Code for Performance >Free Intel webinars can help you accelerate application performance. >Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >the latest Intel processors and coprocessors. See abstracts and register > >http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-28 12:14 ` Adam Back @ 2013-10-28 13:21 ` Mike Hearn 0 siblings, 0 replies; 10+ messages in thread From: Mike Hearn @ 2013-10-28 13:21 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1904 bytes --] On Mon, Oct 28, 2013 at 1:14 PM, Adam Back <adam@cypherspace•org> wrote: > Maybe I voice this opinion a bit late in the cycle, but .... A bit late is one way to put it. All these topics and more were discussed to death a year ago when the payment protocol was first being designed. Bluntly, I think we're all sick of it. You are welcome to PGP sign your payment requests if you want to. If not, then please see my FAQ for discussion: https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143 tl;dr - the right way to tackle governments getting bogus certs issued is certificate transparency. All other suggestions tend to boil down to "here's some handwaving that doesn't actually solve the problem". By the way, the evidence from the Snowden case rather reinforces the strength of the CA system. Did we see stories about bulk usage of fake certificates? No. What we read is that the increased usage of SSL was a major game-changer for intelligence agencies. They "solve" SSL by compiling databases of private keys they obtain in various ways. True to form when the FBI wanted access to LavaBit, they tried to obtain his private keys rather than just push a convenient "give me a fake cert" button, and when it became known that Lavabit had to hand over their key, GoDaddy revoked their certificate. Industry policies forced their hand and those policies don't have a get-out clause for the FBI. It's without a doubt that there are government-issued fake certs floating about, somewhere, just due to the scale of hacking that's been taking place. However, demanding perfection in a system that handles security for over a billion people and tens of millions of operators is unreasonable. All we can ask for is that it it's being improved, which through initiatives like cert transparency, it is. Please, let's call time on these discussions. They long ago ceased to have any value. [-- Attachment #2: Type: text/html, Size: 2557 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-26 3:31 [Bitcoin-development] Payment protocol for onion URLs Gregory Maxwell 2013-10-26 3:41 ` Luke-Jr @ 2013-10-26 3:55 ` Gavin Andresen 2013-10-26 4:15 ` Peter Todd 2013-10-28 5:58 ` John Dillon 3 siblings, 0 replies; 10+ messages in thread From: Gavin Andresen @ 2013-10-26 3:55 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 662 bytes --] On Sat, Oct 26, 2013 at 1:31 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > .... This would give us an fully supported option which is completely CA > free... it would only work for tor sites, but the people concerned > about CA trechery are likely to want to use tor in any case. > > Thoughts? > I think a tiny number of people would use it, so from a purely engineering priority perspective my initial reaction is "not worth it." However, as a demonstration of the flexibility of the payment protocol and because it is a really nifty idea that will give lots of people warm fuzzies I think you should do it and we should pull it. -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1235 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-26 3:31 [Bitcoin-development] Payment protocol for onion URLs Gregory Maxwell 2013-10-26 3:41 ` Luke-Jr 2013-10-26 3:55 ` Gavin Andresen @ 2013-10-26 4:15 ` Peter Todd 2013-10-28 5:58 ` John Dillon 3 siblings, 0 replies; 10+ messages in thread From: Peter Todd @ 2013-10-26 4:15 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1544 bytes --] On Fri, Oct 25, 2013 at 08:31:05PM -0700, Gregory Maxwell wrote: > One limitation of the payment protocol as speced is 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. > > A tor hidden service (onion site) is controlled by an RSA key. > > It would be trivial to pack a tor HS pubkey into a self-signed x509 > certificate with the cn set to foooo.onion. > > If we specified in the payment protocol an additional validation > procedure for [base32].onion hosts that just has it hash and base32 > encode the pubkey (as tor does) then the payment protocol could work > seamlessly with tor hosts. (Displaying that the payment request came > from "foooo.onion"). I believe that the additional code for this > would be trivial (and I'll write it if there is support for making > this a standard feature). > > This would give us an fully supported option which is completely CA > free... it would only work for tor sites, but the people concerned > about CA trechery are likely to want to use tor in any case. > > Thoughts? Strong ACK on the basis of responding for forum trolls alone. It's easy enough to make it a genuinely useful tool for multisig wallets too: keep a copy of your Tor URL bookmarks on your second signing computer. So long as either computer has the correct URL you're safe. -- 'peter'[:-1]@petertodd.org 0000000000000006fbd917e8b4770c566dbc8ed4bedd00f441286ffb6e7f73ac [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-26 3:31 [Bitcoin-development] Payment protocol for onion URLs Gregory Maxwell ` (2 preceding siblings ...) 2013-10-26 4:15 ` Peter Todd @ 2013-10-28 5:58 ` John Dillon 2013-10-28 19:37 ` Jeremy Spilman 3 siblings, 1 reply; 10+ messages in thread From: John Dillon @ 2013-10-28 5:58 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote: > One limitation of the payment protocol as speced is 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. > > Thoughts? I think this is a great idea and wish to see it done. Here is 1BTC for you, redeemable when you finish this task. I trust either Jeff Garzik or Peter Todd to evaluate your finished product, or possibly someone elses: 37NDa6iFLEozbvw8vj38ri5D6SLw5xQujS 22e067d3317e6300a9edda84fd0e24d8bfb86cf91540c3fe7acff45e4dc64dd3:0 redeemScript : "5241045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe44104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSbfy2AAoJEEWCsU4mNhiPrMMH/jd+AgVYUKd1vmP1BfaZum1s X186JulwF659YHOx94dLs+NOjvjMfY6cPbHm+B0j20CnhWrZrXzcXvwTHnzOSuoc 1AAXg0KDbvyo+7PvTrsGQfHhT1FZSRzIUToofVmFlvEIO6/LiYMAYWCgIiX9nPvv RlvdtavTST+cY19yZamo5X0XU5cgI2tbtVWKEHJQ2VcglCgwFg5K0kZ0O1NMKbcZ KBagY3PVTiHnYP+LwSTW6EU9DNq0eLYG39mz4N6CqGkXZjGgh2YXZ6Sl2qRuO/5e Rd9HcJXKqPKqMuRpQ2PA5U3U6QSyrUz7/fmi5dsOxnR6pdR53kjUVSvbOqBFHXw= =I1/R -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-28 5:58 ` John Dillon @ 2013-10-28 19:37 ` Jeremy Spilman 2013-10-31 0:44 ` Peter Todd 0 siblings, 1 reply; 10+ messages in thread From: Jeremy Spilman @ 2013-10-28 19:37 UTC (permalink / raw) To: Gregory Maxwell, John Dillon; +Cc: Bitcoin Development Just an aside... The 1BTC bountry John references below is a 1BTC P2SH output, where the redeemScript he provided does hash to the expected value, and is itself a 2-of-3 multisig, with the following pubkeys, expressed as addresses: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB By comparison, the signatories for the 4BTC bountry are: 1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB On the one hand, the vanity address makes it easy to guess who one of the signatories is, on the other hand, is it bad form to reuse keys for signing? John, you mentioned wanting to disambiguate bounties, perhaps through a bounty-specific pubkey. I'm not sure I follow, how is that better than just referencing the address of the output, or the TxID, in a 'Table of Bounties'? Or you want to embed a hash of your signed message announcing the bounty? Out of curiosity, I suppose right now you just keep pubkeys for the signatories you want to appoint and reuse the same pubkey to create these multi-sigs, or you have to ask for a new one each time? From the signatories perspective, I imagine we're a long way off from a wallet receiving or importing the p2sh, tracking that 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. And of course, thanks for posting the bounties! On Sun, 27 Oct 2013 22:58:13 -0700, John Dillon <john.dillon892@googlemail•com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell <gmaxwell@gmail•com> > wrote: >> One limitation of the payment protocol as speced is 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. >> >> Thoughts? > > I think this is a great idea and wish to see it done. Here is 1BTC for > you, > redeemable when you finish this task. I trust either Jeff Garzik or > Peter Todd > to evaluate your finished product, or possibly someone elses: > > 37NDa6iFLEozbvw8vj38ri5D6SLw5xQujS > > 22e067d3317e6300a9edda84fd0e24d8bfb86cf91540c3fe7acff45e4dc64dd3:0 > > redeemScript : > "5241045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe44104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBCAAGBQJSbfy2AAoJEEWCsU4mNhiPrMMH/jd+AgVYUKd1vmP1BfaZum1s > X186JulwF659YHOx94dLs+NOjvjMfY6cPbHm+B0j20CnhWrZrXzcXvwTHnzOSuoc > 1AAXg0KDbvyo+7PvTrsGQfHhT1FZSRzIUToofVmFlvEIO6/LiYMAYWCgIiX9nPvv > RlvdtavTST+cY19yZamo5X0XU5cgI2tbtVWKEHJQ2VcglCgwFg5K0kZ0O1NMKbcZ > KBagY3PVTiHnYP+LwSTW6EU9DNq0eLYG39mz4N6CqGkXZjGgh2YXZ6Sl2qRuO/5e > Rd9HcJXKqPKqMuRpQ2PA5U3U6QSyrUz7/fmi5dsOxnR6pdR53kjUVSvbOqBFHXw= > =I1/R > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Payment protocol for onion URLs. 2013-10-28 19:37 ` Jeremy Spilman @ 2013-10-31 0:44 ` Peter Todd 0 siblings, 0 replies; 10+ messages in thread From: Peter Todd @ 2013-10-31 0:44 UTC (permalink / raw) To: Jeremy Spilman; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 3340 bytes --] On Mon, Oct 28, 2013 at 12:37:30PM -0700, Jeremy Spilman wrote: > Just an aside... > > The 1BTC bountry John references below is a 1BTC P2SH output, where the > redeemScript he provided does hash to the expected value, and is itself a > 2-of-3 multisig, with the following pubkeys, expressed as addresses: > > 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj > 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv > 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB > > By comparison, the signatories for the 4BTC bountry are: > > 1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe > 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv > 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB > > On the one hand, the vanity address makes it easy to guess who one of the > signatories is, on the other hand, is it bad form to reuse keys for > signing? It's a bit more risky from a cryptography perspective, but provided your wallet implementation is done correctly the extra risk is pretty much theoretical. However this has caused real-world coin loss in the past in the case of the Android PRNG flaw - re-using nonces in ECC signing causes the private key to be revealed. I think the real issue here is that John doesn't appear to have asked any of the people whose signatures can release the funds if they were willing to take part. If he had done that, he could have, and should have, gotten separate pubkeys for the purpose of the bounty like was done for Gregory Maxwell's CoinJoin bounty. Instead by not asking he is in reality if not in theory placing demands on people who haven't consented, particularly for the 1BTC bounty where he doesn't control any of the private keys required to release the funds. IMO this is rude and I encourage people not to do this. > John, you mentioned wanting to disambiguate bounties, perhaps through a > bounty-specific pubkey. I'm not sure I follow, how is that better than > just referencing the address of the output, or the TxID, in a 'Table of > Bounties'? Or you want to embed a hash of your signed message announcing > the bounty? Well, the issue with not disambiguating bounties is that if further funds are sent to the bounty address it's unclear how do you handle those funds. Note how he specified a specific txout for the 1BTC bounty, but specified an address for the 4BTC bounty. > Out of curiosity, I suppose right now you just keep pubkeys for the > signatories you want to appoint and reuse the same pubkey to create these > multi-sigs, or you have to ask for a new one each time? > > From the signatories perspective, I imagine we're a long way off from a > wallet receiving or importing the p2sh, tracking that 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. We're not that far off: I could cook up a Python script to do the signature accumulation and signing in a few hours. There's just not all that much demand yet to fully polish the UI's, and in any case, it'll differ for every specific application. FWIW blockchain.info added multisig escrow support ages ago, then removed it not long after because usage was near zero. -- 'peter'[:-1]@petertodd.org 0000000000000001daf527009e07f452eee5dca920d3a9253b682d8bd26783ff [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-10-31 0:44 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-10-26 3:31 [Bitcoin-development] Payment protocol for onion URLs Gregory Maxwell 2013-10-26 3:41 ` Luke-Jr 2013-10-26 4:06 ` Gregory Maxwell 2013-10-28 12:14 ` Adam Back 2013-10-28 13:21 ` Mike Hearn 2013-10-26 3:55 ` Gavin Andresen 2013-10-26 4:15 ` Peter Todd 2013-10-28 5:58 ` John Dillon 2013-10-28 19:37 ` Jeremy Spilman 2013-10-31 0:44 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox