From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UkOBB-000850-1j for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 00:35:49 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.172 as permitted sender) client-ip=209.85.223.172; envelope-from=etotheipi@gmail.com; helo=mail-ie0-f172.google.com; Received: from mail-ie0-f172.google.com ([209.85.223.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UkOB8-0004QY-Rw for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 00:35:49 +0000 Received: by mail-ie0-f172.google.com with SMTP id 17so5457916iea.17 for ; Wed, 05 Jun 2013 17:35:41 -0700 (PDT) X-Received: by 10.42.102.211 with SMTP id j19mr16092647ico.0.1370478941512; Wed, 05 Jun 2013 17:35:41 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id r20sm8673047ign.8.2013.06.05.17.35.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 17:35:40 -0700 (PDT) Message-ID: <51AFD92F.1020206@gmail.com> Date: Wed, 05 Jun 2013 20:34:55 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------070809070101090002050907" 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 (etotheipi[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: 1UkOB8-0004QY-Rw 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 00:35:49 -0000 This is a multi-part message in MIME format. --------------070809070101090002050907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The two most basic ways would be simply: (1) You create your transactions having a locktime of X days and has sequence numbers such that it can be replaced exactly once. The replacement, can be executed within 30 days. (2) You simply send money to 1-of-2 transactions: me-or-you. If the person who is receiving it wants it, they have to sign for it by sending it to one of their own single-sig addresses. Otherwise, you can return it to yourself at some point in the future. I don't totally understand the goal, and how/if these solutions actually achieve such goal. But it does add a way for transactions to exist a non-final state for some amount of time. But in both cases, accessibility is still binary: you have complete access to it, until you don't. Which might be seen as the point of irrevocable transfer. -Alan On 06/05/2013 08:19 PM, 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. > > Peter > > -- > > ------------------------------------------------------------------------ > > CoinLab LogoPETER 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 --------------070809070101090002050907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The two most basic ways would be simply:

(1) You create your transactions having a locktime of X days and has sequence numbers such that it can be replaced exactly once.  The replacement, can be executed within 30 days.

(2) You simply send money to 1-of-2 transactions:  me-or-you.  If the person who is receiving it wants it, they have to sign for it by sending it to one of their own single-sig addresses.  Otherwise, you can return it to yourself at some point in the future.

I don't totally understand the goal, and how/if these solutions actually achieve such goal.  But it does add a way for transactions to exist a non-final state for some amount of time.  But in both cases, accessibility is still binary:  you have complete access to it, until you don't.   Which might be seen as the point of irrevocable transfer.

-Alan



On 06/05/2013 08:19 PM, 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.

Peter

--

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

--------------070809070101090002050907--