diff options
| author | Dr Adam Back <adam.back@gmail.com> | 2015-10-07 11:45:24 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-07 09:45:25 +0000 |
| commit | 242c34ae4d0e9d90b5308d69673dfaeac859a876 (patch) | |
| tree | 5ddefbc9f7acc55206ee03c547d2968e4ba37bc8 | |
| parent | 75773307c6f5d8ae517b7e39667278415d6de51b (diff) | |
| download | pi-bitcoindev-242c34ae4d0e9d90b5308d69673dfaeac859a876.tar.gz pi-bitcoindev-242c34ae4d0e9d90b5308d69673dfaeac859a876.zip | |
[bitcoin-dev] extension-blocks/sidechains & fractional/coin-cap/demurrage (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!)
| -rw-r--r-- | a5/42e3b1c9d0c8ab605f78d1845774d8f32fa4b3 | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/a5/42e3b1c9d0c8ab605f78d1845774d8f32fa4b3 b/a5/42e3b1c9d0c8ab605f78d1845774d8f32fa4b3 new file mode 100644 index 000000000..90537ce6f --- /dev/null +++ b/a5/42e3b1c9d0c8ab605f78d1845774d8f32fa4b3 @@ -0,0 +1,108 @@ +Return-Path: <adam.back@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id DC42C2194 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Oct 2015 09:45:25 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-io0-f181.google.com (mail-io0-f181.google.com + [209.85.223.181]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BECFC10E + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 7 Oct 2015 09:45:24 +0000 (UTC) +Received: by ioii196 with SMTP id i196so15916412ioi.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 07 Oct 2015 02:45:24 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:reply-to:date:message-id:subject:from:to:cc + :content-type; bh=r353xgq9nP6qHGWm29XRtrt63Y4UQjvKPTrVMK8wvPE=; + b=UhSYAhb8Thgu3hadHdzLb2ic3VsBu9/KXtDj5rmOtCj1MU7mAInxb8R7xUYJthtusn + 8gGidsxj0E8frp8uu8nExK45Xivu1FGTno5HCICtcyEwGSzFjja0+R9bTbczVnbi6t1k + //66dNQOMd7SKrV2pFY3VgBq+vs2Jawl+NnK/xb5cz/WaK/QjpjakfI8qJZhXGqCjIIE + Jw5yec0F8TidU8VFazofZoKJyB9rfaqv2/1U8KNVueKqCrRt2GoQ5N83S1tPTgLhlqTk + 7dRfo7XTc/sOUUtl2NI0j/fTB+qIpaYe3rGqjUp7hPTXMSDoJqvoV2fs0qnfrMrtyNnx + 7XDw== +MIME-Version: 1.0 +X-Received: by 10.107.128.106 with SMTP id b103mr679825iod.116.1444211124178; + Wed, 07 Oct 2015 02:45:24 -0700 (PDT) +Received: by 10.50.85.135 with HTTP; Wed, 7 Oct 2015 02:45:24 -0700 (PDT) +Reply-To: adam@cypherspace.org +Date: Wed, 7 Oct 2015 11:45:24 +0200 +Message-ID: <CALqxMTFAb5_AQfH1ZfWAC6JscttG6puaJGbS43WDZRt9h7cRQg@mail.gmail.com> +From: Dr Adam Back <adam.back@gmail.com> +To: Micha Bailey <michabailey@gmail.com> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_NAME_FM_DR, + RCVD_IN_DNSWL_LOW autolearn=no 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: [bitcoin-dev] extension-blocks/sidechains & + fractional/coin-cap/demurrage (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!) +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: Wed, 07 Oct 2015 09:45:26 -0000 + +Micha I think you are correct, I dont think extension blocks (or +sidechains for that matter) can allow soft-fork increase of the total +Bitcoins in the system, because the main chain still enforces the 21m +coin cap. A given extension block could go fractional, but if there +was a run to get out, the last users out will lose, or they'll all +take a hair-cut etc. So presumably users would decline to use an +extension block with fractional bitcoin. + +I mean you could view it like say an exchange (mtgox?) that somehow +accidentally or intentionally creates fictional Bitcoin IOUs in it's +system, eg in some kind of pyramid scheme - that doesnt create more +Bitcoins, it just means people who think they have IOUs for real +Bitcoins, are fractional or fake. With an extension block or +sidechain furthermore it is transparent so they will know they are +fractional. + +Relatedly it seems possible to implement a sidechain with advertised +demurrage, with an exit or entrance fee to discourage holding outside +of the chain to avoid demurrage. There are apparently economic +arguments for why people might opt in to that (higher velocity +economic activity, gresham's law, merchants offering discounts for +buying with demurrage Bitcoins, maybe lower per transaction fees +because say miners can mine the demurrage). However that is a +different topic, again not changing the number of coins in +circulation. + +Adam + + +On 7 October 2015 at 08:13, Micha Bailey via bitcoin-dev +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> +> +> On Monday, October 5, 2015, Mike Hearn via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> +>>> As Greg explained to you repeatedly, a softfork won't cause a +>>> non-upgraded full node to start accepting blocks that create more +>>> subsidy than is valid. +>> +>> +>> It was an example. Adam Back's extension blocks proposal would, in fact, +>> allow for a soft forking change that creates more subsidy than is valid (or +>> does anything else) by hiding one block inside another. +> +> +> Maybe I'm missing something, but wouldn't this turn into a hard fork the +> moment you try to spend an output created in one of these extension blocks? +> So sure, the block that contains the extension would be considered valid, +> but unupgraded validators will not update the UTXO set accordingly, meaning +> that those new TXOs can't be spent because, according to their rules, they +> don't exist. + |