Quote from: justusranvier on October 27, 2014, 04:01:04 AM

Quote from: amincd on October 27, 2014, 02:55:36 AM

The solution I'm suggesting is for the protocol to charge block generating nodes for the blocks they create, based on how much data is contained in the block, and distribute fees collected to other block generating nodes (proportional to their share of the network hashrate). This would not solve the centralization problem, but it would solve the problem of txs becoming a net cost to the block generating nodes as a whole. For this proposed solution to work, we need to pick a magic number to represent the minimum number of block generating number we believe the network needs to be sufficiently decentralized, and the protocol needs a way to reach consensus on the cost of bandwidth in relation to bitcoin. Multiplying these two numbers together would give us an estimation of the cost of bandwidth for the network per byte of data included in a block.

There's no need for magic numbers, which are wrong by definition.

The blocks miners produce are meaningless unless they reach an economic majority of the network. Therefore miners should be willing to pay relay nodes to ensure this happens.

Other users of the network require timely access to the most recent blocks in order to know the state of the ledger. Therefore users of the network should be willing to pay relay nodes to deliver the blocks to them.

Users want their transactions to reach the miners. Therefore they should be willing to pay relay nodes to deliver them.

Miners want to receive transactions, because the fees embedded within those transactions is a source of revenue for them. Therefore they should be willing to pay relay nodes to deliver those transactions to them.

The only thing needed to make a market for block/transaction relaying work is a mechanism for price discovery and payments.

Price discovery will ensure that relay nodes are sufficiently compensated by an amount that covers their costs, and will also regulate the number of relay nodes to meet the demand of the users, including their demand for decentralization (a user who wants to buy more decentralization does so by connecting to more relay nodes than they would otherwise need).

No magic numbers needed, no central planning needed.

The fact that Bitcoin has a magic number acting as a production quota for transaction processing is a flaw that was supposed to be temporary. Replacing one magic number with a different magic number isn't a long term solution.

I don't like magic numbers at all, but I can't see a way around using one. Almost any solution makes use of a magic number. The recent proposal made by Gavin (which I think is a very good one) to have the max block size increase automatically by 50% a year is using 1.5 as the magic number that the block size limit will grow by each period. The current 1 MB block limit is a magic number.

The alternative to a magic number selected out the outset is the mining network (through proof of work) or currency holders (through proof of stake) voting on a number continuously, but the downside to that is that Bitcoin becomes more gameable, and possibly loses its immunity to political intrigue and manipulation by parties within the community. And even a dynamic number that is continuously voted on, is still a magic number.

Eliminating the block size limit without putting in place a new protocol-level control on bloat I believe is a poor option for the reasons I outlined in the first post. Block generating nodes outputting a large percentage of the network hashrate could still get away with producing large blocks, and having them propagate to the whole network. The casualty will be network security, as the block generation revenues, net bandwidth costs, on a network wide basis decrease.

If you think otherwise, please take one of the hypotheticals I provided, and explain how incentives, with paid data propagation through micropayment channels, would result in an outcome different from what I suggested.

If there is going to be a magic number, I prefer it to represent the number of block generating nodes we believe that Bitcoin should be able to support, so that it is explicit what we are deciding on when we choose a magic number.