📅 Original date posted:2016-02-06
📝 Original message:On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam at cypherspace.org> wrote:
>
> It would probably be a good idea to have a security considerations
> section
Containing what? I'm not aware of any security considerations that are any
different from any other consensus rules change.
(I can write a blog post summarizing our slack discussion of SPV security
immediately after the first greater-than-1mb-block if you like).
> , also, is there a list of which exchange, library, wallet,
> pool, stats server, hardware etc you have tested this change against?
>
That testing is happening by the exchange, library, wallet, etc providers
themselves. There is a list on the Classic home page:
https://bitcoinclassic.com/
>
> Do you have a rollback plan in the event the hard-fork triggers via
> false voting as seemed to be prevalent during XT? (Or rollback just
> as contingency if something unforseen goes wrong).
>
The only voting in this BIP is done by the miners, and that cannot be faked.
Are you talking about people spinning up pseudo-full-nodes that fake the
user-agent?
As I said, there are people who have said they will spin up thousands of
full nodes to help prevent possible Sybil attacks which would become
marginally easier to accomplish immediately after the first >1mb block was
produced and full nodes that hadn't upgraded were left behind.
Would Blockstream be willing to help out by running a dozen or two extra
full nodes?
I can't imagine any even-remotely-likely sequence of events that would
require a rollback, can you be more specific about what you are imagining?
Miners suddenly getting cold feet?
> How do you plan to monitor and manage security through the hard-fork?
>
I don't plan to monitor or manage anything; the Bitcoin network is
self-monitoring and self-managing. Services like statoshi.info will do the
monitoring, and miners and people and businesses will manage the network,
as they do every day.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/e60b5b0c/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 17:48:39
in reply to nevent1q…kmfe
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 17:48:39Event JSON
{
"id": "116dac5f5774da88c3f58395a148d977018b31f9f19ff95bd4168e96b9304495",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686160119,
"kind": 1,
"tags": [
[
"e",
"299dc342b2928a854d3cdebebdfa1b5d7d113553560926ba6670328be5b1c1ce",
"",
"root"
],
[
"e",
"a8d2ab9cfe34de113f299f4ce46ee867f6cd5698c7b6fc6c50accadfe9085eee",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2016-02-06\n📝 Original message:On Sat, Feb 6, 2016 at 12:01 PM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\n\u003e\n\u003e It would probably be a good idea to have a security considerations\n\u003e section\n\n\nContaining what? I'm not aware of any security considerations that are any\ndifferent from any other consensus rules change.\n\n(I can write a blog post summarizing our slack discussion of SPV security\nimmediately after the first greater-than-1mb-block if you like).\n\n\n\n\u003e , also, is there a list of which exchange, library, wallet,\n\u003e pool, stats server, hardware etc you have tested this change against?\n\u003e\n\nThat testing is happening by the exchange, library, wallet, etc providers\nthemselves. There is a list on the Classic home page:\n\nhttps://bitcoinclassic.com/\n\n\n\u003e\n\u003e Do you have a rollback plan in the event the hard-fork triggers via\n\u003e false voting as seemed to be prevalent during XT? (Or rollback just\n\u003e as contingency if something unforseen goes wrong).\n\u003e\n\nThe only voting in this BIP is done by the miners, and that cannot be faked.\n\nAre you talking about people spinning up pseudo-full-nodes that fake the\nuser-agent?\n\nAs I said, there are people who have said they will spin up thousands of\nfull nodes to help prevent possible Sybil attacks which would become\nmarginally easier to accomplish immediately after the first \u003e1mb block was\nproduced and full nodes that hadn't upgraded were left behind.\n\nWould Blockstream be willing to help out by running a dozen or two extra\nfull nodes?\n\nI can't imagine any even-remotely-likely sequence of events that would\nrequire a rollback, can you be more specific about what you are imagining?\nMiners suddenly getting cold feet?\n\n\n\u003e How do you plan to monitor and manage security through the hard-fork?\n\u003e\n\nI don't plan to monitor or manage anything; the Bitcoin network is\nself-monitoring and self-managing. Services like statoshi.info will do the\nmonitoring, and miners and people and businesses will manage the network,\nas they do every day.\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/e60b5b0c/attachment.html\u003e",
"sig": "238872443ed216effd45bdc705a387aeb852435b794d299fa939f77288bd53c608d245268a6c343e1eae941cab2450a1897e28f7e9c9ae8998914c7d0b0e8742"
}