public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: David Chan <digitsu@gmail.com>
To: joe2015@openmailbox.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Generalized soft forks
Date: Thu, 31 Dec 2015 02:58:44 +0900	[thread overview]
Message-ID: <0DD6A08C-897A-49D6-BDDE-00C6B94DB281@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4930 bytes --]

                 reply	other threads:[~2015-12-30 17:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=0DD6A08C-897A-49D6-BDDE-00C6B94DB281@gmail.com \
    --to=digitsu@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=joe2015@openmailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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