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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
Return-Path: <venzen@mail.bihthai.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 37012104D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Oct 2015 10:13:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bihthai.net (unknown [5.255.87.244])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5C46090
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Oct 2015 10:13:20 +0000 (UTC)
Received: from [10.8.0.6] (unknown [10.8.0.6])
by mail.bihthai.net (Postfix) with ESMTP id D96C48070D;
Wed, 7 Oct 2015 10:13:16 +0000 (UTC)
Reply-To: venzen@mail.bihthai.net
References: <CALqxMTFAb5_AQfH1ZfWAC6JscttG6puaJGbS43WDZRt9h7cRQg@mail.gmail.com>
To: adam@cypherspace.org, Dr Adam Back <adam.back@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
From: Venzen Khaosan <venzen@mail.bihthai.net>
Openpgp: id=9BF4C669F5A36817CD2465186C0086541CF07D66;
url=pool.sks-keyservers.net
X-Enigmail-Draft-Status: N1110
Organization: Bihthai Bai Mai
Message-ID: <5614F03B.5010405@mail.bihthai.net>
Date: Wed, 7 Oct 2015 17:13:15 +0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CALqxMTFAb5_AQfH1ZfWAC6JscttG6puaJGbS43WDZRt9h7cRQg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [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 10:13:21 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Exactly,
In the coming fee market crunch, any speculator would trade an
extended block in the implied direction and also hedge in the opposite
direction in case it gets rejected.
The speculative public will most likely trade in the same direction,
initially, but arbitrage and futures markets perspectives (generally
more informed) will go the opposite way and create a new chart pattern
that will precede contrarian price motion.
In the end, as the community illusion of non-interdependce fades, we'd
expect bitcoin price to tend to its natural condition: parity with the
most powerful fiat currency out there: the psychological King, the US
dollar.
After decades we could expect an inverse correlation to develop as the
majority world moves from paper to digital - barring a critical
survival event such as a solar EMP, which is due, but which I reserve
judgement upon for investment purposes.
You can buy coffee with XT bitcoins, but that is really small-minded
behavior in the current deflationary environment... Mike Hearn, you
economic imbicile, give me 15 minutes with you in public and I will
knock you out of the Bitcoin space forever...
Venzen Khaosan
On 10/07/2015 04:45 PM, Dr Adam Back via bitcoin-dev wrote:
> 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.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWFPA4AAoJEGwAhlQc8H1m6VMH+wXreRpLb8VweIxVJ9mDJL2g
d3rfhLL+50gZTt8csYJ7f/0BzbcS7nICOlvqn3PLAIu+Usr06iPIJSfHezvJ0GvE
gbspU4lNZArScPjOVhrigrQVuN75KM2a84QW/hf/5Epf6rXWnClqc+IR/I33V/Yg
0LUUFcmSXjOHVE18Yh3PB0ELY5I8/JYSzYX0dTu5qpbWzcjXUDfCfqewLKEgveZB
+QGVrvMDPNxnx1AvMuMsmP3el/lvaNBTtuVjKhYZEgF8NhFB4hm/nLRSrMFOuBju
vZlE8gbAQQlShCicuanL+l8KHiUi4/o3O5dIGoI/FwVoiXDK88158hpDLh1slv0=
=GUI4
-----END PGP SIGNATURE-----
|
