Rules for TXN propogation, minRelayTxFee and FeeFilter with CPFP

[brianddk]

Looking at the default reference implementation, I'm trying to get an idea has to how minRelayFee, FeeFilterand CPFP work. So maybe someone can tell me where I'm off track.

• I think fee-per-KB is fee per 1000 vbytes, not 1024 (KB -vs- KiB)
• I think that minRelayTxFee, and FeeFilter does calculations in vbytes not bytes
• I think that minRelayTxFee, and FeeFilter ignore CPFP relations

To restate, I think each Tx must meet the requirements for minRelayTxFee, and FeeFilter on its own merits and without CPFP relations, but that segwit sizing is taken into consideration.

Thoughts?

[nc50lc]

Thoughts?

I also think that it's vBytes, the fee rate is also based from vBytes not Bytes.
Because if the minRelayTxFee is based from Bytes, then 1input-2output 1sat/vB TXns w/ SegWit data will be lower than the
default minRelayTxFee & FeeFilter which would be rejected by most of the nodes, which doesn't usually happen.

Example:
A SegWit transaction of 166vBytes with 1sat/B transaction fee would have 0.67sat/B if it will be computed based on Raw Bytes (approx 247B).
Or just take a look at blockstream's data from a random SegWit Tx: 5de78791f4c7d545c5c03eda1953a62da7d4b9a07416687c851988b57ce1807f
"Transaction fees" is based from vBytes.

Just my thoughts.

[ranochigo]

I think fee-per-KB is fee per 1000 vbytes, not 1024 (KB -vs- KiB)

That is correct. Bitcoin uses kilobytes and not kilobits.

I think that minRelayTxFee, and FeeFilter does calculations in vbytes not bytes

This is also correct. Transactions are calculated in vbytes instead of bytes.

I think that minRelayTxFee, and FeeFilter ignore CPFP relations

For now. minRelayTXfee and FeeFilter cannot judge transactions based on CPFP outright as there is no way to know whether a transaction has CPFP until the child transaction gets relayed.

However, there is a pull requests which fixes this, slated for release in v0.20.0 [1]. The pull requests is beneficial for CPFP as the node would be able to fetch the parent transaction after seeing the child transaction.

[1] https://github.com/bitcoin/bitcoin/pull/16851

[brianddk]

For now. minRelayTXfee and FeeFilter cannot judge transactions based on CPFP outright as there is no way to know whether a transaction has CPFP until the child transaction gets relayed.

However, there is a pull requests which fixes this, slated for release in v0.20.0 [1]. The pull requests is beneficial for CPFP as the node would be able to fetch the parent transaction after seeing the child transaction.

[1] https://github.com/bitcoin/bitcoin/pull/16851

Very cool... thank you.  I had seen an article or interview with some LN people and they were discussing a proposal to handle cooperative closing with a form of CPFP.  The idea was that either, or both operators could broadcast a 0 sat/b txn.  This would give a little more options for handling the channel reserve and allow both parties to split the cost of closing with 0 sat/b + CPFP.  Of course the same could be done for the opening channel TXN as well.