The cool story isn't when the miners bravely reject the large blocks, it's when the users of Bitcoin bravely reject large blocks, by doing nothing more than not installing any version of Bitcoin that removes the current 1MiB block limit.

Bravery by doing nothing; kinda anti-climatic really.

Read my post on the subject.

Exactly. For mining itself, 1MiB blocks ensure that the barriers to entry are very low, and thus an oligopoly of miners won't form.

Increasing the block size, and especially allowing miners themselves to determine by how much, increases the barriers to entry, allowing for an oligopoly to form.

Bitcoin itself may be an oligopoly, but we really, really do not want Bitcoin mining to become an oligopoly.

I'll suspect Coinbase works the way it does so that newbies don't lose their Satoshidice bets...

Good catch, fixed.

Because if we don't have a limit, your ability to mine isn't a function of how much hashing power you have, the thing that protects us against 51% attackers, it's a function of how much network bandwidth you have, something 51% attackers need none of. Bigger blocks mean more money uselessly spent on network bandwidth, rather than what actually keeps Bitcoin secure.

See my post here, as well as other viewpoints on the issue.

Bitcoin itself is an oligopoly. What are Bitcoins made of anyway? They're just bits, information, and by themselves information is incredibly, ridiculously cheap. Of course the incredibly low price of information is made possible by the free market itself, specifically the amazingly successful computer industry.

Bitcoin is a system by which every participant creates a shared oligopoly on a particular set of information, the blockchain. From day #1 Bitcoin was about taking information that, if subject to free market forces, would be so incredibly cheap that it'd be basically free and artificially making it expensive. This shared oligopoly, achieved through the rules set out by Satoshi, makes this information incredibly expensive, so much so that 32 bytes of information, a private key, can now be worth millions of dollars.

Basically the decision about how big our shared oligopoly should allow blocks to be is just a decision about what rules we'll follow to make our little bits of otherwise worthless information as valuable as possible. Myself, gmaxwell, and many others happen to think that if we limits blocks to 1MiB each, keeping the regulations as they are, our little oligopoly will maximize the value of that information. Gavin, Mike Hearn, and many others happens to think that if blocks are allowed to be bigger than 1MiB, thus changing the regulations, our little oligopoly will maximize the value of that information.

Don't for a second think any of this discussion is about free market forces. Bitcoin is about artificially subverting free market forces through regulation, for the benefit of everyone participating in the oligopoly that is Bitcoin. It just happens to be that the way to become part of this oligopoly isn't by, say, living in a certain part of the world that's mostly desert, it's by either buying entrance (buying some Bitcoins) or by doing a completely made up activity that has no purpose outside the oligopoly. (mining)

Dammit, http://blockchainbymail.com was going to be my April Fools prank...

Anyway, if the startbitcoin.com guys want the domain, I'll happily give it to them for the 0.5BTC it cost me to register.

Well, you gotta look at the process by which the reference client determines a block is valid. First of all it's received from a peer with ProcessMessage(). That function almost immediately calls ProcessBlock(), which first calls CheckBlock() to do context independent validation of the block; basic rules like "Does it have a coinbase?" which must be true for any block. The real heavy lifting is the next step, AcceptBlock(), which does  the context dependent validation. This is where transactions in the block are validated, and that requires the blockchain as well as full knowledge of the unspent transaction outputs. (the UTXO set) Getting those rules right is very difficult - the scripting system is complex and depends on a huge amount of code. Like it or not, there is no way to turn it into a "short verifier program"; the reference implementation itself is your short verifier program.

Thus right now we are far safer if all miners use the reference implementation to generate blocks and nothing else. However, we are also a lot safer if the vast majority of relay nodes also continue to use the reference implementation, at least right now. The problem is that even if a block is valid by the validation rules, if for some reason it doesn't get relayed to the majority of hash power you've caused a fork anyway. With the reference implementation this is really unlikely - as I explained above the relay rules are the validation rules - alternate implementations of relay nodes might not have that property though.

An interesting example of relay failure is how without the block-size limit any sequence of blocks with a size large enough that some minority of the hashing power can't download and validate them fast enough creates a fork. Specifically the blocks need to be large enough that the hash power in the "smaller-block" fork still creates blocks at a faster rate than the large-blocks are downloaded. Technically, with the block-size limit this can happen too, but the limit is so low even most dial-up modems can keep up. Block "discouragement" rules can also have the same effect, for much the same reasons.


For merchants a hard-fork bug leaves them vulnerable to double-spends by anyone with a lot of hashpower, but it'll cost the attacker one block reward per confirmation required. (the attacker can amortize the attack across multiple merchants) Merchants should be running code that looks for unusually long block creation time, and automatically shuts down their service if it looks like the hash rate has dropped significantly. Just doing this is probably good enough for the vast majority of merchants that take at least 12 hours to process and ship an order.

Some merchants are more vulnerable - a really bad example would be a chaum token issuing bank. Once you accept a deposit, give the customer the chaum token you have absolutely no way of invalidating the token because redemption is anonymous. Merchants like that should be running their own reference implementation nodes, double-checking those blockchains with other sources, and keeping their clocks accurate so they'll know when hashing power has dropped off mysteriously.

For instance you could run a service that would (ab)use DNS to publish each block header as a DNS record. Headers are just 96 bytes long so they'd still fit in single UDP packet DNS requests I think. Caching at the ISP level would reduce load on the server. (although ISP's that don't respect TTL's are a problem) The proof-of-work inherently authenticates the data and parallel services should be run by multiple people with different versions of the reference client. I wouldn't want to only trust such a service, but it'd make for a good "WTF is going on, shut it all down" failsafe mechanism for detecting forks.

Good to hear!

One last thing, you also need to mandate that at least one txin signature uses SIGHASH_ALL so the txin list can't be changed after the fact. Once you've taken that step you'll only be vulnerable to regular, miner-supported, double-spends.

EDIT: fixed SIGHASH_NONE brainfart.

BFG9000

Nobody is saying we need to raise the size limit now. I brought the issue up because we need off-chain alternatives, and those alternatives take time to create. Ripple is one alternative, and I'm glad to see people working on it, but competition is a good thing and multiple alternatives should be pursued.

What makes you think miners are "high bandwidth"? Pools tend to have reasonable amounts of bandwidth, if only to resist DDoS attacks, but the pools aren't the issue, validation is. P2Pool is currently the best example, because every miner participating in P2Pool runs their own fully validating node that ensures the blocks produced follow the Bitcoin rules. With the getblocktemplate and stratum mining protocols, again miners know what blocks they are actually mining and can fully validate them to ensure the rules of Bitcoin are followed.

Relay nodes matter too. Because running a fully validating node is very cheap, there are lots and lots of relays out there. A core principle behind Bitcoin's security is that information is easy to copy, and hard to censor, which means that the large number of relays protect you because it's very likely you'll connect to an honest relay and you'll get an honest, uncensored view of what is happening on the network.


You don't need to trust clearing houses and other payment services built on top of Bitcoin if you can run a fully validating node. The protocols by which those payment services operate can be written in such a way that everything they do, every single transaction, is auditable, and critically, if they commit any fraud, you'll be able to prove that fraud. You publish your proof of fraud on a P2P network, it'll get broadcast to everyone on the network in seconds, and the payment services business will collapse immediately. I've written about these concepts multiple times; I'll post a big summary of the options later tonight.

On the other hand, if you can't run a fully validating node, you can't monitor the on-chain activities of those clearing houses to make sure they really are still holding the funds they claim they do. You have to take their word for it. At the same time, if you can't fully validate blocks, what's to stop miners and the few remaining validating nodes from getting together and creating blocks that collect fees from transactions that don't exist, thus inflating the money supply?

If the blocksize limit is lifted, and blocks continue to grow without bound, to me the plan seems to be a bait-and-switch, selling people a purportedly decentralized currency that anyone in the world can validate without having to rely on third parties, then pulling the rug out from under them by migrating it to a system where only big businesses able to invest the thousands of dollars required to purchase high-speed network connections and lots of harddrive space can validate blocks.


...and a 1MiB blockchain limit does this. That's 55GiB/year, low enough that anyone will be able to afford the hard-drive space to store a full copy of the block chain for years to come. Anyone will be able to also afford an internet connection, nearly anywhere in the world, with the capacity needed to participate as a full, validating node.

Like it or not we can't have every transaction using Bitcoin on the block chain. We need to develop alternate solutions anyway for small-value transactions, and since we're doing that, why not use those solutions for day-to-day spending and keep the blocksize low enough to keep Bitcoin itself truly decentralized?

My biggest fear is these small-value transaction solutions won't be developed, and instead we'll see pressure to just keep raising the blocksize, losing decentralization each time until Bitcoin is just another PayPal.

Why not? They're 64-bit numbers, might as well give plenty of room for whatever the price turns out to be.

More to the point, if I'm correct and in the future we're paying miners billions of dollars a year, that implies Bitcoin is probably transfering trillions of dollars a year in value, on and off chain. In that scenario the market cap is probably tens of trillions of dollars worth, so 1BTC could easily be worth something like $10,000USD. Thus the $20 fee is 0.002BTC. That's pretty close to fees currently in terms of BTC - you might as well ask why do we have 8 decimal places now?


You know, it's not a crazy idea, but trying to figure out what's the right BTC value is a tough, tough problem, and changing it later if it turns out your estimates of what the BTC/USD/mining hardware conversions as well as the orphan rate is a tough problem. You'll also create a lot of incentives for miners to create systems to crawl through the whole Bitcoin network, discovering every single node, and then use that knowledge to connect to every node at once. Using such a system the second you find your block, you'll immediately broadcast it to every node immediately. Of course, the biggest miner who actually succeeds in doing this will have the lowest orphan rate, and thus has much more room to increase block sizes because faking tx fee's costs them a lot less than miners who haven't spent so much effort. (effort that like all this stuff diverts resources from what really keeps the network secure, hashing power)

This same system can also now be used to launch sybil attacks on the network. You could use it to launch double-spend attacks, or to monitor exactly where every transaction is coming from. Obviously this can be done already - blockchain.info already has such a network - but the last thing we need is to give incentives to build these systems. As it is we should be doing more to ensure that each peer nodes connect to comes from a unique source run by an independent entity like using P2Pool PoW's linked to IP addresses.

I don't mean worse than today, I mean worse than the average case.

Just implementing your idea is fine and probably should be done; the issue purely in making assumptions, particularly security assumptions, about how fast blocks will propagate based on it.

On the bitcoin-dev email list I responded to exactly that argument actually; my responses below are based on the response:


The cost of mining is in two parts: mining itself, and overhead. The mining equipment costs basically the same regardless of how many hashes/s you want to mine with; if anything I suspect small mining operations are cheaper than larger operations because cooling costs are non-existance for a small miners with a few rigs, and at a small scale power can often be either re-used for heating (cold climates) or is available at a flat rate. (I don't pay for power at my apartment) We're fortunate that the primary cost of ASICs is the mining chip itself, and they are cheapest when you make thousands of inexpensive chips. You'll always be able to buy relatively inexpensive rigs that only contain a few chips, just like BFL sells everything from $150 rigs, one chip, to $35,000 rigs, lots of chips.

The overhead, running a validating node to verify the blocks you are mining, is a fixed cost.

Thus I see no reason why large fees have anything to do with the size required to profitably run a mining operation.


Sure, but that's already true. Even the ASIC operations have been mining in pools to keep varience low. The important thing is that small blocks make it cheap for anyone to validate the blocks you are mining for the pool, keeping the pool honest. Equally they allow you to mine on P2Pool, which is totally distributed and not controlled by anyone.

Anyway, the argument you're really making is that we can't spend a lot of money ensuring that the network remains secure against a well funded 51% attacker, not that small blocks themselves are an issue. I dunno about you, but I think huge mining rewards are a good thing and keep us all safe from 51% attackers.


These are real issues, but they can be solved with the same micropayment systems people will use for small transactions. For instance, P2Pool makes payments directly from the coinbase, taking block space away from transactions that could earn money instead.

What would happen as blocks approach the limit is first P2Pool would take into account the cost of payout transactions in terms of lost fees. This would give miners an incentive to only get payouts when the payout amount was sufficiently high. The amount of hashing power required would be pretty large, so you'd naturally see sub-pools develop combining a whole bunch of hashing power together. (P2Pool already supports sub-pools BTW) Those sub-pools would publish contracts specifying how they would pay out, what micropayment system and so on, and miners using those sub-pools would either be payed correctly, or if the pool defrauded them, they'd be able to prove the pool defrauded them and make them lose their fidelity bonds they had to purchanse to be trusted in the first place.

Note how that's basically how most pools already work anyway - you trust the pool to pay what you are owed. The only change is in the mechanism by which you get paid.

You need to be really careful with anything that discourages blocks. Any time a given rule for discouraging blocks is adopted by a minority, rather than a majority, the majority of hashing power that is not following that particular rule has an incentive to deliberately produce blocks that will be discouraged by the minority.

What you are proposing is a relay rule, so the issue is really what % of hashing power doesn't get the block because of the rule, but regardless if only 25% of the hashing power ignores the violating block, the other 75% should include an unknown TX in every block they mine. They'll have 25% less competition - an obvious advantage.

Bitcoin has changed before, but the last time a hard-fork change happened was way back in the summer of 2010 to fix the overflow bug. Back then Bitcoin's were nearly worthless, there wasn't really an economy built, and the userbase was tiny. There have been soft-forks like P2SH, where only mining power requires upgrading, but even those took months of planning and advocacy.

Changing the block size is a really big deal. Technically speaking the change is no different than changing the inflation schedule, and as we've seen, it's not a change without a lot of controversy. Everyone needs to change their software to accept the change; if Gavin pushed a blocksize change to the reference client tomorrow, I know I myself would stick with the existing system as would many others.

Two pull requests I would like to see, ones that make prototyping this stuff easier, would be "getrawblock/sendrawblock" RPC commands, and a "notifytransaction" mechanism.

The latter lets you find new incoming transactions that have been accepted to the mempool so you can inject them into your alternate distribution mechanism, later added to the client mempool with sendrawtransaction (a flag that disables re-broadcasting would be nice) The latter has already been attempted; I seem to remember there were some issues with locking that needed to be solved, but they looked tractable.

The former lets you do the same thing for entire blocks. (submitblock isn't quite what you want)

For instance a cool and potentially useful thing to do would be to operate a service that mulicasts the blockchain via Amazon's Simple Messaging Service. You'd sign up, and get a blockchain feed for your EC2 node without having to actually connect to anyone else. EC2 bandwidth is fairly expensive, so costs would be significantly less, and it could scale to absolutely enormous numbers of clients. Of course, you are trusting the service, but for some applications it's not a big deal.

Another cool thing to do would be to implement multicast broadcasting of the blockchain and transactions. While not commonly available, multicast is available on a few networks, so there will be some people who can make use of it. Equally you could start up a satellite downlink service or radio service.

The point is, actually implementing those ideas will be much easier with those two pull requests.