In the case of Bitcoin, code is synonymous with politics. Code is law, Bitcoin is a social contract. Consensus is a form of democracy, and the fundamental protocol rules are like a constitution.

This dillema in Bitcoin can not be simplified, you can not come up with one liners that adequatly explain all of the relavant factors involved with this issue. However I can present you with an extremely simplfied argument since you did request it, If you would like to see this in context I suggest you read the whole article I have written on the subject.

To put it simply, if we do not increase the block size it will be more expensive and less people will be able to use it, that is to transact on the main chain directly.

However if we increase the block size then it will be less expensive and more people will be able to use it. Even if full nodes will only be able to be hosted on powerful computers with high bandwidth connections. Considering that these would be the most likely outcomes with increased adoption. I argue that increasing the blocksize is the most decentralized option considering the alternative.

https://bitcointalk.org/index.php?topic=1164464.0

I am not convinced by your argument. It would be more convincing if you tried to rebuttal the arguments that have already been presented.

Similar to how several people convinced themselves that "bitcoin couldn't scale" (and so now we see such a vicious backlash against increasing the max block size as these people overcome their cognitive dissonance), I think people also convinced themselves that Bitcoin Core would be the permanent core of Bitcoin (and again now they make up reasons for why we need centralized development to keep Bitcoin decentralized).  

It's sort of ironic that the push to increase the block size is what woke the community up to the problem of developer centralization in the first place.  Prior to this debate, people took it for granted that "basically everyone runs Core."  



In response to Brg444: everyone agrees that the consensus rules need to be such that the implementations don't permanently fork.  That's not the debate here.  The debate surrounds the question of why the choice should be dictated by a specific set of developers.  The only argument I've heard is a hand-wavy "well duh it will be chaos otherwise and the various implementations will all fork."  I don't find that convincing.  

ok, well I have written some Bitcoin code...a few utility scripts in the electrum section of this forum.
Nothing spectacular but since apparently more than you've done, the noob comments are funny.

Have a nice day.

have you ever written any related Bitcoin code?

Logical fallacy my ass.

If I want to blacklist you, I will create an ipset 'blacklist' of type hash:ip

Then I ill add your address by


Thats how its done. You cont need Core or XT to do that.  Any node can do that to you right now, running Core 0.11 or any other version.

Elements...yeah...we already knew that.  Well at least he gives a use case.  Still too vague overall.

btw, if you think your snide sarcasm makes you appear more intelligent or respected, let me inform you: it doesn't.

Let's start simple. Can you give a rational argument against immediately raising the block size cap to 8MB?

Please stop making assumptions about what I know or have done.

The point about blockstream isn't that they need to or should reveal trade secrets.
But many would like them to reveal enough to mitigate concerns over conflict of interests.
Whether or not that is feasible is unknown, but clearly they haven't done it and
I am pointing out that important fact.

As far as a centralized authority being in charge of the code, you are entitled to that opinion.
Ironically, that is an opinion Mike Hearn has expressed too.  But you are anti-XT.  So that
just shows you like the idea of authority, as long as it's one you agree with.

[–]nullc

BRAINSSSS.

But really, look at the kind of work we're doing open source cryptographic solutions to solve really hard problems which other people aren't able or aren't trying to solve, E.g. the CT range proofs that protects commercial confidentiality by making transaction values private. Or using Elements Alpha to give people powerful, secure, auditable databases for internal transaction tracking and clearing. Helping smaller players the Bitcoin industry with uniform access to technical firepower that they're not justified hiring full time (and perhaps couldn't-- being the one hard core bitcoin guru at at web shop is a lonely place to be).
Some companies to look at for examples would be things like RedHat's, Cisco's open source and IETF work, and the Mozilla Corporation. (I'm not saying our dozen or so person company is like these organizations yet, but they are places we've looked for inspiration, places people at blockstream have worked before, etc.)

Oh yeah! That's why Switzerland failed: Having more idiots "vote" on what should go into the consensus politics, instead of a gang of professionals who decide.

That wasn't my intention, but maybe some willful ignorance on my part. (which is probably just a bad)
Anyway, thanks for reply and making me understand the issue better.

You're right, if I understood it correctly, when XT node is under DDoS attack and your node connects to it via TOR it would drop your connection. In normal circumstances that shouldn't happen though.

As you say you cannot control the behaviour of other nodes so such code would probably be better disabled by default. (if someone wants protection from DDoS attacks coming through TOR they could enable it, but as default all peers would be treated the same)

See above.

confirmed: gmax refuses to disclose blockstream business model beyond vague generalities:

https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu8ityt

What you are saying is true, obviously.

The advantage of several implementations is that rule changes are done more 'democratically'.  Contrast this to the current debate where the 'core' doesn't want to raise the blocksize limit right now but others do, and those that do are forced to implement code from Mike Hearn, who not everyone trusts.

You must not deal or look at altcoins much eh?

By sowing more disinformation?


And how do you stop other nodes from using the feature against you? Turning it off stops your node from deprioritising others, not others from deprioritising you. This is an elementary logical fallacy; you cannot control the behaviour of other nodes, only your own.


Does a hardcoded list of permissible TOR exit nodes compromise privacy? Can I get a "hell yes"? (link to the XT relevant code, conveniently, is a few posts above)

With the current limit of 1mb for the last 5 years, the vast majority of blocks averaged about 40% of this limit. Miners are incentivized to produce the tightest, efficient blocks  dependent upon tx's.  Its only in the last few months that tx'x are such that block sizes are tending to close on this limit.

A good example of where the anti-Blockstream people have a point IMO.

How will Lightning make money, and for who? How will that be structured? Will settling all Lightning channels on the blockchain provide enough revenue to keep miners incentivised?

The answers aren't complete because the system isn't finished. Where my agreement with people like knight22 ends is with their conclusion: because side chains framework and Lightning are currently incomplete, therefore the only other scaling "solution" is what everyone should choose, regardless of the flaws in that idea. Being the only game in town is frequently cited as a good reason to support 101 lol

we basically agree but I still don't see any reason why it needs to remain "centralized" so for that reason I don't think you've invalidated what Peter R had to say.