Topic: Blocks are [not] full. What's the plan? - page 9. (Read 14283 times)

+1 Change the f*&$%ng title of this thread!

All I know is I'm trying to do business in Bitcoins and I've got a wallet full of "0/unconfirmed" and no good answers as to what to do about it.

We ain't ready for mainstream yet.

Actually the only measurement you need is the orphan rate and the block interval:

http://www.mail-archive.com/[email protected]/msg03274.html

Note that's actual block interval, not steady state, an oversight Michael Gronage corrected for me in his reply. Of course this doesn't give you detailed breakdowns of latency and bandwidth, but given the consolidation of hashing power the measurements Decker et al. made on network wide latency/bandwidth make a tonne of assumptions about topology that if not already inaccurate, won't be in the future.

2 days ago I received a payment for my work. 1 input, 1 output, 0.1 mBTC fee and the transaction stuck for a lot of hours. This is NOT fine. I think I should force all my customers to use BTC-e USD redeemable codes. That delay cost me >4000 USD due to BTC price crash.

Oh god !!!!! another misleading title...
Was there ever a full 1mb block?

My transaction confirmed in about 28 hours.

So I can still send no fee transactions, you just got to wait a little bit longer. Add a 0.0001 fee, and it confirms a lot sooner.

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

You seem to have misplaced a decimal point.

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

First, RE: the orphan cost of transactions:  Decker/Wattenhofer measured 80ms for a 1K bigger block. The math to compute orphan cost is:
Plugging in 25 XBT block reward, 600 target time, 0.08 delta time, and assuming no fees (to make the math easier):

So 3.3 millies per kilobyte is the orphan cost.

Even if we assume Decker/Wattenhofer are off by a factor of two (we have made some improvements since they measured block propagation; better measurements welcome), default transaction fees (1 to 5 millies per kilobyte) are in the right ballpark to minimize orphan costs. the .1 default transaction fee does not come close to covering the orphan cost (edited: thanks foxpup).

It should be fairly easy to get about another factor of about 10-20 reduction in orphan costs. 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.

I hope not. I have a medium priority transaction that's not yet confirmed for the past 12 hours, although I think it will confirm by the end of the day. I'll let you guys know. I sent a whole bitcoin a day after I got it, thinking it would confirm. The Satoshi Client (bitcoin-qt) did not request for a fee, so I did not include one.

But, that also tells me, I should include transaction fees next time if I need it to confirm within the hour.

My understanding (pool ops feel free to correct me) is that pools are already running highly customized version of bitcoind.  Honestly if you can't compile bitcoind then you probably don't have the technical skills to run a pool.

Still up to 250KB you wouldn't even need to compile bitcoind simply modify one line in the bitcoin.conf file.  A LOT of blocks are much smaller than 250KB.  So it becomes a no brainer to focus on that first.  The average block in past 30 days is ~150KB.  Eyeballing it, it looks like 80% of blocks are <250KB.  A good 25% of blocks aren't even 100KB and at least 10% aren't even 50KB.  If all blocks were 250KB we wouldn't even have a backlog (except for no-fee txs).

There are some exceptions.  BTC Guild does sometimes push out much larger blocks (350KB to 400KB).  Not sure what conditions trigger that.  Maybe they only do it when the backlog gets real bad.  https://blockchain.info/block-index/441049



There is a cost but fees do offset that.  Users shouldn't expect pools to make larger blocks full of free tx but paid tx offset the marginal cost of larger blocks.  One estimate put the marginal cost (due to increased orphan risk) at ~0.04 mBTC per KB.  Still at some point pool ops have to decide if 1% or so lower orphan losses worth the bad PR of Bitcoin "choking" at ~0.3 tps.  I mean 0.3 tps.   The 1 MB limit is 4 to 6 tps.  PayPal is 50 tps.  VISA is 5,000 tps.   We are at 0.3 tps, and the network seems to be straining.   If pools are unwilling to push the envelope to at least 300KB to 500KB blocks well we might as well pack it up because this experiment is going nowhere.

For the record I do think they will adapt and I do think the protocol will eventually handle block broadcasting in a more intelligent manner so this becomes less of an issue over time.  The falling subsidy will also improve the economics of larger blocks.  It also isn't all on the pools.  Users need to accept you either PAY or you get a confirmation eventually where eventually can be days or possibly weeks.   It is a "charity" option and you get space when space is available (which probably means a block on Tuesday at 2:48 in the morning). The days of pay no fee and see it in the next block are over.  So doing that over and over and getting mad is just silly.

The fact is that many miners are producing 250kB blocks, and this is the behaviour of the Satoshi client. If many miners are using clients that function substantially differently, we would not be seeing so many 250kB blocks. Whatever modifications they have made, they still seem to be following the same fee rules.

True, there's nothing special about the 250kB limit other than that's the threshold imposed by the Satoshi client. I never said it was a good idea, and in fact I think it's particularly absurd that the minimum fee suddenly jumps to more than double once the threshold is hit and then increases gradually from there, but that's for the miners to decide. If they don't like it, they're free to modify the fee rules in any way they choose.

Not necessarily. A number of parameters regarding the fee rules can be set from bitcoin.conf. In any case, modifying the code and recompiling is not at all difficult.

It appears that way, yes. I expect that as the block subsidy drops, it will eventually stop making sense to scale transaction fees with the block size.

Just how would a pool go about putting more transactions into the blocks they find? I assume they have to modify the source code, recompile, and then deploy? Are the changes trivial for the average pool operator?

And on top of this there is a greater chance of an orphan block resulting in the loss of 25 BTC?

It sounds like the pools will not change until the reward is much less then it is today. It simply does not justify the risk to add more transactions and lose out on the reward. Is this a correct assumption(s)?

... Looks like a new client isn't going to fix this.

I guess it's time to rethink whether bitcoin will ever go mainstream.

Paying extra transaction fees doesn't make anything go faster. It merely transfers your position on the waiting list, driving up transaction costs for everyone.

Remember, it's the people, it's the miners that are doing this...

Larger blocks up to 1MB yes.  Creating blocks greater than 1MB no.

Oh okay. So it's only the major pools are choosing to make small blocks. If I were a solo miner, I could set up and be customized to a larger block size (one that won't fork the chain.)

That seems ingenuous to me, to believe miners would use the satoshi client "as it is".

When you say "Higher fees must be paid to compensate for this increased risk" (of taking a longer time to propagate), the idea is true, but your approach is not quite logic. It's not that there is a threshold above which you take a risk. Actually it starts from the first KB, everything you add in terms of size increase your chance to get an orphan block because your freshly mined block will take more time to propagate, and this is a continous, linear trade-off. Not something that appears after 250KB.

You can actually measure the cost (in terms of network propagation) of including more transactions in a block, and thus define a transaction fee per KB that matches perfectly the real cost in terms of propagation. There was an interesting discussion going on recently on the bitcoin-dev mailing list, in short Michael Gronager shown that a fee of about 0.0004 per KB is "fair" in this regard.

Right NOW, the reality is 0.1 mBTC IS fine.  There isn't a massive backlog of paying tx. The backlog is on free tx.  The average block size isn't >250KB it is ~150KB.  That isn't to say it won't be an issue in the future but right now the min fee is fine.  

Still the larger fee for larger blocks is a huge landmine and beyond stupid.  It makes absolutely no sense.  Users have no idea what size blocks miners are targeting.  If a user pays double but a miner is targeting 100KB block the higher fee is just useless.  The larger fees for larger blocks nonsense should just be scrapped.  It might have made sense in the early history when average block was 20KB and there was a risk of a spam attack creating 1MB bloat blocks but those days are gone now.

You misunderstand how fees work with regard to large blocks. The minimum fee is not fine. Under the Satoshi client's fee rules, only the first 250kB of a block is available for transactions paying the minimum fee (which is why we're seeing so many 250kB blocks). The Satohsi client will create larger blocks if and only if there are transactions paying more than double the minimum fee. This is due to the fact that large blocks take longer to propagate, resulting in an increased risk of the block being orphaned. Higher fees must be paid to compensate for this increased risk.

What do you mean affected? 

You can create blocks of any size up to 1MB.  Of course pools can do as well.  They have simply CHOSEN to make much much smaller blocks.   It looks like a few regular miners are keeping blocks <100KB.  Most seem to cap at 250KB.  The average for prior 30 days is ~150KB or a staggering 0.3 transactions per second.