On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
 Since, in the long run,
Bitcoin can't meet its security and decenteralization promises without
blockspace scarcity to drive non-trivial fees and without scaling
limits to keep it decenteralized— it's not a change that could be made
more lightly than changing the supply of coin.

I disagree with Gregory on this.  I believe that Bitcoin CAN meet its security and decentralization promises without any hard limit on block size. 

I had a fruitful discussion about this with an economist friend this weekend, and I'll eventually getting around to writing up why I believe raising the block size limit will not be a problem.

If you've already validated the majority of transactions in a block, isn't validating the block not all that compute intensive?  Thus, it's really not blocks that should be used to impose any sort of scarcity, but rather it's the costs associated with the validation and propagation of the transactions themselves...which is the way it should be.

When I think about issues like this, I like to remind myself that the mesh network isn't really an essential part of Bitcoin.  It is a way to disseminate transactions and blocks, but it's by no means the only possible way and could certainly be improved in various ways.  Nodes can at some point start to charge fees to collect and distribute transactions and blocks.  Collectives of such nodes could pool together fees to ensure connected nodes can propagate and hear about transactions and blocks.  These nodes would charge based on the bandwidth and the work required to validate transactions.  They would also charge for the propagation of blocks based on the work required to validate them.  Miners would of course have a lot of incentive to pay for such services since they will want to get access to as many fee bearing transactions as possible (and filter out the transactions they don't want to include in blocks).  They will also want the blocks to ensure they're always building on the latest valid block.  That in turn would give these relay nodes a window into the fees needed to ensure fast inclusion into the block chain (something that wallets could use to automatically set fees on transactions).

Note, I think the bitcoin protocol might actually be ideally suited for this type of thing...nodes would broadcast INV messages all day long, but as soon as one of your peers wants the actual transaction or block, well, then you have to pay up.  Two relay nodes sending transactions between each other would pay each other when they have to download the transaction body...if they trade roughly equal amounts of transactions, they wouldn't end up owing each other anything...for a given transaction they would pull the data exactly, but would then turn around and provide that transaction to many connected peers, earning a fee for each delivery.

P.S. such a fee structure would address the spam issue with economics rather than rules about spammy transactions

P.P.S. micropayment channels could be used as the payment method for nodes that validate and relay transactions...this would actually be a very good first use of that technology (people have talked about micropayment channels for renting bandwidth...why not use them to pay for the bandwidth and CPU needed to validate and relay transactions)