Since there is no surviving argument in this thread contrary to my original
post, I'll begin work on a BIP.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>Instead of there being one altcoin fighting to take hashpower from
bitcoin, there’d now be 2
Yes, there would be 2. One of which would (in the scenario we are
discussing) be producing blocks excruciatingly slowly but be the same in
all other aspects.
>changing the difficulty adjustment
You phrase the question as if “deploying a hard fork to bitcoin” would protect
the bitcoin chain from the attack. But that’s not what happens. If you are hard
forking from the perspective of deployed nodes, you are an different ledger,
regardless of circumstance or who did it. Instead of there
Good morning Ben,
I am not Mark, and I am nowhere near being a true Core developer yet, but I
would like to point out that even under a 51% attack, there is a practical
limit to the number of blocks that can be orphaned. It would still take years
to rewrite history from the Genesis block, for
Mark, this seems an awful lot like an answer of "no", to my question "Is
there a contingency plan in the case that the incumbent chain following the
Bitcoin Core consensus rules comes under 51% attack?" - is this a correct
interpretation?
In fact, beyond a no, it seems like a "no, and I disagree
I agree: a new difficulty algorithm starting from zero is inconceivably
rushed. But it's also inconceivable to not have one ready in two months
if my understanding of our current situation is correct. Is there any
complaint or suggestion about this algorithm or the appropriate goals of
an
[bitcoin-dev] New difficulty algorithm needed for SegWit2x fork?
(reformatted text)
The problem of fast acting but non vulnerable difficulty adjustment algorithms
is interesting. I would certainly like to see this space further explored, and
even have some ideas myself.
However withou
Is there a contingency plan in the case that the incumbent chain following
the Bitcoin Core consensus rules comes under 51% attack?
If the 2x fork really does have the support of >66% of miners (which
remains to be seen), it seems like they'd have spare capacity to perform
such an attack. In
The problem of fast acting but non vulnerable difficulty adjustment algorithms
is interesting. I would certainly like to see this space further explored, and
even have some ideas myself.
However without commenting on the technical merits of this specific proposal, I
think it must be said
Sorry, my previous email did not have the plain text I intended.
Background:
The bitcoin difficulty algorithm does not seem to be a good one. If there
is a fork due to miners seeking maximum profit without due regard to
security, users, and nodes, the "better" coin could end up being the
10 matches
Mail list logo
