From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VbgMy-0001ss-NF for bitcoin-development@lists.sourceforge.net; Thu, 31 Oct 2013 00:44:16 +0000 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; Received: from outmail148098.authsmtp.com ([62.13.148.98]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VbgMx-00079V-B5 for bitcoin-development@lists.sourceforge.net; Thu, 31 Oct 2013 00:44:16 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id r9V0i71I001625; Thu, 31 Oct 2013 00:44:07 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r9V0i24r055751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 31 Oct 2013 00:44:05 GMT Date: Wed, 30 Oct 2013 20:44:01 -0400 From: Peter Todd To: Jeremy Spilman Message-ID: <20131031004401.GA22665@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 8ba8705b-41c5-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdQMUF1YAAgsB AmUbW1ReVFl7WWY7 bAxPbAVDY01GQQRq WVdMSlVNFUsqCHoB XxwaEBl3cgJDeTBy YENmXj5TDhVyckZ4 EFNQFD4DeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zFy85 ShYeVS01GlECTCI3 ZxIhMBYbGkcWNA0P C386HzoA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: blockchain.info] X-Headers-End: 1VbgMx-00079V-B5 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Payment protocol for onion URLs. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 00:44:16 -0000 --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--