📅 Original date posted:2016-02-09
📝 Original message:Gavin, please don't quote that list on the Classic website. It's horribly
inaccurate and misleading to the general public.
> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>
> https://bitcoinclassic.com/
I know for a fact that most companies you list there have no intention to
run Classic, much less test it. You should not mix support for 2MB with
support for Classic, or if people say they welcome a fork, to mean they
support Classic.
On Sun, Feb 7, 2016 at 5:11 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev
> wrote:
> > 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 covered the security considerations unique to hard-forks on my blog:
>
> https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
>
> > > , 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/
>
> How do we know any of this testing is actually being performed? I don't
> currently know of any concrete testing actually done.
>
> > > 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 unaware of Not Bitcoin XT?
>
> https://bitcointalk.org/index.php?topic=1154520.0
>
> > 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?
>
> See above.
>
> Also, as the two coins are separate currencies and can easily trade
> against each other in a 75%/25% split, it would be easy for the price to
> diverge and hashing power to move.
>
> In fact, I've been asked multiple times now by exchanges and other
> players in this ecosystem for technical advice on how to split coins
> across the chains effectively (easily done with nLockTime). Notably, the
> exchanges who have asked me this - who hold customer funds on their
> behalf - have informed me that their legal advice was that the
> post-hard-fork coins are legally speaking separate currencies, and
> customers must be given the opportunity to transact in them separately
> if they choose too. Obviously, with a 75%/25% split, while block times
> on the other chain will be slower, the chain is still quite useful and
> nearly as secure as the main chain against 51% attack; why I personally
> have suggested a 99% threshold:
>
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html
>
> (remember that the threshold can always be soft-forked down)
>
> It's also notable that millions of dollars of Bitcoin are voting agsast
> the fork on the proof-of-stake voting site Bitcoinocracy.com While
> obviously not comprehensive, the fact that a relatively obscure site
> like it can achieve participation like that, even without an easy to use
> user friendly interface.
>
> > > 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.
>
> Please provide details on exactly how that's going to happen.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/021a7b73/attachment.html>;
Samson Mow [ARCHIVE] /
npub1ka…eucdz
2023-06-07 17:48:40
in reply to nevent1q…stp2
Author Public Key
npub1kak8yfezzae4wds05nj6kr0k43hv6c524tqx8qggafnqak5r2hqqyeucdzSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:48:40Event JSON
{
"id": "f64cb458f2b10d33d22632ec7679a65c5789c584577f70d9f7a3579a4e19e5d4",
"pubkey": "b76c722722177357360fa4e5ab0df6ac6ecd628aaac0638108ea660eda8355c0",
"created_at": 1686160120,
"kind": 1,
"tags": [
[
"e",
"299dc342b2928a854d3cdebebdfa1b5d7d113553560926ba6670328be5b1c1ce",
"",
"root"
],
[
"e",
"a8ca102eaff24e426fe7f7ae053de6658b78f56c44fe137b94f81725db85baaf",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2016-02-09\n📝 Original message:Gavin, please don't quote that list on the Classic website. It's horribly\ninaccurate and misleading to the general public.\n\n\u003e That testing is happening by the exchange, library, wallet, etc providers\n\u003e themselves. There is a list on the Classic home page:\n\u003e\n\u003e https://bitcoinclassic.com/\n\nI know for a fact that most companies you list there have no intention to\nrun Classic, much less test it. You should not mix support for 2MB with\nsupport for Classic, or if people say they welcome a fork, to mean they\nsupport Classic.\n\nOn Sun, Feb 7, 2016 at 5:11 AM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev\n\u003e wrote:\n\u003e \u003e On Sat, Feb 6, 2016 at 12:01 PM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e It would probably be a good idea to have a security considerations\n\u003e \u003e \u003e section\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Containing what? I'm not aware of any security considerations that are\n\u003e any\n\u003e \u003e different from any other consensus rules change.\n\u003e\n\u003e I covered the security considerations unique to hard-forks on my blog:\n\u003e\n\u003e https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks\n\u003e\n\u003e \u003e \u003e , also, is there a list of which exchange, library, wallet,\n\u003e \u003e \u003e pool, stats server, hardware etc you have tested this change against?\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e That testing is happening by the exchange, library, wallet, etc providers\n\u003e \u003e themselves. There is a list on the Classic home page:\n\u003e \u003e\n\u003e \u003e https://bitcoinclassic.com/\n\u003e\n\u003e How do we know any of this testing is actually being performed? I don't\n\u003e currently know of any concrete testing actually done.\n\u003e\n\u003e \u003e \u003e Do you have a rollback plan in the event the hard-fork triggers via\n\u003e \u003e \u003e false voting as seemed to be prevalent during XT? (Or rollback just\n\u003e \u003e \u003e as contingency if something unforseen goes wrong).\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e The only voting in this BIP is done by the miners, and that cannot be\n\u003e faked.\n\u003e\n\u003e Are you unaware of Not Bitcoin XT?\n\u003e\n\u003e https://bitcointalk.org/index.php?topic=1154520.0\n\u003e\n\u003e \u003e I can't imagine any even-remotely-likely sequence of events that would\n\u003e \u003e require a rollback, can you be more specific about what you are\n\u003e imagining?\n\u003e \u003e Miners suddenly getting cold feet?\n\u003e\n\u003e See above.\n\u003e\n\u003e Also, as the two coins are separate currencies and can easily trade\n\u003e against each other in a 75%/25% split, it would be easy for the price to\n\u003e diverge and hashing power to move.\n\u003e\n\u003e In fact, I've been asked multiple times now by exchanges and other\n\u003e players in this ecosystem for technical advice on how to split coins\n\u003e across the chains effectively (easily done with nLockTime). Notably, the\n\u003e exchanges who have asked me this - who hold customer funds on their\n\u003e behalf - have informed me that their legal advice was that the\n\u003e post-hard-fork coins are legally speaking separate currencies, and\n\u003e customers must be given the opportunity to transact in them separately\n\u003e if they choose too. Obviously, with a 75%/25% split, while block times\n\u003e on the other chain will be slower, the chain is still quite useful and\n\u003e nearly as secure as the main chain against 51% attack; why I personally\n\u003e have suggested a 99% threshold:\n\u003e\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html\n\u003e\n\u003e (remember that the threshold can always be soft-forked down)\n\u003e\n\u003e It's also notable that millions of dollars of Bitcoin are voting agsast\n\u003e the fork on the proof-of-stake voting site Bitcoinocracy.com While\n\u003e obviously not comprehensive, the fact that a relatively obscure site\n\u003e like it can achieve participation like that, even without an easy to use\n\u003e user friendly interface.\n\u003e\n\u003e \u003e \u003e How do you plan to monitor and manage security through the hard-fork?\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e I don't plan to monitor or manage anything; the Bitcoin network is\n\u003e \u003e self-monitoring and self-managing. Services like statoshi.info will do\n\u003e the\n\u003e \u003e monitoring, and miners and people and businesses will manage the network,\n\u003e \u003e as they do every day.\n\u003e\n\u003e Please provide details on exactly how that's going to happen.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/021a7b73/attachment.html\u003e",
"sig": "60ca27444b7094e141adb3bcc88bd22a8ca1eef654449149328446707f070eb0a02e9a88f561bd96b9a24abec4f2eaaf0480715d0220f84c4037600dd322d1ff"
}