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
189
190
191
192
|
Return-Path: <trevinhofmann@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CC47CFF9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 19:19:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E9CFE1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 19:19:46 +0000 (UTC)
Received: by mail-wm0-f49.google.com with SMTP id p63so88007598wmp.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Feb 2016 11:19:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=bw5p6IOrtTo/QmCXRbjbEU6R6yiXnp/Fi4BfXvko15o=;
b=pn1xSFiqc+5153kCFWs5OnF69w2VuarYDDkee1MuWf9Y9kF0Kzlhedfd0roRDSgP3J
JaVOhvIk3kGHGaO0erfSnlgsOYPPJwYTVYzRROoxemZbGBzkPwHeb56XMEmG+4WPUg+B
nxnt6K+Z6Y1LZ9ddtuCYR9N1zh0+/uVhzVKgny0NaZVaQEAHBeuhxazzP+FYaAes48My
TG6SV/el32WRQZwTXUUjREKVI5UDVXhwijENWTcUILYookj7YAz495zxcjAIVALc3iXz
5/+hJbT1ruxpaSxj48d66pwSdTUFl8Rz2Y6JL7ArzsQlxR8GEHu6xpvmFVcebcETBah7
Pr1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=bw5p6IOrtTo/QmCXRbjbEU6R6yiXnp/Fi4BfXvko15o=;
b=BXDdL07KU2dMbcHRQ6ySmM2ZUsF7S+tE63Ti0UkmsZJpoIBslBiED7hM2hKPgXg2jS
NkRUR9zfHgv1r84BRi12q1iPTD7DYhWIBSd2txqBLk5/xeJcV0QHQCzta7AgSYboPIl+
4Lmz206zbf43FWtaCgzT/O4E9x33di8/9TRDmnwVvTWOhvFwt/vSJLzBCq2Om9uFNo9e
MF0md35x1/uFADYciY1JCsjnYU/GVCS60hlKt7zmTpZXv4wmfLbP9nBqfwVhm6FdWm97
VGDbu6D8Pw338FvTYGuRrai4HCrIsF6m6byxwO4JkpvXVDAA92foRudA+5Q2Gdbg51VR
hqJQ==
X-Gm-Message-State: AG10YOTw+nXdSOvoH21kHSIoCeb0NV3SvbWLxRHSphML4PJVLRr/uI4bsbV4inmi1DU97QpvBIZN0HYUmV9jVA==
MIME-Version: 1.0
X-Received: by 10.194.133.233 with SMTP id pf9mr24447889wjb.75.1454872785051;
Sun, 07 Feb 2016 11:19:45 -0800 (PST)
Received: by 10.194.66.167 with HTTP; Sun, 7 Feb 2016 11:19:44 -0800 (PST)
In-Reply-To: <56B7951A.2090800@gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
<201602060012.26728.luke@dashjr.org>
<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
<CABeL=0i8_Ns25=OaXG86uSsQKzPA2YbTU_zRj6k6K48aYhw3wA@mail.gmail.com>
<7E723AB3-ED80-40CE-B5BD-DD5F69486C16@toom.im>
<56B7951A.2090800@gmail.com>
Date: Sun, 7 Feb 2016 13:19:44 -0600
Message-ID: <CALd2G5fX+_kCL52t0DVobE28bJ2UVLB7jYBktP=mLg1jMzrMkg@mail.gmail.com>
From: Trevin Hofmann <trevinhofmann@gmail.com>
To: Patrick Strateman <patrick.strateman@gmail.com>
Content-Type: multipart/alternative; boundary=089e012292d08bec3c052b32f796
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 07 Feb 2016 20:08:07 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2016 19:19:48 -0000
--089e012292d08bec3c052b32f796
Content-Type: text/plain; charset=UTF-8
Patrick,
I would say that a company's terms of service should include their position
on this issue. It does not seem reasonable that they all are required to
provide access to coins on every single fork. Are custodial wallet users
also entitled to Clam, Zcash, and Decred, and others?
Regardless, I think this thread should be about the technical merits of the
BIP. Discussion of hard forks would be better held elsewhere.
On Sun, Feb 7, 2016 at 1:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would expect that custodians who fail to produce coins on both sides
> of a fork in response to depositor requests will find themselves in
> serious legal trouble.
>
> Especially if the price moves against either fork.
>
> On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
> >
> > On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >> They *must* be able to send their customers both coins as separate
> >> withdrawals.
> >>
> > Supporting the obsolete chain is unnecessary. Such support has not
> > been offered in any cryptocurrency hard fork before, as far as I know.
> > I do not see why it should start now.
> >>
> >> If not, that amounts to theft of their customers funds.
> >>
> > If they announce their planned behavior before the fork, I do not see
> > any ethical or legal issues.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e012292d08bec3c052b32f796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Patrick,<div><br></div><div>I would say that a company'=
;s terms of service should include their position on this issue. It does no=
t seem reasonable that they all are required to provide access to coins on =
every single fork. Are custodial wallet users also entitled to Clam, Zcash,=
and Decred, and others?</div><div><br></div><div>Regardless, I think this =
thread should be about the technical merits of the BIP. Discussion of hard =
forks would be better held elsewhere.</div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sun, Feb 7, 2016 at 1:03 PM, Patrick Str=
ateman via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would exp=
ect that custodians who fail to produce coins on both sides<br>
of a fork in response to depositor requests will find themselves in<br>
serious legal trouble.<br>
<br>
Especially if the price moves against either fork.<br>
<br>
On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:<br>
><br>
> On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
> <mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>>> wrote:<br>
><br>
>> They *must* be able to send their customers both coins as separate=
<br>
>> withdrawals.<br>
>><br>
> Supporting the obsolete chain is unnecessary. Such support has not<br>
> been offered in any cryptocurrency hard fork before, as far as I know.=
<br>
> I do not see why it should start now.<br>
>><br>
>> If not, that amounts to theft of their customers funds.<br>
>><br>
> If they announce their planned behavior before the fork, I do not see<=
br>
> any ethical or legal issues.<br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
--089e012292d08bec3c052b32f796--
|
