Topic: Gavin Andresen Proposes Bitcoin Hard Fork to Address Network Scalability - page 9. (Read 18399 times)

What is the current status on this, and estimated implementation date?

-B-

I think that miners will eventually be supported by TX fees, but right now our TX fee structure is probably wrong for it.

TX fees are what we pay the miners to maintain security on the chain.  They do this mainly by making a major investment in hashing power.  When Bitcoin got started the resources required to do mining were mainly bandwidth and storage space for the blockchain, because CPU power was assumed to be widely if unevenly distributed. Accordingly the tx fees were set according to the amount of bandwidth and storage space a tx required -- that is, the transaction size in bits, because the cost of mining was assumed at the time to be proportional to bandwidth and storage required.  

But ASICs changed the world.  The bandwidth and storage space required to do mining is now essentially irrelevant as regards the expense of mining.  People with the bandwidth and storage can't mine effectively in competition with ASIC farms.  The major expense of mining is now dedicated hashing hardware, not bandwidth or storage.  If we want to charge what a transaction costs the network to secure, TX size is no longer an accurate measure of anything.  

Ultimately, what secures the blockchain now is sheer dedicated hashing hardware.  The question is how much of it we want to buy -- indeed, how much we will economically cause to be manufactured -- in order to secure the chain.

I think that we need security proportional to the value of the transactions secured.  Therefore if we're going to charge tx fees for security, we need tx fees proportional to the amount of bitcoin sent.  The charge for tx size in bits (bandwidth and storage) should be high enough to keep "dust" out of the chain, but if we want security proportional to the amount secured, the main source of tx fees should probably be charged for the tx size measured in bitcoins, not in bits.

http://bitcoinist.net/the-optimal-block-size/

I think the disagreement lies within what will happen if we raise the block limit. I think some people think there will be more no TX fee TXs included in blocks because because there would be more room for these TXs in each block. The argument is that this is bad because the miners would receive less total TX fees which will become a larger portion of their "income" as the block subsidy declines over time. I would disagree because the miners would still be doing the same amount of work to confirm a TX in a block and there would be nothing that would force miners to include no TX fee TXs period, regardless of max block size.

I think there are a very small subset of applications when off-blockchain transactions would be better, primarily when an off-chain transaction would require a very small amount of additional risk to the buyer (for example someone who already trusts  an airline enough to prepay for an airline ticket could deposit funds into an account for pay for in-flight wifi, or someone who trusts a retail store to not sell faulty products to deposit funds in an account to pay for a number of transactions with the retail store, or some other similar situation).

If we move primarily to off-chain solutions that are not store specific (or band/company specific) (and are very similar to coinbase) then we have essentially invented a new version of paypal.

Bitcoin has been marketed as a payment network with little to no transaction fees, from the start. I think it is a good idea to raise the block size.

With the block size increasing, and the block relay code being merged. Miners will not have to worry about the block size taking too long to propogate and being beaten. So the incentive is there to include as many transactions as possible in that block and collect miners fee even if it is small amount. I think this is good for consumers, because it will keep transaction fees at a minimum.

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.

Have you run any tests on the testnet (or a scamcoin/altcoin) to get some kind of idea as to just how much TX fees will increase when the 1 MB block size limit has reached? I would have the same question with how TX fees would change after the block size is increased?

I think this would be valuable evidence to provide to help your argument to increase the block size. I think it is more or less agreed upon that the block size limit will eventually be reached as it stands, however I think the disagreement is what effects both not raising the limit and raising the limit will have on the network and on TX fees

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.

Has this actually been set in stone or is Gavin just pondering ideas?

Increasing block frequency would be beyond a bad idea. It would increase the number of orphaned blocks and reduce the security of the network. It would also do nothing to address the size of the total blockchain.

IMO if you are looking for a shorter block time you should look at the many failed altcoins that have much shorter block times

The number of tx per second (and the amount of storage required) is limited by two things; block size and block frequency.  We could double tx per second by doubling blocksize or by doubling block frequency.   Or we could do both and quadruple it.  Of course if we doubled block frequency we'd need to halve block rewards to stay on the same money supply curve.

A lot of the motivation for the 1MB limit was a fear that if it weren't limited we'd have people building gigantic blocks just to clog up the system.  If someone with major hashing power started building giant blocks every time he got a block, he  could DoS the system just by making the block chain too large for most people to store. 

A lot of the motivation for the ten-minute intervals was limiting the amount of storage devoted to block headers.

Any time you send a TX, it must be included in a block that is found by the miners. The TX that you create takes up a certain amount of space in the block based on how many addresses you are sending the money to and how many different people sent you the money you are spending.

As it is now there is a 1 MB limit as to how much space each block can hold. This limits the number of transactions to roughly 7 per second as if more transactions are sent there would not be enough space in each block.

The change being proposed is to gradually increase the maximum block size so that more transactions can fit in each confirmed block

Explain it like I'm 5 version:


The size of the "closet" (block) that is "created" (mined) every 10 minutes will be increased so that more "clothes" (transactions) can fit in each "closet" (block).

Of course bigger "closets" (blocks) also need more space to "store" (MB's per block) all those created closets.

This does not necessarily mean that miners will get paid less, but it will be easier for them to include more "clothes" (transactions) into each "closet" (block). Miners will always charge what they want for a transaction, the market will take care of the rest.
=====================================================================

Each block will still reward 25 bitcoins to the miner that generates the block (that continues to lower per halvening as scheduled). The only thing can MIGHT change is how much transaction fee is paid per transaction.

Hi Gavin,

Is there a time schedule for future updates/upgrades or a list with the high priority items for future updates?

That is great news - I am very supportive of where this is going!

It is already being done, so yes. Optimizations to how transactions or blocks are communicated between peers don't require any sort of fork.

I actually had thought it was your invention (sorry Matt) - but yes - I do remember hearing about it before.

The real question is do you think it is feasible to do this before the "hard-fork"?

I think you're reinventing Matt's fast block relay code.  See:
  https://bitcoinfoundation.org/2014/08/a-bitcoin-backbone/

The thing is we really dont know what will happen next.

Great decision, enabling more transactions over the network is one of Bitcoins core necessities as the project grows. Especially removing the stupid 7tps limit imposed right now.

Don't forget that as more transactions would be allowed per block it's very likely that if these changes are implemented right now would mean that all broadcast transactions would be immediately included into the very next mined block, this would in turn also SIGNIFICANTLY lower mining fees since miners will want to include as many as possible transactions per block.

Also, it would be easy to hard fork this since you can technically give nodes time to update, for example the new Bitcoin-QT/bitcoind is rolled out and the block change doesn't go into effect for another 6000 blocks. This way there would be time for everyone to update their clients.

And scaling all this at half of Moore's law looks more fair as well to keep the costs of storage down. This would however be even better if combined with a more compressed version of the blockchain.

Perfect change, here's to hoping they will implement it soon.