A hard-fork is a situation where non-upgraded nodes reject a block mined
and relayed by upgraded nodes. This creates a fork that cannot heal
regardless of what follows.
This proposal is not a hard-fork, because the non-upgraded node *will heal*
if the attack has less than 1/2 of the original-POW
Forgive me if this has been asked elsewhere before, but I am trying to
understand a potential failure mode of Bitcoin mining.
A majority of miners can decide which valid blocks extend the chain. But
what would happen if a majority of miners, in the form of a cartel decided
to validly orphan any
Thanks Mats, this proposal makes sense to me (especially the idea of
fork-specific addresses). It prevents replay across forks, and makes it
easy for client software, and thus potentially users, to specify which fork
a tx is for. But, like other (rougher) past proposals I've seen, it does
little
If a block that would be discarded under previous rules becomes accepted after
a rule addition, there is no reason to not simply call the new rule a hard
fork. IOW it's perfectly rational to consider a weaker block as "invalid"
relative to the strong chain. As such I don't see any reason to
>
> Note how you're basically proposing for the block interval to be decreased,
>> which has security implications due to increased orphan rates.
>>
>
> Note that the total transaction rate and block size don't materially
> change, so I don't
> see why the orphan rate will change. Normal blocks
Presented is a generalised way of providing replay protection for future hard
forks. On top of replay protection, this schema also allows for fork-distinct
addresses and potentially a way to opt-out of replay protection of any fork,
where deemed necessary (can be beneficial for some L2
