Rules for TXN propogation, minRelayTxFee and FeeFilter with CPFP

brianddk

jr. member

Activity: 47

Merit: 16

Quote from: ranochigo on May 21, 2020, 09:41:24 PM

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.

ranochigo

legendary

Activity: 3038

Merit: 4418

Crypto Swap Exchange

Quote from: brianddk on May 21, 2020, 04:12:15 PM

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

That is correct. Bitcoin uses kilobytes and not kilobits.

Quote from: brianddk on May 21, 2020, 04:12:15 PM

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

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

Quote from: brianddk on May 21, 2020, 04:12:15 PM

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

nc50lc

legendary

Activity: 2534

Merit: 6080

Self-proclaimed Genius

Quote from: brianddk on May 21, 2020, 04:12:15 PM

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.

brianddk

jr. member

Activity: 47

Merit: 16

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?

Topic: Rules for TXN propogation, minRelayTxFee and FeeFilter with CPFP (Read 162 times)