From: Melvin Carvalho <melvincarvalho@gmail•com>
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: Fri, 7 Jun 2013 00:22:40 +0200 [thread overview]
Message-ID: <CAKaEYhKiRutKYeQjLocJJ0L2Yra790WnUiF5Px64Kxv7Q-0z8w@mail.gmail.com> (raw)
In-Reply-To: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3952 bytes --]
On 6 June 2013 02:19, Peter Vessenes <peter@coinlab•com> 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.
>
Also see satoshi's comments on this, though it may be restating what others
have said:
https://bitcointalk.org/index.php?topic=750.0
"Here's an outline of the kind of escrow transaction that's possible in
software. This is not implemented and I probably won't have time to
implement it soon, but just to let you know what's possible.
The basic escrow: The buyer commits a payment to escrow. The seller
receives a transaction with the money in escrow, but he can't spend it
until the buyer unlocks it. The buyer can release the payment at any time
after that, which could be never. This does not allow the buyer to take the
money back, but it does give him the option to burn the money out of spite
by never releasing it. The seller has the option to release the money back
to the buyer.
While this system does not guarantee the parties against loss, it takes the
profit out of cheating.
If the seller doesn't send the goods, he doesn't get paid. The buyer would
still be out the money, but at least the seller has no monetary motivation
to stiff him.
The buyer can't benefit by failing to pay. He can't get the escrow money
back. He can't fail to pay due to lack of funds. The seller can see that
the funds are committed to his key and can't be sent to anyone else.
Now, an economist would say that a fraudulent seller could start
negotiating, such as "release the money and I'll give you half of it back",
but at that point, there would be so little trust and so much spite that
negotiation is unlikely. Why on earth would the fraudster keep his word and
send you half if he's already breaking his word to steal it? I think for
modest amounts, almost everyone would refuse on principle alone."
>
> Peter
>
> --
>
> ------------------------------
>
> [image: CoinLab Logo]PETER VESSENES
> CEO
>
> *peter@coinlab•com * / 206.486.6856 / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 6233 bytes --]
next prev parent reply other threads:[~2013-06-06 22:22 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
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 [this message]
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=CAKaEYhKiRutKYeQjLocJJ0L2Yra790WnUiF5Px64Kxv7Q-0z8w@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--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