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 <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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
