Along the same lines, I wonder if unrelated people with tx that are not confirming could cooperate to merge their disparate tx into a CoinJoin tx with a higher fee rate? Perhaps they could even replace old tx with economically equivalent summary transactions? The mempool seems like nature's accumulator for pre-mining compression opportunities. On Mon, Jan 22, 2018 at 1:18 PM, Rhavar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > If you spent your change from transaction A, that would be safe. There'd > be no way you John could end up with 2 BTC from you then. > > Yes, that's what the following paragraph says -- along with it's > limitations =) > > -Ryan > > > -------- Original Message -------- > On January 22, 2018 1:16 PM, Alan Evans wrote: > > > So now I still owe John 1 BTC, however it's not immediately clear if it's > safe to send to him > > If you spent your change from transaction A, that would be safe. There'd > be no way you John could end up with 2 BTC from you then. > > On Mon, Jan 22, 2018 at 1:40 PM, Rhavar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> 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? >> >> >> --- >> 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. >> >> There's a few other hacks you can do to make it work in a few more cases, >> but nothing that is realistic to expect anyone to implement any time soon. >> >> However, if there was a straight foward way to merge N unconfirmed >> transactions, it would be easy get into production, and potentially offer >> some pretty nice savings for everyone. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >