📅 Original date posted:2017-07-03
📝 Original message:This seems like something that might be better dealt with by modifying
the RBF eviction policy to calculate feerate separation between the
transactions in the mempool and opportunistically evict the sweep
transaction+parent if it has a sufficiently different feerate from the
bumped fee replacement. Basically you allow the fee bumped replacement
to evict the sweep transaction+parent if there is more than 1MB of
transactions(or whatever the block size/weight limit is) of
transactions between the sweep transaction+parent feerate and bumped
fee replacement feerate. This way the sweep transaction parent only
gets replaced if it is unlikely that miners would ever produce a block
template with transactions at the sweep transaction+parent feerate at
the same time as the replacement transaction feerate. From the miners
point of view this give a higher fee block template overall since it
would be unlikely that one would see transactions with the feerate of
both the CPFP sweep and the replacement parent in the same block
template.
On Sun, Jul 2, 2017 at 10:02 PM, Rhavar via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
> It actually doesn't really matter much.
>
> Let's say I want to pay Alice and Bob (unrelated entities), so I send it to
> them (together) with a low-fee transaction of paying 50 sat/byte. After an
> hour it's obvious that it's not confirmed (maybe there was a big backlog, or
> no blocks mined), so I want to replace my small transaction with one that
> pays 70 sat/byte.
>
> But in the mean time, Alice has swept her wallet (or used a service that has
> done so) and generated 50KB of descendant transactions paying 40 sat/byte
> (i.e. total fees of 0.02 BTC or $50).
>
> According to the BIP125 rules, I would need to pay for the cost of
> invalidating all the transactions (an absolute higher amount of fee) along
> with the replay cost of the descendant transactions.
>
> So in this case, for me to fee bump the transaction I'm looking at throwing
> away $50 because of descendant transactions that were totally out of my
> control. If I don't fee bump, I violate my promise to Bob to pay in a
> timely manner (and also probably Alice, as it wasn't in her control she was
> using an exchange that did this).
>
> If I guarantee to fee bump, the amount I risk is effectively unbounded. And
> even if the descendant transactions have a higher fee rate, and are
> assisting by CPFP boosting my transaction -- it very well might not be
> enough.
>
> --
>
> The idea of this proposal comes from the problems *in practice* of trying to
> low-ball fee estimation with scheduled continuous fee bumps until it
> confirms. At the moment it's not viable, but if this proposal was adopted
> then it would be.
>
> Personally I think it's of critical piece of having a stable fee market. Fee
> estimation is a fools game, even the new and improved fee estimation in
> master today was suggesting x30 fees to what was required (and I
> successfully made transactions with). People (and especially services) being
> able to be able to dynamically increase their fees sanely when dealing with
> withdrawals (and especially batched ones) will go a long way to helping the
> overall ecosystem.
>
>
> -Ryan
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable
> transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> From: greg at xiph.org
> To: Rhavar <rhavar at protonmail.com>
> bitcoin-dev at lists.linuxfoundation.org
> <bitcoin-dev at lists.linuxfoundation.org>
>
> On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar at protonmail.com> wrote:
>> That"s not really realistic. In practice some receivers do big sweeps and
>> include unconfirmed inputs. Replacing the transaction means you need to
>> pay
>> the cost of the sweep, which you probably don"t want to do (can be in the
>> order of $100s of dollars).
>
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 18:03:48
in reply to nevent1q…0pkv
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:03:48Event JSON
{
"id": "00a4f57f2317d3856c9b46f61b844c207df781e1818d5826a8648b65649f5b46",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686161028,
"kind": 1,
"tags": [
[
"e",
"6ae908cbd0a9f12abff6467fd3d89eab09bcc74de9ac35cd83e3048488dcab93",
"",
"root"
],
[
"e",
"a10f9f81f8a02606da2c7cecb6a5c9f90d77b584b2aae1e00f79a2114a492290",
"",
"reply"
],
[
"p",
"0edd50f962d40f6d28430b426c163d97f61365f07c64af51b8de33261ddd108a"
]
],
"content": "📅 Original date posted:2017-07-03\n📝 Original message:This seems like something that might be better dealt with by modifying\nthe RBF eviction policy to calculate feerate separation between the\ntransactions in the mempool and opportunistically evict the sweep\ntransaction+parent if it has a sufficiently different feerate from the\nbumped fee replacement. Basically you allow the fee bumped replacement\nto evict the sweep transaction+parent if there is more than 1MB of\ntransactions(or whatever the block size/weight limit is) of\ntransactions between the sweep transaction+parent feerate and bumped\nfee replacement feerate. This way the sweep transaction parent only\ngets replaced if it is unlikely that miners would ever produce a block\ntemplate with transactions at the sweep transaction+parent feerate at\nthe same time as the replacement transaction feerate. From the miners\npoint of view this give a higher fee block template overall since it\nwould be unlikely that one would see transactions with the feerate of\nboth the CPFP sweep and the replacement parent in the same block\ntemplate.\n\nOn Sun, Jul 2, 2017 at 10:02 PM, Rhavar via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Perhaps I am not following what you\"re saying here.\n\u003e\n\u003e If the receiver is paying a higher feerate than your replacement,\n\u003e he\"ll get it confirmed as fast or faster than your replacement in any\n\u003e case.\n\u003e\n\u003e\n\u003e It actually doesn't really matter much.\n\u003e\n\u003e Let's say I want to pay Alice and Bob (unrelated entities), so I send it to\n\u003e them (together) with a low-fee transaction of paying 50 sat/byte. After an\n\u003e hour it's obvious that it's not confirmed (maybe there was a big backlog, or\n\u003e no blocks mined), so I want to replace my small transaction with one that\n\u003e pays 70 sat/byte.\n\u003e\n\u003e But in the mean time, Alice has swept her wallet (or used a service that has\n\u003e done so) and generated 50KB of descendant transactions paying 40 sat/byte\n\u003e (i.e. total fees of 0.02 BTC or $50).\n\u003e\n\u003e According to the BIP125 rules, I would need to pay for the cost of\n\u003e invalidating all the transactions (an absolute higher amount of fee) along\n\u003e with the replay cost of the descendant transactions.\n\u003e\n\u003e So in this case, for me to fee bump the transaction I'm looking at throwing\n\u003e away $50 because of descendant transactions that were totally out of my\n\u003e control. If I don't fee bump, I violate my promise to Bob to pay in a\n\u003e timely manner (and also probably Alice, as it wasn't in her control she was\n\u003e using an exchange that did this).\n\u003e\n\u003e If I guarantee to fee bump, the amount I risk is effectively unbounded. And\n\u003e even if the descendant transactions have a higher fee rate, and are\n\u003e assisting by CPFP boosting my transaction -- it very well might not be\n\u003e enough.\n\u003e\n\u003e --\n\u003e\n\u003e The idea of this proposal comes from the problems *in practice* of trying to\n\u003e low-ball fee estimation with scheduled continuous fee bumps until it\n\u003e confirms. At the moment it's not viable, but if this proposal was adopted\n\u003e then it would be.\n\u003e\n\u003e Personally I think it's of critical piece of having a stable fee market. Fee\n\u003e estimation is a fools game, even the new and improved fee estimation in\n\u003e master today was suggesting x30 fees to what was required (and I\n\u003e successfully made transactions with). People (and especially services) being\n\u003e able to be able to dynamically increase their fees sanely when dealing with\n\u003e withdrawals (and especially batched ones) will go a long way to helping the\n\u003e overall ecosystem.\n\u003e\n\u003e\n\u003e -Ryan\n\u003e\n\u003e\n\u003e -------- Original Message --------\n\u003e Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable\n\u003e transactions\n\u003e Local Time: July 2, 2017 9:28 PM\n\u003e UTC Time: July 3, 2017 2:28 AM\n\u003e From: greg at xiph.org\n\u003e To: Rhavar \u003crhavar at protonmail.com\u003e\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\n\u003e On Sun, Jul 2, 2017 at 9:01 PM, Rhavar \u003crhavar at protonmail.com\u003e wrote:\n\u003e\u003e That\"s not really realistic. In practice some receivers do big sweeps and\n\u003e\u003e include unconfirmed inputs. Replacing the transaction means you need to\n\u003e\u003e pay\n\u003e\u003e the cost of the sweep, which you probably don\"t want to do (can be in the\n\u003e\u003e order of $100s of dollars).\n\u003e\n\u003e Perhaps I am not following what you\"re saying here.\n\u003e\n\u003e If the receiver is paying a higher feerate than your replacement,\n\u003e he\"ll get it confirmed as fast or faster than your replacement in any\n\u003e case.\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "f372e10056dabdd7c18c4ada9eb5246c0bf0c8481bfda137ae2f5ce6259fda351ff1b3bc69a5f907f474266e826fac4e195274c7a8d63de229a8b11c8b3618e6"
}