📅 Original date posted:2015-06-16
📝 Original message:>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>
How do we plan to deal with security & incident response - exactly the same
way as before. Remember that XT is basically Core plus a few patches.
Gavin and myself are both on the bitcoin-security mailing list and have
been for years. Both of us have experience of responding to very serious
and tight-deadline security incidents, for example, the accidental bdb hard
fork and (in my case) when we discovered that Android phones had so little
entropy in them that different devices were actually generating the same
keys!
That one required co-ordinated crash rollouts of multiple wallets across
the Bitcoin ecosystem because there was a parallel investigation into key
collisions taking place in an open forum and they were not far from
discovering the truth about how badly the Android RNG was broken (I knew
because at the time I had access to the Google internal Android bug
tracker). I organised the whole thing.
So I think we'll manage. But I don't expect things to exist in a state of
disjointness for very long. XT will rebase on top of Core and follow it's
releases for as long as there seems to be interest in bigger blocks and as
long as I have the time/energy/interest. If the >1mb chain wins then Core
will have to adopt the new ruleset or simply stop being relevant, as it
will have no users. That wouldn't make much sense.
Now, there have been concerns raised that a hard fork is unbelievably
risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I
don't believe it's anywhere near that risky. The patch Gavin is working on
requires both a miner majority *and* also has a date trigger in it. Much
like previous forks, in fact. So nobody should be taken by surprise if/when
bigger blocks appear, because it will have been known for a long time
beforehand that there was sufficiently strong consensus, there will have
been messages printed to the node logs, announcements in various places and
so on.
Does that help clear things up?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/abf446cc/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:38:16
in reply to nevent1q…ny82
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:38:16Event JSON
{
"id": "1bd5ed3027441189ddf85e93770a63cea5ad8768b13aa6f6a1553a65dd73a917",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686152296,
"kind": 1,
"tags": [
[
"e",
"c55960f842472012dd9d15b2051fcbd70eb3de46e90355da852eabf498d858a6",
"",
"root"
],
[
"e",
"6305a0538f76fe2f683460bd2d25befa8d959e1ad8f861a5c0df81cf1e302c4f",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-06-16\n📝 Original message:\u003e\n\u003e \"How do you plan to deal with security \u0026 incident response for the\n\u003e duration you describe where you will have control while you are deploying\n\u003e the unilateral hard-fork and being in sole maintainership control?\"\n\u003e\n\nHow do we plan to deal with security \u0026 incident response - exactly the same\nway as before. Remember that XT is basically Core plus a few patches.\n\nGavin and myself are both on the bitcoin-security mailing list and have\nbeen for years. Both of us have experience of responding to very serious\nand tight-deadline security incidents, for example, the accidental bdb hard\nfork and (in my case) when we discovered that Android phones had so little\nentropy in them that different devices were actually generating the same\nkeys!\n\nThat one required co-ordinated crash rollouts of multiple wallets across\nthe Bitcoin ecosystem because there was a parallel investigation into key\ncollisions taking place in an open forum and they were not far from\ndiscovering the truth about how badly the Android RNG was broken (I knew\nbecause at the time I had access to the Google internal Android bug\ntracker). I organised the whole thing.\n\nSo I think we'll manage. But I don't expect things to exist in a state of\ndisjointness for very long. XT will rebase on top of Core and follow it's\nreleases for as long as there seems to be interest in bigger blocks and as\nlong as I have the time/energy/interest. If the \u003e1mb chain wins then Core\nwill have to adopt the new ruleset or simply stop being relevant, as it\nwill have no users. That wouldn't make much sense.\n\nNow, there have been concerns raised that a hard fork is unbelievably\nrisky, the sky will fall, the value of Bitcoin will drop to zero, etc. I\ndon't believe it's anywhere near that risky. The patch Gavin is working on\nrequires both a miner majority *and* also has a date trigger in it. Much\nlike previous forks, in fact. So nobody should be taken by surprise if/when\nbigger blocks appear, because it will have been known for a long time\nbeforehand that there was sufficiently strong consensus, there will have\nbeen messages printed to the node logs, announcements in various places and\nso on.\n\nDoes that help clear things up?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/abf446cc/attachment.html\u003e",
"sig": "dbd76b21f3e3b32f8b5cc10b0a67516ab9a92a27a4071fb34b84658ea9a805a5c68d37926feeaffb30a8738cb47e5485b5942587a837458d581bd33d1e0d4bba"
}