đź“… Original date posted:2015-08-17
đź“ť Original message:Dear Eric,
thank you for sharing your thoughts.
It obviously boils down to political beliefs, not so much technical
arguments. I understand that you are in favor of a "guided
decentralization" and you are most happily invited to follow this path. I
don't want to be on it. I want total decentralisation of bitcoin and many
other parts of the current system.
So in the end the hard fork might be perfect, because people like you will
not waste so much more energy and time fighting people like me (and others)
who are following different dogmata because we are using different coins
and talking about different code. Interestingly enough in the end we will
probably have a winner - determined by the price - so I am looking forward
to the outcome. It is just the time so make some bets, which I embrace.
Another interesting thing is, that you actually fear problems arising from
this. What do you have to loose? Just stick with the old bitcoin version
and weather this storm. Bitcoin is not going to vanish or break from this.
It is just forking. One fork will come stronger out of this. You just have
to choose a side and live with it, if you loose it all. But that is the
story of bitcoin since the beginning. If you ask me, you fear the choice,
not the change.
Cheers
Levin
Adam Back via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> schrieb
am Mo., 17. Aug. 2015 um 16:37 Uhr:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/5816f286/attachment-0001.html>;
Levin Keller [ARCHIVE] /
npub153…ucv4s
2023-06-07 17:36:09
in reply to nevent1q…tsd2
Author Public Key
npub153djqudvkf75u2f2u4ya8ty0yncq8cjlp3g5txgxgcegug3k7kustucv4sPublished at
2023-06-07 17:36:09Event JSON
{
"id": "151be680cee92c3425888eba813290babc66e4d64f3b045828aa91ae340ad7b8",
"pubkey": "a45b2071acb27d4e292ae549d3ac8f24f003e25f0c5145990646328e2236f5b9",
"created_at": 1686159369,
"kind": 1,
"tags": [
[
"e",
"8bab4b65547ea525500c3da32e0aaa3f149ec5abd990afc7ae86d8eed16de657",
"",
"root"
],
[
"e",
"8da06965be8f1432da24467c991ce9ebe334560f18acf8f226362303aa14c73d",
"",
"reply"
],
[
"p",
"4a707c4056a3811acd80f1c1bf4c3bde0ee81915a44f6f409a7d61776f638491"
]
],
"content": "📅 Original date posted:2015-08-17\n📝 Original message:Dear Eric,\n\nthank you for sharing your thoughts.\n\nIt obviously boils down to political beliefs, not so much technical\narguments. I understand that you are in favor of a \"guided\ndecentralization\" and you are most happily invited to follow this path. I\ndon't want to be on it. I want total decentralisation of bitcoin and many\nother parts of the current system.\n\nSo in the end the hard fork might be perfect, because people like you will\nnot waste so much more energy and time fighting people like me (and others)\nwho are following different dogmata because we are using different coins\nand talking about different code. Interestingly enough in the end we will\nprobably have a winner - determined by the price - so I am looking forward\nto the outcome. It is just the time so make some bets, which I embrace.\n\nAnother interesting thing is, that you actually fear problems arising from\nthis. What do you have to loose? Just stick with the old bitcoin version\nand weather this storm. Bitcoin is not going to vanish or break from this.\nIt is just forking. One fork will come stronger out of this. You just have\nto choose a side and live with it, if you loose it all. But that is the\nstory of bitcoin since the beginning. If you ask me, you fear the choice,\nnot the change.\n\nCheers\n\nLevin\n\nAdam Back via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e schrieb\nam Mo., 17. Aug. 2015 um 16:37 Uhr:\n\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 multiple\n\u003e 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 on\n\u003e Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core\n\u003e SPV nodes that did not opt-in. It exposes those SPV nodes to loss in\n\u003e the likely event that Bitcoin-XT results in a network-split.\n\u003e\n\u003e The recent proposal here to run noXT (patch to falsely claim to mine\n\u003e on XT while actually rejecting it's blocks) could add enough\n\u003e uncertainty about the activation that Bitcoin-XT would probably have\n\u003e 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 even\n\u003e closely resembling a hard fork like what’s being proposed here.\n\u003e \u003e\n\u003e \u003e Many of us have wanted to push our own hard-forking changes to the\n\u003e protocol…and have been frustrated because of the inability to do so.\n\u003e \u003e\n\u003e \u003e This inability is not due to any malice on anyone’s part…it is a feature\n\u003e of Satoshi’s protocol. For better or worse, it is *very hard* to change the\n\u003e rules…and this is exactly what imbues Bitcoin with one of its most powerful\n\u003e attributes: very well-defined settlement guarantees that cannot be suddenly\n\u003e altered nor reversed by anyone.\n\u003e \u003e\n\u003e \u003e We’ve managed to have a few soft forks in the past…and for the most part\n\u003e these changes have been pretty uncontroversial…or at least, they have not\n\u003e had nearly the level of political divisiveness that this block size issue\n\u003e is having. And even then, we’ve encountered a number of problems with these\n\u003e deployments that have at times required goodwill cooperation between\n\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 being\n\u003e proposed - we’ve never done any sort of hard fork before like this. If even\n\u003e fairly uncontroversial soft forks have caused problems, can you imagine the\n\u003e kinds of potential problems that a hard fork over some highly polarizing\n\u003e issue might raise? Do you really think people are going to want to\n\u003e cooperate?!?\n\u003e \u003e\n\u003e \u003e I can understand that some people would like bigger blocks. Other people\n\u003e might want feature X, others feature Y…and we can argue the merits of this\n\u003e or that to death…but the fact remains that we have NEVER attempted any hard\n\u003e forking change…not even with a simple, totally uncontroversial no-brainer\n\u003e improvement that would not risk any sort of ill-will that could hamper\n\u003e remedies were it not to go as smoothly as we like. *THIS* is the\n\u003e fundamental problem - the whole bigger block thing is a minor issue by\n\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 first\n\u003e time an aircraft is ever flown…directly into combat without having tested\n\u003e the plane? This is what attempting a hard fork mechanism that’s NEVER been\n\u003e done before in such a politically divisive environment basically amounts\n\u003e to…but it’s even worse. We’re basically risking the entire air force (not\n\u003e just one plane) over an argument regarding how many seats a plane should\n\u003e have that we’ve never flown before.\n\u003e \u003e\n\u003e \u003e We’re talking billlions of dollars’ worth of other people’s money that\n\u003e is on the line here. Don’t we owe it to them to at least test out the\n\u003e system on a far less controversial, far less divisive change first to make\n\u003e sure we can even deploy it without things breaking? I don’t even care about\n\u003e the merits regarding bigger blocks vs. smaller blocks at this point, to be\n\u003e quite honest - that’s such a petty thing compared to what I’m talking about\n\u003e here. If we attempt a novel hard-forking mechanism that’s NEVER been\n\u003e attempted before (and which as many have pointed out is potentially fraught\n\u003e with serious problems) on such a politically divisive, polarizing issue,\n\u003e the result is each side will refuse to cooperate with the other out of\n\u003e spite…and can easily lead to a war, tanking the value of everyone’s assets\n\u003e on both chains. All so we can process 8 times the number of transactions we\n\u003e currently do? Even if it were 100 times, we wouldn’t even come close to\n\u003e touching big payment processors like Visa. It’s hard to imagine a protocol\n\u003e improvement that’s worth 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 understand that nobody is trying to stop anyone from doing anything out of\n\u003e some desire for maintaining control - NONE of us are able to deploy hard\n\u003e forks right now without facing these problems. And different people\n\u003e obviously have different priorities and preferences as to which of these\n\u003e changes would be best to do first. This whole XT thing is essentially\n\u003e giving *one* proposal special treatment above those that others have\n\u003e proposed. Many of us have only held back from doing this out of our belief\n\u003e that goodwill amongst network participants is more important than trying to\n\u003e 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 and are\n\u003e doing our best, given what we understand and know, to do what’s right.\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/5816f286/attachment-0001.html\u003e",
"sig": "a2b2042a10c9a6ac4c1fe3dbac7505f7b68ea3f7c49f4dba847ab01a514b3b6404060f8f89ad967d0c98f7558084d9e0f9f6aa3e13721699343074dd6563f243"
}