<div>&gt;&nbsp;Most transactions don't have change?! Under what circumstance? For most<br></div><div>&gt; use-cases the reverse is true: almost all all transactions have change, because<br></div><div>&gt; it's rare for the inputs to exactly math the requested payment.<br></div><div><br></div><div>It's actually a common misconception. With good coin selection, I am able to avoid change about ~75% of the time in my simulations (on my real world data). In practice it's a bit lower, probably about 40-50% of the time because of the need to keep the majority of my funds offline where they can't be used for coin selection, and I have not been able to accurate simulate how I consolidate.&nbsp;<br></div><div><br></div><div>Also the other misconception is that inputs don't need to match exactly the requested payment, it's totally fine to do something I call a "miner sacrifice" where you overpay txfees up to the amount that that would otherwise be the total cost (immediate + consolidation) of creating change.<br></div><div><br></div><div>Also another trick I use, is something I call "output selection". If I have N queued non-time sensitive payments, I don't really need to send them all at the same time. So I can pick the best combination of inputs+outputs.<br></div><div><br></div><div>Obviously none of this applies to consumer wallets, who typically have less than a handful of options. But for a service, avoiding change can be the norm with good coin selection.<br></div><div><br></div><div>---<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>-Ryan<br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><div>-------- Original Message --------<br></div><div> On January 22, 2018 3:00 PM, Peter Todd &lt;pete@petertodd.org&gt; wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div>On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:<br></div><blockquote><div>So my half-baked idea is very simple:<br></div><div>Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.<br></div><div><div>This is currently not possible because of the bip125 rule:<br></div><div> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."<br></div></div><div>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.<br></div><div>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?<br></div></blockquote><div><div>&nbsp;<br></div><div> It would definitely introduce DoS vectors by making it much cheaper to use<br></div><div> relay bandwidth. You'd also be able to push others' txs out of the mempool.<br></div><div> &nbsp;<br></div></div><blockquote><div><hr><br></div><div>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.<br></div><div><div>From a "coin selection" point of view, this was significantly easier than<br></div><div> I had anticipated. I was able to encode the rules in my linear model and<br></div><div> feed in all my unspent and in-flight transactions and it can solve it without difficulty.<br></div></div><div>However, the real problem is tracking the mess. Consider this sequence of events:<br></div><ol><li>I have unconfirmed transaction A<br></li><li>I replace it with B, which pays John 1 BTC<br></li><li>Transaction A gets confirmed<br></li></ol><div><div>So now I still owe John 1 BTC, however it's not immediately clear if<br></div><div> it's safe to send to him without waiting $n transactions. However even<br></div><div> for a small $n, this breaks my promise to pay him immediately.<br></div></div><div>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.<br></div><div><div>However, this will only work &lt;50% of the time for me (most transactions<br></div><div> don't have change) and opens a pandora's box of complexity.<br></div></div></blockquote><h2><div>&nbsp;<br></div><div> Most transactions don't have change?! Under what circumstance? For most<br></div><div> use-cases the reverse is true: almost all all transactions have change, because<br></div><div> it's rare for the inputs to exactly math the requested payment.<br></div><div> &nbsp;<br></div></h2><div><a href="https://petertodd.org">https://petertodd.org</a> 'peter'[:-1]@petertodd.org<br></div></blockquote><div><br></div>