diff options
| author | Peter Todd <pete@petertodd.org> | 2013-10-30 20:44:01 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-10-31 00:44:16 +0000 |
| commit | fc10fc2f28253756f0c2c6f94e57140d71a1e365 (patch) | |
| tree | c9ff35f06de7ec021feb4016fdeaf773f49dcafe | |
| parent | 5c0442dc518d99f0cbd3d8a2b44d4d5729fd4657 (diff) | |
| download | pi-bitcoindev-fc10fc2f28253756f0c2c6f94e57140d71a1e365.tar.gz pi-bitcoindev-fc10fc2f28253756f0c2c6f94e57140d71a1e365.zip | |
Re: [Bitcoin-development] Payment protocol for onion URLs.
| -rw-r--r-- | 38/cb9ecbec9ff091862625458076252b10f73fd1 | 184 |
1 files changed, 184 insertions, 0 deletions
diff --git a/38/cb9ecbec9ff091862625458076252b10f73fd1 b/38/cb9ecbec9ff091862625458076252b10f73fd1 new file mode 100644 index 000000000..5567a5e0d --- /dev/null +++ b/38/cb9ecbec9ff091862625458076252b10f73fd1 @@ -0,0 +1,184 @@ +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 <pete@petertodd.org>) 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 <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) +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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-- + + |