combat dust thru utxo merge policies #173
Conversation
adlai
changed the title
|
Nice PR. Testing... |
|
I will also test. Hopefully it can deprecate my pycoin reallocation tool. |
|
I realise there's a few different meaning to dust in bitcoin.
Unless I'm wrong, these new utxo selection algos solve the problem of 3. because 1. is already solved and 2. cant be solved yet as joinmarket miner fees are broken. |
|
@chris-belcher That is correct, currently. I, for one, would vote to include this code though, as I am one that find those small outputs annoying. If I am not mistaken, having more and smaller outputs eventually contributes to more bandwidth usage and larger blockchain size over time, no? I understand that is not an issue to be solved within scope of joinmarket, but we may as well not contribute to the issue. @adlai Code is good so far, no issues with it over the last couple days. |
|
OK yes @CohibAA it's true that combining together lots of small outputs will reduce the size of the UTXO set, which cant be pruned without some new fancy crypto. On the downside, combining together more outputs links them and provides evidence of common ownership to anyone looking at the blockchain. So I don't think it's a good idea to encourage it. For dust of type 2. I've written about a possible solution here https://gist.github.com/chris-belcher/27b1743ba63e34736863 @tailsjoin whats your pycoin reallocation tool? Maybe tell me by email or start an issue about dust. |
|
Outputs are only ever linked from within a single mixdepth; the current privacy model assumes that these are already linkable, so no privacy is lost by signing them into the same transaction. Dust must eventually be swept, and this approach allows some granularity over the manner in which this sweeping is done, although doing a single Most importantly, default behavior is unchanged. |
|
Rebased onto latest master. I still don't see why this shouldn't be merged: it doesn't change default behavior, and only merges within a single depth, leaving the privacy model intact. |
- adds an optional config section: [POLICY] - adds a merge_algorithm option in the new section - two sample merge algorithms are provided, beyond the default: + select_gradual still makes small transactions, clearing dust patiently + select_greedy collects dust as quickly as practical
|
I'd add that the default behaviour it's a factory of dust (when it is possible it always use 1 input and the output are 2). Why do not change the default behaviour? |
combat dust thru utxo merge policies
|
@the9ull I believe it's fairer towards users that new behavior is enabled through opt-in rather than opt-out. |
combat dust thru utxo merge policies
combat dust thru utxo merge policies
|
If I understand the privacy model based on mixing depths correctly, then a higher mixing depth usually means a higher level of uncertainty regarding the origin of the utxos, right? Wouldn't it then make sense to have different merge policies for different mixing depths? For example: sorry, probably should have commented in #91 instead. |
|
@MMMonsterrr that's somewhat true for the tumbler, depending on in which mixing level the user first deposited their coins. But for the yield generator which is what this thread is mostly about, the mixing levels are circular, after level 4 it goes back to level 0. So it probably makes no difference. |
|
Oh okay, I didn't know that. But even then, the yield generator would still work, even with these depth dependent policies. STRICT might be a bit annoying in that case though, so maybe the circular jump should go from 4 to 1 instead in that case? Anyway, was just a thought :) |
combat dust thru utxo merge policies [gitreformat yapf-ify (github/ghtdak) on Fri Dec 4 04:51:20 2015] [from commit: 6f3a98c]
cf #91