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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 68350FA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 20:29:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com
[209.85.213.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3775A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 20:29:42 +0000 (UTC)
Received: by mail-ig0-f170.google.com with SMTP id mw1so45567290igb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 Feb 2016 12:29:42 -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:cc
:content-type; bh=2DUQv7WgeXWJAWcPoFIArXX3iTf8KA4fQhWnXnojpMk=;
b=L2IZ5q95Ofx58vp+YzDgw6RP+I1JbK1oF+WPv39G7nByFlAZYmbUz38WrV3zyD+FEf
lkXqgPHgLQ6e6zKdKReN1Czjg9WPD+egz2nSJT99MwuRtsQzYDIB93xvcgmqLyRMSboG
7ZFz5PjKF7y1Nme7f+N1WTx01Qp8BjXnt79PGOT9M3CDvmkL8NmXf0IlC0GOGTgXntnB
j15DoLIwIjTXCkMu3BxG43cqqSOBqd7UY5gnKx48X27Hd3g6Xw6SWX9y4rha7JYLuPNb
a9pp+VYMKEES4W1XYW0QSOFLHtL4lNojk3GFZN3pf2U1lK80VEeft9BdFCR6pYHaJTzs
vOkQ==
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:cc:content-type;
bh=2DUQv7WgeXWJAWcPoFIArXX3iTf8KA4fQhWnXnojpMk=;
b=X15OVwYwHn9bOLHBjUC8PMPb2kuONs64eQ59n24IinrQwrV8biYCU1zk+6DNVou1j/
oZKpRMaJRPijIH3aqyyyQJZA41k8YTytJqO6E134bM6/jXbW50yqf58hK/75zAa+acoT
fFdVPGeynDv/+EcYSpCJabd/tVAZ0xeKjgYsjgBNiIaW9oVdTExsoqCKLJ24u4iObo61
cfJK+y3m2Ng1+ElnOxQ6Qp2TUUNSlDzyYNFRyRNKZ1kx2mxw/vS/XSiw2QmxLxAT0ORf
x2uk0IPI3P6TdbLWlSP33YNF7x6Z2o4+uRqKJyZgEY4tT9VwHiypxUmayZj3W+4jzL9G
OFFg==
X-Gm-Message-State: AG10YORKgfv0oaM7RDXWNLnHVDO00AMtf0bihGBScJFHPh/q30N3bNNWfpKf++0JLfOfFqXzkX0qBcLj1QqSfw==
MIME-Version: 1.0
X-Received: by 10.50.40.8 with SMTP id t8mr26329968igk.26.1454876982302; Sun,
07 Feb 2016 12:29:42 -0800 (PST)
Received: by 10.79.77.65 with HTTP; Sun, 7 Feb 2016 12:29:42 -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 20:29:42 +0000
Message-ID: <CAE-z3OWMyqHLAdd9+qqGN_oEXKb+MReGSANSQT9MxxiF6gHAhg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e0122eab0b8e871052b33f1e3
X-Spam-Status: No, score=2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_IMAGE_ONLY_24,
HTML_MESSAGE,
HTML_SHORT_LINK_IMG_3, MALFORMED_FREEMAIL, MISSING_HEADERS,
RCVD_IN_DNSWL_LOW, T_REMOTE_IMAGE autolearn=no version=3.3.1
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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 20:29:43 -0000
--089e0122eab0b8e871052b33f1e3
Content-Type: text/plain; charset=UTF-8
On Sun, Feb 7, 2016 at 7: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.
>
If the exchange uses an UTXO from before the fork to pay their clients,
then they are guaranteed to count as paying on all forks. The exchange
doesn't need to specifically pay out for each fork.
As long as the exchange doesn't accidently double spend an output, even
change addresses are valid.
It is handling post-fork deposits where the problem can occur. If they
only receive coins on one fork, then that should cause the client to be
credited with funds on both forks.
The easiest thing would be to refuse to accept deposits for a while
before/after the fork happens.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--089e0122eab0b8e871052b33f1e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev <span dir=3D"=
ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">I would expect that custodians who fail to prod=
uce coins on both sides<br>
of a fork in response to depositor requests will find themselves in<br>
serious legal trouble.<br></blockquote><div><br></div><div></div><div>If th=
e exchange uses an UTXO from before the fork to pay their clients, then the=
y are guaranteed to count as paying on all forks.=C2=A0 The exchange doesn&=
#39;t need to specifically pay out for each fork.<br><br></div><div>As long=
as the exchange doesn't accidently double spend an output, even change=
addresses are valid.<br><br></div><div>It is handling post-fork deposits w=
here the problem can occur.=C2=A0 If they only receive coins on one fork, t=
hen that should cause the client to be credited with funds on both forks.<b=
r><br></div><div>The easiest thing would be to refuse to accept deposits fo=
r a while before/after the fork happens. <br></div></div></div></div><div i=
d=3D"DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><table style=3D"border-top:1px s=
olid #aaabb6;margin-top:30px">
<tr>
<td style=3D"width:105px;padding-top:15px">
<a href=3D"https://www.avast.com/sig-email" target=3D"_blank"><img src=
=3D"https://ipmcdn.avast.com/images/logo-avast-v1.png" style=3D"width: 90px=
; height:33px;"></a>
</td>
<td style=3D"width:470px;padding-top:20px;color:#41424e;font-size:13px;fo=
nt-family:Arial,Helvetica,sans-serif;line-height:18px">This email has been =
sent from a virus-free computer protected by Avast. <br><a href=3D"https://=
www.avast.com/sig-email" target=3D"_blank" style=3D"color:#4453ea">www.avas=
t.com</a>
</td>
</tr>
</table><a href=3D"#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width=3D"1" heigh=
t=3D"1"></a></div>
--089e0122eab0b8e871052b33f1e3--
|
