David Chan [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-30 📝 Original message:Please forgive the perhaps ...
📅 Original date posted:2015-12-30
📝 Original message:Please forgive the perhaps pedantic question but in the referred document
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
It talks about how a soft fork with >50% support will doom the other fork to being orphaned eventually but that hard forks could persist forever. I fail to see why the same logic that one side having the majority will eventually win wouldn't also apply to hard forks.
Additionally it seems to me that a notable difference between a generalized soft fork as described and a hard fork majority is in the process by which they force the other fork to be orphaned. In a hard fork an unupgraded node would know you were in a forking situation due to your node getting a lot of blocks from the other fork and having to reject them (because they are invalid) whereas in a generalized soft fork you wouldn't know there was a fork going on so there would be less of an impetus to upgrade. Of course the downside of the hard fork is that the losing side would potentially lose money in the orphaned chain, but presumably this discussion of generalized soft forks is with regards to non-mining nodes so it shouldn't come into consideration.
In fact if an non-upgraded miner were to start mining on top of that block which they cannot actually fully validate essentially this condones mining without verification (and trusting that others which have upgraded nodes to have validated the txns for you) as this situation can continue for a prolonged period of time does this not hurt network security ?
>> On 2015/12/31, at 1:27, joe2015--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151231/4526c922/attachment-0001.html>;
📝 Original message:Please forgive the perhaps pedantic question but in the referred document
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
It talks about how a soft fork with >50% support will doom the other fork to being orphaned eventually but that hard forks could persist forever. I fail to see why the same logic that one side having the majority will eventually win wouldn't also apply to hard forks.
Additionally it seems to me that a notable difference between a generalized soft fork as described and a hard fork majority is in the process by which they force the other fork to be orphaned. In a hard fork an unupgraded node would know you were in a forking situation due to your node getting a lot of blocks from the other fork and having to reject them (because they are invalid) whereas in a generalized soft fork you wouldn't know there was a fork going on so there would be less of an impetus to upgrade. Of course the downside of the hard fork is that the losing side would potentially lose money in the orphaned chain, but presumably this discussion of generalized soft forks is with regards to non-mining nodes so it shouldn't come into consideration.
In fact if an non-upgraded miner were to start mining on top of that block which they cannot actually fully validate essentially this condones mining without verification (and trusting that others which have upgraded nodes to have validated the txns for you) as this situation can continue for a prolonged period of time does this not hurt network security ?
>> On 2015/12/31, at 1:27, joe2015--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151231/4526c922/attachment-0001.html>;