summaryrefslogtreecommitdiff
path: root/28/ec6eb9f919f975df044e54fc18f661866e8bac
blob: 67eb1eb6fd91560ac1c6187fa0025cf217a3ac2d (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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <calebdelisle@lavabit.com>) id 1UkpV8-0008EP-DM
	for bitcoin-development@lists.sourceforge.net;
	Fri, 07 Jun 2013 05:46:14 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of lavabit.com
	designates 72.249.41.33 as permitted sender)
	client-ip=72.249.41.33; envelope-from=calebdelisle@lavabit.com;
	helo=karen.lavabit.com; 
Received: from karen.lavabit.com ([72.249.41.33])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UkpV6-00044D-ME for bitcoin-development@lists.sourceforge.net;
	Fri, 07 Jun 2013 05:46:14 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
	by karen.lavabit.com (Postfix) with ESMTP id 6455411BB86
	for <bitcoin-development@lists.sourceforge.net>;
	Fri,  7 Jun 2013 00:46:07 -0500 (CDT)
Received: from 192.168.1.6 (c-174-62-136-247.hsd1.ct.comcast.net
	[174.62.136.247]) by lavabit.com with ESMTP id 6FPAPQ8T2UHH
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 07 Jun 2013 00:46:07 -0500
Message-ID: <51B1739C.5000909@lavabit.com>
Date: Fri, 07 Jun 2013 01:46:04 -0400
From: Caleb James DeLisle <calebdelisle@lavabit.com>
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: <CAMGNxUv7wkiUYZ2nZjOP0mEW7bgR0a+CXKyDPq38joU-fMMQ9Q@mail.gmail.com>
	<CAKaEYhKiRutKYeQjLocJJ0L2Yra790WnUiF5Px64Kxv7Q-0z8w@mail.gmail.com>
In-Reply-To: <CAKaEYhKiRutKYeQjLocJJ0L2Yra790WnUiF5Px64Kxv7Q-0z8w@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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 FSL_HELO_BARE_IP_2     FSL_HELO_BARE_IP_2
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [72.249.41.33 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-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: 1UkpV6-00044D-ME
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: Fri, 07 Jun 2013 05:46:14 -0000

IMO this story falls somewhere between rose colored glasses and outright trolling.
Whereas LR was a (relatively shady) company, bitcoin is an entire branch of technology
and research, I can't think of any real caselaw in the US with regards to banning a
technology, perhaps the cryptography export regulation and we all know how well that
worked. Furthermore, the non-reversibility of LR is mostly because they didn't want
to deal with mediation while the non-reversibility of bitcoin is technological barrier.

It seems AmericanBanker has a record of hosting articles which urge policy decisions:
  http://www.americanbanker.com/bankthink/governments-must-co-opt-bitcoin-to-avert-disaster-1058380-1.html
that would obviously be of personal benefit to the article's author:
  http://www.clearbit.com/company_management.htm
It is the very job of governments to resist the efforts of lobbyists to line their
pockets at the public expense.

While I don't think significant risk of developed countries actually banning an entire
area of research such as bitcoin, I do suspect that bitcoin's popularity lead to LR's
downfall as it will other companies which allow people to transact anonymously.


The tragedy of bitcoin's irreversibility is that it makes kidnap/ransom schemes
profitable. The relative safety of the first world is largely due to the fact that
until now, there has never been any effective way to steal significant amounts of
money. While this problem is serious I don't think it's intractable. Bitcoin offers
us a modeling tool which like never before allows us to experiment with our
motivations and build something better than even bitcoin is today.

I believe regulators are intelligent people who understand this and would rather
legitimize bitcoin than ban it. If there ever were such a ban, I would be more
concerned for the future of the country imposing it than I would for bitcoin.


Thanks,
Caleb

tl;dr haters gonna hate



On 06/06/2013 06:22 PM, Melvin Carvalho wrote:
> 
> 
> 
> On 6 June 2013 02:19, Peter Vessenes <peter@coinlab.com <mailto: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
> 
>     -- 
> 
>     --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
>     CoinLab LogoPETER VESSENES 
>     CEO
> 
>     *peter@coinlab.com <mailto:peter@coinlab.com> * /  206.486.6856 <tel: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 <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
>