{"type":"rich","version":"1.0","author_name":"npub1pmw4p7tz6s8k62zrpdpxc93ajlmpxe0s03j275dcmcejv8wazz9qhe5c0r","author_url":"https://nostr.ae/npub1pmw4p7tz6s8k62zrpdpxc93ajlmpxe0s03j275dcmcejv8wazz9qhe5c0r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-22\n📝 Original message:\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, because\n\u003e it's rare for the inputs to exactly math the requested payment.\n\nIt'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.\n\nAlso 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.\n\nAlso 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.\n\nObviously 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.\n\n---\n\n-Ryan\n\n-------- Original Message --------\nOn January 22, 2018 3:00 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:\n\u003e\n\u003e\u003e So my half-baked idea is very simple:\n\u003e\u003e Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.\n\u003e\u003e This is currently not possible because of the bip125 rule:\n\u003e\u003e \"The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.\"\n\u003e\u003e 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.\n\u003e\u003e 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?\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\u003e ---------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e 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.\n\u003e\u003e From a \"coin selection\" point of view, this was significantly easier than\n\u003e\u003e I had anticipated. I was able to encode the rules in my linear model and\n\u003e\u003e feed in all my unspent and in-flight transactions and it can solve it without difficulty.\n\u003e\u003e However, the real problem is tracking the mess. Consider this sequence of events:\n\u003e\u003e\n\u003e\u003e - I have unconfirmed transaction A\n\u003e\u003e - I replace it with B, which pays John 1 BTC\n\u003e\u003e - Transaction A gets confirmed\n\u003e\u003e\n\u003e\u003e So now I still owe John 1 BTC, however it's not immediately clear if\n\u003e\u003e it's safe to send to him without waiting $n transactions. However even\n\u003e\u003e for a small $n, this breaks my promise to pay him immediately.\n\u003e\u003e 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.\n\u003e\u003e However, this will only work \u003c50% of the time for me (most transactions\n\u003e\u003e don't have change) and opens a pandora's box of complexity.\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, 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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180122/1abc39e2/attachment.html\u003e"}