From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UkNva-0007a1-Rw for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 00:19:42 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of coinlab.com designates 209.85.216.169 as permitted sender) client-ip=209.85.216.169; envelope-from=peter@coinlab.com; helo=mail-qc0-f169.google.com; Received: from mail-qc0-f169.google.com ([209.85.216.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UkNva-0000ny-0N for bitcoin-development@lists.sourceforge.net; Thu, 06 Jun 2013 00:19:42 +0000 Received: by mail-qc0-f169.google.com with SMTP id c10so872369qcz.14 for ; Wed, 05 Jun 2013 17:19:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=l3BpyyDPnq94Wph0GQCbv9URC8yy70lwi3PD4V0+jiA=; b=oNnGp8vXm54vHduLKyEEY83efDn0VyqodeYMt1x941rX/dx5Ka1+srX+I9MMMcR4c2 82+UQfbMsE00ughyCi8lpllyqy9iThaeXRhtJnyZ+VtqOC34eqfLLAWe+SDIYBwhc47D agxV1Yxg23V4jU16muzCQKc3f/3XBRQsrjrvCIBSdyca//n96k5G5QDa+81ls4hqQZM4 wyJ2HGeHRLiqOIXSHQfdU86o13gzJF0NCKx89qUOdekAzvnWTvjwrlFVcBdLXb27RdF8 /Lbfcwujq9TbLhWz7v6epej9K302kQUbH7EkGp6XR+ucMe72ibHLgRgpD1ogP+NMB1GI 4MJw== X-Received: by 10.224.161.3 with SMTP id p3mr31683458qax.37.1370477976356; Wed, 05 Jun 2013 17:19:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.39.137 with HTTP; Wed, 5 Jun 2013 17:19:16 -0700 (PDT) From: Peter Vessenes Date: Wed, 5 Jun 2013 17:19:16 -0700 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e01537ba4f4195e04de714436 X-Gm-Message-State: ALoCoQnd9d8wkjha5Noz7aFCT/BTpNqk18rmC9yEEvTip1V8w5hqzmBQLlYLBANrJzTCoUAqsa1n X-Spam-Score: -0.5 (/) 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 SPF_PASS SPF: sender matches SPF record 0.0 HTML_IMAGE_ONLY_32 BODY: HTML: images with 2800-3200 bytes of words 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1UkNva-0000ny-0N Subject: [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:19:43 -0000 --089e01537ba4f4195e04de714436 Content-Type: text/plain; charset=ISO-8859-1 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 -- ------------------------------ [image: CoinLab Logo]PETER VESSENES CEO *peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104 --089e01537ba4f4195e04de714436 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So, this http://www.americanbank= er.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=3D1 =A0ar= ticle got posted today, noting that FinCEN thinks irrevocable payments are = money laundering tools.=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 wo= uld have warning if someone wanted to try and spend them, and could do some= thing about it. I'm not sure if it gets me anything over a standard esc= row arrangement, though.

Peter

--

3D=PETER=A0VESSE= NES=A0
CEO

peter@coinlab.com=A0=A0/=A0=A0206.486.6856 = =A0/=A0SKYPE:=A0vessenes=A0
71 COLUMBIA ST / SUITE 300 =A0/=A0 SEATTLE, WA 98104

--089e01537ba4f4195e04de714436--