Re: [bitcoin-dev] An implementation of BIP102 as a softfork.

[joe2015@openmailbox.org]

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