diff options
| author | Hector Chu <hectorchu@gmail.com> | 2015-08-01 09:43:56 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-01 08:44:19 +0000 |
| commit | ca35b8c2930e0e9edb2535bcfb76349fe379b5e6 (patch) | |
| tree | b94a16962448bac83959eef002b2c3290f59d899 | |
| parent | 0991c29f6901836cf1e1ee7ed0799c15759889b8 (diff) | |
| download | pi-bitcoindev-ca35b8c2930e0e9edb2535bcfb76349fe379b5e6.tar.gz pi-bitcoindev-ca35b8c2930e0e9edb2535bcfb76349fe379b5e6.zip | |
Re: [bitcoin-dev] Block size hard fork
| -rw-r--r-- | 34/ddb654d44d628b69d3c7b5436edac8fca42003 | 161 |
1 files changed, 161 insertions, 0 deletions
diff --git a/34/ddb654d44d628b69d3c7b5436edac8fca42003 b/34/ddb654d44d628b69d3c7b5436edac8fca42003 new file mode 100644 index 000000000..70abde52e --- /dev/null +++ b/34/ddb654d44d628b69d3c7b5436edac8fca42003 @@ -0,0 +1,161 @@ +Return-Path: <hectorchu@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 18C419C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Aug 2015 08:44:19 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com + [209.85.217.171]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 020608F + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 1 Aug 2015 08:44:17 +0000 (UTC) +Received: by lbqc9 with SMTP id c9so32406277lbq.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 01 Aug 2015 01:44:16 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc:content-type; + bh=r2CgLAN0lkJ/BJSrEyk8R/MvTt/Ta/clOvdaU34EjL0=; + b=v2FI4BndjvJDJ6nnZ8+U0uVyXOWZBzUFP6k0IcgHN3lAfO4t5GfTkbly0A8MfHTN6z + gkHEd7kjeM8Q3TuBtx7bTUXDgOkdSihUqOKTbCdsHr7k5kz0EQgtk4R19mJJmfd9kOew + qUy+2uuk3Q0BEBEE8KNzw2ypAdB1bPo9x3wrXkIRzTBW8x/pgLoQHvpAQYzXGtvQr+0g + TbE7Xlb8ZHeGb7jyzbnS9OsvQ5k5n154yOAp/9S7khO92koG7Rwj9rInBApi5aR8ghSX + QgZ0rDYc+XBd+ImUeYjjd0gUoE5+o10nbhWXc3dZhfrvJZHVheEcOCQW5v7F4cB+cOMX + T/3A== +X-Received: by 10.152.182.194 with SMTP id eg2mr7465337lac.71.1438418656260; + Sat, 01 Aug 2015 01:44:16 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.25.21.94 with HTTP; Sat, 1 Aug 2015 01:43:56 -0700 (PDT) +In-Reply-To: <CAAS2fgQL_0W0i5j0DVBY2dVtZzBj6sryycMG3Q-5KrTd1tpWaw@mail.gmail.com> +References: <CAAO2FKFQjjftgEgZoDAUrMxa86KTbNzAqg+xgExTRPpGxedwRw@mail.gmail.com> + <CAAS2fgQL_0W0i5j0DVBY2dVtZzBj6sryycMG3Q-5KrTd1tpWaw@mail.gmail.com> +From: Hector Chu <hectorchu@gmail.com> +Date: Sat, 1 Aug 2015 09:43:56 +0100 +Message-ID: <CAAO2FKH4txfNxz9H51YPm+5hMaZ+w16gBhpF5ztvbef4ar3K8w@mail.gmail.com> +To: Gregory Maxwell <gmaxwell@gmail.com> +Content-Type: multipart/alternative; boundary=001a113491f20b79f5051c3bf1ae +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 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Block size hard fork +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: Sat, 01 Aug 2015 08:44:19 -0000 + +--001a113491f20b79f5051c3bf1ae +Content-Type: text/plain; charset=UTF-8 + +On 1 August 2015 at 01:17, Gregory Maxwell <gmaxwell@gmail.com> wrote: + +> One can quite easily transact in a way to intentionally produce such a +> split to seperate the existance of your coins onto the seperate forks; +> just as anyone would need to do to perform a reorg-and-respend attack +> on a single blockchain. +> + +Right. Why anyone would want to do this intentionally, however, is not +clear. The coins would be worth less as they wouldn't be fungible across +the chains anymore. + +Additionally, new coins will be issued, along with fees, on both +> chains. These new outputs become spendable after 100 blocks, and any +> transaction spending them can exist exclusively on one chain. +> + +This is something that hadn't entered my mind when I made my assertions. At +the moment I can't see any way to avoid this fact. + +Also any transaction whos casual history extends from one of the above +> cases can exist only on one chain. This also means that someone who +> has single-chain coins (via a conflict or from coinbase outputs) can +> pay small amount to many users to get their wallets to consume them +> and make more of the transactions single chain only-- if they wanted +> the process to happen faster. +> + +Wallets could detect this and notify the user. Due to Gresham's Law, I'll +admit the observation that these outputs would likely get spent in +preference (as they are less fungible), but whether the payee would be +happy to accept them is a different matter. + +> Miners will migrate to the bigger chain in search of higher profits due +> to higher volume of fees +> +> The migration remark is a considerable oversimplification. Imagine if +> I released a version of the software programmed to reassign ownership +> of a million of the earliest created unmoved coins to me at block +> 400k, and then after that I made transaction to pay 5 coin/block in +> fees. Would miners move to this chain? It pays more in fees! +> + +Well in your example they wouldn't, because they know that your version +wouldn't be accepted by the economic majority. But it's not as clear cut +for the larger blocks case. They may move over gradually as they see the +new chain gain acceptance, demonstrated by the higher trading volume on it. + +--001a113491f20b79f5051c3bf1ae +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 1= + August 2015 at 01:17, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mai= +lto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span>= + wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= +der-left:1px #ccc solid;padding-left:1ex">One can quite easily transact in = +a way to intentionally produce such a<br> +split to seperate the existance of your coins onto the seperate forks;<br> +just as anyone would need to do to perform a reorg-and-respend attack<br> +on a single blockchain.<br></blockquote><div><br></div><div>Right. Why anyo= +ne would want to do this intentionally, however, is not clear. The coins wo= +uld be worth less as they wouldn't be fungible across the chains anymor= +e.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 = +0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Additionally, new coins will be issued, along with fees, on both<br> +chains. These new outputs become spendable after 100 blocks, and any<br> +transaction spending them can exist exclusively on one chain.<br></blockquo= +te><div><br></div><div>This is something that hadn't entered my mind wh= +en I made my assertions. At the moment I can't see any way to avoid thi= +s fact.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> +Also any transaction whos casual history extends from one of the above<br> +cases can exist only on one chain. This also means that someone who<br> +has single-chain coins (via a conflict or from coinbase outputs) can<br> +pay small amount to many users to get their wallets to consume them<br> +and make more of the transactions single chain only-- if they wanted<br> +the process to happen faster.<br></blockquote><div><br></div><div>Wallets c= +ould detect this and notify the user. Due to Gresham's Law, I'll ad= +mit the observation that these outputs would likely get spent in preference= + (as they are less fungible), but whether the payee would be happy to accep= +t them is a different matter.</div><div><br></div><blockquote class=3D"gmai= +l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= +:1ex"><span class=3D""> +> Miners will migrate to the bigger chain in search of higher profits du= +e to higher volume of fees<br> +<br> +</span>The migration remark is a considerable oversimplification. Imagine i= +f<br> +I released a version of the software programmed to reassign ownership<br> +of a million of the earliest created unmoved coins to me at block<br> +400k, and then after that I made transaction to pay 5 coin/block in<br> +fees. Would miners move to this chain?=C2=A0 It pays more in fees!<br></blo= +ckquote><div><br></div><div>Well in your example they wouldn't, because= + they know that your version wouldn't be accepted by the economic major= +ity. But it's not as clear cut for the larger blocks case. They may mov= +e over gradually as they see the new chain gain acceptance, demonstrated by= + the higher trading volume on it.=C2=A0</div></div><br></div></div> + +--001a113491f20b79f5051c3bf1ae-- + |