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

From: Nick ODell <nickodell@gmail•com>
To: joe2015@openmailbox•org, bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
Date: Mon, 4 Jan 2016 11:04:29 -0700	[thread overview]
Message-ID: <CANN4kme78DzknfOY_kOG0Bo+v16O1McxznCi4VPq5p9HxgzuKw@mail.gmail.com> (raw)
In-Reply-To: <3b3d9102043577785d1b1679704eabfd@openmailbox.org>

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