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

I'm pretty sure there could be ways to achieve that in a decentralized way. I'll think about that.
And even if all miners don't have the same exact information about min block size at a given time, that would be an incentive to fill blocks a little more to be sure...
I might be 100% off, but that would be like block size becoming part of the proof-of-work?

(And by the way, thank you for your incisive but clear insight, D&T  )

Agreed.  It is kinda pointless to have that level of precision (54.3% of min fee to relay) for a value which really is just an aproximation.  It would be like going to the Dr office and they record your temp as 98.57828928764388489289892 pretty much everything past 98.6 is just noise.  The idea is that inputs have a certain size and thus the min useful output has a relationship to the min fee which is per kB.  All that is fine and good but 1/2 is close enough to 54.30% and a lot easier to explain.  I would like to see the 0.543 * (min fee) replaced with (minfee)/2.

"The min fee is currently 0.1 mBTC, the min you can send is half that to a single address is half that".

No. There is no one memory pool (queue).  There is no way for any node to know with certainty what tx are known by any other node.  Often people think of Bitcoin as this single unified grand network.  The reality is it is tens of thousands of independent nodes running different rules which are often not in "sync".  Decentralization has a cost.

Newbie question.

Would it be possible to replace the "MaxBlockSize" by a "MinBlockSize" in the protocol, that would adapt, depending on queue size?
Thus, we get rid of the upper limit, and all miners are equal regarding the orphan risks?

This isn't as huge of a benefit as you think.  Miners devote most of the block space to paying tx.  Having a fee is much better than having high priority for getting a tx included in a timely manner.  I pay a fee on my high priority txs which DON'T require it because relying on priority is no longer sufficient for timely and consistent payments.  For example: BTC Guild builds blocks up to 500 KB but uses the default 27KB for free txs.  There is a lot more space for paying tx then free ones.  

Having enough priority for relaying without a fee is one thing, but ultimately you need a miner to put it into a block and if you look at the backlog of unconfirmed txs it is 90% free tx (or have unconfirmed inputs or other problems).


Probabilistic micropayments are more useful for paying in a trust free manner where you are likely to need a large number of small payments and you don't want to make a deposit.  Say some future version of TOR allowed higher speeds for paying customers.  You wouldn't want to make a deposit to an untrusted unknown entity.  However if their fee was 1 mBTC per MB of data transfer you would instead send one probabilistic payment per KB (1/1000th chance of 1 mBTC instead of paying 100% chance of 1 kBTC).  In the long run you will pay the agreed rate and the receiver will get the agreed rate and no trust or escrow is needed.  Never seen it used but it is an interesting concept in payments that Bitcoin makes possible.

The 0.01 thing is finally gone in GIT IIRC, as the thing it was trying to do was largely addressed by the anti-dust-output changes. And indeed, you can avoid the anti-dust-output rule exactly as you describe, and there is nothing wrong with that.  The point of the anti-dust-output rule is to discourage people from creating UTXO which cost more to spend (in terms of marginal fees) then they yield in coin and your little protocol achieves that fine.

I wouldn't say "easily circumvented" but yes that would work.  No client supports that so it isn't easy but it can be done.  Now you have to ask yourself is the work worth that tiny amount of value (1/1,000th of a penny).  Probably not.  There are also other methods that can be done called probabilistic micro payments (essentially instead of sending 1 satoshi you create a tx that the receiver has a 1/10,00th of a chance of receiving 10,000 satoshis) but they aren't easy either.  Improved code will make these sorts of things "easy" someday.

In the short term maybe.  Obviously the more people that do it, the less priority access it will give.  In theory if everyone bumped their fee to 0.1001 mBTC then you wouldn't be ahead of anyone to do that would require 0.1002 mBTC.  However in my experience to date the vast vast majority of tx are either paying no fee or the min enforced for low priority txs.   You don't need to be first in line you just need to be close enough to the front to get into the next block.

So do we all agree that sticking with your strategy of bumping the tx fee to 0.10010 mBTC on my high priority transactions is a sound advice?

I updated my first post and deleted the rest.  No sense devoting 20 posts to a math error.  So the min mandatory fee to relay low priority txs is 0.1 mBTC.  The treshold between free and paying is also set to 0.1 mBTC.  Thus paying slightly more than 0.1 mBTC gives priority even over those paying the min.


No it doesn't. Do you mean wallet software does? Yea sure. It does. But the miner behavior is not rounded up.

Well that is probably an oversight then.  How can users make smart decisions on fee pricing if users tx are rounded up to nearest kb for fee purposes and miners aren't.  Either make them both round up or make them both pay fees based on actual size.

There is no reason for the threshold to not be set at the same value as the min fee to relay low priority txs.  No wonder why we have all kinds of issues with people having tx unconfirmed.  So the min fee for low priority tx to get relayed is 0.1 mBTC but then they are treated as zero fee by miners for inclusion in a block.  NOBODY (and I mean nobody I just checked the last 15,000 transactions) pays 1 mBTC per KB.  That is an asinine $0.60 per KB. The line of code is utterly useless.  It might as well be 10 BTC.   Every major pool is overriding that as they DO sort by fee.

On edit:  to avoid a long rambling semi-off topic subthread.  Lets just correct the math error here.

10,000 sat = 0.1 mBTC not 1 mBTC.

Deleting the rest of my posts.

The threshold is 1 mBTC: main.cpp:int64_t CTransaction::nMinTxFee = 10000;  // Override with -mintxfee

0.1001 mBTC is ABOVE the min threshold of 0.1 mBTC. I am going to shut up now as I am quickly going to cut my own throat.

Thanks and I am happy to be corrected.  


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.


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.


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.

And our prayers have been heard!!!!!!

Prioritize by fee in the stock code, at least, is made robust against that kind of gamesmanship by treating any fee below a minimum threshold as zero for the purpose of prioritizing the transactions.

Good advice.

Some factors to consider.
How many blocks were you "passed over"? Measuring in hours is kinda misleading.  A fee can't make a block come faster.   If in a 2 hour interval only 5 blocks were found that is a lot different than if 15 blocks were found.  

Another thing to consider is was the input confirmed or unconfirmed?  Often (not always but anecdotal it seems to be very common) when there is ranting about paying tx being "stuck" for hours it is because one or more of the inputs are unconfirmed and they didn't have fees.  If your inputs are unconfirmed and have no fee then for all intents and purposes your paying tx is a free one (at least until "parent pays child" is implemented).

I shouldn't share this semi-obvious fact but I pay a fee of 0.1001 mBTC on every single tx.  Since miners prioritize by fees and 99.9% of tx are either no fee or min fee (0.1 mBTC) it almost guarantees my tx will be prioritized the highest in the mempool and thus included in the VERY NEXT block for just 0.001 mBTC more than the default fee.