joe2015 at openmailbox.org [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-03 📝 Original message:On 2016-01-03 02:46, Marco ...
📅 Original date posted:2016-01-03
📝 Original message: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. [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
📝 Original message: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. [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