📅 Original date posted:2018-01-23
📝 Original message:Another way to limit abuse would be to have the fee *rate* be required to
increase, which is kind of the spirit of RBF, applied to this situation.
That is to say, if you wished to replace transactions A and B with C which
spends the same inputs as A and B, then the following must be true before C
will be relayed:
(Fee_A + Fee_B) / (Weight_A + Weight_B) < Fee_C / Weight_C
On Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Getting back on topic:
>
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth.
>
>
> I think I'm missing something, as I don't really understand this DoS
> vector. Relay bandwidth is already very cheap and easy to use by repeatedly
> fee bumping. And it's not obvious to me that requiring an absolute higher
> fee actually makes such an attack more expensive.
>
> I can see that my "proposed" change would make it cheaper to evict low-fee
> transactions from other node's mempool. Maybe I'm being naive, but I don't
> really see why this would be such a big deal.
>
> But what about a compromise, and require that the absolute fee must be >=
> half the original fees. I know everyone hates magic values, but I think in
> practice it will allow legitimate and useful use of "retroactive
> transaction merging" without much downside.
>
> And really the great thing about "retroactive transaction merging" is just
> how easy it is to implement. In fact, right now it's quite possible to do
> -- but because of the "higher absolute fee" rule the benefits are pretty
> muted (although if you can compress 2 change into 1, that's still likely
> worthwhile)
>
>
>
> -Ryan
>
>
> -------- Original Message --------
> On January 22, 2018 3:00 PM, Peter Todd <pete at petertodd.org> wrote:
>
> On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
>
> So my half-baked idea is very simple:
> Allow users to merge multiple unconfirmed transactions, stripping
> extraneous inputs and change as they go.
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum paid
> by the original transactions."
> Because the size of the merged transaction is smaller than the original
> transactions, unless there is a considerable feerate bump, this rule isn't
> possible to observe.
> I my question is: is it possible or reasonable to relax this rule? If this
> rule was removed in its entirety, does it introduce any DoS vectors? Or can
> it be changed to allow my use-case?
>
>
> It would definitely introduce DoS vectors by making it much cheaper to use
> relay bandwidth. You'd also be able to push others' txs out of the mempool.
>
>
> ------------------------------
>
> Full backstory: I have been trying to use bip125 (Opt-in Full
> Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I
> owe John 1 bitcoin, and have promised to pay him immediately: Instead of
> creating a whole new transaction if I have an in-flight (unconfirmed)
> transaction, I can follow the rules of bip125 to create a replacement that
> accomplishes this goal.
> From a "coin selection" point of view, this was significantly easier than
> I had anticipated. I was able to encode the rules in my linear model and
> feed in all my unspent and in-flight transactions and it can solve it
> without difficulty.
> However, the real problem is tracking the mess. Consider this sequence of
> events:
>
> 1. I have unconfirmed transaction A
> 2. I replace it with B, which pays John 1 BTC
> 3. Transaction A gets confirmed
>
> So now I still owe John 1 BTC, however it's not immediately clear if
> it's safe to send to him without waiting $n transactions. However even
> for a small $n, this breaks my promise to pay him immediately.
> One possible solution is to only consider a transaction "replaceable" if
> it has change, so if the original transaction confirms -- payments can
> immediately be made that source the change, and provide safety in a reorg.
> However, this will only work <50% of the time for me (most transactions
> don't have change) and opens a pandora's box of complexity.
>
>
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change,
> because
> it's rare for the inputs to exactly math the requested payment.
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/bded9fb7/attachment.html>;
Moral Agent [ARCHIVE] /
npub1gh…gc6pd
2023-06-07 18:09:57
in reply to nevent1q…muc7
Author Public Key
npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pdPublished at
2023-06-07 18:09:57Event JSON
{
"id": "4991d725cd5abb0bce08e25e5ea78358ae3b967917f72497d3b9674ca100e2e9",
"pubkey": "45fe5a57f42bb740cd879288f26f61d357e7d8ca7c7d97e9dd6278bf2257d1ee",
"created_at": 1686161397,
"kind": 1,
"tags": [
[
"e",
"d590d99f0e59a3ab6f27c432eb817e5977c68b50eee604d754c0603c2eeb8762",
"",
"root"
],
[
"e",
"357374fb71125276cc7428b66f6b54e7426af0c5c346c5b11890dbdeadaca4bb",
"",
"reply"
],
[
"p",
"0edd50f962d40f6d28430b426c163d97f61365f07c64af51b8de33261ddd108a"
]
],
"content": "📅 Original date posted:2018-01-23\n📝 Original message:Another way to limit abuse would be to have the fee *rate* be required to\nincrease, which is kind of the spirit of RBF, applied to this situation.\n\nThat is to say, if you wished to replace transactions A and B with C which\nspends the same inputs as A and B, then the following must be true before C\nwill be relayed:\n\n(Fee_A + Fee_B) / (Weight_A + Weight_B) \u003c Fee_C / Weight_C\n\nOn Tue, Jan 23, 2018 at 11:31 AM, Rhavar via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Getting back on topic:\n\u003e\n\u003e\n\u003e It would definitely introduce DoS vectors by making it much cheaper to use\n\u003e relay bandwidth.\n\u003e\n\u003e\n\u003e I think I'm missing something, as I don't really understand this DoS\n\u003e vector. Relay bandwidth is already very cheap and easy to use by repeatedly\n\u003e fee bumping. And it's not obvious to me that requiring an absolute higher\n\u003e fee actually makes such an attack more expensive.\n\u003e\n\u003e I can see that my \"proposed\" change would make it cheaper to evict low-fee\n\u003e transactions from other node's mempool. Maybe I'm being naive, but I don't\n\u003e really see why this would be such a big deal.\n\u003e\n\u003e But what about a compromise, and require that the absolute fee must be \u003e=\n\u003e half the original fees. I know everyone hates magic values, but I think in\n\u003e practice it will allow legitimate and useful use of \"retroactive\n\u003e transaction merging\" without much downside.\n\u003e\n\u003e And really the great thing about \"retroactive transaction merging\" is just\n\u003e how easy it is to implement. In fact, right now it's quite possible to do\n\u003e -- but because of the \"higher absolute fee\" rule the benefits are pretty\n\u003e muted (although if you can compress 2 change into 1, that's still likely\n\u003e worthwhile)\n\u003e\n\u003e\n\u003e\n\u003e -Ryan\n\u003e\n\u003e\n\u003e -------- Original Message --------\n\u003e On January 22, 2018 3:00 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e\n\u003e On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:\n\u003e\n\u003e So my half-baked idea is very simple:\n\u003e Allow users to merge multiple unconfirmed transactions, stripping\n\u003e extraneous inputs and change as they go.\n\u003e This is currently not possible because of the bip125 rule:\n\u003e \"The replacement transaction pays an absolute fee of at least the sum paid\n\u003e by the original transactions.\"\n\u003e Because the size of the merged transaction is smaller than the original\n\u003e transactions, unless there is a considerable feerate bump, this rule isn't\n\u003e possible to observe.\n\u003e I my question is: is it possible or reasonable to relax this rule? If this\n\u003e rule was removed in its entirety, does it introduce any DoS vectors? Or can\n\u003e it be changed to allow my use-case?\n\u003e\n\u003e\n\u003e It would definitely introduce DoS vectors by making it much cheaper to use\n\u003e relay bandwidth. You'd also be able to push others' txs out of the mempool.\n\u003e\n\u003e\n\u003e ------------------------------\n\u003e\n\u003e Full backstory: I have been trying to use bip125 (Opt-in Full\n\u003e Replace-by-Fee) to do \"transaction merging\" on the fly. Let's say that I\n\u003e owe John 1 bitcoin, and have promised to pay him immediately: Instead of\n\u003e creating a whole new transaction if I have an in-flight (unconfirmed)\n\u003e transaction, I can follow the rules of bip125 to create a replacement that\n\u003e accomplishes this goal.\n\u003e From a \"coin selection\" point of view, this was significantly easier than\n\u003e I had anticipated. I was able to encode the rules in my linear model and\n\u003e feed in all my unspent and in-flight transactions and it can solve it\n\u003e without difficulty.\n\u003e However, the real problem is tracking the mess. Consider this sequence of\n\u003e events:\n\u003e\n\u003e 1. I have unconfirmed transaction A\n\u003e 2. I replace it with B, which pays John 1 BTC\n\u003e 3. Transaction A gets confirmed\n\u003e\n\u003e So now I still owe John 1 BTC, however it's not immediately clear if\n\u003e it's safe to send to him without waiting $n transactions. However even\n\u003e for a small $n, this breaks my promise to pay him immediately.\n\u003e One possible solution is to only consider a transaction \"replaceable\" if\n\u003e it has change, so if the original transaction confirms -- payments can\n\u003e immediately be made that source the change, and provide safety in a reorg.\n\u003e However, this will only work \u003c50% of the time for me (most transactions\n\u003e don't have change) and opens a pandora's box of complexity.\n\u003e\n\u003e\n\u003e Most transactions don't have change?! Under what circumstance? For most\n\u003e use-cases the reverse is true: almost all all transactions have change,\n\u003e because\n\u003e it's rare for the inputs to exactly math the requested payment.\n\u003e\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180123/bded9fb7/attachment.html\u003e",
"sig": "557ff532120c9f83761e9f5c9902123f3a866d4a675e89544e1d33defb1877ff77692ebe40ed4b2857ea5960a3ebbab7de2cf8aa82116f256434eca175757472"
}