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

[DeathAndTaxes]

OK, it was me that was making the unit conversion error: this was why I gave you the size in satoshi, in my very first response, in the actual code that sets it.

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.

The protocol rounds the size up to 1KB so it is 0.2 mBTC per KB.

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.

[1714933457]

1714933457

[1714933457]

1714933457

[1714933457]

1714933457

[Yogafan00000]

OK, it was me that was making the unit conversion error: this was why I gave you the size in satoshi, in my very first response, in the actual code that sets it.

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.

The protocol rounds the size up to 1KB so it is 0.2 mBTC per KB.

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.

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?

[DeathAndTaxes]

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?

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.

[DeathAndTaxes]

  tell people to not send transactions < 0.01 BTC, bitcoin is not ready for micro payments yet

Apparently not many people have figured out that any 0.01 BTC minimum is rather easily circumvented.

Person A wants to send 0.00000001 BTC to Person B.
Person A owns address 11 (with a single 1 BTC output in it) and address 12 (newly created).
Person B owns address 13 (with a single 1 BTC output in it) and address 14 (newly created).

The naive way to pay would be to use 11 as an input of 1 BTC, 12 as an output of 0.99999999 BTC, and 14 as an output of 0.00000001 BTC. (That'd be a non-standard transaction as all outputs have to be at least one Gavin.)

The smart way would be to use 11 as an input of 1 BTC, 13 as an input of 1 BTC, 12 as an output of 0.99999999 BTC, and 14 as an output of 1.00000001 BTC. Person A signs the outputs with address 11. Person B signs the outputs with address 13. (That'd be a standard transaction, and would probably be confirmed in a reasonable amount of time even without any transaction fees if the BTC in address 11 and 13 was old enough.)

It's basically the same concept as CoinJoin, but the only two participants are the buyer and the seller.

Surely I'm not the first one to think of this.

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.

[gmaxwell]

Apparently not many people have figured out that any 0.01 BTC minimum is rather easily circumvented.
[...]
Surely I'm not the first one to think of this.

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.

[DeathAndTaxes]

I'm still surprised it hasn't been done already. In addition to getting around the 1 Gavin (5430 Satoshi) minimum, it lets you boost the priority of your transaction to the point where you don't have to pay any transaction fees.

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).

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).

Interesting. I never thought of that one. I like my method better though. At least if both parties own at least 0.1 BTC.

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.

[Kouye]

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?

[DeathAndTaxes]

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?

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.

[DeathAndTaxes]

And yeah, I've come to accept what I'll call the 5430 rule, though not the fact that it's 5430 instead of 1000 or even 5000.

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".

[Kouye]

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.

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  )

[Dabs]

It's useful when the sending party is trusted not to double-spend and the receiving party doesn't need to respend the BTC right away.

My transaction did not require a fee. It was a whole bitcoin more than a day old. But I was trusted not to double-spend, and receiver didn't need it right away.

So we waited 28 hours for it to get included in a block.

Next time, I'm adding a 0.00010001 fee.

One day of mining on a 2 GH/s USB stick takes care of my future transaction fees for a long time. (also, 1 gamble on 98% on any of those dice games.)

[DeathAndTaxes]

Next time, I'm adding a 0.00010001 fee.

The first rule of 10001 club is we don't talk about 10001 club.

[jl2012]

We may use total bitcoin day destroyed as the tie-break for a fork. I guess Satoshi had a similar idea?

[bionicghost]

If a block gets orphaned, it means another viable block was added to the chain while the miner was adding transactions to the orphan block, right? Does that mean the miner doesn't get neither the 25 coins nor the transaction fees? If so, what's the point of adding bigger transaction fees as a safeguard against having the block orphaned?

[DeathAndTaxes]

If a block gets orphaned, it means another viable block was added to the chain while the miner was adding transactions to the orphan block, right? Does that mean the miner doesn't get neither the 25 coins nor the transaction fees? If so, what's the point of adding bigger transaction fees as a safeguard against having the block orphaned?

Miners don't add tx to a block after they find one.

Simplified mining process
1) Miners select tx from the memory pool for inclusion in a new block (the number, method, and criteria is up to the miner)
2) Miners construct a merkle tree from the tx in step #1
3) Miners create a block header with the merkle tree, prior block hash, version, timestamp, and nonce
4) Miner will hash the blockheader.  If it is a solution go to step 5.
4a) Miner will increment nonce and go to step 4.  If nonce range is exhausted go to step 4b
4b) Miner will modify another element in blockheader, reset nonce range back to 0 and go to step 4
5) Miner has found a block.  They broadcast it to peers.

So once a miner finds a block they are done.  All the work for deciding tx comes BEFORE solving a block.

[BurtW]

I have always wondered about this:

Would it be possible in step 4b) instead of modifying the header do the following

Add some more transactions to the block that have come in since the last header creation
Do the step needed now that the new transactions are in the block
Zero the nonce
Continue

Or is that too much work?

It seems that they may be able to pick up some good paying transactions into the block "on the fly" that way and the new transactions will modify the header for the new nonce cycle.

[DeathAndTaxes]

I have always wondered about this:

Would it be possible in step 4b) instead of modifying the header do the following

Add some more transactions to the block that have come in since the last header creation
Do the step needed now that the new transactions are in the block
Zero the nonce
Continue

Or is that too much work?

It seems that they may be able to pick up some good paying transactions into the block "on the fly" that way and the new transactions will modify the header for the new nonce cycle.

Technically 4b can be completed by changing the tx set.  Essentially you just need to make any change to the blockheader and changing the tx set works for that.

It probably doesn't make sense to do it on each new transaction and there are methods for pool workers to make a change locally (like incrementing the timestamp) which saves a round trip to the server but  any change to the blockheader (including changing the tx set works).  Pools are highly customized but I would assume they strive for a balance between reacting to changes in the memory pool and having miners make timestamp changes locally to reduce server load.

Computing a new tx set may seem like a lot of work but the tx are already validated before they are in the memory pool so you are just looking at 2x the # of transactions in SHA-2 hashes.  Even for a large block a single CPU core can do that in a millisecond (or less).

[gmaxwell]

Add some more transactions to the block that have come in since the last header creation
Do the step needed now that the new transactions are in the block
Zero the nonce
Continue

Miners already do this. Some pools will even trigger longpolls to trigger miners to get work early if enough new txn come in (or at least eligius did in the past, I'm not sure if they still bother).

[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?

[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?