📅 Original date posted:2018-02-12 📝 Original message:On Mon, Feb 12, 2018 at ...

Russell O'Connor [ARCHIVE] /

npub1dw8…plrw

2023-06-07 18:10:41

in reply to nevent1q…kmz9

📅 Original date posted:2018-02-12
📝 Original message:On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <pete at petertodd.org> wrote:

>
> I don't actually see where the problem is here. First of all, suppose we
> have a
> transaction T_a that already pays Alice with a feerate sufficiently high
> that
> we expect it to get mined in the near future. If we want to pay Bob, we
> can do
> that by simply creating a double-spend of T_a that pays both Bob and Alice,
> T_{ab}. BIP125 only requires that double-spend to have an absolute fee
> higher
> than the minimum relay feerate * size of the transaction.
>

The problem is that rule 3 of BIP 125 requires you pay a fee that is higher
than the the fee of T_a *plus* the fee of the sweep-transaction that the
Alice has added as a unconfirmed child transaction to T_a because
double-spending to pay Alice and Bob invalidates Alice's
sweep-transaction. Alice's sweep-transaction is very large, and hence pays
a large absolute fee even though her fee-rate is very low. We do not have
any control over its value, hence Alice has "pinned" our RBF transaction.

> 3'. The replacement transaction pays a fee rate of at least the effective
> > fee rate of any chain of transactions from the set of original
> transactions
> > that begins with the root of the original transaction set.
>
> I think what you mean here should be the effective fee rate of the maximum
> feerate package that can be built from the set of transactions that begins
> with
> the candidate replacement. But actually calculating this is I believe
> non-trivial, which is why I didn't implement it this way when RBF was first
> implemented.
>

Yes, that is what I mean. My proposal was off-the-mark.

Surely CPFP is already computing the package-fee rates of mempool
transactions. That is the value we need to compute.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/c1b15de0/attachment-0001.html>;

Author Public Key

npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw

Show more details

Published at

2023-06-07 18:10:41

Kind type

1 Short Text Note

Event JSON

{ "id": "278a7f50ee8af0d2ce98c7f1c3279f4c3f52614ec5d0d3e5164f8a1955f3a912", "pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d", "created_at": 1686161441, "kind": 1, "tags": [ [ "e", "5383538cd2f56a51e291c00061d21ca9bc4561faee2982afb441fa4fcccaa01f", "", "root" ], [ "e", "9782d19fae4c6d71027cba578779c78aebfbc6f4866323baa9489e19725cf01a", "", "reply" ], [ "p", "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa" ] ], "content": "📅 Original date posted:2018-02-12\n📝 Original message:On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e\n\u003e I don't actually see where the problem is here. First of all, suppose we\n\u003e have a\n\u003e transaction T_a that already pays Alice with a feerate sufficiently high\n\u003e that\n\u003e we expect it to get mined in the near future. If we want to pay Bob, we\n\u003e can do\n\u003e that by simply creating a double-spend of T_a that pays both Bob and Alice,\n\u003e T_{ab}. BIP125 only requires that double-spend to have an absolute fee\n\u003e higher\n\u003e than the minimum relay feerate * size of the transaction.\n\u003e\n\nThe problem is that rule 3 of BIP 125 requires you pay a fee that is higher\nthan the the fee of T_a *plus* the fee of the sweep-transaction that the\nAlice has added as a unconfirmed child transaction to T_a because\ndouble-spending to pay Alice and Bob invalidates Alice's\nsweep-transaction. Alice's sweep-transaction is very large, and hence pays\na large absolute fee even though her fee-rate is very low. We do not have\nany control over its value, hence Alice has \"pinned\" our RBF transaction.\n\n\u003e 3'. The replacement transaction pays a fee rate of at least the effective\n\u003e \u003e fee rate of any chain of transactions from the set of original\n\u003e transactions\n\u003e \u003e that begins with the root of the original transaction set.\n\u003e\n\u003e I think what you mean here should be the effective fee rate of the maximum\n\u003e feerate package that can be built from the set of transactions that begins\n\u003e with\n\u003e the candidate replacement. But actually calculating this is I believe\n\u003e non-trivial, which is why I didn't implement it this way when RBF was first\n\u003e implemented.\n\u003e\n\nYes, that is what I mean. My proposal was off-the-mark.\n\nSurely CPFP is already computing the package-fee rates of mempool\ntransactions. That is the value we need to compute.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/c1b15de0/attachment-0001.html\u003e", "sig": "d8b8046fef96a68604824cdfade0458cd3576f31d8c26c9a80f6a4af6a86cb94bae1d3b73c96f962164991b09394b92084a48ab8cbffc8c8b2108389bf978b23" }