Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UkVbZ-0006oG-G8 for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 08:31:33 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.84 as permitted sender) client-ip=62.13.149.84; envelope-from=pete@petertodd.org; helo=outmail149084.authsmtp.net; Received: from outmail149084.authsmtp.net ([62.13.149.84]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UkVbY-0004yj-5Y for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 08:31:33 +0000 Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r568VPL3009682; Thu, 6 Jun 2013 09:31:25 +0100 (BST) 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 r568VG9v065680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 09:31:19 +0100 (BST) Date: Thu, 6 Jun 2013 04:31:16 -0400 From: Peter Todd To: Peter Vessenes Message-ID: <20130606083116.GA23658@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 7675462c-ce83-11e2-98a9-0025907ec6c5 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgQUEkAaAgsB AmUbW11eU1x7WGo7 bAxPbAVDY01GQQRq WVdMSlVNFUsqBBoJ YGkXFBl0cgNOeDBx YUZhWT5cWkN/cUB/ EVMHQGUFeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4xEyA7 TBkIHDEuAVxNWCQv L1QlLFkDGg4NKFgp LVYtEV8DOAUVFW8W BExXHi5SKkJWLwAA X-Authentic-SMTP: 61633532353630.1020: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 X-Headers-End: 1UkVbY-0004yj-5Y Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Revocability with known trusted escrow services? 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, 06 Jun 2013 08:31:33 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 05, 2013 at 05:19:16PM -0700, Peter Vessenes wrote: > So, this > http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-105960= 8-1.html?pg=3D1 > article got posted today, noting that FinCEN thinks irrevocable > payments > are money laundering tools. >=20 > I will hold my thoughts about the net social good of rent-seeking large > corporations taking money from consumers over fraudulent reversals. > Actually, I won't, I just said it. >=20 > At any rate, it got me thinking, can we layer on revocability somehow > without any protocol change, as an opt-in? >=20 > My initial scheme is a trusted (hah) escrow service that issues time > promises for signing. If it doesn't receive a cancel message, it will sign > at the end of the time. >=20 > The addresses would be listed by the escrow service, or in an open > registry, so you could see if you were going to have a delay period when > you saw a transaction go out. >=20 > This seems sort of poor to me, it imagines that mythical thing, a trusted > escrow service, and is vulnerable to griefing, but I thought I'd see if > some of the brighter minds than me can come up with a layer-on approach > here. >=20 > When I think about it, I can imagine that I would put a good number of my > coins in a one day reversible system, because I would have warning if > someone wanted to try and spend them, and could do something about it. I'm > not sure if it gets me anything over a standard escrow arrangement, thoug= h. A few issues: Revocable payments are almost always invoked in cases where the decision that a payment needs to be revoked is done by humans. To worry about the difficulty of finding a "trusted escrow service" is irrelevant at the protocol level - this isn't a problem that can be solved by math. Legally speaking revocation can generally happen any time in the future, even years in the future. Note the controversies involved around a variety of land transactions that occured hundreds of years in the past in North America and other parts of the world, where distant relatives of those who made the transactions are attempting to have them reversed partially or fully. Technical solutions with a limited revocation window are likely to be found unacceptable in the eyes of the law. Focusing on the need to "revoke" a transaction is taking a banking idea, and applying it very incorrectly to the Bitcoin world; in banking revoking a transaction can result in your balance being negative. What you need to focus on is the spirit of what revoking a transaction is about, which is to take money from someone who thought they had it, and give it to someone else. We can easily replicate this effect in Bitcoin by simply giving the private keys for our wallets to the relevant revocation authority, or, if more auditing is desired, storing our coins in 1-of-2 multisig addresses spendable by either us or that authority. In the event that a transaction needs to be revoked, simply have the escrow service make a transaction that takes the correct amount of coins =66rom your wallet, and gives it to the person who sent you the money. Problem solved. --=20 'peter'[:-1]@petertodd.org 0000000000000108f8cf27a2a2f49384346d915ff0970554358b9544bc7f5bfd --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRsEjTAAoJECSBQD2l8JH76LEIAKp0VXe43pAaXIEn3PZFIEmJ uDwStmW7LTtTApN++U78g22UOjnp9J8CiqG1Rfrj24UFOoVmtgg57XAjcwMn3qYO mERU9ka9gwI6fuPDJ0j4BhTJxO2nDDEO9E6zMpzYKKwVJNZyDBWOszEUGNx4yFj9 2x4yUSQn49cYbjnOTI1pRVSg5rAtcRER/Ekxxf0Y/GqaDJYloIl7gEAUth27/gma UfGs9mW295pLX+XnVH16wAgCvdVAsqoRaPDIC0TnHupqmQy7NCK/N3ZGdzop7ZYI I2iv8kHjFGa7d0m30Z5EKXixjLmEy2LXIuVIr2B2ioOgR1uH+QnmNDokWWQB8pM= =Le+h -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx--