From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 68350FA9 for ; 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 ; Sun, 7 Feb 2016 20:29:42 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id mw1so45567290igb.1 for ; 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: <201602060012.26728.luke@dashjr.org> <7E723AB3-ED80-40CE-B5BD-DD5F69486C16@toom.im> <56B7951A.2090800@gmail.com> Date: Sun, 7 Feb 2016 20:29:42 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. This email has been sent from a virus-free computer protected by Avast. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> --089e0122eab0b8e871052b33f1e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, 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 prod= uce coins on both sides
of a fork in response to depositor requests will find themselves in
serious legal trouble.

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.

As long= as the exchange doesn't accidently double spend an output, even change= addresses are valid.

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.
The easiest thing would be to refuse to accept deposits fo= r a while before/after the fork happens.
This email has been = sent from a virus-free computer protected by Avast.
www.avas= t.com
--089e0122eab0b8e871052b33f1e3--