On 2016-01-03 02:46, Marco Falke wrote:
2015-12-30 17:27 GMT+01:00 <joe2...@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
