rich1.0npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pdhttps://nostr.ae/npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pdnjumphttps://nostr.ae📅 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>