From: Peter Todd <pete@petertodd•org>
To: Jeremy Spilman <jeremy@taplink•co>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol for onion URLs.
Date: Wed, 30 Oct 2013 20:44:01 -0400 [thread overview]
Message-ID: <20131031004401.GA22665@savin> (raw)
In-Reply-To: <op.w5ojgsityldrnw@laptop-air>
[-- 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 --]
prev parent reply other threads:[~2013-10-31 0:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-26 3:31 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131031004401.GA22665@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox