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 bl
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 qual
>
> 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 ar
Hi Peter, thank you for the review. See below
On Mon, Nov 6, 2017 at 11:50 AM Peter Todd wrote:
> On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote:
>
> Some quick thoughts...
>
> > Hi all,
> >
> > Feedback is welcome on the draft below. In particular, I want to see if
+1 to all of Peter Todd's comments
On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote:
>
> Some quick thoughts...
>
> > Hi all,
> >
> > Feedback is welcome on the draft b
On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote:
Some quick thoughts...
> Hi all,
>
> Feedback is welcome on the draft below. In particular, I want to see if
> there is interest in further development of the idea and also interested in
> any attack vectors or undesirab
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 applicat
