Blocks are [not] full. What's the plan?

[zvs]

I killed all my bitcoind nodes (@ approx 5:00PM CST).  I doubt it'll have any effect whatsoever on propagation, but I can't help but be a bit curious...

Anyone know what timezone the daily charts on http://bitcoinstats.com/network/propagation/ are based on?

How many did you shut-down?

the top 3 on here

https://blockchain.info/hub-nodes

plus one other top secret one!

(remember 129.132.xx.xx is evil)

[binaryFate]

I killed all my bitcoind nodes (@ approx 5:00PM CST).  I doubt it'll have any effect whatsoever on propagation, but I can't help but be a bit curious...

Anyone know what timezone the daily charts on http://bitcoinstats.com/network/propagation/ are based on?

How many did you shut-down?

the top 3 on here

https://blockchain.info/hub-nodes

plus one other top secret one!

(remember 129.132.xx.xx is evil)

Wow, they were relaying like crazy... 
Did you have any particular tuning (I saw the question raised on bitcoin-dev list, but didn't see any answer) to reduce checking or make any relevant step faster?

[zvs]

I killed all my bitcoind nodes (@ approx 5:00PM CST).  I doubt it'll have any effect whatsoever on propagation, but I can't help but be a bit curious...

Anyone know what timezone the daily charts on http://bitcoinstats.com/network/propagation/ are based on?

How many did you shut-down?

the top 3 on here

https://blockchain.info/hub-nodes

plus one other top secret one!

(remember 129.132.xx.xx is evil)

Wow, they were relaying like crazy...  
Did you have any particular tuning (I saw the question raised on bitcoin-dev list, but didn't see any answer) to reduce checking or make any relevant step faster?

I had blockchain stored in ramfs (which requires removing all the diskspace checks from the source)...  also the 600+ connections...  also 1gbit connections, so after a block hit I'd see something like 2000kb-25mb-70mb-30mb-5000kb  in dstat

but probably most important was lowering the sleep timers in net.cpp

none of the verification steps were removed, aside from it checking available disk space

[binaryFate]

I killed all my bitcoind nodes (@ approx 5:00PM CST).  I doubt it'll have any effect whatsoever on propagation, but I can't help but be a bit curious...

Anyone know what timezone the daily charts on http://bitcoinstats.com/network/propagation/ are based on?

How many did you shut-down?

the top 3 on here

https://blockchain.info/hub-nodes

plus one other top secret one!

(remember 129.132.xx.xx is evil)

Wow, they were relaying like crazy...  
Did you have any particular tuning (I saw the question raised on bitcoin-dev list, but didn't see any answer) to reduce checking or make any relevant step faster?

I had blockchain stored in ramfs (which requires removing all the diskspace checks from the source)...  also the 600+ connections...  also 1gbit connections, so after a block hit I'd see something like 2000kb-25mb-70mb-30mb-5000kb  in dstat

but probably most important was lowering the sleep timers in net.cpp

none of the verification steps were removed, aside from it checking available disk space

Thanks man, very neat info! In particular the net.cpp sleep time trick, never heard about or considered that... Do you see any downside to lowering the timer in net.cpp with your conf, or it's just all better?

[Cryddit]

Yes, I did misplace the decimal point.  I'm really good at that.

Welp, you're not the only one. I did the same thing in another topic, and wound up calculating (wrongly) on several 'fee' questions.

[Cryddit]

It should be fairly easy to get about another factor of about 10-20 reduction in orphan costs.

Here's a protocol design that makes block size *almost* irrelevant to orphan costs.  Could be a reduction in orphan costs of 3 orders of magnitude or more - unfortunately it comes with a cost in bandwidth.

Consider a new protocol message, with semantics "HEY!  Somebody found this new block!" which is tiny for rapid propagation, issued from the miner immediately before he issues the block.  

Clients who are hip to it can propagate it (way faster than the block) before they even get done reading the block, let alone checking it and deciding to send it on.  And clients who don't know what the heck it is can drop it on the floor until their software is updated.  If even one client in five knows about the new message, it'll still propagate faster than a block.

Anyway, you'd then expect clients who hear about one block, then receive another, to hash on/possibly extend the first received only until the first one they heard about arrives, then switch.  Assuming it arrives in fifteen seconds or less.  If it doesn't then the first one they got is the one they work on.

That gives a new block the *effective* propagation time of a very small message, and gives it all the clients it can broadcast to in the next fifteen seconds (which, really, ought to be all of them).

You'll still get the occasional orphan block when two different "announce" messages go into the network at the same time, but this should reduce the incidence of orphan blocks dramatically.  

[binaryFate]

It should be fairly easy to get about another factor of about 10-20 reduction in orphan costs.

Here's a protocol design that makes block size *almost* irrelevant to orphan costs.  Could be a reduction in orphan costs of 3 orders of magnitude or more - unfortunately it comes with a cost in bandwidth.

Consider a new protocol message, with semantics "HEY!  Somebody found this new block!" which is tiny for rapid propagation, issued from the miner immediately before he issues the block.  

Clients who are hip to it can propagate it (way faster than the block) before they even get done reading the block, let alone checking it and deciding to send it on.  And clients who don't know what the heck it is can drop it on the floor until their software is updated.  If even one client in five knows about the new message, it'll still propagate faster than a block.

Anyway, you'd then expect clients who hear about one block, then receive another, to hash on/possibly extend the first received only until the first one they heard about arrives, then switch.  Assuming it arrives in fifteen seconds or less.  If it doesn't then the first one they got is the one they work on.

That gives a new block the *effective* propagation time of a very small message, and gives it all the clients it can broadcast to in the next fifteen seconds (which, really, ought to be all of them).

You'll still get the occasional orphan block when two different "announce" messages go into the network at the same time, but this should reduce the incidence of orphan blocks dramatically.  

Not sure If I got it properly... Correct me if I didn't: So anybody broadcasting fake announcements would be able to waste 15s of the miners willing to trust the fake announcement?

[Cryddit]

Nope.  The miners would still get to work on the first one they received.  Then, if they get the announced block within 15 seconds, they'll switch to the first block they heard about.  But if they don't get the announced block (and if it's a fakeout message they won't) then they don't change what they're doing at all.  Even if that includes *FINDING* a new block before the announced block arrives, in which case the announced block *will* become an orphan.

[vane91]

DeathAndTaxes: I'm normally impressed with your posts, but I think you've got some details wrong.

Thanks and I am happy to be corrected.  

First, RE: the orphan cost of transactions:  Decker/Wattenhofer measured 80ms for a 1K bigger block.
...
So 3.3 millies per kilobyte is the orphan cost.

I didn't know about this source.  I recall (but can't seem to find a cite) with a much lower estimated cost although it may have simply been an error on my part ~0.4 mBTC vs ~4 mBTC.

It should be fairly easy to get about another factor of about 10-20 reduction in orphan costs.

Correct me if I am wrong but a rather simple block broadcast improvement would be to not include the tx just include their hashes.  Since a well connected miner aware of a given tx X should already have relayed that tx X to his peers there is little need to include the full tx in the block message.  Instead block message could just consist of the header and a list of tx hashes.  If average tx size is 400 bytes and the SHA-256 hash is 32 bytes that alone could cut the orphan cost of a tx by 90% to ~0.3 mBTC.  In reality since the tx hash is just being compared to the UXTO a more involved modification would be for the block message to include a truncated hash of the tx.  This wouldn't represent a security risk as the actual merkle tree would involve the full SHA-256 hash.  Using say the first 64 bits of the SHA-256 hash would still make collisions essentially highly unlikely events and would reduce the orphan cost by another 4x to <0.1 mBTC.

And as I said in another thread, if EVERYBODY produces larger blocks then EVERYBODY bears the increased orphan cost, and the result is better for everybody . There is a fixed number of new bitcoins to be earned, regardless of the orphan rate; everybody's share of that fixed number will be the same if everybody has a slightly higher orphan block rate. But everybody will earn more fees, and their bitcoins will be worth more because bitcoins will be more useful.

Agreed.  Hopefully pools and major solo operators can see that their long term profitability is based MORE on the growth of Bitcoin than the short term orphan cost.   Hopefully large pools are aware they don't need universal support.  If 70% of hashpower agrees to produce larger blocks (say 500KB avg) for the good of the network.  It cuts the orphan cost by 70%.   Still I think the orphan cost does highlight the reality that miners are going to be increasingly reluctant to devote more space to free tx.  This is something users will have to come to grips with.   Including a fee and waiting hours or days is unacceptable (although it is often for non-fee reasons) however no fee tx should be considered charity by users and if someone does you an act of charity in an hour, or day, or week well you got what you paid for.  The default behavior of most clients should probably be changed to include the "min fee" on ALL txs not just low priority ones.  If users want to they could change this but they should be warned "Including no tx fee may result in delayed confirmation times".  Enforcement for relaying at node level should still only be on low priority.  

It is somewhat ironic that this is more of an issue due to the higher exchange rate.  The min fee on low priority tx was lowered due to rising exchange rate.  Today 3.3 mBTC is ~$1.50.  Ouch.  However if Bitcoins were worth less it would be less of a cost.  Since Bitcoin is often used as a proxy for USD a 5 mBTC fee (which more than covers orphan costs) is more viable at a lower exchange rate.

Couldn't it be possible for blocks to just include hashes of a file, without including all the inputs, outputs, etc, just minimal info, the nuonce (that will be longer than the it is now), timestamp, maybe number of inputs/output and bitcoins transfered.

So bitcoin will work with a DHT just like bittorrent,

the miner will broadcast just this mini-blocks that matches the difficulty, then the rest of the nodes will accept it as valid, and start working in the next block, and simultaneously, ASK for the "file with all the transactions in it".  (this file is just like the block is now.)

So this fix is just like the "announce fix" but with proof of work.

This small fix, together with an option to  "just download the last X blocks", and the proper implementation of said DHT, allowing to lookup by block and also query the network for any input, just like the client actually does with the database, could make bitcoin infinitely scalable without the block propagation issue.

Or a quick&dirty fix could be just make all blocks the same 1 mb size and fill a field with info from the last block(s) in order for them to meet said size, then the block size propagation time will be a non issue, and this additional data can be discarded as it is just a filler.

[DeathAndTaxes]

Nope.  The miners would still get to work on the first one they received.  Then, if they get the announced block within 15 seconds, they'll switch to the first block they heard about.  But if they don't get the announced block (and if it's a fakeout message they won't) then they don't change what they're doing at all.  Even if that includes *FINDING* a new block before the announced block arrives, in which case the announced block *will* become an orphan.

Then you haven't sold anything.

The "critical window" for computing orphan losses is the time between when a miners finds a block AND the entire network is building the next block on top of that.  That includes the time to relay and verify the node, and all miners to switch to the next block.

During the "critical window" if another miner finds and broadcasts a competing block the network will be split.

Announcing an announcement of a block would solve absolutely nothing.  There are solution to significantly reduce the block broadcast latency but that isn't it.

[binaryFate]

Nope.  The miners would still get to work on the first one they received.  Then, if they get the announced block within 15 seconds, they'll switch to the first block they heard about.  But if they don't get the announced block (and if it's a fakeout message they won't) then they don't change what they're doing at all.  Even if that includes *FINDING* a new block before the announced block arrives, in which case the announced block *will* become an orphan.

So If I understand properly the rational behind your proposal is to have the majority acceptance behing taken over the "light announcements" rather than full blocks (but still being resiliant to fake light-announcements).  Is there any advantage of doing this?

[Cryddit]

The advantage is that the first block announced will win an even race (two blocks at the same level) depending on the speed with which the lightweight message propagates rather than the speed at which the block propagates.  When miners who haven't yet found a block revert to the first block they heard about, that block gets an overwhelming advantage in terms of being the block that the next will be based on.

The idea is to eliminate if possible the cost of block size in terms of orphan blocks.  Miners are limiting block size specifically because a large block can take about 15 seconds to propagate across the network -- a smaller one can propagate faster.  The risk to them is that somebody is putting out a smaller block that propagates faster than theirs.

A lightweight message will cross the network in 8 seconds -- meaning no advantage for smaller blocks released even as little as one second later.  The only advantage a smaller block still has is that it can reach miners a few seconds faster and get them to mine for just a few seconds before the block they heard about first gets there - even if the block they heard about first is bigger.  

If not for the "announce" messages, all the miners that got the later smaller block first would mine on it until the next block was found (ten minutes average) instead of until the earlier larger block reaches them ( < 15 seconds.  )

The difference between "under 15 seconds of mining effort" and "ten minutes of mining effort on average" gives the first block found an overwhelming advantage even if it's a full megabyte.

[DeathAndTaxes]

No miners aren't going to switch to a new block until they receive and verify the existing block so pre-announcement or not the faster block will be received and verified and miners will switch to that.  Doing anything else would be subsidizing the owner of the slower block at the expense of their own revenue.

There are real solutions which can reduce the broadcast time by 90%+ or more.

[Cryddit]

I thought the idea was to reduce the speed advantage of a smaller block making it less expensive in block awards to create a larger one. ie, subsidize the guy who finds a block *FIRST* regardless of the size of the competing blocks.  

I see your point though; it's a 'prisoners dilemma' for the miners.  In the current environment, a miner would lose revenue if switching behavior, even though the network would benefit with absolutely no change to mining revenues if all the miners switched at once.  Conversely, in an environment where the protocol were already deployed, a miner would lose revenue if he switched to issuing blocks with no preceding announcement.  In both cases whichever miner doesn't go with the majority loses due to increased rates of orphaned blocks compared to other miners with the same hashing power.

If you've got a good way to make the blocks propagate faster though, that will largely accomplish the same thing; get the first block distributed before the smaller block that it would otherwise be competing with is even found.  First strategy I suppose would be transmitting to the neighbors with the most peers and greatest bandwidth first, if a peer knows which neighbors those are.

[DeathAndTaxes]

Well larger blocks are never going to be faster or as fast as smaller blocks.  The goal is to reduce the latency time per kB.  The faster a block can be broadcast the lower the "orphan cost" per tx.   Still larger blocks will always have a higher orphan rate but they also have higher gross revenue.

The good news is the current method is about the slowest, most bloated method possible for broadcasting a block.  Any change is an improvement.

One proposal is to only include tx hashes in the block message.  Currently a block message consists of a block header and a list of all tx in the block.  Most nodes know of most or all of these tx, hell they already have verified them and included them in the memory pool.  This simply makes the block larger than it needs to be.  Instead the block message can consist of the block header and a list of tx hashes.   The average tx is ~ 400 bytes and a SHA-256 hash is 32 bytes so we are talking a 90%+ reduction in block message size and thus propagation time and thus orphan costs.

For example lets look at this recent block:
https://blockchain.info/block-index/443364/0000000000000003b90c99433d07078d5498910442489383f18e250db0a843e2

301 tx and 480 KB.  If the block message was changed to be just tx hashes the block message would drop from 480 KB to ~10 KB or a 98% reduction in size.

Another client side change would be removing the double verification of txs.  This may have already been completed I haven't looked at that code since before v 0.7.

Improving the efficiency of mining benefits all users not just miners as orphaned blocks are simply wasted energy.  They lower the effective security of the network.  Further size reduction is possible but requires some more significant changes to the protocol.

[JimiQ84]

Well larger blocks are never going to be faster or as fast as smaller blocks.  The goal is to reduce the latency time per kB.  The faster a block can be broadcast the lower the "orphan cost" per tx.   Still larger blocks will always have a higher orphan rate but they also have higher gross revenue.

The good news is the current method is about the slowest, most bloated method possible for broadcasting a block.  Any change is an improvement.

One proposal is to only include tx hashes in the block message.  Currently a block message consists of a block header and a list of all tx in the block.  Most nodes know of most or all of these tx, hell they already have verified them and included them in the memory pool.  This simply makes the block larger than it needs to be.  Instead the block message can consist of the block header and a list of tx hashes.   The average tx is ~ 400 bytes and a SHA-256 hash is 32 bytes so we are talking a 90%+ reduction in block message size and thus propagation time and thus orphan costs.

For example lets look at this recent block:
https://blockchain.info/block-index/443364/0000000000000003b90c99433d07078d5498910442489383f18e250db0a843e2

301 tx and 480 KB.  If the block message was changed to be just tx hashes the block message would drop from 480 KB to ~10 KB or a 98% reduction in size.

Another client side change would be removing the double verification of txs.  This may have already been completed I haven't looked at that code since before v 0.7.

Improving the efficiency of mining benefits all users not just miners as orphaned blocks are simply wasted energy.  They lower the effective security of the network.  Further size reduction is possible but requires some more significant changes to the protocol.

Is this being implemented? Does bitcoin foundation know about this? (rather naive question, I'm 99% sure they know, but what if...)

[ilpirata79]

Hi guys,
My opinion is that we should schedule a change to the max block size to be 10mB in a year or two,
So we match the tps of paypal. Would the world fall If we made such a change? In any case miners could be free to set a lower threshold If they believe it's appropriate.
Micro translations though, would still be Made off-chain, using a network a micro payment channels, as they require fast confirmation.

Best regards,
Ilpirata7

Badly typed on my iPad

[Carlor]

Why not a dynamic blocksize?

[BurtW]

Just do this:

For example lets look at this recent block:
https://blockchain.info/block-index/443364/0000000000000003b90c99433d07078d5498910442489383f18e250db0a843e2

301 tx and 480 KB.  If the block message was changed to be just tx hashes the block message would drop from 480 KB to ~10 KB or a 98% reduction in size.

then you do not need to do this:

we should schedule a change to the max block size to be 10mB in a year or two

and we can easily support more TPS than PayPal.

[ilpirata79]

Why not a dynamic blocksize?

I think that an automatic dinamic block size is difficulty to design and implement and could lead to disparities among peers. The community should be in charge of deciding what the max block size should look like through planned increases.

Best regards,
Ilpirata79

Badly typed on my iPad