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
|
Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1747DEF0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 4 Jan 2016 18:04:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com
[209.85.160.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56ECC183
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 4 Jan 2016 18:04:30 +0000 (UTC)
Received: by mail-yk0-f175.google.com with SMTP id x67so255390840ykd.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 04 Jan 2016 10:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=Zj1ysUqDH0FoeAAvttz73CIYZ5Am6WPmuEYR9ivgHDI=;
b=JHv6Nzi0illdfIpRWOhpWQMSNlKfwsV+CsRJFjzbYjPV2G4e2PHQDTJwiWQTJqRfL5
pcq/LlHUWTQJTA76F4vENMxRf6FdqQdaZW1PhpCMibHBlvAvMHAycLBeznDc4PFx64sc
KFRIxvYsfnP8U8iOvNsSQVYUaQtVq2RKJFOSuI9MFpxOzevgvJ/eg7m6mCPXkceQfyvr
30fszStbgt4lpGjLWc05rIMwwu6BLqekC5NDkgoYmb1F7lb8CCTpUtzdo3yFuV4+xs7f
H9nwveULk1Uy5s7zkWhc0A7/NyWDnY8ZLatTXTd3SjMnPlVSBqjWUzIYmdgiO/j9b5Cb
RelA==
MIME-Version: 1.0
X-Received: by 10.129.50.12 with SMTP id y12mr62638668ywy.305.1451930669661;
Mon, 04 Jan 2016 10:04:29 -0800 (PST)
Received: by 10.129.32.86 with HTTP; Mon, 4 Jan 2016 10:04:29 -0800 (PST)
In-Reply-To: <3b3d9102043577785d1b1679704eabfd@openmailbox.org>
References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
<CAKJqnrGUKeUb7g4SrjnWNAcPZOuLDKB-kjP2+Jy8Rdk_MfWLyQ@mail.gmail.com>
<814e1ba765445a4c3b7364c471299393@openmailbox.org>
<CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com>
<3b3d9102043577785d1b1679704eabfd@openmailbox.org>
Date: Mon, 4 Jan 2016 11:04:29 -0700
Message-ID: <CANN4kme78DzknfOY_kOG0Bo+v16O1McxznCi4VPq5p9HxgzuKw@mail.gmail.com>
From: Nick ODell <nickodell@gmail.com>
To: joe2015@openmailbox.org, bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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
X-Mailman-Approved-At: Mon, 04 Jan 2016 18:08:00 +0000
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: Mon, 04 Jan 2016 18:04:31 -0000
How are you collecting fees from the transactions in the block?
On Sat, Jan 2, 2016 at 8:51 PM, joe2015--- via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
