public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Johnson Lau <jl2012@xbt.hk>
Subject: Re: [bitcoin-dev] New BIP: Hardfork warning system
Date: Thu, 1 Dec 2016 20:44:06 +0000	[thread overview]
Message-ID: <201612012044.07574.luke@dashjr.org> (raw)
In-Reply-To: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk>

On Thursday, December 01, 2016 5:20:31 PM Johnson Lau via bitcoin-dev wrote:
> Any bitcoin implementation (full nodes and light nodes) supporting this
> softfork should also implement a hardfork warning system described below.

I think this "should" needs to be a "must" be make this useful.

> Hardfork with unknown rules
> If a generalized block header chain with non-trivial total proof-of-work is
> emerging, and is not considered as a valid blockchain, a hardfork with
> unknown rules may be happening.
> 
> A wallet implementation should issue a warning to its users and stop
> processing incoming and outgoing transactions, until further instructions
> are given. It should not attempt to conduct transactions on or otherwise
> interpreting any block data of the hardfork with unknown rules.

This seems too unclear. Specifically, if an invalid chain with *equivalent or 
better* work than the best valid chain exists, nodes ought to treat all blocks 
following the common chain (between the better-invalid and best-valid chains) 
as suspect.

So if we have two chains:

    A->B->C->D (valid)
    A->B->X->Y (invalid)

The node should consider block B as the tip until the valid chain becomes and 
stays longer than the invalid one.

> A mining implementation should issue a warning to its operator. Until
> further instructions are given, it may either stop mining, or ignore the
> hardfork with unknown rules. It should not attempt to confirm a
> generalized block header with unknown rules.

I think we need to decide more specifically which behaviour is sane here.

> Hardfork warning system in light nodes
> 
> Light node (usually wallet implementations) is any bitcoin protocol
> implementations that intentionally not fully enforcing the network rules.
> As an important part of the hardfork warning system, a light node should
> observe the hardfork notification bits in block header, along with any
> other rules it opts to validate. If any of the hardfork notification bits
> is set, it should issue a warning to its users and stop processing
> incoming and outgoing transactions, until further instructions are given.
> It should not attempt to conduct transactions on or otherwise interpreting
> any block data of the hardfork blockchain, even if it might be able to
> decode the block data.

Light nodes should probably not be specified here differently than full nodes. 
If they detect an invalid block through *any* means, they should react the 
same as a full node would.

> Redefining the Merkle root hash field and changing block content validation
> rules The 32-byte Merkle root hash could be redefined, for example, with a
> different hashing algorithm. Any block resources limitation and
> transaction validation rules may also be changed. All such hardforks would
> be detected by the warning system.

Note, some changes may be needed to current nodes for this to work. I think at 
this time this would cause a "deserialisation" error, and not accept NOR 
reject the block...

> Introducing secondary proof-of-work
> Introducing secondary proof-of-work (with non-SHA256 algorithm or fixing
> the block withholding attack against mining pools) may be detectable, as
> long as the generalized block header format is preserved.

Not necessarily. A secondary PoW might drastically change the measurement of 
work. Fixing block withholding may result in block hashes that meet a preimage 
rather than bits directly. I think it may be important to fix the latter 
problem for this BIP.

> Accidental hardfork
> An accidental hardfork may be detectable, if the generalized block headers
> in both forks are valid but no hardfork notification bit is set.

Probably best to not call this a hardfork, since it is a break without 
consensus.

Luke


  parent reply	other threads:[~2016-12-01 20:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 17:20 [bitcoin-dev] New BIP: Hardfork warning system Johnson Lau
2016-12-01 18:51 ` Tom Zander
2016-12-01 20:44 ` Luke Dashjr [this message]
2016-12-02  1:42 ` Jorge Timón
2016-12-02  4:18   ` Luke Dashjr
2016-12-02  6:35     ` Jorge Timón

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=201612012044.07574.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /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