Gavin Andresen [ARCHIVE] on Nostr: š Original date posted:2016-02-07 š Original message:As I feared, request on ...
š
Original date posted:2016-02-07
š Original message:As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.
I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."
Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer. I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
http://gavinandresen.ninja/minority-branches
... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.
All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.
As for the argument that creating and testing a patch for Core would take
longer than 28 days:
The glib answer is "people should just run Classic, then."
A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.
That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/8f19d8d9/attachment.html>;
š Original message:As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.
I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."
Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer. I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
http://gavinandresen.ninja/minority-branches
... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.
All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.
As for the argument that creating and testing a patch for Core would take
longer than 28 days:
The glib answer is "people should just run Classic, then."
A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.
That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/8f19d8d9/attachment.html>;