Please do not change MAX_BLOCK_SIZE

[tvbcof]

And second, even if it did, there are bigger powers out there that you need to convince - how are you planing to do that, when obviously there already are people who are convincing them otherwise?

Which "bigger powers" and which "people" ?

Is there some secret cabal out there I don't know about?

If you mean "Peter Todd has convinced some big mining pool operators not to increase the size of the blocks they create" -- then great!  That's the free market at work, big mining pools should be free to create blocks that are as large or as small as they like, and to accept or reject other's blocks for whatever reason they like.

Ya know what?  I think you've check-mated us decentralized folks.  A big block can eat a little block, and the SPV's are pawns who have no choice but to upgrade.

I'll have to think about it a bit more, but I think the you and your employer are going to win this one.  So, carry on and make me rich.  My BTC will flow, but they will be to had only dearly.

[Kempelen]

Ya know what?  I think you've check-mated us decentralized folks.  A big block can eat a little block, and the SPV's are pawns who have no choice but to upgrade.

I'll have to think about it a bit more, but I think the you and your employer are going to win this one.  So, carry on and make me rich.  My BTC will flow, but they will be to had only dearly.

Try taking your meds first before thinking. You might at least generate something coherent.

[piotr_n]

And second, even if it did, there are bigger powers out there that you need to convince - how are you planing to do that, when obviously there already are people who are convincing them otherwise?

Which "bigger powers" and which "people" ?

Is there some secret cabal out there I don't know about?

If you mean "Peter Todd has convinced some big mining pool operators not to increase the size of the blocks they create" -- then great!  That's the free market at work, big mining pools should be free to create blocks that are as large or as small as they like, and to accept or reject other's blocks for whatever reason they like.

So you are OK with like 70% of the haspower going to a fork that did not accept your change?
I mean, you do not seem to be concerned about it at all. Like you just assumed "whatever I decide, will be the right choice".
People may just not agree with you. Especially people who run mining pools and basically only their vote counts.
But not disagree with you because they are mean - maybe, like me, they disagree with you from good reasons.
Do you even have any proofs that increasing this number is necessary?

[Gavin Andresen]

So you are OK with like 70% of the haspower going to a fork that did not accept your change?

No, absolutely not. The process for a hard fork looks like:

+ Get rough consensus that the change is necessary.
+ Write the code.
+ Get it reviewed and thoroughly tested.
+ Release software that will support it when X% of hashing power agrees

... where X is a super-majority (like 75% or more).  If 70% of hashing power disagrees, then it doesn't happen. Miners will express support by producing block.version=3 blocks (just like they are now producing block.version=2 blocks that MUST include the chain height in the coinbase transaction).

It is possible the X% threshold will never happen if 1MB is plenty big enough. It is possible it will only happen when transaction fees start going up and pressure increases on pools to make their blocks bigger (or maybe merchants tired of paying high fees figure out they'll save money by mining or operating pools themselves, will get X% of hashing power, and will increase the block size).

Again, I spent a lot of time at the conference talking with people about the block size issue, and there is definitely consensus that 1MB just won't be big enough eventually. That has nothing to do with microtransactions, normal growth in "macrotransactions" will bump up against the limit in a year or three.

[tvbcof]

[Try taking your meds first before thinking. You might at least generate something coherent.

My, how clever and original you are!

I'm try very hard to avoid the tech section in order keep in order to keep it marginally useful.  I'm out now.  I'll sell you some uBTC on the Google 'send money' thingy in a year or two.  So, see ya in hell.

[piotr_n]

So you are OK with like 70% of the haspower going to a fork that did not accept your change?

No, absolutely not. The process for a hard fork looks like:

+ Get rough consensus that the change is necessary.
+ Write the code.
+ Get it reviewed and thoroughly tested.
+ Release software that will support it when X% of hashing power agrees

... where X is a super-majority (like 75% or more).  If 70% of hashing power disagrees, then it doesn't happen. Miners will express support by producing block.version=3 blocks (just like they are now producing block.version=2 blocks that MUST include the chain height in the coinbase transaction).

It is possible the X% threshold will never happen if 1MB is plenty big enough. It is possible it will only happen when transaction fees start going up and pressure increases on pools to make their blocks bigger (or maybe merchants tired of paying high fees figure out they'll save money by mining or operating pools themselves, will get X% of hashing power, and will increase the block size).

Again, I spent a lot of time at the conference talking with people about the block size issue, and there is definitely consensus that 1MB just won't be big enough eventually. That has nothing to do with microtransactions, normal growth in "macrotransactions" will bump up against the limit in a year or three.

sounds like a good idea, thanks for explaining.
I'm gonna vote NO, at least for the next 12 months.
however I do have some mining shares and I wish you did too

[kjj]

You win the Orwellian of the day award for having successfully used every term you included in that rant as if it meant the opposite of its meaning.

What I want is for the network to be allowed to provide a service at a quantity and price that they and their customers find acceptable. You want to ration the amount of transaction processing miners are allowed to provide to their customers.

The fact that we don't know how much it costs to process a transaction is expected and irrelevant.  Miners won't continue to mine if the benefit the receive does not exceed the costs involved, and users will not send transactions if the cost of doing so exceeds the benefit they derive. That's that that matters. If you don't believe this process works in the real world then you should really contemplate how it's possible for the providers of the products and services you consume every day to figure out the correct amount to produce and the correct price to offer it at.

There is always rationing.  The question is how.

In a mature system with a market, I'd let the market figure it out.  That's what market are for, and that's what markets do.

But we don't have a mature system, and we don't have a market.  Not only do we not know what a transaction really costs, we don't have any way to find out.  You are arguing as if I didn't believe in markets.  I do, but I only believe in real markets.  I have absolutely zero faith in the ability of a market that does not and can not exist to provide useful information.

In the absence of useful information, it is prudent to be careful.  Since backpressure on the transaction volume does not reasonably exist yet, and whatever actions we take will have serious long term consequences for the entire world, we should not just remove the limit, nor create dynamic rules that are too easy.

When we do need to increase the limit, I would propose the following rules:  Block max size increases iff at the time of difficulty change, the sum of the size of the last 2016 blocks is > (1814 * block_max_size).  If size increase is indicated, block_max_size+=(block_max_size>>4).  I'll leave the implications as an exercise for the reader.  1814 and 4 are magic numbers, they could be changed, but I suggest they not be any smaller than specified.

[Peter Todd]

[Try taking your meds first before thinking. You might at least generate something coherent.

My, how clever and original you are!

I'm try very hard to avoid the tech section in order keep in order to keep it marginally useful.  I'm out now.  I'll sell you some uBTC on the Google 'send money' thingy in a year or two.  So, see ya in hell.

Don't give up that quick. Gavin represents the United States-centric, FinCEN fearing above-ground side of Bitcoin; the world is a lot bigger and a lot more diverse than that. I suspect Peter Vanesse and his "we'll help regulators crush bad actors" antics are a much smaller part of Bitcoin than you might think.

Speaking of, reminds me of an email I got yesterday:

Date: Sun, 02 Jun 2013 02:40:10 +0100
From: aitahk2l <aitahk2l@tormail.org>
To: pete@petertodd.org
Subject: Your timestamper

We spoke a few months back and I sent you some funds to run your
timestamper.

I'm letting you know we're going back to unspendable txout timestamps
for our needs. Your service is great, but I think you have written it
prematurely. Like you said in your recent bitcoin-development post on
sacrifices if the technology enables a use, people will use it.
Inefficient timestamping is one such use and threatens the blockchain
with unlimited bloat, but from what I hear from Gavin he doesn't see
decentralization as particularly important.

You really should turn off your OpenTimestamps servers. They mislead
people into a sense of scalability that just isn't there. You'll see
some of our efforts at 1MBGavinWuiJCF6thGfEriB2WhDD5nhB2a soon;
frankly I think he is the biggest threat Bitcoin faces in the long
term and will back us all into a scalability corner with no good
solutions.

Feel free to forward this message to others.

When I first heard from this guy he sincerely wanted to help out Bitcoin by moving his timestamping needs to my OpenTimestamps service to try to avoid UTXO bloat, and now he's pissed off enough to be adding to the problem as a political statement. Of course, that's a tormail address, and he's been using my service through Tor according to my logs; I suspect he doesn't share Peter Vanesse's thoughts on Bitcoin...

Having said that, nothing wrong with taking a break from the forums - easy to get yourself exhausted by it.


I will say though, Gavin's proposed 75% threshold is kinda funny - right now it would take just three or four pools to meet it.

I really gotta make my decentralizing mining project with pooled-solo mode happen: https://bitcointalk.org/index.php?topic=221164.0

[tvbcof]

...
Having said that, nothing wrong with taking a break from the forums - easy to get yourself exhausted by it.
...

Sage advice which I will take.

Before I go, I'll just like to say screw Gavin and the Bitcoin Foundation horse he rode in on...or at least rides into the future.  I'm sorry to not be more hopeful, but at this point I see Bitcoin to be not much more than a cash cow to be milked.  I'm counting on the army of mouth-breathing think-they-are-libertarians here to continue to help me line my nest with $USD and they have not let me down yet.

I do have confidence in the 'free market' and have confidence that it will eventually produce something the people of world actually need vis-a-vis distributed crypto-currencies.  What we definitely don't need is some corporate controlled one-world currency solution which is exactly where this thing is headed to be blunt about it.

I hope I'm wrong and you are right that there is still some hope for Bitcoin proper, but I'm not betting on it.  Were it not for Garzik and Maxwell I would have zero hope.  I will participate in what efforts I might be able to in terms of experimentation and such as they will likely produce useful data and code no matter what happens.

[solex]

All I care about is for Bitcoin to succeed in a long term - you put USD requirements over running a node and you are giving the power back, to the very same people that Satoshi was trying to escape from with his great invention.

Do you actually understand that PEOPLE, not only banks will be able to run full nodes in their basements even if block size is 50MB, right ?

You are wrong there. Me and all my friends who are running full nodes are already peaking our upload speeds, with maxconnections=16 and 32 kB upload,
which is speed almost everyone I know here go for. To increase it to 64 kB I'd need to go for 8 MB download package which not only costs too much but
I don't need it for day to day computer use. My upload:download ratio now is 20:1 or more when only Bitcoin client is running on computer. If block size
goes up significantly, there is no way me or my friends will run full nodes. So, you lose few of us here, many others elsewhere, and you'll be left with less
than 1000 full nodes worldwide. Good luck!

Bitcoin Megastore, are you aware of this project for a software solution which goes a good way towards alleviating node bandwidth loading?
https://bitcointalk.org/index.php?topic=204283.msg2135237#msg2135237

[Atruk]

All I care about is for Bitcoin to succeed in a long term - you put USD requirements over running a node and you are giving the power back, to the very same people that Satoshi was trying to escape from with his great invention.

Do you actually understand that PEOPLE, not only banks will be able to run full nodes in their basements even if block size is 50MB, right ?

You are wrong there. Me and all my friends who are running full nodes are already peaking our upload speeds, with maxconnections=16 and 32 kB upload,
which is speed almost everyone I know here go for. To increase it to 64 kB I'd need to go for 8 MB download package which not only costs too much but
I don't need it for day to day computer use. My upload:download ratio now is 20:1 or more when only Bitcoin client is running on computer. If block size
goes up significantly, there is no way me or my friends will run full nodes. So, you lose few of us here, many others elsewhere, and you'll be left with less
than 1000 full nodes worldwide. Good luck!

Right now I'm running a full node on a VPS because the traffic is a bit rough on the home connection. For people who are invested enough in Bitcoin and want to see it stay decentralized, this might present a reasonable compromise. I keep my wallet in an SPV client and sponsor this node to help keep the network strong.

People already do this for tor nodes and have been doing it for a while. I don't see much reason why people who have benefited financially from the bitcoin network and want to see it continue to succeed would be very averse to taking on this responsibility. It is not something everyone needs to do, should need to do, or even should do. It is one very practical way of adapting to the changing realities of bitcoin though.

[ecliptic]

Bitcoin is designed to be distributed peer to peer currency first and foremost.  Certainly more than any importance of "microtransactions"

If allowing microtransactions means that you need a T3 line and terabytes of harddrive space to run a node, then your microtransactions will have to go, because otherwise it simply consolidates power and destroys the entire point of the network, which becomes datacenter-to-datacenter-to-bank-to-government-to-datacenter

You can also see that satashi fully intended to be able to use everything over Tor, which again is impossible with bloated block sizes

Blocksize should scale such that the average peer with average internet (broadband, roughly speaking ~50-100kb/sec upload/many MB/sec download currently) and average computation and storage resources can always participate as a full node

[Peter Todd]

Sage advice which I will take.

Before I go, I'll just like to say screw Gavin and the Bitcoin Foundation horse he rode in on...or at least rides into the future.  I'm sorry to not be more hopeful, but at this point I see Bitcoin to be not much more than a cash cow to be milked.  I'm counting on the army of mouth-breathing think-they-are-libertarians here to continue to help me line my nest with $USD and they have not let me down yet.

I do have confidence in the 'free market' and have confidence that it will eventually produce something the people of world actually need vis-a-vis distributed crypto-currencies.  What we definitely don't need is some corporate controlled one-world currency solution which is exactly where this thing is headed to be blunt about it.

I hope I'm wrong and you are right that there is still some hope for Bitcoin proper, but I'm not betting on it.  Were it not for Garzik and Maxwell I would have zero hope.  I will participate in what efforts I might be able to in terms of experimentation and such as they will likely produce useful data and code no matter what happens.

Remember it's still very early in this game. Even taking the abnormally high hashing rate into account blocks are barely pushing 150kB average; don't forget that at the conference there were just a dozen vendors, mostly representing internal Bitcoin businesses or investors. For all we know we'll find out that this whole payments stuff never takes off the way people keep hoping, and where it does take off is certainly going to continue to be the "bad actors" Peter Vanesse says he wants to crush.

The Bitcoin Foundation is not Bitcoin. In terms of technology all they can do is pay people to write code; open-source projects can and do fork if they have too. At the same time from what I heard at the conference the legal and lobbying strategy of the Bitcoin Foundation looks to be very much in our interests: I had a really good discussion at the conference with the foundations' chief lawyer Patrick Murck and their strategy of lobbying to make virtual currency trades unregulated. It may or may not work, but it's not going to do us any harm.

It was quite funny at the speakers dinner at the conference how I wound up sitting next to Mike Hearn... and a bunch of finance and investor types. We, well, minus Mike, talked about where Bitcoin was headed and what it's role in the world will be. At that table, and indeed at the whole conference, the finance crowd seemed to really get how what makes Bitcoin special is decentralization and freedom from authority, and how Bitcoin's future lay as a reserve currency rather than an inefficient and inconvenient payments system. You don't remake the worlds financial system by focusing on penny bets and ad-impression scams first and foremost.

Of course, I doubt the high finance crowd spend much time on troll talk...   

[amincd]

Bitcoin is designed to be distributed peer to peer currency first and foremost.  Certainly more than any importance of "microtransactions"

Bitcoin is designed to be a peer to peer digital cash. Read the Bitcoin white paper. Nakamoto wrote that BTC nodes would eventually use large amounts of bandwidth and be run by specialists, so that's what it was designed for.

$30 transaction fees, due to a 1 MB block limit, would make regular transactions impossible. It would convert Bitcoin into a high powered money that only BTC-banks could handle. I don't want a BTC-bank to hold my private keys and be the third party intermediary to my transactions. It's bad enough BTC has to rely on centralized exchanges. Forcing people to store their BTC at banks and process their transactions through them for straight BTC transactions would make the problem of centralization exponentially worse.

[Anon136]

hey retrep could you take a look at post #191 and tell me if i understand this correctly.

[da2ce7]

These are just variables. Variables can be changed.

But the CORE Bitcoin protocol allows ANY number of transactions per second. The only REAL limitation is the speed of the internet connection and TFLOPS of processing power.

So why the hell people keep shouting "Bitcoin is not designed for microtransactions" ? This is just a big piece of Über-Bullshit.

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).

[edmundedgar]

Bitcoin is designed to be distributed peer to peer currency first and foremost.  Certainly more than any importance of "microtransactions"

Bitcoin is designed to be a peer to peer digital cash. Read the Bitcoin white paper.

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.

[ecliptic]

Bitcoin is designed to be distributed peer to peer currency first and foremost.  Certainly more than any importance of "microtransactions"

Bitcoin is designed to be a peer to peer digital cash. Read the Bitcoin white paper. Nakamoto wrote that BTC nodes would eventually use large amounts of bandwidth and be run by specialists, so that's what it was designed for.

$30 transaction fees, due to a 1 MB block limit, would make regular transactions impossible. It would convert Bitcoin into a high powered money that only BTC-banks could handle. I don't want a BTC-bank to hold my private keys and be the third party intermediary to my transactions. It's bad enough BTC has to rely on centralized exchanges. Forcing people to store their BTC at banks and process their transactions through them for straight BTC transactions would make the problem of centralization exponentially worse.

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

Bitcoin is designed to be distributed peer to peer currency first and foremost.  Certainly more than any importance of "microtransactions"

Bitcoin is designed to be a peer to peer digital cash. Read the Bitcoin white paper.

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.

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

[maaku]

It comes down to maths.

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

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

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

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

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.

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)

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

[da2ce7]

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

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.

This conceptual argument I take issue with:

... There is no protocol reason why more than 1 full node needs to be running...

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).