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 CC47CFF9 for ; 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 ; Sun, 7 Feb 2016 19:19:46 +0000 (UTC) Received: by mail-wm0-f49.google.com with SMTP id p63so88007598wmp.1 for ; 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: <201602060012.26728.luke@dashjr.org> <7E723AB3-ED80-40CE-B5BD-DD5F69486C16@toom.im> <56B7951A.2090800@gmail.com> Date: Sun, 7 Feb 2016 13:19:44 -0600 Message-ID: From: Trevin Hofmann To: Patrick Strateman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > > > 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
Patrick,

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?

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 Str= ateman via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.org> wrote:
I would exp= ect 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-d= ev@lists.linuxfoundation.org
> <mailto:bi= tcoin-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<= br> > any ethical or legal issues.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e012292d08bec3c052b32f796--