1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
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.
|
