đź“… Original date posted:2015-08-19
đź“ť Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Agreed.
On 08/17/2015 07:36 AM, Adam Back via bitcoin-dev wrote:
> Thank you Eric for saying what needs to be said.
>
> Starting a fork war is just not constructive and there are
> multiple proposals being evaluated here.
>
> I think that one thing that is not being so much focussed on is
> Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork
> on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin
> core SPV nodes that did not opt-in. It exposes those SPV nodes to
> loss in the likely event that Bitcoin-XT results in a
> network-split.
>
> The recent proposal here to run noXT (patch to falsely claim to
> mine on XT while actually rejecting it's blocks) could add enough
> uncertainty about the activation that Bitcoin-XT would probably
> have to be aborted.
>
> Adam
>
> On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> NxtChg,
>>
>> In the entire history of Bitcoin we’ve never attempted anything
>> even closely resembling a hard fork like what’s being proposed
>> here.
>>
>> Many of us have wanted to push our own hard-forking changes to
>> the protocol…and have been frustrated because of the inability to
>> do so.
>>
>> This inability is not due to any malice on anyone’s part…it is a
>> feature of Satoshi’s protocol. For better or worse, it is *very
>> hard* to change the rules…and this is exactly what imbues Bitcoin
>> with one of its most powerful attributes: very well-defined
>> settlement guarantees that cannot be suddenly altered nor
>> reversed by anyone.
>>
>> We’ve managed to have a few soft forks in the past…and for the
>> most part these changes have been pretty uncontroversial…or at
>> least, they have not had nearly the level of political
>> divisiveness that this block size issue is having. And even then,
>> we’ve encountered a number of problems with these deployments
>> that have at times required goodwill cooperation between
>> developers and mining pool operators to fix.
>>
>> Again, we have NEVER attempted anything even remotely like what’s
>> being proposed - we’ve never done any sort of hard fork before
>> like this. If even fairly uncontroversial soft forks have caused
>> problems, can you imagine the kinds of potential problems that a
>> hard fork over some highly polarizing issue might raise? Do you
>> really think people are going to want to cooperate?!?
>>
>> I can understand that some people would like bigger blocks. Other
>> people might want feature X, others feature Y…and we can argue
>> the merits of this or that to death…but the fact remains that we
>> have NEVER attempted any hard forking change…not even with a
>> simple, totally uncontroversial no-brainer improvement that would
>> not risk any sort of ill-will that could hamper remedies were it
>> not to go as smoothly as we like. *THIS* is the fundamental
>> problem - the whole bigger block thing is a minor issue by
>> comparison…it could be any controversial change, really.
>>
>> Would you want to send your test pilots on their first flight…the
>> first time an aircraft is ever flown…directly into combat without
>> having tested the plane? This is what attempting a hard fork
>> mechanism that’s NEVER been done before in such a politically
>> divisive environment basically amounts to…but it’s even worse.
>> We’re basically risking the entire air force (not just one plane)
>> over an argument regarding how many seats a plane should have
>> that we’ve never flown before.
>>
>> We’re talking billlions of dollars’ worth of other people’s money
>> that is on the line here. Don’t we owe it to them to at least
>> test out the system on a far less controversial, far less
>> divisive change first to make sure we can even deploy it without
>> things breaking? I don’t even care about the merits regarding
>> bigger blocks vs. smaller blocks at this point, to be quite
>> honest - that’s such a petty thing compared to what I’m talking
>> about here. If we attempt a novel hard-forking mechanism that’s
>> NEVER been attempted before (and which as many have pointed out
>> is potentially fraught with serious problems) on such a
>> politically divisive, polarizing issue, the result is each side
>> will refuse to cooperate with the other out of spite…and can
>> easily lead to a war, tanking the value of everyone’s assets on
>> both chains. All so we can process 8 times the number of
>> transactions we currently do? Even if it were 100 times, we
>> wouldn’t even come close to touching big payment processors like
>> Visa. It’s hard to imagine a protocol improvement that’s worth
>> the risk.
>>
>> I urge you to at least try to see the bigger picture here…and to
>> understand that nobody is trying to stop anyone from doing
>> anything out of some desire for maintaining control - NONE of us
>> are able to deploy hard forks right now without facing these
>> problems. And different people obviously have different
>> priorities and preferences as to which of these changes would be
>> best to do first. This whole XT thing is essentially giving *one*
>> proposal special treatment above those that others have proposed.
>> Many of us have only held back from doing this out of our belief
>> that goodwill amongst network participants is more important than
>> trying to push some pet feature some of us want.
>>
>> Please stop this negativity - we ALL want the best for Bitcoin
>> and are doing our best, given what we understand and know, to do
>> what’s right.
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJV0/yyAAoJEGxwq/inSG8CaicIALQU//jNkUVRb6uzYFtSNb/y
cWViS5oaberLC2S0pQu2C4CciHSht347luM8kxlp3xL045SgIvvwXBzooH5HE+JE
+NscfC58+2RyQWgPiWrwQ2JSFQgaRzi58fyE8rLSdsLKXjJkbkaol6w2atbpvHP8
Zbm6sAOybLurA+2N9ZtxWosEZEfjT54Sf14+YNQlr5ve3JbYBIbZ8PhWPXwc5P/5
FuwBb/JBszClasWGxmsexrpXfK6Kqy2rOVOWmmYNMjpHR8oYZWKC42HTOXw2lig1
lspqMEXBTv+ppSk1KU5ovwftongX3W0lM5DOj3FXE7frlgcBxeMMFBFBFGnT3ZU=
=vCZH
-----END PGP SIGNATURE-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 17:36:10
in reply to nevent1q…kt3c
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 17:36:10Event JSON
{
"id": "3d60134f68a31c893e4dc37e79c809e3610ced98c5e8c5232768a93e6e0d5315",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686159370,
"kind": 1,
"tags": [
[
"e",
"8bab4b65547ea525500c3da32e0aaa3f149ec5abd990afc7ae86d8eed16de657",
"",
"root"
],
[
"e",
"a5c98bf8c3ea49d69eadc6d94b817355919d6b704f8202e604b0e66601ac2826",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-08-19\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAgreed.\n\nOn 08/17/2015 07:36 AM, Adam Back via bitcoin-dev wrote:\n\u003e Thank you Eric for saying what needs to be said.\n\u003e \n\u003e Starting a fork war is just not constructive and there are\n\u003e multiple proposals being evaluated here.\n\u003e \n\u003e I think that one thing that is not being so much focussed on is \n\u003e Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork\n\u003e on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin\n\u003e core SPV nodes that did not opt-in. It exposes those SPV nodes to\n\u003e loss in the likely event that Bitcoin-XT results in a\n\u003e network-split.\n\u003e \n\u003e The recent proposal here to run noXT (patch to falsely claim to\n\u003e mine on XT while actually rejecting it's blocks) could add enough \n\u003e uncertainty about the activation that Bitcoin-XT would probably\n\u003e have to be aborted.\n\u003e \n\u003e Adam\n\u003e \n\u003e On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e NxtChg,\n\u003e\u003e \n\u003e\u003e In the entire history of Bitcoin we’ve never attempted anything\n\u003e\u003e even closely resembling a hard fork like what’s being proposed\n\u003e\u003e here.\n\u003e\u003e \n\u003e\u003e Many of us have wanted to push our own hard-forking changes to\n\u003e\u003e the protocol…and have been frustrated because of the inability to\n\u003e\u003e do so.\n\u003e\u003e \n\u003e\u003e This inability is not due to any malice on anyone’s part…it is a\n\u003e\u003e feature of Satoshi’s protocol. For better or worse, it is *very\n\u003e\u003e hard* to change the rules…and this is exactly what imbues Bitcoin\n\u003e\u003e with one of its most powerful attributes: very well-defined\n\u003e\u003e settlement guarantees that cannot be suddenly altered nor\n\u003e\u003e reversed by anyone.\n\u003e\u003e \n\u003e\u003e We’ve managed to have a few soft forks in the past…and for the\n\u003e\u003e most part these changes have been pretty uncontroversial…or at\n\u003e\u003e least, they have not had nearly the level of political\n\u003e\u003e divisiveness that this block size issue is having. And even then,\n\u003e\u003e we’ve encountered a number of problems with these deployments\n\u003e\u003e that have at times required goodwill cooperation between\n\u003e\u003e developers and mining pool operators to fix.\n\u003e\u003e \n\u003e\u003e Again, we have NEVER attempted anything even remotely like what’s\n\u003e\u003e being proposed - we’ve never done any sort of hard fork before\n\u003e\u003e like this. If even fairly uncontroversial soft forks have caused\n\u003e\u003e problems, can you imagine the kinds of potential problems that a\n\u003e\u003e hard fork over some highly polarizing issue might raise? Do you\n\u003e\u003e really think people are going to want to cooperate?!?\n\u003e\u003e \n\u003e\u003e I can understand that some people would like bigger blocks. Other\n\u003e\u003e people might want feature X, others feature Y…and we can argue\n\u003e\u003e the merits of this or that to death…but the fact remains that we\n\u003e\u003e have NEVER attempted any hard forking change…not even with a\n\u003e\u003e simple, totally uncontroversial no-brainer improvement that would\n\u003e\u003e not risk any sort of ill-will that could hamper remedies were it\n\u003e\u003e not to go as smoothly as we like. *THIS* is the fundamental\n\u003e\u003e problem - the whole bigger block thing is a minor issue by\n\u003e\u003e comparison…it could be any controversial change, really.\n\u003e\u003e \n\u003e\u003e Would you want to send your test pilots on their first flight…the\n\u003e\u003e first time an aircraft is ever flown…directly into combat without\n\u003e\u003e having tested the plane? This is what attempting a hard fork\n\u003e\u003e mechanism that’s NEVER been done before in such a politically\n\u003e\u003e divisive environment basically amounts to…but it’s even worse.\n\u003e\u003e We’re basically risking the entire air force (not just one plane)\n\u003e\u003e over an argument regarding how many seats a plane should have\n\u003e\u003e that we’ve never flown before.\n\u003e\u003e \n\u003e\u003e We’re talking billlions of dollars’ worth of other people’s money\n\u003e\u003e that is on the line here. Don’t we owe it to them to at least\n\u003e\u003e test out the system on a far less controversial, far less\n\u003e\u003e divisive change first to make sure we can even deploy it without\n\u003e\u003e things breaking? I don’t even care about the merits regarding\n\u003e\u003e bigger blocks vs. smaller blocks at this point, to be quite\n\u003e\u003e honest - that’s such a petty thing compared to what I’m talking\n\u003e\u003e about here. If we attempt a novel hard-forking mechanism that’s\n\u003e\u003e NEVER been attempted before (and which as many have pointed out\n\u003e\u003e is potentially fraught with serious problems) on such a\n\u003e\u003e politically divisive, polarizing issue, the result is each side\n\u003e\u003e will refuse to cooperate with the other out of spite…and can\n\u003e\u003e easily lead to a war, tanking the value of everyone’s assets on\n\u003e\u003e both chains. All so we can process 8 times the number of\n\u003e\u003e transactions we currently do? Even if it were 100 times, we\n\u003e\u003e wouldn’t even come close to touching big payment processors like\n\u003e\u003e Visa. It’s hard to imagine a protocol improvement that’s worth\n\u003e\u003e the risk.\n\u003e\u003e \n\u003e\u003e I urge you to at least try to see the bigger picture here…and to\n\u003e\u003e understand that nobody is trying to stop anyone from doing\n\u003e\u003e anything out of some desire for maintaining control - NONE of us\n\u003e\u003e are able to deploy hard forks right now without facing these\n\u003e\u003e problems. And different people obviously have different\n\u003e\u003e priorities and preferences as to which of these changes would be\n\u003e\u003e best to do first. This whole XT thing is essentially giving *one*\n\u003e\u003e proposal special treatment above those that others have proposed.\n\u003e\u003e Many of us have only held back from doing this out of our belief\n\u003e\u003e that goodwill amongst network participants is more important than\n\u003e\u003e trying to push some pet feature some of us want.\n\u003e\u003e \n\u003e\u003e Please stop this negativity - we ALL want the best for Bitcoin\n\u003e\u003e and are doing our best, given what we understand and know, to do\n\u003e\u003e what’s right.\n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJV0/yyAAoJEGxwq/inSG8CaicIALQU//jNkUVRb6uzYFtSNb/y\ncWViS5oaberLC2S0pQu2C4CciHSht347luM8kxlp3xL045SgIvvwXBzooH5HE+JE\n+NscfC58+2RyQWgPiWrwQ2JSFQgaRzi58fyE8rLSdsLKXjJkbkaol6w2atbpvHP8\nZbm6sAOybLurA+2N9ZtxWosEZEfjT54Sf14+YNQlr5ve3JbYBIbZ8PhWPXwc5P/5\nFuwBb/JBszClasWGxmsexrpXfK6Kqy2rOVOWmmYNMjpHR8oYZWKC42HTOXw2lig1\nlspqMEXBTv+ppSk1KU5ovwftongX3W0lM5DOj3FXE7frlgcBxeMMFBFBFGnT3ZU=\n=vCZH\n-----END PGP SIGNATURE-----",
"sig": "ff13331ff312e342fee48853fdd52d43580dd1c7683373b2ff17480e386a30a5fedafac617a6796a09067784658fe83c49efd2c113df19fb1f6c7fa5952ffb2b"
}