On Fri, Dec 2, 2016 at 5:18 AM, Luke Dashjr wrote:
> On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote:
>> We can already warn users of a hardfork when a block is invalid (at
>> least) because of the highest bit in nVersion (as you say, because it
>> is forbidden since bip3
On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote:
> We can already warn users of a hardfork when a block is invalid (at
> least) because of the highest bit in nVersion (as you say, because it
> is forbidden since bip34 was deployed).
The difference is that right now, full
We can already warn users of a hardfork when a block is invalid (at
least) because of the highest bit in nVersion (as you say, because it
is forbidden since bip34 was deployed). It seems the softfork serves
only to warn about soft-hardforks, assuming it chooses to use this
mechanism (which a malici
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.
> Hard
I am failing to see how you actually will detect a hard fork with this
system.
Maybe its because of this sentence not being very clear to me;
«If a generalized block header chain with non-trivial total proof-of-work
is emerging»
Also, can you explain what you are actually trying to accomplis
This BIP defines a change in consensus rules regarding to block nVersion, and
define a concept of generalized block header to implement a hardfork warning
system for full nodes and light nodes.
For better formatting, visit github
https://github.com/jl2012/bips/blob/hfwarning/bip-hfwarning.mediaw
