📅 Original date posted:2019-06-14
📝 Original message:"David A. Harding" <dave at dtrt.org> writes:
> On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:
>> If that's true, I don't think this proposal makes it worse.
>
> Here's a scenario that I think shows it being at least 20x worse.
[ Snip ]
Indeed :(
To be fair, if I have a transaction of median size (250 bytes) and I use
the current estimatefee 2 of '0.00068325' I get to replace is 68 times;
that's $0 for an additional 1GB across all nodes.
So, I don't think the current rules are sufficient. But I understand
the desire not to make things worse. I'll roll in some changes and
re-propose.
> It's already hard for wallet software to determine whether or not its
> transactions have successfully been relayed.
As the deadline approaches, a lightning wallet would RBF with increasing
desparation until it gets into a block. It doesn't really matter *why*
the tx isn't going through, there's nothing else it can do.
> This proposal requires LN
> wallets not only be able to guess where the next-block feerate boundary
> is in other nodes' individual mempools (now and in the future for the
> time it takes the transaction to propagate to ~100% of miners), but it
> possibly requires that under the condition that the LN wallet can't
> guess too low because it might not get another chance for relay in the
> limited time available before contract expiration.
I think you mean any proposal which relies on a deadline? If so, that
bus has already left.
When you see a block you can guess the fees required for the next block.
You need some smoothing to avoid wild spikes, but in practice you can
start this "desperation mode" 10 blocks before your deadline.
Without RBF changes, it needs to assume that it needs to replace a
400kSipa tx @ feerate-for-next-block. With some RBF change, it need
only replace @feerate-for-next-block.
> Considered that way, I worry that these constraints produce a recipe for
> paying extremely high feerates. If that's an actual risk, is that
> actually significantly better than dealing with the existing transaction
> pinning issue where one needs to pay a high total fee in order to evict
> a bunch of junk descendents? Paying lots of fees may not be the optimal
> solution to the problem of having to pay lots of fees. :-)
I don't understand this at all, sorry.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 18:18:33
in reply to nevent1q…zag9
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 18:18:33Event JSON
{
"id": "99979ea8beaa8db45954f9522c6082681684bf5bc70b06b97816f02a763d3903",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686161913,
"kind": 1,
"tags": [
[
"e",
"4ed6b3bfac83a99a462d959ed4b694df66ad2dfbc9892c6468b3b5ef5318cefd",
"",
"root"
],
[
"e",
"2353c693169df136c2b984acf7f6c224b3f943b7bffa773c45c1a80f1bfde37a",
"",
"reply"
],
[
"p",
"47ed572f0827eaf63c4354055640c8a61ef11a2948d31eec71d2828345386c4a"
]
],
"content": "📅 Original date posted:2019-06-14\n📝 Original message:\"David A. Harding\" \u003cdave at dtrt.org\u003e writes:\n\u003e On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote:\n\u003e\u003e If that's true, I don't think this proposal makes it worse.\n\u003e\n\u003e Here's a scenario that I think shows it being at least 20x worse.\n\n[ Snip ]\n\nIndeed :(\n\nTo be fair, if I have a transaction of median size (250 bytes) and I use\nthe current estimatefee 2 of '0.00068325' I get to replace is 68 times;\nthat's $0 for an additional 1GB across all nodes.\n\nSo, I don't think the current rules are sufficient. But I understand\nthe desire not to make things worse. I'll roll in some changes and\nre-propose.\n\n\u003e It's already hard for wallet software to determine whether or not its\n\u003e transactions have successfully been relayed.\n\nAs the deadline approaches, a lightning wallet would RBF with increasing\ndesparation until it gets into a block. It doesn't really matter *why*\nthe tx isn't going through, there's nothing else it can do.\n\n\u003e This proposal requires LN\n\u003e wallets not only be able to guess where the next-block feerate boundary\n\u003e is in other nodes' individual mempools (now and in the future for the\n\u003e time it takes the transaction to propagate to ~100% of miners), but it\n\u003e possibly requires that under the condition that the LN wallet can't\n\u003e guess too low because it might not get another chance for relay in the\n\u003e limited time available before contract expiration.\n\nI think you mean any proposal which relies on a deadline? If so, that\nbus has already left.\n\nWhen you see a block you can guess the fees required for the next block.\nYou need some smoothing to avoid wild spikes, but in practice you can\nstart this \"desperation mode\" 10 blocks before your deadline.\n\nWithout RBF changes, it needs to assume that it needs to replace a\n400kSipa tx @ feerate-for-next-block. With some RBF change, it need\nonly replace @feerate-for-next-block.\n\n\u003e Considered that way, I worry that these constraints produce a recipe for\n\u003e paying extremely high feerates. If that's an actual risk, is that\n\u003e actually significantly better than dealing with the existing transaction\n\u003e pinning issue where one needs to pay a high total fee in order to evict\n\u003e a bunch of junk descendents? Paying lots of fees may not be the optimal\n\u003e solution to the problem of having to pay lots of fees. :-)\n\nI don't understand this at all, sorry.\n\nCheers,\nRusty.",
"sig": "fc614f5a9de3d466fe981d9a11bb0812b8faaec67e346a9b07fffc36fb13f179c6fce500c6290c6cdf98a82ebf884cc123c317f164e8c78b5b97fb32678225d2"
}