From: Peter Todd <pete@petertodd•org>
To: Peter Vessenes <peter@coinlab•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Revocability with known trusted escrow services?
Date: Thu, 6 Jun 2013 04:31:16 -0400 [thread overview]
Message-ID: <20130606083116.GA23658@savin> (raw)
In-Reply-To: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-06-06 8:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 0:19 Peter Vessenes
2013-06-06 0:34 ` Alan Reiner
2013-06-06 1:06 ` Melvin Carvalho
2013-06-06 8:31 ` Peter Todd [this message]
2013-06-06 9:01 ` Leszek Rychlewski
2013-06-06 16:31 ` Jorge Timón
2013-06-06 9:03 ` Mike Hearn
2013-06-06 18:18 ` Mark Friedenbach
2013-06-06 22:22 ` Melvin Carvalho
2013-06-07 5:46 ` Caleb James DeLisle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130606083116.GA23658@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=peter@coinlab$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox