[Bitcoin-development] Revocability with known trusted escrow services?

Peter Todd pete at petertodd.org
Thu Jun 6 08:31:16 UTC 2013


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-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable
> payments
> are money laundering tools.
> 
> 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.
> 
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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, though.

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
from your wallet, and gives it to the person who sent you the money.

Problem solved.

-- 
'peter'[:-1]@petertodd.org
0000000000000108f8cf27a2a2f49384346d915ff0970554358b9544bc7f5bfd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130606/f92a83c2/attachment.sig>


More information about the bitcoin-dev mailing list