From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UkOfQ-0000vn-M4 for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 01:07:04 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.48 as permitted sender) client-ip=209.85.215.48; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f48.google.com; Received: from mail-la0-f48.google.com ([209.85.215.48]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UkOfP-0007pP-7H for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 01:07:04 +0000 Received: by mail-la0-f48.google.com with SMTP id lx15so1032817lab.7 for ; Wed, 05 Jun 2013 18:06:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.167.2 with SMTP id zk2mr15772905lbb.83.1370480816448; Wed, 05 Jun 2013 18:06:56 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Wed, 5 Jun 2013 18:06:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Jun 2013 03:06:56 +0200 Message-ID: From: Melvin Carvalho To: Peter Vessenes Content-Type: multipart/alternative; boundary=001a11c386623c6b2a04de71eeef X-Spam-Score: -0.6 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UkOfP-0007pP-7H 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 01:07:04 -0000 --001a11c386623c6b2a04de71eeef Content-Type: text/plain; charset=ISO-8859-1 On 6 June 2013 02:19, 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. > It's great that this article quotes the first page of Sasoshi's white paper. There are some other text that they missed, though, which I think may be relevant. [[ Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non- reversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. ]] > > 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. > > 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 > > --001a11c386623c6b2a04de71eeef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



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=3D1 =A0article g= ot posted today, noting that FinCEN thinks irrevocable payments are money l= aundering tools.=A0

It's great that this article quotes th= e first page of Sasoshi's white paper.=A0 There are some other text tha= t they missed, though, which I think may be relevant.

[[
Complete= ly non-reversible transactions are not really possible, since financial ins= titutions cannot
avoid mediating disputes. The cost of mediation increases transaction costs= , limiting the
minimum practical transaction size and cutting off the po= ssibility for small casual transactions,
and there is a broader cost in = the loss of ability to make non-reversible payments for non-
reversible services. With the possibility of reversal, the need for trust s= preads. Merchants must
be wary of their customers, hassling them for mor= e information than they would otherwise need.
A certain percentage of fr= aud is accepted as unavoidable. These costs and payment uncertainties
can be avoided in person by using physical currency, but no mechanism exist= s to make payments
over a communications channel without a trusted party= .

What is needed is an electronic payment system based on cryptograp= hic proof instead of trust,
allowing any two willing parties to transact directly with each other witho= ut the need for a trusted
third party. Transactions that are computation= ally impractical to reverse would protect sellers
from fraud, and routin= e escrow mechanisms could easily be implemented to protect buyers.
]]
=A0

I will hold my thoughts about the net social good of rent-se= eking large corporations taking money from consumers over fraudulent revers= als. Actually, I won't, I just said it.

At any r= ate, it got me thinking, can we layer on revocability somehow without any p= rotocol change, as an opt-in?

My initial scheme is a trusted (hah) escrow service tha= t issues time promises for signing. If it doesn't receive a cancel mess= age, it will sign at the end of the time.=A0

The a= ddresses 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 trans= action go out.

This seems sort of poor to me, it imagines that mythica= l thing, a trusted escrow service, and is vulnerable to griefing, but I tho= ught I'd see if some of the brighter minds than me can come up with a l= ayer-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 ha= ve 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 ar= rangement, though.

Peter

--

=3D"CoinLabPETER=A0VESSENES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 =A0/=A0SKYPE:=A0vessene= s=A0
71 COLUMBIA ST / SUITE 300 =A0/=A0 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c386623c6b2a04de71eeef--