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
|
Return-Path: <joe2015@openmailbox.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 070EB127F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Jan 2016 03:51:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from smtp13.openmailbox.org (smtp13.openmailbox.org [62.4.1.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5AE2711A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Jan 2016 03:51:39 +0000 (UTC)
Received: by mail2.openmailbox.org (Postfix, from userid 1004)
id AF4A62AC281F; Sun, 3 Jan 2016 04:51:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org;
s=openmailbox; t=1451793096;
bh=+heZvLkZ1on+UxcOuPY2FAoohj0eDz1AnLZiXMf4GyI=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=adUkE+wmYgGVftQn9pK/HKF3Wb88STVpG+t2P41jjPx0LFI7S1toGFoxWEHsO7NZF
cb+7QW4y+J5z5kHWDsuFGMarS+/pkFCMUZEOlUzHhIZDdqg8jovzpEaRIxDTy7FTpQ
HKmS5HL1QVriQhI4sChb+0p8Hz+5ruWAWa1mXDOA=
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from www.openmailbox.org (openmailbox-b1 [10.91.69.218])
by mail2.openmailbox.org (Postfix) with ESMTP id 64D122AC1494;
Sun, 3 Jan 2016 04:51:26 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 03 Jan 2016 11:51:26 +0800
From: joe2015@openmailbox.org
To: Marco Falke <falke.marco@gmail.com>
In-Reply-To: <CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com>
References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
<CAKJqnrGUKeUb7g4SrjnWNAcPZOuLDKB-kjP2+Jy8Rdk_MfWLyQ@mail.gmail.com>
<814e1ba765445a4c3b7364c471299393@openmailbox.org>
<CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com>
Message-ID: <3b3d9102043577785d1b1679704eabfd@openmailbox.org>
X-Sender: joe2015@openmailbox.org
User-Agent: Roundcube Webmail/1.0.6
X-Mailman-Approved-At: Sun, 03 Jan 2016 14:17:42 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
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: Sun, 03 Jan 2016 03:51:40 -0000
On 2016-01-03 02:46, Marco Falke wrote:
> 2015-12-30 17:27 GMT+01:00 <joe2015@openmailbox.org>:
>> On 2015-12-30 18:33, Marco Falke wrote:
>>>
>>> This is an interesting approach but I don't see how this is a soft
>>> fork. (Just because something is not a hard fork, doesn't make it a
>>> soft fork by definition)
>>> Softforks don't require any nodes to upgrade. [1]
>>> Nonetheless, as I understand your approach, it requires nodes to
>>> upgrade. Otherwise they are missing all transactions but the coinbase
>>> transactions. Thus, they cannot update their utxoset and are easily
>>> susceptible to double spends...
>>>
>>> Am I missing something obvious?
>>>
>>> -- Marco
>>>
>>>
>>> [1] https://en.bitcoin.it/wiki/Softfork#Implications
>>
>>
>> It just depends how you define "softfork". In my original write-up I
>> called
>> it a "generalized" softfork, Peter suggested a "firm" fork, and there
>> are
>> some suggestions for other names. Ultimately what you call it is not
>> very
>> important.
>>
>> --joe.
>
> joe, indeed it is not important how you call it, but please, let's not
> call it "soft fork".
This kind of fork (whatever it is called) has all the traditional
properties of a softfork except meaningful backwards compatibility for
non-upgraded clients. So I think it is reasonable to call it a softfork
with some qualification.
> Besides my initial question about the coinbase
> tx, I was also wondering how non-updated nodes would verify the
> collected fees without the actual txs at hand. (They only have the
> coinbase tx, don't they?)
Yes this appears to be an oversight in my proof-of-concept
implementation. The unintended consequence being that all transactions
would have to be zero-fee...
The simplest fix would be make the new rules add the fees implicitly.
There are other solutions.
> Moreover, I can't see the benefits over a hard fork. A hard fork is
> much cleaner in regard to code changes. As one of the intends of
> "generalized soft forks" is to force user to update, at least a hard
> fork doesn't lie about the fact. Am I missing any obvious advantages
> of a "generalized soft fork" over a "clean" hard fork?
A "firm soft fork" also does not lie about that fact -- you must
upgrade. I don't see it dishonest if it was never claimed otherwise.
I agree that hardforks can be "cleaner".
However the obvious disadvantage of a hardfork is the risk of the
network splitting between upgraded and non-upgraded clients. This is
not a problem if there is 100% consensus behind the hardfork, but I am
not sure if 100% is realistically achievable for contentious issues such
as the blocksize limit.
If 100% consensus is never achieved, then the options are:
1. Never upgrade and keep the blocksize limit unchanged forever.
2. Use a firm softfork to resolve the deadlock.
3. Hardfork anyway and split the network.
My argument is simply that 2 is better than 3 and possibly 1.
--joe
|
