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>
User-Agent: Roundcube Webmail/1.0.6
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
Precedence: list

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