Peter Todd [ARCHIVE] on Nostr: š Original date posted:2018-02-12 š Original message:On Mon, Feb 12, 2018 at ...
š
Original date posted:2018-02-12
š Original message: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.
> > 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.
True, maybe we can just reuse the CPFP calculation now. That said, AFAIK that's
only done in the miner code, not the mempool, so that may not be trivial to
actually do.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/416aec03/attachment.sig>;
š Original message: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.
> > 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.
True, maybe we can just reuse the CPFP calculation now. That said, AFAIK that's
only done in the miner code, not the mempool, so that may not be trivial to
actually do.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180212/416aec03/attachment.sig>;