From: joe2015@openmailbox•org
To: Marco Falke <falke.marco@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
Date: Sun, 03 Jan 2016 11:51:26 +0800 [thread overview]
Message-ID: <3b3d9102043577785d1b1679704eabfd@openmailbox.org> (raw)
In-Reply-To: <CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com>
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
next prev parent reply other threads:[~2016-01-03 3:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-30 5:46 joe2015
2015-12-30 10:33 ` Marco Falke
2015-12-30 16:27 ` joe2015
[not found] ` <CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com>
2016-01-03 3:51 ` joe2015 [this message]
2016-01-04 18:04 ` Nick ODell
2016-01-05 1:26 ` joe2015
2016-01-12 3:58 ` joe2015
2015-12-30 13:29 ` Jonathan Toomim
2015-12-30 13:57 ` Marcel Jamin
2015-12-30 14:19 ` Peter Todd
2015-12-30 14:31 ` Peter Todd
2015-12-30 15:00 ` Jonathan Toomim
2015-12-30 11:16 Martijn Meijering
2015-12-30 14:28 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3b3d9102043577785d1b1679704eabfd@openmailbox.org \
--to=joe2015@openmailbox$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=falke.marco@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox