📅 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:42

in reply to nevent1q…mdt3

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

> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> > 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.
>
> Ah ok, I misunderstood and didn't realise you were talking about the case
> where
> Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> case
> is possible to solve without putting some kind of restriction on spending
> unconfirmed outputs; with a restriction it's fairly simple to solve.
>

Adding such a restriction was Rhavar's original suggestion in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html,
but it seems the proposal wasn't well received because it kinda destroys
CPFP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/c7158cb4/attachment.html>;

Author Public Key

npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw

Show more details

Published at

2023-06-07 18:10:42

Kind type

1 Short Text Note

Event JSON

{ "id": "41e4821eb78c9c118571db0cf42103f42685e2f94cf168582c3cfb6c8240049a", "pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d", "created_at": 1686161442, "kind": 1, "tags": [ [ "e", "5383538cd2f56a51e291c00061d21ca9bc4561faee2982afb441fa4fcccaa01f", "", "root" ], [ "e", "d264a1e710ccdf84e9bcc28d30708bdef54f02885e21c750b2a583364a852c50", "", "reply" ], [ "p", "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa" ] ], "content": "📅 Original date posted:2018-02-12\n📝 Original message:On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:\n\u003e \u003e On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e \u003e I don't actually see where the problem is here. First of all, suppose\n\u003e we\n\u003e \u003e \u003e have a\n\u003e \u003e \u003e transaction T_a that already pays Alice with a feerate sufficiently\n\u003e high\n\u003e \u003e \u003e that\n\u003e \u003e \u003e we expect it to get mined in the near future. If we want to pay Bob, we\n\u003e \u003e \u003e can do\n\u003e \u003e \u003e that by simply creating a double-spend of T_a that pays both Bob and\n\u003e Alice,\n\u003e \u003e \u003e T_{ab}. BIP125 only requires that double-spend to have an absolute fee\n\u003e \u003e \u003e higher\n\u003e \u003e \u003e than the minimum relay feerate * size of the transaction.\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e The problem is that rule 3 of BIP 125 requires you pay a fee that is\n\u003e higher\n\u003e \u003e than the the fee of T_a *plus* the fee of the sweep-transaction that the\n\u003e \u003e Alice has added as a unconfirmed child transaction to T_a because\n\u003e \u003e double-spending to pay Alice and Bob invalidates Alice's\n\u003e \u003e sweep-transaction. Alice's sweep-transaction is very large, and hence\n\u003e pays\n\u003e \u003e a large absolute fee even though her fee-rate is very low. We do not\n\u003e have\n\u003e \u003e any control over its value, hence Alice has \"pinned\" our RBF transaction.\n\u003e\n\u003e Ah ok, I misunderstood and didn't realise you were talking about the case\n\u003e where\n\u003e Alice re-spends her unconfirmed payment. Unfortunately I don't think that\n\u003e case\n\u003e is possible to solve without putting some kind of restriction on spending\n\u003e unconfirmed outputs; with a restriction it's fairly simple to solve.\n\u003e\n\nAdding such a restriction was Rhavar's original suggestion in\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html,\nbut it seems the proposal wasn't well received because it kinda destroys\nCPFP.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/c7158cb4/attachment.html\u003e", "sig": "058305ceb9238ea711e405bcd4e8a2d5a5c3a07d9b11c52be1439c18f6ec17af5402f3a86bdeda1d9d39c86afea62472a7c0588d328fb44b74acd121ab9c1aae" }