MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
Precedence: list

--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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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&#39;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--