[bitcoin-dev] An implementation of BIP102 as a softfork.
nickodell at gmail.com
Mon Jan 4 18:04:29 UTC 2016
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 at lists.linuxfoundation.org> wrote:
> On 2016-01-03 02:46, Marco Falke wrote:
>> 2015-12-30 17:27 GMT+01:00 <joe2015 at 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. 
>>>> 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
>>>>  https://en.bitcoin.it/wiki/Softfork#Implications
>>> It just depends how you define "softfork". In my original write-up I
>>> it a "generalized" softfork, Peter suggested a "firm" fork, and there are
>>> some suggestions for other names. Ultimately what you call it is not
>> 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
>> 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
> 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.
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
More information about the bitcoin-dev