Bitcoin Forum

I was surprised to see this one getting through today - I thought zero-fee transactions on mainnet were no longer possible?

https://www.blockchain.com/btc/tx/fd4d01843d4a7b36696dafdf2fbaafb1aa159ff8c21755189a5b3fb14411aee1

The transaction belongs to F2Pool. The inputs are mined coins . They themselves mined the block so they included their own 0 fee transaction in it. Other mining pools wouldn't have included that transaction in their block

Any fee they pay will come back to F2Pool anyway

It's still valid but not standard.
"Non-standard" implies that it's the most common configuration of the nodes to do not accept/relay it.

But as explained above, if it's a transaction of the miner themselves, then they can make an exception to include it to their own block since it's valid.

IIRC there are a few other pools that do that too for their own transactions.

Kind of OT for this post but I think it would be good if someone could build the what would have to be a lot of bloat and complexity into core and the protocol that would allow a 2nd mempool so to speak that only has 0 fee tx in it. People could still consolidate their small inputs when the main mempool was empty BUT their TX would not be filling up the main mempool. Want to conoldate but don't care when it really happens send a 0 fee with this flag and possibly some pool would pick it up. Would it be worth the program / logic bloat is tough to say but I think it would be nice. Not going to happen, but it would be nice.

-Dave

It will still be protected from spam, because getblocktemplate and similar commands always put transactions from the highest to the lowest fee, so with those settings, free transactions will be included only if there is a room for them. And meanwhile, they could be combined with full-RBF, or they could even increase in fees, so that 500 transactions A->B->C->...->Z paying one satoshi each could be compressed into a single transaction with 500 satoshi fee.

Edit:
And I agree: there should be some room for free transactions. And my node has it, maybe it will be real, if mining will get more decentralized, or if my computing power will increase to enforce that.

It doesn't seem to need that much complexity and definitely not a secondary mempool. It only needs a new condition to reduce the minimum fee from x to 0 either manually for all conditions or automatically when the mempool size drops below a certain size.

It is quite strange how blockchain.com lists the transaction as a Coinbase transaction (or at least this is the impression I'm getting, as it is listed as the first transaction on the page).

They don't show it as the first transaction of block 743104 at my end.
Have you visited the link of the block height: www.blockchain.com/btc/block/743104 (http://www.blockchain.com/btc/block/743104)?

The parameters are designed to prevent unnecessary resource usage by having to receive and relay these free transactions. While your mempool will still kick the transactions from the lowest fee once it hits the size limit, the mempool fee rate will still increase and overwrite your parameters.

If not, then your mempool will contain unnecessary transactions that wouldn't be mined regardless.

I know. By using those settings, it means that by default there is a room for free transactions, up to 300 MB, or something like that. But of course if this mempool will be filled with 300 MB of regular transactions, those free transactions will vanish. And it is all by-design: allow free transactions if (and only if) there is a room for them, and allow gradually increasing fees, so that free or low-fee transactions are collected and broadcasted, and then they are batched into transactions with more fees, that will be mined, after crossing one satoshi per virtual byte. So, it works exactly as planned: transactions could be created as free, then they could contain low fees, and then they could pass the minimal fee, after being batched with other low-fee transactions.

Another thing is that those settings can be used to enable P2P communication, and the best thing is that by default all of those low-or-no-fee-transactions are sent only between nodes that declare to accept them, so by using default one satoshi per virtual byte, you won't even receive them, no matter if your node is connected with those low-fee nodes, because they simply won't send you that, if they use the official Core client.

Yes I have. Looks like I scrolled too far down, I see it as the second transaction.

True, and all full node operators should be more aware of that, to not miss some hidden traffic from applications like P2P marketplace. Of course, it requires extra resource usage, for example bandwidth, but it may be profitable, while being trustless and respecting users' privacy.

It depends on users. It is possible to receive some transactions with 0.999 sat/vB or lower, that can be joined (because of sighashes) and then broadcasted after reaching 1 sat/vB.

No, it is the other way around: it is practical to use only fees from excluded by default [0-1) sat/vB range in such subnetwork, then they are guaranteed to not be mined by most miners, and that means you can safely replace them. Also, each node broadcasts its own fee range, so you can easily filter nodes that accept such fees from those who don't. You can just leave your nodes running 24/7, and they should log all nodes with lower fee rates, in this way you can find them in a P2P way. It is like a not-so-obvious port, where you can choose a number from 0 to 999, because all numbers from 1000 upwards are standard fee rates.

Another thing is that mining such half-baked transactions is not desired, even if they are technically correct, because they contain more information than usual on purpose. For example, a transaction with "<pubkey> OP_CHECKSIG" which has "<message> OP_DROP <signature>" scriptSig. That "<message> OP_DROP" is a part of some P2P protocol, it is useful when exchanging data in a P2P way between nodes, but it should be dropped when broadcasting to the main network, just for better privacy.

That would leave it open to abuse. Mempool small enough to get in a 0 fee TX, send out all these TX to bloat it and push the fees back up. We all know that people would do that.
Having a 2nd separate one would eliminate that. As I said, I really really really don't think that would ever happen, but it would be nice.

-Dave

Good point about it being abused but the same arguments are correct for a second separate mempool, that could be flooded with zero fee transactions to the point where the size of this secondary mempool becomes bigger than the main one. This is why I don't think separating it would solve that problem.

Yes but in my fantasy it would be optional. I would not have to see it or download it if I did not want to. Want to flood it, fine. Some people may care others may not.

But...when we have times like now with dozens and dozens of unfilled blocks I would not have to think about combining a ton of small inputs and what it cost me. Yes it's minor but even at 1 sat/b over the last week I probably spent close to $5.00 cleaning up a lot of them. Here is the point; this post (sorry @DarkStar_) would get me more then that if I was keeping the money, good for me. For someone living in the 3rd world (you know part of the people BTC was supposed to help) that can be DAYS of food for their family.

-Dave

But it can be. All that is needed is multiplying each private key by each other public key, and then use that to symmetrically encrypt any message with AES, and then push it into the script. So, nodes could see the message itself, but if it will be encrypted, then the content can be safely routed. And if OP_DROP inside input is too much, then it is still possible to put it in the output, and then push one zero byte, when sending to the mainnet. But I personally prefer OP_DROP inside input, then it can be removed without leaving any trace that it was present.

And that's why I think some transactions in some cases should be free. It could be based on UTXO utilization or something, it is an open topic. Definitely, you can use dust outputs in some cases, and make it non-dust, for example by spending it with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and putting higher output than input. Sometimes it may be even profitable, when more people will join their transactions to save fees.

The mempool on your own node does not mean anything to which transactions will get confirmed, unless you are mining as an entity that decides which transactions get confirmed (you are solo mining, or are running a pool).

A pool's nodes could potentially keep these types of transactions, however, they have little reason to confirm these transactions, even if the mempool has no fee-paying transactions because there is an incremental cost for including an additional transaction by way of having a slightly higher chance the block will get orphaned.

It depends on sighashes. If you can join 500 transactions with one satoshi fee, to reach a single transaction with 500 satoshi fee, then you don't have to be a miner, you can just be a validator. It is ongoing, and there are practical examples, where you can reach fee rates below 1 sat/vB, or where you can even earn something, see testnet3 transaction: 99459ff5ce058067ed87b99f326305768444068a5659dce5ea5f126bfd4b0bda.

Keep calm, today 1 sat/vB means "no priority", and anything below that means "joke priority", so all users should be aware that their transaction can be rejected. But so far so good, in the past, it was normal to pay 0.01 BTC as a fee. But it is sad that the community removed free transactions entirely from the "reasonable defaults". However, regular fees can now reach values like 100 satoshis. In the future, I think we could reach even single satoshis on mainnet, if the whole traffic will jump into sidechains or Lightning Network. It is a matter of time, historically, fees were decreasing, when it comes to the number of satoshis.

That transaction has exactly 1 sat/vb fee rate not below it since it pays 5048 and has 5048 virtual size.

It depends on the mempool, 1 sat/vbyte fee most of the times means high priority and if competition grows it would be low priority.

Anything below 1 would be rejected by majority of bitcoin core nodes.

Fees decreased because of the price not because "traffic" went somewhere else. For example 0.01BTC fee would have cost less than a cent at some point but today that is about $200 so it had to be decreased.

Yes, but it was created by joining transactions that were below 1 sat/vB fee rate, see sighashes.

People don't want to go below 1000 sats/kvB on-chain, so if you want to make any transaction with lower fee rates, you can get it accepted only in separate networks, where transactions are batched in a trustless way, to form something that will appear as 1000 sats/kvB on-chain, but for users it is cheaper during making off-chain transactions.

The protocol doesn't care what happened before the final transaction was made and individual inputs don't pay a separate fee to come to a final sum. Meaning the protocol doesn't care if the owner of input one with a value of 0.00001 BTC took out 0.00000895 BTC or 0.0000179 BTC (2x the input), the protocol sees the whole transaction and the fee that this transaction paid in total.

Actually there has been some proposals about decreasing the minrelaytxfee to less than the current value.