MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 31 Dec 2015 00:27:50 +0800
From: joe2015@openmailbox.org
To: Marco Falke <falke.marco@gmail.com>
In-Reply-To: <CAKJqnrGUKeUb7g4SrjnWNAcPZOuLDKB-kjP2+Jy8Rdk_MfWLyQ@mail.gmail.com>
References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
	<CAKJqnrGUKeUb7g4SrjnWNAcPZOuLDKB-kjP2+Jy8Rdk_MfWLyQ@mail.gmail.com>
Message-ID: <814e1ba765445a4c3b7364c471299393@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 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.