📅 Original date posted:2017-07-03
📝 Original message:> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170702/a1b04eb8/attachment.html>;
Rhavar [ARCHIVE] /
npub1pm…e5c0r
2023-06-07 18:03:47
in reply to nevent1q…djwh
Author Public Key
npub1pmw4p7tz6s8k62zrpdpxc93ajlmpxe0s03j275dcmcejv8wazz9qhe5c0rPublished at
2023-06-07 18:03:47Event JSON
{
"id": "a10f9f81f8a02606da2c7cecb6a5c9f90d77b584b2aae1e00f79a2114a492290",
"pubkey": "0edd50f962d40f6d28430b426c163d97f61365f07c64af51b8de33261ddd108a",
"created_at": 1686161027,
"kind": 1,
"tags": [
[
"e",
"6ae908cbd0a9f12abff6467fd3d89eab09bcc74de9ac35cd83e3048488dcab93",
"",
"root"
],
[
"e",
"39630b867a8ea143e49e62a452bd9a444827574bba5c996ca78d5b68eafc3d30",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-07-03\n📝 Original message:\u003e Perhaps I am not following what you\"re saying here.\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\nIt actually doesn't really matter much.\nLet'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.\nBut 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).\nAccording 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.\nSo 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).\nIf 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.\n--\nThe 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.\nPersonally 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.\n\n-Ryan\n\n\u003e -------- Original Message --------\n\u003e Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable 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 \u003cbitcoin-dev at lists.linuxfoundation.org\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 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 Perhaps I am not following what you\"re saying here.\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170702/a1b04eb8/attachment.html\u003e",
"sig": "a83d509f6e23b4d36fbcd75134b4cf15967dbbf3ccc4f1d18d61907b7bc1f1ef98588ab4b975fcc3a71ac333750b96e0f9d87289a45c84ecd2e7613313a23ffc"
}