Topic: Please do not change MAX_BLOCK_SIZE - page 9. (Read 13023 times)

Someone asked me to reply....

So Gavin's idea for mining in an anonymous, free from coercion and central control way goes like this:

Step 1. Run a high-bandwidth, publicly visible Bitcoin node.

Step 2. Send the blocks you mine over Tor.


This came up at the conference at the developer round table - it was kinda funny talking to some Argentinians after about the plan. (at the conference Gavin's idea was Step 1 would involve a "censorship-proof satellite" - I think he's since figured out that space isn't known for decentralized grassroots efforts) Those Argentinians figured the discussion they'd wind up having with their local authorities would go roughly like this:

"Q: So tell us why are you running a full Bitcoin node exactly? You don't happen to be mining by any chance do you?"
"A: Um...."


In any case we need mining to be more decentralized, not just done at a few big pools. Anonymity and censorship aside requiring  high-bandwidth sure won't help the situation we're in right now where almost 50% of the network is controlled entirely by two pools.

So why the rush? Why not let the merchants and users ask for change when the need arises?

We might be getting closer to agreement  . I was thinking just now that the software changes for scalability might be well advanced even before 1MB blocks are common. That would be a nice outcome.

With regard to playing with lethal forces: because for most of Bitcoin's lifespan blocks have been way below the 1MB limit (and only recently approached the soft-limits), then it has operated with no effective block limit. Letting it hit the 1MB actually introduces a lethal force where it didn't really exist before.

You are right - if it works, then Tor mining should be easier, though the scaling issues of a home node still remain.

Anyway let's at least hope that they will prove the debunking thesis working, before touching the number.
Though after learning that decentralization is not considered as particularly important, I am not so certain about it...


Because for me Bitcoin has already succeeded and increasing the block size is playing with lethal forces that we don't even understand.
So it has succeeded, but if you act irrationally, you can easily screw it up.

Relying on 3rd-party providers for using BTC makes the above very possible (p2p won't be used by bitcoin-banks as they will want control of their systems).



This is the 2nd software change needed, as well as blockchain pruning:


If this 2nd change works then Bitcoin will be massively scalable and can become the success everyone wants.

Why don't you want Bitcoin to have this chance to succeed?

Why you assume that it would need to be Google/Facebook/Baidu Credits?
Why do you think that a bitcoin backed payment processor cannot be built as just yet another lightweight P2P network, protected by a cryptography?

Why do you guys keep repeating that one would be forced to give all his private keys to a bank?

And what blockchain-pruning has to do with making mining available via Tor?

Excellent post. People won't run nodes if they are priced away from the blockchain, and the worst-case scenario of centralization would occur: Bitcoin with just major companies running server-farm nodes.


once the blockchain-pruning solutions are up and running Tor will be usable for a long time, probably indefinitely.

So what?
Thinking about Tor and the current 1MB limit, still seems like a reasonable number to stop at.

So just stop, take a breath, look around and see how the market responded... and then try to improve it further, if needed.
By increasing the block size limit now, you are not improving anything - you are only making transactions cheaper for satoshidice, which is especially stupid when you consider the fact that the transactions are essentially free ATM. As kjj has nicely phrased it, currently the transactions are being added to the chain on a charity basis - why would anyone aim to make them even cheaper, at the cost of an exponential growth in the price of infrastructure required to run a node, or a miner?

IMO the 1MB limit is the best moment to stop this madness, let the fee market work, and just think about the best way to go from there.
If the best solution to the scaling problem the developers have is magnifying the scaling problem, then I am honestly disappointed.

I really wish this was better known, the amount of people shouting crap about how Satoshi intended for 1MB block size is sad. So many misinformed people here....

Satoshi did not intend the 1MB block size to be final at all and it was not even in the paper or in the original code. He envisioned a much larger dynamic block size.

This is not about microtransactions, at least not in the sense most people understand that word. With the current 1 MB limit per block, the number of transactions is capped at around 7 per second, which roughly translates into 200 million transactions per year. So, if there were 20 million users of Bitcoin in the whole world (a very conservative estimate of what Bitcoin can achieve), the average user would be able to carry out 10 transactions in a year. Say I wanted to get my salary from my employer and then pay my landlord in bitcoins, that would be 24 transactions in a year. With a 20-million user base, such "microtransactions" as paying a salary or a monthly rent would be off-limits to most people. Even if I was willing to pay a hefty fee to get more blockchain space than your average Joe Bloggs, my landlord would have trouble getting his bitcoins out of the chain and would end up saying "But why don't you just pay me in euros?".

The solution proposed by the "do not change MAX_BLOCK_SIZE" advocates, if I understand them correctly, is that I shouldn't use the blockchain for such mundane transactions. Transactions like paying a rent would be handled through off-chain processors that provide me with BTC tokens. But then I'd be using bitcoins as a mere denomination, like the IMF's SDR or the old European ECU. Certainly not what Bitcoin was designed for. And it's far from certain that Bitcoin could even survive in such a scenario. Why would ordinary people even run Bitcoin nodes if it becomes just an infrastructure for Google/Facebook/Baidu Credits? It would make as much sense as running a SWIFT or LCH.Clearnet node (if these systems worked as distributed networks).

There are intermediate solutions between a 1 MB block limit and letting a node create a block of any size.


You can either have digital cash, or you can have a Bitcoin that can be run fully through Tor. You can't have both. Given the philosophy of Bitcoin is to be a digital cash, and being able to run through Tor was not a design goal, raising the block limit, as Nakamoto intended and the devs have been planning for years, is the right decision.

I'm not concerned about censorship of nodes, because they can be run in any jurisdiction in the world. As long as there is some free jurisdiction in the world, the Bitcoin network will be up, and people can access the nodes through encrypted channels if need be.

The important point is that people be able to control their own private keys. If transaction fees go up to $30 due to a 1 MB block size limit, then people will have to trust BTC-banks with their private keys, and transactions will have to take place through these intermediaries. Bitcoin would no longer be a p2p cash.

The cost to make a transaction should be equilibrium point at the intersection of the supply curve and the demand curve.

I'm not sure who constitutes the mysterious "some" you're talking about. Do you have a link to a specific post?

While Bitcoin was small, a low-importance transactions were fine, as the entire network size was small.  However as the network increases in size, so must the 'importance' of the transactions.  Otherwise it becomes disappointingly costly to maintain the network -> thus, creating great economic incentives to centralize the network.

If, for example, fees are LINEARLY related to Network-Size, then the cost of maintaining the network will be LINEAR * LOG (number of unspent outputs).  Or just LINERAR, if you have an unlimited amount of random access storage (eg. RAM).  This is a sustainable proposition. (The fees will pay for the cost of running a node).

The position argued, by some, is that the cost to make a transaction on the Bitcoin network should be CONSTANT.  This means that the cost to run a node on the network (while maintaining the same quality of decentralization); will be increasing faster than the amount of fees, per node.  -> Thus creating an economic situation, where either:  Nodes are subsidized, or the ratio or full nodes vs. uses goes down.

I, personalty, value a very decentralized and non subsidized processing network of Bitcoin full-nodes, more than the utility advantage of having low importance transactions.

Than would it be worth it, to take a portion of the transaction fees and distribute them to the owners of the full nodes. After all they are contributing just as much to the security of bitcoin.

This softens the effect of a mining monopoly that is currently highly centralized.

My point is that the same argument applies to Open-Transactions, or any other known distributed money system, except perhaps zero-knowledge proof systems which are still theoretical. In Open-Transactions you are given the information necessary to audit the server's actions. If you want to make an apples-to-apples comparison, you should be accounting for this computational cost incurred by users who do such validations.

This conceptual argument I take issue with:


The very security model of Bitcoin requires there be multitude of full nodes, unless, if there was only one full-node, then non-bitcoin transactions could be possibly slipped in (unaware to SPV nodes).

For the current standard of decentralization to hold, we need a constant ratio of full nodes vs users.  Having only a few full nodes is a very much a higher-trust security model than what the Bitcoin Network currently provides.

People who advocate a high tpc, must necessarily, advocate a more centralized full-node processing network.  (Because of the QUADRATIC cost of maintaining the decentralization).

No, it's a little disingenuous to make such an argument:


It could very well be constant, if a hash table were used.


There is no protocol reason why more than 1 full node needs to be running. If there are N full nodes, it is because N-1 people decided it was a worthwhile investment of their time and resources to do so. Open-Transactions runs with a single validating node, the server. But audit information is (in theory) available so anyone can check that the server isn't lying. And if they were to do so for all transactions processed by the server, then it would incur the same overhead. Now typically in Open-Transactions one only verifies their own receipts, but the same could be said for SPV/SPV+ clients.


Which with your qualifications is essentially saying that the cost of full validation scales linearly with the number of transactions. No surprise there.

As opposed to removing the limit, letting malicious miners make massive blocks?  Privatizing profit, and distributing the pain?'

If you can't run it over Tor or similar you've just destroyed a much more important part of the philosophy. 

Not only that, it's specifically designed to help with "small, casual transactions" too small to be handled by centralized payment processors who have to charge too much per transaction because they can't avoid doing dispute mediation. This is right there in the first paragraph of the white paper.

While there are some elements of Bitcoin that may be used for microtransactions; I do not believe that it is rational to suggest that Bitcoin-itself is designed for microtransactions.
It comes down to maths.

The cost to check the inputs of a transaction is:
O log(total number of unspent outputs).

The cost of checking any one transaction is:
O (number of full nodes) * (cost of checking a transaction).

The cost of growing the network with a constant number of transactions per user is:
O (number of users) * (cost of the network checking the transaction)

For a constant ratio between users and, full nodes (so we can maintain the decentralization of the network). It can be shown that:
The cost of verifying the Bitcoin Network of any given network size (number of users), for a constant number of transactions and full verifying nodes per user is: QUADRATIC.

or

Cost of Verifying the Transactions of the Bitcoin network = O (network size in users)^2 * log(number of unspent outputs)
Where we assume: Constant number of transactions per user, and a constant ratio of users and full verifying nodes.

This is why I will re-iterate, that Bitcoin was NOT designed for large-scale microtransactions.


EDIT: fixed, from CUBIC to QUADRATIC. (thanks amiller).