summaryrefslogtreecommitdiff
path: root/a9/261849463cd5c83c9616e4905cbf70d6911716
blob: 2c9bc603f55bb8b31b8ab31979da72532e2d9721 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1UkW6Q-0006KY-2P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Jun 2013 09:03:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.44 as permitted sender)
	client-ip=209.85.219.44; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f44.google.com; 
Received: from mail-oa0-f44.google.com ([209.85.219.44])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UkW6O-0005kd-Tl
	for bitcoin-development@lists.sourceforge.net;
	Thu, 06 Jun 2013 09:03:26 +0000
Received: by mail-oa0-f44.google.com with SMTP id n12so1998820oag.31
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 06 Jun 2013 02:03:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.215.133 with SMTP id oi5mr181934obc.83.1370509399436;
	Thu, 06 Jun 2013 02:03:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.9.1 with HTTP; Thu, 6 Jun 2013 02:03:19 -0700 (PDT)
In-Reply-To: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
References: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
Date: Thu, 6 Jun 2013 11:03:19 +0200
X-Google-Sender-Auth: kLP4yUpCrwPqItWirFFmjlaVljE
Message-ID: <CANEZrP1HhNGeSeD7TbsZtVZLxYKSJZtv8+8VnU6UFLA38tfs9Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Vessenes <peter@coinlab.com>
Content-Type: multipart/alternative; boundary=001a11c25434ea8ca704de789531
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1UkW6O-0005kd-Tl
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 09:03:26 -0000

--001a11c25434ea8ca704de789531
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 6, 2013 at 2:19 AM, 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.
>

That's not how I read it, I don't see how one could argue that irreversible
transactions are a money laundering tool. Credit card transactions aren't
completely reversible either, you have to either claim that the card was
stolen or that the merchant didn't deliver. If you charge back routinely,
then the card companies are supposed to crack down on you. Though I don't
know if that really happens.

I think we should expect the head of FinCEN to argue that more or less
anything can be seen as money laundering. She directly and personally
profits from expansion of the notion of money laundering. That doesn't mean
other people have to agree.


> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>

I think we need 2-of-3 dispute mediation and have thought that for a long
time, indeed, Satoshi's paper says so:

https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

It doesn't require any core protocol changes but it does require deployment
of the payment protocol first, as that's the foundation on which we can add
lots of other useful features like that. And then it needs a whole lot of
work to define how you open a dispute from your wallet, how you find
mutually agreeable mediators, etc. Having reversible payments in which one
of the trading parties gets to decide whether to reverse seems pointless to
me. If the buyer decides it's simply equivalent to post pay, and if the
seller decides then it's just a refund, which the payment protocol already
supports.

--001a11c25434ea8ca704de789531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jun 6, 2013 at 2:19 AM, Peter Vessenes <span dir=
=3D"ltr">&lt;<a href=3D"mailto:peter@coinlab.com" target=3D"_blank">peter@c=
oinlab.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">So, this <a href=3D"http://www.americanba=
nker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=3D1" target=
=3D"_blank">http://www.americanbanker.com/bankthink/the-last-straw-for-bitc=
oin-1059608-1.html?pg=3D1</a> =C2=A0article got posted today, noting that F=
inCEN thinks irrevocable payments are money laundering tools.=C2=A0</div>
</blockquote><div><br></div><div style>That&#39;s not how I read it, I don&=
#39;t see how one could argue that irreversible transactions are a money la=
undering tool. Credit card transactions aren&#39;t completely reversible ei=
ther, you have to either claim that the card was stolen or that the merchan=
t didn&#39;t deliver. If you charge back routinely, then the card companies=
 are supposed to crack down on you. Though I don&#39;t know if that really =
happens.</div>
<div style><br></div><div style>I think we should expect the head of FinCEN=
 to argue that more or less anything can be seen as money laundering. She d=
irectly and personally profits from expansion of the notion of money launde=
ring. That doesn&#39;t mean other people have to agree.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>At any rate, it got=
 me thinking, can we layer on revocability somehow without any protocol cha=
nge, as an opt-in?<br>
</div></div></blockquote><div><br></div><div style>I think we need 2-of-3 d=
ispute mediation and have thought that for a long time, indeed, Satoshi&#39=
;s paper says so:</div><div style><br></div><div style><a href=3D"https://e=
n.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation">https:=
//en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation</a><=
br>
</div><div style><br></div><div style>It doesn&#39;t require any core proto=
col changes but it does require deployment of the payment protocol first, a=
s that&#39;s the foundation on which we can add lots of other useful featur=
es like that. And then it needs a whole lot of work to define how you open =
a dispute from your wallet, how you find mutually agreeable mediators, etc.=
 Having reversible payments in which one of the trading parties gets to dec=
ide whether to reverse seems pointless to me. If the buyer decides it&#39;s=
 simply equivalent to post pay, and if the seller decides then it&#39;s jus=
t a refund, which the payment protocol already supports.</div>
</div></div></div>

--001a11c25434ea8ca704de789531--