Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.98 as permitted sender)
	client-ip=62.13.148.98; envelope-from=pete@petertodd.org;
	helo=outmail148098.authsmtp.com; 
Date: Wed, 30 Oct 2013 20:44:01 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20131031004401.GA22665@savin>
References: <CAAS2fgRRobkE2GdYomtJof7HCH-9ZczE9EBj7DBS-pCGscUSNQ@mail.gmail.com>
	<CAPaL=UXxyKpWxG3qE=76B1HmbUXRCEWWRsCAceL6RfToDh01yg@mail.gmail.com>
	<op.w5ojgsityldrnw@laptop-air>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP"
Content-Disposition: inline
In-Reply-To: <op.w5ojgsityldrnw@laptop-air>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol for onion URLs.
Precedence: list


--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 28, 2013 at 12:37:30PM -0700, Jeremy Spilman wrote:
> Just an aside...
>=20
> The 1BTC bountry John references below is a 1BTC P2SH output, where the =
=20
> redeemScript he provided does hash to the expected value, and is itself a=
 =20
> 2-of-3 multisig, with the following pubkeys, expressed as addresses:
>=20
> 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
> 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
> 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
>=20
> By comparison, the signatories for the 4BTC bountry are:
>=20
> 1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe
> 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
> 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
>=20
> On the one hand, the vanity address makes it easy to guess who one of the=
 =20
> signatories is, on the other hand, is it bad form to reuse keys for =20
> 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 =
=20
> bounty-specific pubkey. I'm not sure I follow, how is that better than =
=20
> just referencing the address of the output, or the TxID, in a 'Table of =
=20
> Bounties'? Or you want to embed a hash of your signed message announcing =
=20
> 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 =20
> signatories you want to appoint and reuse the same pubkey to create these=
 =20
> multi-sigs, or you have to ask for a new one each time?
>=20
>  From the signatories perspective, I imagine we're a long way off from a =
=20
> wallet receiving or importing the p2sh, tracking that these outputs as =
=20
> "yours", and even more, which contract/bounty they correspond to, and =20
> finally a usable way to accumulate signatures and ultimately spend the =
=20
> 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.

--=20
'peter'[:-1]@petertodd.org
0000000000000001daf527009e07f452eee5dca920d3a9253b682d8bd26783ff

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGrBAEBCACVBQJScafRXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDVmYzBjZmZhMmYxYzYwMzYyYWQ5OThkMmE2ZGQ5MmFiNjlj
MzQyMzVhMGUwYjA2NGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsk3wgAvXrL+puR/65Wim1sbRvmXyZR
Up2vX36LzqnbxR6KzpBPVOVY0WBmmAlAto1jKzs4E16FFPNGGYZywu9JebdmSAdy
UkSi5JMzpz8/2SWmthuBcVKJLKFXNFvBFwqdtQyqq+ROsUclTCJTXY+WWlRH4QPu
1NTE/8jE7tWJUCiAXyYNGaEdiHh1nRNUOf2xz5TVckGTp8WwslHn1yRxHMI7R9Q6
XrpGcUysQZurGBUpUawMpoMYB+UBjHjaTw+DqzcGKDyfujJ5CUc18hQYCwYU6U1H
W47FSn7S6G43da12d8XLPYnl6Uh/Y1cHRonthkJcCnAO+0Be3DhnSzxqlHoINQ==
=kc0f
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--