{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-24\n📝 Original message:On Tue, Jan 23, 2018 at 09:31:00PM +0000, Gregory Maxwell wrote:\n\u003e On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Most transactions don't have change?! Under what circumstance? For most\n\u003e \u003e use-cases the reverse is true: almost all all transactions have change, because\n\u003e \u003e it's rare for the inputs to exactly math the requested payment.\n\u003e \n\u003e It's quite easy to get no change with a not-dumb algorithm selecting\n\u003e coins if you have a decent number of outputs well under the value\n\u003e you're paying.\n\u003e \n\u003e The number of ways n choose m combines grows exponentially, and you\n\u003e only need to get close enough over the right value so that you're\n\u003e paying excess fees equal or less than the cost of the change (which\n\u003e should include the current cost output itself as well as estimated\n\u003e cost of the future signature to spend it).\n\u003e \n\u003e Achow101 and Murch have code to implement an efficient algorithm for\n\u003e finding these solutions for Bitcoin core which will hopefully get in\n\u003e soon.\n\nOh, Bitcoin Core doesn't already do that? I though that was what the (rather\ncomplex) knapsack code was supposed to be doing.\n\nIn any case, you're assuming that there actually are a large number of outputs.\nThat's not likely to be the case in most \"consumer-like\" use-cases where the\nnumber of deposits into the wallet is relatively low compared to the number of\nwithdrawls as coins are spent in smaller amounts; that's the pattern most of my\nBitcoin usage follows, particularly as I keep the amount of funds in my hot\nwallets low.\n\nHaving said that, Rhavar's usage patterns could easily be different; I'd be\ncompletely wrong in the case of a payment service for instance where a large\nnumber of deposits are aggregated into a smaller number of payments; that\nuse-case happens to be a particularly interesting one for using tx replacement\nto add outputs, so my criticism was definitely premature.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180124/e656471f/attachment.sig\u003e"}