* [bitcoin-dev] Annoucing Not-BitcoinXT
@ 2015-08-16 22:34 jyellen
2015-08-17 3:10 ` jl2012
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: jyellen @ 2015-08-16 22:34 UTC (permalink / raw)
To: bitcoin-dev
Announcing Not-BitcoinXT
https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-16 22:34 [bitcoin-dev] Annoucing Not-BitcoinXT jyellen
@ 2015-08-17 3:10 ` jl2012
2015-08-17 7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2 siblings, 0 replies; 22+ messages in thread
From: jl2012 @ 2015-08-17 3:10 UTC (permalink / raw)
To: jyellen; +Cc: bitcoin-dev
Thanks to mining centralization, such attempts won't be successful.
Asking mining pools to mine spoofing blocks in their real name is even
harder than asking them to run the real BitcoinXT
Node count is always manipulable, there is nothing new. People running
this will only be interpreted as XT-supporters.
Julie via bitcoin-dev 於 2015-08-16 18:34 寫到:
> Announcing Not-BitcoinXT
>
> https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
>
>
>
>
> -------------------------------------------------
>
> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out
> of the NSA's hands!
> $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No
> bandwidth quotas!
> Commercial and Bulk Mail Options!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-16 22:34 [bitcoin-dev] Annoucing Not-BitcoinXT jyellen
2015-08-17 3:10 ` jl2012
@ 2015-08-17 7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2 siblings, 0 replies; 22+ messages in thread
From: Peter Todd @ 2015-08-17 7:04 UTC (permalink / raw)
To: jyellen, Julie via bitcoin-dev, bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The fun thing about this, is you only need >25% of hashing power running Not-BitcoinXT to screw over the miners running XT, as XT blocks are valid Bitcoin blocks if they're on a valid Bitcoin chain.
75% upgrade thresholds have a lot of issues...
On 16 August 2015 15:34:33 GMT-07:00, Julie via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>Announcing Not-BitcoinXT
>
>https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
>
>
>
>
>-------------------------------------------------
>
>ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of
>the NSA's hands!
>$24.95 ONETIME Lifetime accounts with Privacy Features!
>15GB disk! No bandwidth quotas!
>Commercial and Bulk Mail Options!
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists•linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YdD
AAoJEMCF8hzn9Lnc47AH/1xFeDBejXmWjYlloDIq4OY8DypXypWk+J6BI2s5htm/
zBEQ/109u2T+7UYV5hSfh9GUj67NJ5HPbsPOpqoMqGO/yoJglM7ZEypNTKnOUlUf
3Ax+sgx5h5z2a51cshG0ups2liYgT926jzIyoz+Cs/O0g0mp+1Xu2rWm3qfnueXU
eqeqZ5SgnVT2JmnHubaYOl3IJvYs0B68TeSzFD0UFQzr7W7bzSFno4dIgpUhr5nP
Rd5ZFdYeotiGiPGStPmYshljuy0sbDydKBN29qViGRqXCUDA5QBAFGc/yfOm+82E
9LznXUfeJmsPztS1Wv8OzB7lpHVISKxrNKTCCt9U3oM=
=ZaI2
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-16 22:34 [bitcoin-dev] Annoucing Not-BitcoinXT jyellen
2015-08-17 3:10 ` jl2012
2015-08-17 7:04 ` Peter Todd
@ 2015-08-17 10:09 ` NxtChg
2015-08-17 12:40 ` Vali Zero
2 siblings, 1 reply; 22+ messages in thread
From: NxtChg @ 2015-08-17 10:09 UTC (permalink / raw)
To: jyellen, bitcoin-dev
>Announcing Not-BitcoinXT
>https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
> "This version can be used to protect the status quo until real technical consensus is formed about the blocksize."
> "...real technical consensus..."
You mean the bunch of self-proclaimed Bitcoin wizards, who decided they have the right to tell everybody what to do, and who never got to grow up and are now angry at the world for not listening to them anymore? That "technical consensus"?
"Bitcoin is decentralized, but you are only allowed to do what we tell you to do. It's our pet project, we wrote code for it!"
That's what it all boils down to, all these dirty games of calling XT an alt-coin and censoring its posts, pretending to be Satoshi, sabotaging XT switch, etc.: "How dare they not listen to Us The Smartest anymore?!!!"
Pathetic. The history will roll over you in a blink. The harder you try, the quicker it will go.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 10:09 ` NxtChg
@ 2015-08-17 12:40 ` Vali Zero
2015-08-17 13:34 ` NxtChg
0 siblings, 1 reply; 22+ messages in thread
From: Vali Zero @ 2015-08-17 12:40 UTC (permalink / raw)
To: bitcoin-dev
Hi,
If you want to write such baseless acusations and inflamatory phrases, please do it somewhere else. We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect.
Nobody should be forced to do anything. People like you will not force me or anyone else to run code for your controversial hard fork just because you think the future will be bright with huge blocks. Just like the developers will not force you to continue running code implementing the current consensus rules.
The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities.
Valiz
--------------------------------------------
În data de L, 17.8.15, NxtChg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> a scris:
Subiect: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Către: jyellen@toothandmail•com, bitcoin-dev@lists•linuxfoundation.org
Data: Luni, 17 August 2015, 13:09
>Announcing Not-BitcoinXT
>https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
> "This version can be
used to protect the status quo until real technical
consensus is formed about the blocksize."
> "...real technical
consensus..."
You mean
the bunch of self-proclaimed Bitcoin wizards, who decided
they have the right to tell everybody what to do, and who
never got to grow up and are now angry at the world for not
listening to them anymore? That "technical
consensus"?
"Bitcoin is decentralized, but you are
only allowed to do what we tell you to do. It's our pet
project, we wrote code for it!"
That's what it all boils down to, all these
dirty games of calling XT an alt-coin and censoring its
posts, pretending to be Satoshi, sabotaging XT switch, etc.:
"How dare they not listen to Us The Smartest
anymore?!!!"
Pathetic.
The history will roll over you in a blink. The harder you
try, the quicker it will go.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 12:40 ` Vali Zero
@ 2015-08-17 13:34 ` NxtChg
2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 16:37 ` Eric Lombrozo
0 siblings, 2 replies; 22+ messages in thread
From: NxtChg @ 2015-08-17 13:34 UTC (permalink / raw)
To: Vali Zero, bitcoin-dev
>We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect.
Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)?
From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead.
>Nobody should be forced to do anything.
Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
Let users decide what Bitcoin is or isn't.
>The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities.
The developers & Co are doing their best to stay in power, so they could continue imposing their will on Bitcoin ecosystem. This is the real power grab, not Gavin and Hearn, who merely provided an alternative.
And the fear they show is most telling.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 13:34 ` NxtChg
@ 2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 14:09 ` Levin Keller
` (2 more replies)
2015-08-17 16:37 ` Eric Lombrozo
1 sibling, 3 replies; 22+ messages in thread
From: Eric Lombrozo @ 2015-08-17 14:03 UTC (permalink / raw)
To: NxtChg; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 5875 bytes --]
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.
> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
>> We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect.
>
> Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)?
>
> From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead.
>
>
>> Nobody should be forced to do anything.
>
> Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
>
> Let users decide what Bitcoin is or isn't.
>
>
>> The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities.
>
> The developers & Co are doing their best to stay in power, so they could continue imposing their will on Bitcoin ecosystem. This is the real power grab, not Gavin and Hearn, who merely provided an alternative.
>
> And the fear they show is most telling.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:03 ` Eric Lombrozo
@ 2015-08-17 14:09 ` Levin Keller
2015-08-17 14:30 ` Eric Lombrozo
2015-08-17 14:36 ` Adam Back
2015-08-17 15:10 ` NxtChg
2 siblings, 1 reply; 22+ messages in thread
From: Levin Keller @ 2015-08-17 14:09 UTC (permalink / raw)
To: Eric Lombrozo, NxtChg; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 6947 bytes --]
Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
schrieb am Mo., 17. Aug. 2015 um 16:03 Uhr:
> 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.
>
Yadayadayada.
If someone could threaten the network by releasing a hard-forking bitcoind
version, then already all is lost. Bitcoins stability does not (and cannot)
depend on the "good will" of anyone. If it would, we should all abandon
this silly project. Relying on the good will of people is the worst idea
one could have.
So please (please please) go ahead and release your hardforking bitcoinds
you have been holding back. Competition is everything.
Cheers
Levin
>
> 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.
>
>
>
> > On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >
> >> We should have the highest respect for what these people are doing, and
> we should try to do something constructive, not waste time with anger and
> disrespect.
> >
> > Why, exactly, should I have any respect for what these people are doing
> (and supposedly not have any respect for what the other side is doing)?
> >
> > From my point of view, the XT side _does_ something constructive. It's
> the Core side that resorts to dirty tactics and tries to sabotage
> community's free choice instead.
> >
> >
> >> Nobody should be forced to do anything.
> >
> > Great, so how about you go tell theymos to stop censoring XT posts and
> banning the other side on /r/Bitcoin?
> >
> > Let users decide what Bitcoin is or isn't.
> >
> >
> >> The developers are not telling you what to do, they are trying to do
> what they consider is best for the ecosystem given their technical
> abilities.
> >
> > The developers & Co are doing their best to stay in power, so they could
> continue imposing their will on Bitcoin ecosystem. This is the real power
> grab, not Gavin and Hearn, who merely provided an alternative.
> >
> > And the fear they show is most telling.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7933 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:09 ` Levin Keller
@ 2015-08-17 14:30 ` Eric Lombrozo
0 siblings, 0 replies; 22+ messages in thread
From: Eric Lombrozo @ 2015-08-17 14:30 UTC (permalink / raw)
To: Levin Keller; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 9059 bytes --]
Levin,
The hope is that eventually the network will be sufficiently resilient and robust to be able to handle anything that’s thrown at it. But it’s still a baby…and this is a serious problem indeed, because on the one hand we don’t want any central authority but on the other it still needs some guardians…and we don’t have anything resembling the kind of institution that could possibly be entrusted to nurture and care for this baby until it is ready to go out on its own.
Imagine, when the US Constitution was being written, if suddenly everyone started to just propose their own different version of it and insisting (under threat of fork) on their own versions before any sort of government could be created. Yes, I know the US federal government is not exactly the paragon of decentralization…but regardless of your views on the US government, it’s still a somewhat analogous situation. Until the system was in place, some people (who at the time were unelected) had to bootstrap the process.
For better or worse, Satoshi has left the picture…and no clear succession model was put in place. The Bitcoin Foundation, which for a time attempted to be a guardian institution, ended up self-destructing. It was an utter failure.
We don’t have any sort of institution like this…and we don’t really want one. But the system is still not fully in place. Importantly, we lack any mechanisms to be able to make potentially controversial changes without serious risks.
It would be amazing if despite this trial-by-fire we still survived and managed to pull through. And if we do we’ll be stronger for it. But quite sincerely, I would have wanted the system to be a little more mature before putting it through this trial. At least I would have liked to have gone through a test hard-fork using a far less politically divisive issue.
Anyhow, completely separate from my views on governance, etc…my main point is that we’re ALL trying to do what’s best given our understanding and resources…and we’ve all poured our hearts and souls into this. We might disagree on certain things, but let’s stop this negativity and misrepresentation and try to figure out a way forward that is less likely to lead to a war.
- Eric
>
>
> Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> schrieb am Mo., 17. Aug. 2015 um 16:03 Uhr:
> 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.
>
> Yadayadayada.
>
> If someone could threaten the network by releasing a hard-forking bitcoind version, then already all is lost. Bitcoins stability does not (and cannot) depend on the "good will" of anyone. If it would, we should all abandon this silly project. Relying on the good will of people is the worst idea one could have.
>
> So please (please please) go ahead and release your hardforking bitcoinds you have been holding back. Competition is everything.
>
> Cheers
>
> Levin
>
>
> 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.
>
>
>
> > On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >
> >> We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect.
> >
> > Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)?
> >
> > From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead.
> >
> >
> >> Nobody should be forced to do anything.
> >
> > Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
> >
> > Let users decide what Bitcoin is or isn't.
> >
> >
> >> The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities.
> >
> > The developers & Co are doing their best to stay in power, so they could continue imposing their will on Bitcoin ecosystem. This is the real power grab, not Gavin and Hearn, who merely provided an alternative.
> >
> > And the fear they show is most telling.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 14:09 ` Levin Keller
@ 2015-08-17 14:36 ` Adam Back
2015-08-17 14:58 ` GC
` (2 more replies)
2015-08-17 15:10 ` NxtChg
2 siblings, 3 replies; 22+ messages in thread
From: Adam Back @ 2015-08-17 14:36 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: Bitcoin Dev
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@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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:36 ` Adam Back
@ 2015-08-17 14:58 ` GC
2015-08-17 15:03 ` Levin Keller
2015-08-19 3:49 ` odinn
2 siblings, 0 replies; 22+ messages in thread
From: GC @ 2015-08-17 14:58 UTC (permalink / raw)
To: Adam Back, Eric Lombrozo; +Cc: Bitcoin Dev
Adam,
While greatly appreciating your prior efforts in crypto-ccy R&D and
current efforts for Blockstream, its not a plus for your reputation to be
using emotive terms like ³attack², ³fork war" and throwing so much FUD
into the developer email channel directly after Eric¹s email.
We would appreciate seeing your well-argued thoughts, not FUD and flaming.
There are multitudes of trolls in all forums already.
On 17/8/15 10:36 pm, "Adam Back via bitcoin-dev"
<bitcoin-dev@lists•linuxfoundation.org> 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@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@lists•linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:36 ` Adam Back
2015-08-17 14:58 ` GC
@ 2015-08-17 15:03 ` Levin Keller
2015-08-17 15:07 ` Eric Lombrozo
2015-08-19 3:49 ` odinn
2 siblings, 1 reply; 22+ messages in thread
From: Levin Keller @ 2015-08-17 15:03 UTC (permalink / raw)
To: Adam Back, Eric Lombrozo; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7151 bytes --]
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@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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7809 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 15:03 ` Levin Keller
@ 2015-08-17 15:07 ` Eric Lombrozo
0 siblings, 0 replies; 22+ messages in thread
From: Eric Lombrozo @ 2015-08-17 15:07 UTC (permalink / raw)
To: Levin Keller; +Cc: Bitcoin Dev
[-- Attachment #1.1: Type: text/plain, Size: 8063 bytes --]
> On Aug 17, 2015, at 8:03 AM, Levin Keller <post@levinkeller•de> wrote:
>
> 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.
I specifically asked you to stop misrepresenting - I’m NOT in favor of guided decentralization, I never said anything like that. *THIS* is the problem…you’re reading intentions into others that simply are NOT there. If you don’t really understand something, ask.
I want complete decentralization - but for practical reasons, which should be obvious, we cannot start at this point. Bitcoin came into existence because Satoshi wrote a whitepaper and implemented the idea - and it was his rules. There was no voting, no committee, no proof-of-work, no nothing…it was a complete dictatorship in the beginning.
>
> 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.
>
Again, misrepresentation - “you fear the choice, not the change” - why should anyone ask *you* what I fear? Why don’t you ask *me*?
> Cheers
>
> Levin
>
> Adam Back via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@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@lists•linuxfoundation.org <mailto:bitcoin-dev@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@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
[-- Attachment #1.2: Type: text/html, Size: 10035 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 14:09 ` Levin Keller
2015-08-17 14:36 ` Adam Back
@ 2015-08-17 15:10 ` NxtChg
2 siblings, 0 replies; 22+ messages in thread
From: NxtChg @ 2015-08-17 15:10 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: bitcoin-dev
Eric,
>In the entire history of Bitcoin we've never attempted anything even closely resembling a hard fork like what's being proposed here.
These concerns are understandable. What's hard to understand is why he, he and he get to decide what is more risky - hitting the limit or forking for larger blocks?
Many people don't seem to think the upcoming hard fork is such a big risk.
---
And why there's so much fear that your side might lose to XT in a honest battle? Why is it suddenly not "let the best man win", but "we are right, they are enemies of the state, go get them!!!"?
This is the same fear dictators have of honest elections. If you know you can't win in a honest battle, you start rigging the game.
With recent "Satoshi" post even this list is not immune...
----
I don't know if everybody had a chance to appreciate this quote by theymos yet:
"If 90% of /r/Bitcoin users find these policies to be intolerable, then I want these 90% of /r/Bitcoin users to leave."
(https://www.reddit.com/r/Bitcoin/comments/3h9cq4/its_time_for_a_break_about_the_recent_mess/)
This is a quote worthy of Gaddafi. Fortunately, it's hard to be a dictator on the Internet, where you can't shoot people.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 13:34 ` NxtChg
2015-08-17 14:03 ` Eric Lombrozo
@ 2015-08-17 16:37 ` Eric Lombrozo
2015-08-17 16:55 ` Eric Lombrozo
2015-08-18 9:46 ` NxtChg
1 sibling, 2 replies; 22+ messages in thread
From: Eric Lombrozo @ 2015-08-17 16:37 UTC (permalink / raw)
To: NxtChg; +Cc: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 3546 bytes --]
> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
>
> Let users decide what Bitcoin is or isn't.
FWIW,
I don’t think what theymos did is very constructive.I understand his position…but it only hurts the cause, unfortunately - the PR battle is not the same thing as a discussion on technical merits. He hurts the PR battle and plays into Mike’s hand by doing that. The actual underlying issue actually has little to do with block size - it has to do with Mike and Gavin feeling that the core devs are being obstructionist.
Regardless of the technical merits of XT, the fact that we’ve never done a hard fork before, not even for things some other devs have wanted…and not due to any malice on anyone’s part but because simply that’s just the nature of decentralized consensus with well-defined settlement guarantees…this is the problem - Mike and Gavin think they’re somehow special and their fork should be pushed while the rest of us resist pushing our own controversial pet ideas because we want civility and understand that at this stage in Bitcoin’s development trying to fork the blockchain over highly divisive issues is counterproductive and destructive.
But the fact of the matter is that in the PR battle, arguments against the fork actually play into Mike’s hand, and that’s the problem.
The whole block size thing is too nuanced and too easily spun simplistically. It’s too easy to spin resistance to bigger blocks (even though the resistance is actually much more towards untested hardforking mechanisms and serious security concerns) as “obstructionism” and it’s too easy to spin bigger blocks as “scalability” because most of the people can’t tell the fucking difference.
The fact is most of the people don’t really understand the fundamental issue and are taking sides based on charismatic leadership and authority which is actually entirely counter to the spirit of decentralized consensus. It’s beyond ironic.
If you guys want to win the PR battle, the key is to make it clear that you are not obstructionist and are giving everyone equal treatment…Bitcoin was designed such that changing the rules is *hard* and this is a feature. Bitcoin simply does not have a reliable and tested hard forking mechanism…and a hard fork for such a politically divisive issue will almost certainly lead to a lack of cooperation and refusal to work together out of spite. All of us would like to be able to process more transactions on the network. It’s not a matter of whether we think higher capacity is a bad thing - it’s more that some of us are concerned that Bitcoin is not sufficiently mature to be able to handle such a schism with so much hostility.
Let’s face it, folks - from a PR standpoint, the block size issue is irrelevant. Nobody really understands it except for a handful of people - I’ve tried to explain it, I’ve even written articles about it - but most people just don’t get it. Most people don’t really get scalability either - they seem to think that scalability is just doing the same thing you’ve always done manyfold.
Block size is an especially dangerous issue politically because it’s one of those that requires deep understanding yet superficially sounds really simple. It’s perfect Dunning-Kruger bait.
So let’s be a little smarter about this.
[-- Attachment #1.2: Type: text/html, Size: 5866 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 16:37 ` Eric Lombrozo
@ 2015-08-17 16:55 ` Eric Lombrozo
2015-08-18 4:37 ` Dave Scotese
2015-08-18 9:46 ` NxtChg
1 sibling, 1 reply; 22+ messages in thread
From: Eric Lombrozo @ 2015-08-17 16:55 UTC (permalink / raw)
To: NxtChg; +Cc: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 3984 bytes --]
I should add that in the interest of peace and goodwill, I extend an offer to both Mike and Gavin to make their grievances heard…but only on the condition that we make a good effort to avoid misrepresentation and misreading of the other side’s intentions.
> On Aug 17, 2015, at 9:37 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>
>> Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin?
>>
>> Let users decide what Bitcoin is or isn't.
>
> FWIW,
>
> I don’t think what theymos did is very constructive.I understand his position…but it only hurts the cause, unfortunately - the PR battle is not the same thing as a discussion on technical merits. He hurts the PR battle and plays into Mike’s hand by doing that. The actual underlying issue actually has little to do with block size - it has to do with Mike and Gavin feeling that the core devs are being obstructionist.
>
> Regardless of the technical merits of XT, the fact that we’ve never done a hard fork before, not even for things some other devs have wanted…and not due to any malice on anyone’s part but because simply that’s just the nature of decentralized consensus with well-defined settlement guarantees…this is the problem - Mike and Gavin think they’re somehow special and their fork should be pushed while the rest of us resist pushing our own controversial pet ideas because we want civility and understand that at this stage in Bitcoin’s development trying to fork the blockchain over highly divisive issues is counterproductive and destructive.
>
> But the fact of the matter is that in the PR battle, arguments against the fork actually play into Mike’s hand, and that’s the problem.
>
> The whole block size thing is too nuanced and too easily spun simplistically. It’s too easy to spin resistance to bigger blocks (even though the resistance is actually much more towards untested hardforking mechanisms and serious security concerns) as “obstructionism” and it’s too easy to spin bigger blocks as “scalability” because most of the people can’t tell the fucking difference.
>
> The fact is most of the people don’t really understand the fundamental issue and are taking sides based on charismatic leadership and authority which is actually entirely counter to the spirit of decentralized consensus. It’s beyond ironic.
>
> If you guys want to win the PR battle, the key is to make it clear that you are not obstructionist and are giving everyone equal treatment…Bitcoin was designed such that changing the rules is *hard* and this is a feature. Bitcoin simply does not have a reliable and tested hard forking mechanism…and a hard fork for such a politically divisive issue will almost certainly lead to a lack of cooperation and refusal to work together out of spite. All of us would like to be able to process more transactions on the network. It’s not a matter of whether we think higher capacity is a bad thing - it’s more that some of us are concerned that Bitcoin is not sufficiently mature to be able to handle such a schism with so much hostility.
>
> Let’s face it, folks - from a PR standpoint, the block size issue is irrelevant. Nobody really understands it except for a handful of people - I’ve tried to explain it, I’ve even written articles about it - but most people just don’t get it. Most people don’t really get scalability either - they seem to think that scalability is just doing the same thing you’ve always done manyfold.
>
> Block size is an especially dangerous issue politically because it’s one of those that requires deep understanding yet superficially sounds really simple. It’s perfect Dunning-Kruger bait.
>
> So let’s be a little smarter about this.
[-- Attachment #1.2: Type: text/html, Size: 6633 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 16:55 ` Eric Lombrozo
@ 2015-08-18 4:37 ` Dave Scotese
2015-08-18 5:13 ` GC
0 siblings, 1 reply; 22+ messages in thread
From: Dave Scotese @ 2015-08-18 4:37 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 6513 bytes --]
Three things:
1) Hostility is generally the result of perceived hostility. If you assume
the best intentions of another person, you will eventually find yourself in
one of two places. Either you will find truth with that person (becuase
they are also seeking it), or you will drive them away (because you will
ask questions that can't be answered by someone trying to deceive).
2) The Wiki says "The current Core developers are Wladimir J. van der Laan,
Gavin Andresen, Jeff Garzik, Gregory Maxwell, and Pieter Wuille." I've
seen no hostility from any of these people.
3) The people who are threatened by Bitcoin aren't stupid enough to ignore
#1. Can anyone imagine that they have not hired highly skilled
psychological warfare agnts to do everything they can to "help" assault
what we decentralization enthusiasts have been working for?
About #2: I'm actually blind to hostility, and that is an intentional
affectation in response to my recognition of #1 and #3 together. If you
feel another person has expressed a bad idea, just ignore it. If you feel
they might be misleading others, post a reply about what you know to clear
up any possible misconceptions. There is no point in identifying
individuals who are being hostile, or pointing out hostility, or being
divisive. Let the rest of us recognize it on our own. Maybe send
something like what I'm writing now.
PS: If anyone is interested in conspiracy theories, I had written this into
my gmail compose window and (presumably) hit a wrong key which caused the
thread to be marked as spam and deleted my whole reply. It hadn't even
saved a draft. I've never seen gmail not save a draft before.
On Mon, Aug 17, 2015 at 9:55 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I should add that in the interest of peace and goodwill, I extend an offer
> to both Mike and Gavin to make their grievances heard…but only on the
> condition that we make a good effort to avoid misrepresentation and
> misreading of the other side’s intentions.
>
> On Aug 17, 2015, at 9:37 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Great, so how about you go tell theymos to stop censoring XT posts and
> banning the other side on /r/Bitcoin?
>
> Let users decide what Bitcoin is or isn't.
>
>
> FWIW,
>
> I don’t think what theymos did is very constructive.I understand his
> position…but it only hurts the cause, unfortunately - the PR battle is not
> the same thing as a discussion on technical merits. He hurts the PR battle
> and plays into Mike’s hand by doing that. The actual underlying issue
> actually has little to do with block size - it has to do with Mike and
> Gavin feeling that the core devs are being obstructionist.
>
> Regardless of the technical merits of XT, the fact that we’ve never done a
> hard fork before, not even for things some other devs have wanted…and not
> due to any malice on anyone’s part but because simply that’s just the
> nature of decentralized consensus with well-defined settlement
> guarantees…this is the problem - Mike and Gavin think they’re somehow
> special and their fork should be pushed while the rest of us resist pushing
> our own controversial pet ideas because we want civility and understand
> that at this stage in Bitcoin’s development trying to fork the blockchain
> over highly divisive issues is counterproductive and destructive.
>
> But the fact of the matter is that in the PR battle, arguments against the
> fork actually play into Mike’s hand, and that’s the problem.
>
> The whole block size thing is too nuanced and too easily spun
> simplistically. It’s too easy to spin resistance to bigger blocks (even
> though the resistance is actually much more towards untested hardforking
> mechanisms and serious security concerns) as “obstructionism” and it’s too
> easy to spin bigger blocks as “scalability” because most of the people
> can’t tell the fucking difference.
>
> The fact is most of the people don’t really understand the fundamental
> issue and are taking sides based on charismatic leadership and authority
> which is actually entirely counter to the spirit of decentralized
> consensus. It’s beyond ironic.
>
> If you guys want to win the PR battle, the key is to make it clear that
> you are not obstructionist and are giving everyone equal treatment…Bitcoin
> was designed such that changing the rules is *hard* and this is a feature.
> Bitcoin simply does not have a reliable and tested hard forking
> mechanism…and a hard fork for such a politically divisive issue will almost
> certainly lead to a lack of cooperation and refusal to work together out of
> spite. All of us would like to be able to process more transactions on the
> network. It’s not a matter of whether we think higher capacity is a bad
> thing - it’s more that some of us are concerned that Bitcoin is not
> sufficiently mature to be able to handle such a schism with so much
> hostility.
>
> Let’s face it, folks - from a PR standpoint, the block size issue is
> irrelevant. Nobody really understands it except for a handful of people -
> I’ve tried to explain it, I’ve even written articles about it - but most
> people just don’t get it. Most people don’t really get scalability either -
> they seem to think that scalability is just doing the same thing you’ve
> always done manyfold.
>
> Block size is an especially dangerous issue politically because it’s one
> of those that requires deep understanding yet superficially sounds really
> simple. It’s perfect Dunning-Kruger bait.
>
> So let’s be a little smarter about this.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
[-- Attachment #2: Type: text/html, Size: 8746 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-18 4:37 ` Dave Scotese
@ 2015-08-18 5:13 ` GC
2015-08-18 5:33 ` Dave Scotese
0 siblings, 1 reply; 22+ messages in thread
From: GC @ 2015-08-18 5:13 UTC (permalink / raw)
To: Dave Scotese, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7210 bytes --]
Dave,
³ Š highly skilled psychological warfare agents ..²
Paranoia, much?
Or perhaps the ³enemies" of Bitcoin are just sitting patiently, waiting for
it to collapse in time due to its internal contradictions.
From: Dave Scotese via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Reply-To: Dave Scotese <dscotese@litmocracy•com>
Date: Tuesday, 18 August 2015 12:37 pm
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Three things:
1) Hostility is generally the result of perceived hostility. If you assume
the best intentions of another person, you will eventually find yourself in
one of two places. Either you will find truth with that person (becuase
they are also seeking it), or you will drive them away (because you will ask
questions that can't be answered by someone trying to deceive).
2) The Wiki says "The current Core developers are Wladimir J. van der Laan,
Gavin Andresen, Jeff Garzik, Gregory Maxwell, and Pieter Wuille." I've seen
no hostility from any of these people.
3) The people who are threatened by Bitcoin aren't stupid enough to ignore
#1. Can anyone imagine that they have not hired highly skilled
psychological warfare agnts to do everything they can to "help" assault what
we decentralization enthusiasts have been working for?
About #2: I'm actually blind to hostility, and that is an intentional
affectation in response to my recognition of #1 and #3 together. If you
feel another person has expressed a bad idea, just ignore it. If you feel
they might be misleading others, post a reply about what you know to clear
up any possible misconceptions. There is no point in identifying
individuals who are being hostile, or pointing out hostility, or being
divisive. Let the rest of us recognize it on our own. Maybe send something
like what I'm writing now.
PS: If anyone is interested in conspiracy theories, I had written this into
my gmail compose window and (presumably) hit a wrong key which caused the
thread to be marked as spam and deleted my whole reply. It hadn't even
saved a draft. I've never seen gmail not save a draft before.
On Mon, Aug 17, 2015 at 9:55 AM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I should add that in the interest of peace and goodwill, I extend an offer to
> both Mike and Gavin to make their grievances heardŠbut only on the condition
> that we make a good effort to avoid misrepresentation and misreading of the
> other side¹s intentions.
>
>> On Aug 17, 2015, at 9:37 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>>
>>> On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> Great, so how about you go tell theymos to stop censoring XT posts and
>>> banning the other side on /r/Bitcoin?
>>>
>>> Let users decide what Bitcoin is or isn't.
>>
>> FWIW,
>>
>> I don¹t think what theymos did is very constructive.I understand his
>> positionŠbut it only hurts the cause, unfortunately - the PR battle is not
>> the same thing as a discussion on technical merits. He hurts the PR battle
>> and plays into Mike¹s hand by doing that. The actual underlying issue
>> actually has little to do with block size - it has to do with Mike and Gavin
>> feeling that the core devs are being obstructionist.
>>
>> Regardless of the technical merits of XT, the fact that we¹ve never done a
>> hard fork before, not even for things some other devs have wantedŠand not due
>> to any malice on anyone¹s part but because simply that¹s just the nature of
>> decentralized consensus with well-defined settlement guaranteesŠthis is the
>> problem - Mike and Gavin think they¹re somehow special and their fork should
>> be pushed while the rest of us resist pushing our own controversial pet ideas
>> because we want civility and understand that at this stage in Bitcoin¹s
>> development trying to fork the blockchain over highly divisive issues is
>> counterproductive and destructive.
>>
>> But the fact of the matter is that in the PR battle, arguments against the
>> fork actually play into Mike¹s hand, and that¹s the problem.
>>
>> The whole block size thing is too nuanced and too easily spun simplistically.
>> It¹s too easy to spin resistance to bigger blocks (even though the resistance
>> is actually much more towards untested hardforking mechanisms and serious
>> security concerns) as ³obstructionism² and it¹s too easy to spin bigger
>> blocks as ³scalability² because most of the people can¹t tell the fucking
>> difference.
>>
>> The fact is most of the people don¹t really understand the fundamental issue
>> and are taking sides based on charismatic leadership and authority which is
>> actually entirely counter to the spirit of decentralized consensus. It¹s
>> beyond ironic.
>>
>> If you guys want to win the PR battle, the key is to make it clear that you
>> are not obstructionist and are giving everyone equal treatmentŠBitcoin was
>> designed such that changing the rules is *hard* and this is a feature.
>> Bitcoin simply does not have a reliable and tested hard forking mechanismŠand
>> a hard fork for such a politically divisive issue will almost certainly lead
>> to a lack of cooperation and refusal to work together out of spite. All of us
>> would like to be able to process more transactions on the network. It¹s not a
>> matter of whether we think higher capacity is a bad thing - it¹s more that
>> some of us are concerned that Bitcoin is not sufficiently mature to be able
>> to handle such a schism with so much hostility.
>>
>> Let¹s face it, folks - from a PR standpoint, the block size issue is
>> irrelevant. Nobody really understands it except for a handful of people -
>> I¹ve tried to explain it, I¹ve even written articles about it - but most
>> people just don¹t get it. Most people don¹t really get scalability either -
>> they seem to think that scalability is just doing the same thing you¹ve
>> always done manyfold.
>>
>> Block size is an especially dangerous issue politically because it¹s one of
>> those that requires deep understanding yet superficially sounds really
>> simple. It¹s perfect Dunning-Kruger bait.
>>
>> So let¹s be a little smarter about this.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/> .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
_______________________________________________ bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 11523 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-18 5:13 ` GC
@ 2015-08-18 5:33 ` Dave Scotese
0 siblings, 0 replies; 22+ messages in thread
From: Dave Scotese @ 2015-08-18 5:33 UTC (permalink / raw)
To: GC; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On Mon, Aug 17, 2015 at 10:13 PM, GC <slashdevnull@hotmail•com> wrote:
> Dave,
>
> “ … highly skilled psychological warfare agents ..”
>
> Paranoia, much?
>
> Well, I respect your characterization of it as paranoia, sure. If you
check out the #1 podcast in higher education on podomatic.com, you may find
that it's more awareness than paranoia. There are other resources too,
like GnosticMedia, SchoolSucksProject, and Corbett Report. These programs
are not addressing bitcoin specifically or even generally. They simply
show that people with high intelligence do not always have the best
interests of the rest of their species in mind when they engineer
solutions. For example, taxation is a form of parasitic human cannibalism,
not in the eating of flesh, but in the consuming of life force. The
methods of farming humans to tolerate such a system are quite advanced.
Learning is the answer. Defend yourself for the sake of everyone else.
Dave
[-- Attachment #2: Type: text/html, Size: 2013 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 16:37 ` Eric Lombrozo
2015-08-17 16:55 ` Eric Lombrozo
@ 2015-08-18 9:46 ` NxtChg
2015-08-19 9:47 ` Jorge Timón
1 sibling, 1 reply; 22+ messages in thread
From: NxtChg @ 2015-08-18 9:46 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: bitcoin-dev
Eric,
>FWIW...
These are all good points and I agree with most of them. Yes, the block size debate is a lucky historical accident, which makes it easier for XT to pull off the split, but that's not the point.
The point is, the split _must_ happen because the centralized governance of Bitcoin became a bigger problem than the risks of a fork or larger blocks.
You cannot govern a decentralized currency with a centralized entity.
That's why we shouldn't fear hard forks - they are the new reality, and if we cannot set up a reliable process for them to happen then there _is_ no decentralized Bitcoin and we all might as well just give up and go home.
----
And that's why it would be nice to have a more complex voting mechanism in the block header (see this proposal for the new header format, for example: https://bitcointalk.org/index.php?topic=1151698) and other initiatives to make forking more reliable and user choice easier.
This is a better path than trying to suppress all forks by dictatorship methods of the few currently in power.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-17 14:36 ` Adam Back
2015-08-17 14:58 ` GC
2015-08-17 15:03 ` Levin Keller
@ 2015-08-19 3:49 ` odinn
2 siblings, 0 replies; 22+ messages in thread
From: odinn @ 2015-08-19 3:49 UTC (permalink / raw)
To: Adam Back, Eric Lombrozo; +Cc: Bitcoin Dev
-----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@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@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-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Annoucing Not-BitcoinXT
2015-08-18 9:46 ` NxtChg
@ 2015-08-19 9:47 ` Jorge Timón
0 siblings, 0 replies; 22+ messages in thread
From: Jorge Timón @ 2015-08-19 9:47 UTC (permalink / raw)
To: NxtChg; +Cc: Bitcoin Dev
On Tue, Aug 18, 2015 at 11:46 AM, NxtChg via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Eric,
>
>>FWIW...
>
> These are all good points and I agree with most of them. Yes, the block size debate is a lucky historical accident, which makes it easier for XT to pull off the split, but that's not the point.
>
> The point is, the split _must_ happen because the centralized governance of Bitcoin became a bigger problem than the risks of a fork or larger blocks.
>
> You cannot govern a decentralized currency with a centralized entity.
Nobody has complained about Bitcoin-XT (nor libbitcoin, nor libcoin,
nor against any other of the multiple alternative implementations of
bitcoin).
Please, understand that people are worried about the schism hardfork,
not about the software fork (which happened long ago when some of
Hearn's changes were reverted due to security concerns). If Bitcoin-XT
didn't had a schism hardfork, nobody would be calling it "an altcoin".
For consensus rules we use "the implementation is the specification"
as a principle for multiple reasons. By separating libconsensus (a
work in progress [far less progress than I would like]) we remove
Bitcoin Core's privileged position: Bitcoin Core wouldn't be "the
specification of the consensus rules" anymore, just a reference
implementation that is not "consensus-safer" compared to alternative
implementations (since they can use libconsensus directly [or a
software fork of it in the case of a reasonable schism hardfork]).
> That's why we shouldn't fear hard forks - they are the new reality, and if we cannot set up a reliable process for them to happen then there _is_ no decentralized Bitcoin and we all might as well just give up and go home.
We have many reasons to fear schism hardforks (
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Schism1_hardforks
), even though they may be unavoidable at some point (ie for an
ASIC-reset hardfork).
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2015-08-19 9:47 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-16 22:34 [bitcoin-dev] Annoucing Not-BitcoinXT jyellen
2015-08-17 3:10 ` jl2012
2015-08-17 7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2015-08-17 12:40 ` Vali Zero
2015-08-17 13:34 ` NxtChg
2015-08-17 14:03 ` Eric Lombrozo
2015-08-17 14:09 ` Levin Keller
2015-08-17 14:30 ` Eric Lombrozo
2015-08-17 14:36 ` Adam Back
2015-08-17 14:58 ` GC
2015-08-17 15:03 ` Levin Keller
2015-08-17 15:07 ` Eric Lombrozo
2015-08-19 3:49 ` odinn
2015-08-17 15:10 ` NxtChg
2015-08-17 16:37 ` Eric Lombrozo
2015-08-17 16:55 ` Eric Lombrozo
2015-08-18 4:37 ` Dave Scotese
2015-08-18 5:13 ` GC
2015-08-18 5:33 ` Dave Scotese
2015-08-18 9:46 ` NxtChg
2015-08-19 9:47 ` Jorge Timón
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox