Analysis and list of top big blocks shills (XT #REKT ignorers)

[Zarathustra]

The core development team had more than enough time now to design a version of Bitcoin that allows scalability.

Core has already designed "a version of Bitcoin that allows scalability."

Is that the one that Nobody Wants^tm?

Nobody Wants a contentious hard fork and subsequent catastrophic consensus failure, except XT/Unlimited/Classic dead-enders (but you guys don't matter, because Bitcoin is not a democracy).

The people who matter support Core.  Here, have some Fact Welfare you poor, low-information Toominista.

https://bitcoin.org/en/bitcoin-core/capacity-increases

Why don't you follow your role model Mike Hearn's example, and ride off into the sunset?

You've got the whining part down, now you just need to GTFO.   

You are always so angry. I love that about you....  

These angry-miCE threads are amusing.

[sAt0sHiFanClub]

That is a list of people who support Core's scaling roadmap.  The "incisive point" is that you are a liar that claimed "nobody wants" Core's approach.

We, the undersigned, support the roadmap in Capacity increases for the Bitcoin system. We have been working on scalability for several years within the Bitcoin Core project and consider this the best possible continuation of our efforts.

The list of core contributers is much longer and may be found at github.

Maybe you missed that highlighted bit.  Do you have a list of turkeys who vote for Christmas?

You are giving me a list of those in involved in creating the approach, and attempt to pass it off as a list of those who support it. Of course they support it, you numpty. 

[Lauda]

Hmm ... let's write some lines of code to restrict transaction size to let's say 1 MB instead of writing 500 lines of code for Segregated Witness that quadripples the complexicity of bitcoin and brings less capacity to a later point in time?

Stop being hyperbolic.

Are you referring to unbounded hashed bytes for sigops? Why not bound them? And are all these transactions isStandard()?

Example transaction.
What kind of transaction could take that long to validate?

a large transaction with a lot of SIGHASH_ALL signatures, basically

The problem is that the algorithm used for SIGHASH_ALL is O( n2 ), and requires that you hash 1.2 GB of data for a 1 MB transaction.

Maybe you missed that highlighted bit.  You are giving me a list of those in involved in creating the approach, and attempt to pass it off as a list of those who support it.

So let's take the development away from a group with several years of experience and assign it to people with much less experience or none? In what world does that make sense?

[sAt0sHiFanClub]

Maybe you missed that highlighted bit.  You are giving me a list of those in involved in creating the approach, and attempt to pass it off as a list of those who support it.

So let's take the development away from a group with several years of experience and assign it to people with much less experience or none? In what world does that make sense?

I dont think that was the point we were making.

But as you mention it, it is an open source project. Anyone can make a contribution and if it passes review it can be accepted. Are you saying that the *only* talented developers in the world work with core? That is utter cock. There are plenty of talented developers who can get involved.

But its a moot point - most of the good contributors would continue with whatever gained consensus.  Unless they felt the politics is more important than the code. In which case they are welcome to leave.

[sAt0sHiFanClub]

Are you referring to unbounded hashed bytes for sigops? Why not bound them? And are all these transactions isStandard()?

Example transaction.
What kind of transaction could take that long to validate?

a large transaction with a lot of SIGHASH_ALL signatures, basically

The problem is that the algorithm used for SIGHASH_ALL is O( n2 ), and requires that you hash 1.2 GB of data for a 1 MB transaction.

I answered this earlier

Sensible bounds on memory usage per tx or time based rules mitigate or solve this entirely.

If you are putting so much into a tx, then you are exceeding isStandard() rules anyway. 

[jonald_fyookball]

So let's take the development away from a group with several years of experience and assign it to people with much less experience or none? In what world does that make sense?

Experience is important but it is not the only factor.  If the experienced group doesn't have the right goals, then you end up reaching the wrong ones.

[siameze]

As a developer for Bitcoin Classic, and co-Chief Architect along with jstolfi, you should have input into the message stored in the Classic "genesis block" that will be produced in a few months.

Oops, thanks for reminding me.  The Toomims tasked me with doing something momentous that will be the headline of /The Times/ on the launch date.  Maybe start a war, find Elvis, or commandeer a UFO to abduct the Pope from a nudist beach and demand ransom in bitcoin.

Only that it will not be a Genesis block, of course, but a Nativity block.

Ooooh Nativity blocks! Our Bitcoin is much more enlightened with 2 MB Nativity blocks. 

[btcusury]

Thank you btcusury, this was an very interesting read. It even made me consider to understand theymos' censorship and ascribe him some kind of heroism.

But yes, what you write is to some kind an eye-opener to understand the small block side.

On the other side you and Lauda seem to fail to understand the other side - the big blockers - and so you built a conspiracy theory about some takeover through "leaders" and "companies" manipulating the markets. The truth may be more simple:

the economy lost faith in core to solve the scalability problem.

Why? From a technical side, core presented a solution (SW) that may be better (I have doubt, but don't want to discuss). But bitcoin is not just technology, it's also economy and politic. It's nothing without exchanges and holders, and a consensus is nothing without a compromise. You seem to recognise this by acknowledging peter_r's grafic. But you don't acknowledge it enough to understand the other side. Maybe this is a result of engineering dominance in core and a lack of understanding of the need of economics and politics.

In the context of Bitcoin, "consensus" refers to "technical consensus" at the protocol level, not "economic consensus" at the user level or "political consensus" at opinion level, despite how much the latter two ideas/memes have been spread lately. Yes, it's permissionless, so you are free to create a hardforked chain bootstrapped off the Bitcoin blockchain, but don't pretend there is "consensus" if the "consensus" is only at a user (economic/political) level after (what at least appears to be) a relentless disinformation campaign to direct the technology into a particular untested/risky nonreversible territory.

Try to see it as you were coinbase. The scalability issue is well known for years. In the past it was always said the blocklimit will just be raised. Now we discuss raising it since 1,5 years, and nothing happened by now.

Coinbase is just a business trying to benefit from a particular technology, without much regard for the direction of the technology -- one that happens to contain unprecedented revolutionary potential, which we should do our (technical) best to preserve/develop. The question is, why are you into Bitcoin? To make money? Or to help move us toward a fairer economic system free from central control and manipulation (debt-based fractional reserve fiat bankster "money")?

As a technologist you could say: yes, it was a coup de liberation, we have SW (there are reasons to discusss this, but here I don't mind). As a politician seeking consensus through compromise, you can only say, it's a disaster.

The premise of "a politician seeking consensus through compromise", and even the premise of a politician itself, is highly questionable, to say the least. Just as politicians (and their spokespeople, the mainstream media "news" outlets) manipulate minds by means of filtering out other information sources, thus exposing minds to particular agenda-driven ideas to the exclusion of more relevant/interesting/better ones, so any opposition group, be it a "radical" political party or grassroots organization or terrorist group or foreign "leader" of a country or (you can safely bet) a decentralized payment system, is targeted by means of getting people to promote disinformation as misinformation. So it's not that there would have to be many actual paid shills spreading disinformation (a major conspiracy, to use that term); the majority of them would be spreading misinformation after having been exposed to cleverly-crafted disinformation.

- the defenders of core's decision act "strange" (ddos, censorship)

Or, an impression has been created that they act strange. Discussion of DDoS comes from individuals, not Core devs, and you already got an answer to the moderation/censorship, no?

Do you really need a conspiracious takeover to understand why businesses support classic en mass?

No, but wouldn't it be the perfect opportunity for such a "takeover" to be executed? Like I asked sgbett (to no response), "At what point, if at all, do you suppose an organized effort to protect the dying old comes into play?"

[Lauda]

I answered this earlier

Sensible bounds on memory usage per tx or time based rules mitigate or solve this entirely.

If you are putting so much into a tx, then you are exceeding isStandard() rules anyway.  

There is currently no solution and you are wrong. XT introduced a per transaction limit (if I'm correct). Core will address this via BIP 143 ,which is an actual improvement unlike the workaround in XT, and a limit. However this is node policy, miners can still create a transaction that would take too long to validate and that would harm the network.

Experience is important but it is not the only factor.  If the experienced group doesn't have the right goals, then you end up reaching the wrong ones.

This comes down to the same thing actually, what is the 'right goal'? This discussion goes in circles. In any case the Core developers are definitely better than those behind Classic.

[VeritasSapere]

So let's take the development away from a group with several years of experience and assign it to people with much less experience or none? In what world does that make sense?

I think you are missing the point, it is not about one development team over another, it is about decentralizing development overall. Having multiple viable implementations of the Bitcoin protocol allows the governance mechanism of Bitcoin to function more effectively by giving us more freedom of choice.

Experience is important but it is not the only factor.  If the experienced group doesn't have the right goals, then you end up reaching the wrong ones.

This comes down to the same thing actually, what is the 'right goal'? This discussion goes in circles. In any case the Core developers are definitely better than those behind Classic.

Classic and Core have different goals, which one we consider better depends on our personal ideologies. I think that Classic is better since I think they are more willing to scale Bitcoin directly compared to Core.

[sAt0sHiFanClub]

I answered this earlier

Sensible bounds on memory usage per tx or time based rules mitigate or solve this entirely.

If you are putting so much into a tx, then you are exceeding isStandard() rules anyway.  

There is currently no solution and you are wrong. XT introduced a per transaction limit (if I'm correct). Core will address this via BIP 143 ,which is an actual improvement unlike the workaround in XT, and a limit. However this is node policy, miners can still create a transaction that would take too long to validate and that would harm the network.

I beg to differ, I think you are wrong when you suggest "there is no solution". Even the text of BIP143 describes what can be done - it says its non-trivial, not impossible. Their biggest objection is the hard fork ( as usual). But as I described, this can be mitigated by a refined version of the XT fix.

Bip143 is part of segwit. Its part of a 2000+ line change to implement it.  When we are ready for segwit, yeah fine.

XT does not have a per tx limit - its a per block limit. It strives to ascertain rational limits to allow most tx's through but to limit obviously vexatious ones.

[jonald_fyookball]

This comes down to the same thing actually, what is the 'right goal'? This discussion goes in circles. In any case the Core developers are definitely better than those behind Classic.

Absolutely not the same thing.

To use an analogy, a CEO of a company may have a star programmer,
but that programmer is not qualified to do the CEOs job and decide
what the mission of the company should be, what kind of software
it should be producing, or what features are most important.

Experience in programming is one thing.  Deciding what Bitcoin should be is another.
 

[DooMAD]

(...) campaign to direct the technology into a particular untested/risky nonreversible territory.

Where do you get the notion that the changes being discussed are nonreversible?  If we can go from 30-odd mb down to 1mb, then I'm pretty sure we could find our way down from 2 if it was deemed necessary.

[Lauda]

Where do you get the notion that the changes being discussed are nonreversible?  If we can go from 30-odd mb down to 1mb, then I'm pretty sure we could find our way down from 2 if it was deemed necessary.

You do realize that the industry and the userbase is completely different now and in comparison to the time when the change of ~30 to 1 MB was made? It was much easier to get consensus back then and satoshi was still leading the development.

I beg to differ, I think you are wrong when you suggest "there is no solution". XT does not have a per tx limit - its a per block limit. It strives to ascertain rational limits to allow most tx's through but to limit obviously vexatious ones.

With 'no solution' I meant in XT. XT was mitigating the problem not solving it. Besides, unless someone ran enough tests we can not know if it was working.

Experience in programming is one thing.  Deciding what Bitcoin should be is another.

So people who major in economics and politics/other random field should decide what the best technical approach is?

I think that Classic is better since I think they are more willing to scale Bitcoin directly compared to Core.

This is false.

[Zarathustra]

I answered this earlier

Sensible bounds on memory usage per tx or time based rules mitigate or solve this entirely.

If you are putting so much into a tx, then you are exceeding isStandard() rules anyway.  

There is currently no solution and you are wrong. XT introduced a per transaction limit (if I'm correct). Core will address this via BIP 143 ,which is an actual improvement unlike the workaround in XT, and a limit. However this is node policy, miners can still create a transaction that would take too long to validate and that would harm the network.

Experience is important but it is not the only factor.  If the experienced group doesn't have the right goals, then you end up reaching the wrong ones.

In any case the Core developers are definitely better than those behind Classic.

Yes, better in producing BS and collaborating with Totalitarians.

[btcusury]

(...) campaign to direct the technology into a particular untested/risky nonreversible territory.

Where do you get the notion that the changes being discussed are nonreversible?  If we can go from 30-odd mb down to 1mb, then I'm pretty sure we could find our way down from 2 if it was deemed necessary.

Alright, I suppose it would be reversible in an emergency situation in which the system is under such severe attack that everyone's coins are in jeopardy. Otherwise, good luck getting miners and others to agree to go back down to 1 MB.

Experience is important but it is not the only factor.  If the experienced group doesn't have the right goals, then you end up reaching the wrong ones.

In any case the Core developers are definitely better than those behind Classic.

Yes, better in producing BS and collaborating with Totalitarians.

An example, please, of Core developers "collaborating with Totalitarians"?

[DooMAD]

Where do you get the notion that the changes being discussed are nonreversible?  If we can go from 30-odd mb down to 1mb, then I'm pretty sure we could find our way down from 2 if it was deemed necessary.

You do realize that the industry and the userbase is completely different now and in comparison to the time when the change of ~30 to 1 MB was made? It was much easier to get consensus back then and satoshi was still leading the development.

(...) campaign to direct the technology into a particular untested/risky nonreversible territory.

Where do you get the notion that the changes being discussed are nonreversible?  If we can go from 30-odd mb down to 1mb, then I'm pretty sure we could find our way down from 2 if it was deemed necessary.

Alright, I suppose it would be reversible in an emergency situation in which the system is under such severe attack that everyone's coins are in jeopardy. Otherwise, good luck getting miners and others to agree to go back down to 1 MB.

You do realise that reducing blocksize only requires a softfork?  It's much easier to go down than up.  It wouldn't take an emergency, either.  If there was even the slightest sign that larger blocks did jeopardise the network, the miners aren't going to hang around and let their source of income fall apart at the seams.  Either incentives align, or they don't and it quickly reverts back to how it was.

[VeritasSapere]

Thank you btcusury, this was an very interesting read. It even made me consider to understand theymos' censorship and ascribe him some kind of heroism.

But yes, what you write is to some kind an eye-opener to understand the small block side.

On the other side you and Lauda seem to fail to understand the other side - the big blockers - and so you built a conspiracy theory about some takeover through "leaders" and "companies" manipulating the markets. The truth may be more simple:

the economy lost faith in core to solve the scalability problem.

Why? From a technical side, core presented a solution (SW) that may be better (I have doubt, but don't want to discuss). But bitcoin is not just technology, it's also economy and politic. It's nothing without exchanges and holders, and a consensus is nothing without a compromise. You seem to recognise this by acknowledging peter_r's grafic. But you don't acknowledge it enough to understand the other side. Maybe this is a result of engineering dominance in core and a lack of understanding of the need of economics and politics.

In the context of Bitcoin, "consensus" refers to "technical consensus" at the protocol level, not "economic consensus" at the user level or "political consensus" at opinion level, despite how much the latter two ideas/memes have been spread lately. Yes, it's permissionless, so you are free to create a hardforked chain bootstrapped off the Bitcoin blockchain, but don't pretend there is "consensus" if the "consensus" is only at a user (economic/political) level after (what at least appears to be) a relentless disinformation campaign to direct the technology into a particular untested/risky nonreversible territory.

Consensus within Bitcoin is the name for the governance mechanism of Bitcoin. It would be wrong to equate this with the literal meaning of the word consensus, which is that everyone agrees. With larger groups of people this becomes impossible. The consensus mechanism within Bitcoin allows us to resolve disagreements through proof of work and with the ability to split. Solving the problem of tyrrany of the majority. Thinking that consensus only refers to technical issues is false, many of these issues are inherently not just technical. "Consensus" in the literal meaning of the word is of course necessary for the continued operation of the Bitcoin network specifically on what I now call consensus critical issues, however as soon such issues become contentious the network is capable of diverging or changing. This is a very important feature of Bitcoin, which for me ensures the continued freedom and decentralization of the protocol.

Consensus is an emergent property which flows from the will of the economic majority. Proof of work is the best way to measure this consensus. The pools act as proxy for the miners, pools behave in a similar way to representatives within a representative democracy. Then in turn the miners act as a proxy for the economic majority. Since the miners are incentivized to follow the economic majority. In effect the economic majority rules Bitcoin, in other words the market rules Bitcoin. Bitcoin relies on the economic self-interest of the masses to govern consensus.

Try to see it as you were coinbase. The scalability issue is well known for years. In the past it was always said the blocklimit will just be raised. Now we discuss raising it since 1,5 years, and nothing happened by now.

Coinbase is just a business trying to benefit from a particular technology, without much regard for the direction of the technology -- one that happens to contain unprecedented revolutionary potential, which we should do our (technical) best to preserve/develop. The question is, why are you into Bitcoin? To make money? Or to help move us toward a fairer economic system free from central control and manipulation (debt-based fractional reserve fiat bankster "money")?

One of the beautiful things about Bitcoin is how it incentivizes its participants towards the good of the network, which works towards the good for all. Coinbase wants what is best for Bitcoin, since that is what is best for them as well, the incentive is even stronger for the miners. This is how the game theory behind Bitcoin works, it does rely on certain aspects of human nature, we are a part of this great machine. The irony of Coinbase being a "Bitcoin Bank" so to speak, with custodial accounts, while being funded in part by Wall Street does not escape me. I suppose the enemy of my enemy is my friend.

As a technologist you could say: yes, it was a coup de liberation, we have SW (there are reasons to discusss this, but here I don't mind). As a politician seeking consensus through compromise, you can only say, it's a disaster.

The premise of "a politician seeking consensus through compromise", and even the premise of a politician itself, is highly questionable, to say the least.

Consensus in the literal meaning of the word is impossible among large groups of people, as I already said previously. Therefore the only times "consensus" is possible among larger groups of people is through compromise. Unless more totalitarian and dictatorial approaches are taken. Politics is about influence and the distribution of power and resources within a given community. For you to think that this is not relevant to Bitcoin or that the premise behind this entire discipline of thought is questionable, I think that is out of touch with reality. Bitcoin does relate to politics, economics, psychology, engineering and computer science among many more fields of thought. To understand the full scope of what Bitcoin is and what we think it should become and how to achieve these goals, requires a multidisciplinary approach.

the defenders of core's decision act "strange" (ddos, censorship)

Or, an impression has been created that they act strange. Discussion of DDoS comes from individuals, not Core devs, and you already got an answer to the moderation/censorship, no?

I think that by not officially speaking out against the censorship Core is complicit in the censorship. They have even honored Theymos by allowing him to be one of the signatories of the road map when he is not even a developer himself.

Do you really need a conspiracious takeover to understand why businesses support classic en mass?

No, but wouldn't it be the perfect opportunity for such a "takeover" to be executed? Like I asked sgbett (to no response), "At what point, if at all, do you suppose an organized effort to protect the dying old comes into play?"

If you think that an increase to two megabyte represents a "takeover" of Bitcoin, I would think that is ridiculous, unless you think this is about control? I do not think any one implementation or development team should be in "control" of Bitcoin. If this was a takeover, it would represent a community takeover from a development team that no longer represents the community and has grown out of touch with the users as well as the economic majority.

Without exaggeration, I have never seen this much disconnect between user wishes and dev outcomes in 20+ years of open source.

[Zarathustra]

Experience is important but it is not the only factor.  If the experienced group doesn't have the right goals, then you end up reaching the wrong ones.

In any case the Core developers are definitely better than those behind Classic.

Yes, better in producing BS and collaborating with Totalitarians.

An example, please, of Core developers "collaborating with Totalitarians"?

An example? LOL. Everybody knows that they constantly 'communicate' via totalitarian forums.

[VeritasSapere]

the defenders of core's decision act "strange" (ddos, censorship)

Or, an impression has been created that they act strange. Discussion of DDoS comes from individuals, not Core devs, and you already got an answer to the moderation/censorship, no?

I think that by not officially speaking out against the censorship Core is complicit in the censorship. They have even honored Theymos by allowing him to be one of the signatories of the road map when he is not even a developer himself.

This is another example of their unethical behavior, from the perspective of freedom loving people at least.