"patches welcome"

In general:  "meh"  -- most testing is done in -regtest mode in a more controlled environment these days.

I couldn't resist peeking at the literature; the first hit on a google search for "experimental economics free rider" turns up this 1984 paper:

This is a very important concept to internalize. I don't think Satoshi realized it, and I think if he did Bitcoin Script would be very different from what we have.

In a future ideal world where arbitrary zero-knowledge-proofs are time-tested and have robust implementations, everybody except for the N entities directly involved in a transaction would validate a short, opaque proof that some computation took place authorizing the transaction.

If you're designing a better transaction system, you should design with that ideal in mind.

How do you imagine you will be able to keep transaction fees artificially high?

I can imagine a future with 1MB blocks full of zero-transaction-fee transactions (all fees paid off-blockchain through special cozy relationships between big merchants/exchanges and big miners. Or simply big merchants/exchanges mining their own transactions).

I think network security CAN be funded through transaction fees-- that is easy, if you want to buy some security just attach a larger-than-strictly-necessary-to-get-confirmed fee to your transactions.

I don't think we know yet whether network security WILL be funded through transaction fees; there might be a free-rider problem that keeps people who want a secure network from actually paying for a secure network.

This is where it would be lovely for some academic economists who have studied the free-rider problem to chime in and predict what is likely to happen, and how other markets have solved (or not) the problem.

You seem to have a very narrow definition of "decentralized system."

In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong.  If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times.

That's not so different from your 'treechains' idea (just simpler and easier to reason about, in my humble opinion).

If you think that hardware costs are going to dominate decentralized-versus-centralized payment network costs, then I think you're wrong. Hardware is cheap, people are expensive.

But all of this is really arguing angels-dancing-on-the-heads-of-pins; we've got years before we have to worry about how to fund network security, and a whole lot of things to work on before then.

You can mitigate the attacks described in the paper by running bitcoind with more lenient banning behavior.

E.g. put this in your bitcoin.conf:


... so if Tor peers sharing an IP address are banned, they are only banned for eleven seconds.

If you want to live dangerously, you can also set:


... to make it a lot harder for an attacker to cause you to ban naughty IP addresses. But this might make it easier for an attacker to fill up your node's memory with garbage.

That is easy, the first. But that is a straw-man argument.

If the decision is:  costs 1.001 kWh and gives 99.99, versus 1kWh and gives 99%, I might decide the extra purity is worth it.

The "centralized is more efficient" might be theoretically true, but in practice the difference might be so slight it doesn't matter.

Theoretically, it would be more efficient if all of our computing happened in huge data centers located near cheap hydroelectric power.

Practically, though, only some of our computing happens that way (e.g. searching terabytes of data), because it is more convenient for us to carry around powerful little computers and we value that convenience.

I still feel that way.

I believe that if people want a secure network, they will figure out a way of getting it. My justification is the same as my belief that if people want clean, cheap, safe drinking water they will figure out a way of getting it.

I don't claim to know how, and it is very possible the how will offend the sensibilities of either (or both) of the "PRIVACY AT ANY COST!!!!" or "DECENTRALIZATION AT ANY COST!!!!" factions. Just like government regulations and institutions around clean water offend the "INDIVIDUAL LIBERTY AT ANY COST!!!!" faction.

I can imagine a lot of possible futures, from big merchants and exchanges investing in mining to save themselves on transaction fees and ensure that their transactions are confirmed securely, to assurance contracts, to a cartel of miners regulated and funded and licensed as a global public utility.

I hope that last one doesn't happen...

"Huge stashes" is a bad assumption. Tweet from Jeff Garzik earlier this year:
  "As such, I dare to do what few if any others do:   My #bitcoin balance is 348.006 BTC."

I'm guessing other frequent contributors have this mindset:


And I'm sure lots of early adopters thought:

RE: O(1) versus O(some-function-of-total-number-of-transactions):

Yes, it will depend on whether or not the number of differences goes up as the number of transactions goes up.

The incentives align so it is in everybody's best interest to make the differences as small as possible. I wouldn't be surprised if that causes innovations to drive the actual size to O(1) minus an increasing constant, as code gets better at predicting which transactions our peers do or don't have.

Start a new thread.  HAVE you read my Scalability Roadmap blog post?

When you respond to me saying patronizing things like "there are other problems with the way scalability is limited," I have trouble not thinking you are either confused or insane. Or just lazy, and did not read my "Scalability Roadmap" blog post.

It is certainly true that nobody can predict the future with 100% accuracy. We might get hit by an asteroid before I finish this sentence. (whew! didn't!)

But extrapolating current trends seems to me to be the best we can do-- we are just as likely to be too conservative as too aggressive in our assumptions.

I think you are confusing MAX_BLOCKSIZE with the floating, whatever-the market-demands blocksize.

MAX_BLOCKSIZE is, in my mind, purely a safety valve-- a "just in case" upper limit to make sure it doesn't grow faster than affordable hardware and software can support.

Ideally, we never bump into it. If we go with my proposal (increase to 20MB now, then double ten times over the next twenty years) I think it is reasonably likely the market-determined size will never bump into MAX_BLOCKSIZE.

I think it is very unlikely that in 20 years we will need to support more Bitcoin transactions than all of the cash, credit card and international wire transactions that happen in the world today (and that is the scale of transactions that a pretty-good year-2035 home computer and network connection should be able to support).

Please stop trolling. I think what I think and do what I do because I want the Bitcoin Project to be even more wildly successful.

If I was motivated by greed I would have a much higher salary. And lots of stock options.

The majority of Bitcoin users here want transaction fees less than a penny; I want them to be as low as practical. The only way to get there is to increase the block size.

Is there really any disagreement? Everybody I have talked with believes that transaction fees will rise if Bitcoin is successful and the 1MB limit is kept.

How much we won't know-- that depends on how much demand for transactions moves somewhere else (fiat currency, altcoin, or some off-blockchain solution).

There is a small minority of people who believe that it would be BETTER if transactions moved to fiat currency, an altcoin, or some more-centralized off-blockchain solution. I strongly disagree.

Did you read my "blocksize economics" blog post?

I don't understand why you think MAX_BLOCK_SIZE necessarily has anything to do with "supporting mining" (aka securing the network).

What stops this from happening:

Big miners accept off-blockchain payments from big merchants and exchanges that want their transactions confirmed. They are included in very small blocks with zero fees.  The blocksize stays at 1MB forever.

Lets look at incentives:

Big miners: have cozy agreements with Big Merchants. Those agreements keep the little guys out.

Big Merchants: same thing. The need to get an agreement with a miner to get your transactions accepted is a barrier to entry for the Little Guys.

I am trying to get consensus. The process will look like:

Get rough consensus. I need to write some code to find out what size blocks the current code can handle, but other than that I think we're close to rough consensus on the approach.

Note: Getting consensus that we actually need to change something NOW will be harder; it will be much easier to get consensus after we hit the 1MB blocksize limit and transaction fees spike up. It would be lovely to avoid that panic/pain.

Implement the change / Write a BIP (these happen at about the same time).

Submit a pull request, after code is reviewed pull it into the reference implementation.

... wait until there is a release containing the change...

... wait until supermajority of miners have upgraded to the new release...

Voila, the possibility of bigger blocks.

The answer cannot be in the blockchain, because the problem being addressed (resource usage rising too quickly so only people willing to spend tens of thousands of dollars can participate as fully validating nodes) is outside the blockchain.

You will go down the same path as the proof-of-stake folks, coming up with ever more complicated on-blockchain solutions to a problem that fundamentally involves something that is happening outside the blockchain. In this case, real-world CPU and bandwidth growth. In the POS case, proof that some kind of real-world effort was performed.

If you're using the GUI:  File->Backup Wallet...

If you're using bitcoind: use the backupwallet RPC command.

Uhhh.... okey dokey. That sounds really dangerous, because it means a blockchain re-org can change the meaning or behavior of a transaction. "There Be Dragons"