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; 
Date: Thu, 6 Jun 2013 04:31:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Peter Vessenes <peter@coinlab.com>
Message-ID: <20130606083116.GA23658@savin>
References: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx"
Content-Disposition: inline
In-Reply-To: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Revocability with known trusted escrow
 services?
Precedence: list


--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--