--- Day changed Sun Oct 27 2019 01:04 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 04:09 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 246 seconds] 04:40 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket 04:50 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 04:51 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket 04:56 < waxwing> belcher, so to continue yesterday's discussion, given the above, do you not think that Amelioration #2 in https://github.com/AdamISZ/JMPrivacyAnalysis/blob/master/tumbler_privacy.md makes some sense? 05:03 < waxwing> Thinking more carefully, I don't understand the logic of the first paragraph in: https://gist.github.com/chris-belcher/7e92810f07328fdfdef2ce444aad0968#add-a-routine-at-the-start-of-the-tumbler-schedule-where-all-mixdepths-are-fully-spent-with-a-no-change-coinjoin 05:04 < waxwing> because, even with sweeps, the taker input is still unambiguously identified. what's different about sweeps is that they 'complete' that mixdepth(account) closure; any later use of the mixdepth is disconnected. 05:04 < waxwing> otherwise i don't see it being different. 05:14 < waxwing> belcher, belcher_ pls check PM (not because it's urgent, just because i'm never sure which one of these is active) 05:37 < waxwing> this old thread is interesting in context. same kind of discussion, really: https://bitcointalk.org/index.php?topic=1609980.msg16168594#msg16168594 06:03 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 240 seconds] 07:13 < belcher> waxwing yes i agree amelioration #2 is a good idea 07:14 < belcher> regarding the logic of that first paragraph, yes indeed even with sweeps the taker's inputs could be identified but sweeps solve the problem of the taker's change being identified 07:17 < belcher> thats an interesting thread, id forgotten about it 07:17 -!- MaxSan [~four@109.202.107.10] has joined #joinmarket 07:22 -!- MaxSan [~four@109.202.107.10] has quit [Ping timeout: 268 seconds] 07:28 < belcher> the code in that thread found the subsets for about a quarter of JM txes it analyzed, compare that with the moser paper which did for about 67% 07:29 < belcher> note that finding subsets of one transaction isnt enough to entirely unmix it, you need to also find the subsets of all the next joinmarket transactions too where those coinjoin outputs get spent 07:31 < belcher> say that each tx has 3 parties and the success rate of 67% is independent, to unmix that tx you also need to find the subsets of 3 further joinmarket transactions so the success probability is (0.67)^4 = 20%... so that very rough calculation is perhaps a reason to be relaxed about finding subsets of inputs and change 07:58 < waxwing> so going back to the sweep idea as per your gist, i still don't really get it. suppose i fund mixdepth 0 with 1btc. then i either (a) do a sweep of ~1btc or (b) do say 2 other txs creating change C1, C2 and a third which is a sweep, what is the exact difference here? C1 and C2 are linked to the deposit, but then they get spent as before (but in more txs), but in either (a) or (b) the 1btc is 'linked' as a whole unit? (not sure if i can express th 07:58 < waxwing> cleanly). 08:00 < waxwing> i sort of mused on this tradeoff in "Amelioration 1". "... mix the advantages of both models: amount de-correlation by means of multiple transactions, and closure mapping de-correlation by means of sweep without closure mapping reuse." 08:02 < waxwing> i get the feeling that your idea is to create a hard break between the tumbler algorithm and whatever funded it. I can *kinda* see that - except for the fixed role business as mentioned, i don't see if it really does that. 08:25 < belcher> yes the aim is to create a hard break and also the second-last paragraph about helping against amount-based tracking. In terms of unlinkability theres no difference between your (a) and (b) examples but the single sweep costs less block space 08:36 < waxwing> well yes the amount based tracking, but the current algo addresses that already, right. it doesn't seem to be specific to exactly, doing 1 sweep first? 08:37 < belcher> it aims to address it, its unclear how well it does and this initial sweep addresses it in another way 08:50 < waxwing> i think i've always been influenced by my own behaviour pattern, but to me the system has a much better function for a 'maker who is sometimes a taker', and indeed that behaviour pattern is a huge 'spanner in the works' for anyone trying to deanonymise anything here. i also don't think it's irrational. 08:51 < waxwing> i mean, fees are low exactly because you get benefit from running a maker, not only costs. and then if you do both roles your maker behaviour subsidises your fees (as per the topic :) ) 08:52 < belcher> yes 08:52 < waxwing> the stuff i put in that tumbler_privacy.md is like a layer above (or just separate) from this discussion though, because it still applies whatever the fees are (even, negative). 09:03 < waxwing> (i shouldn't forget, and should remind others, that we have a customized schedule feature, i.e. people could make up their own algos. i should also test that more!). 09:08 -!- MaxSan [~four@195.206.105.203] has joined #joinmarket 09:35 -!- openoms [~quassel@cpc115066-stok20-2-0-cust313.1-4.cable.virginm.net] has joined #joinmarket 09:40 -!- MaxSan [~four@195.206.105.203] has quit [Ping timeout: 245 seconds] 10:29 -!- MaxSan [~four@195.206.105.203] has joined #joinmarket 10:46 -!- side^effects [~al|iss@gateway/tor-sasl/aliss/x-63218493] has joined #joinmarket 10:59 -!- side^effects [~al|iss@gateway/tor-sasl/aliss/x-63218493] has quit [Quit: side^effects] 11:46 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket 11:57 -!- reallll [~belcher@unaffiliated/belcher] has joined #joinmarket 12:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds] 12:01 -!- reallll is now known as belcher 12:46 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has quit [Ping timeout: 260 seconds] 12:59 -!- technonerd [~techno@gateway/tor-sasl/technonerd] has joined #joinmarket 13:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 13:22 -!- bsm1175321 [~mcelrath@pool-70-109-136-73.cncdnh.east.myfairpoint.net] has quit [Ping timeout: 252 seconds] 15:21 -!- MaxSan [~four@195.206.105.203] has quit [Ping timeout: 265 seconds] 15:30 -!- MaxSan [~four@195.206.105.227] has joined #joinmarket 16:50 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds] 18:48 -!- CgRelayBot [~CgRelayBo@p5DE4A76C.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 18:48 -!- AgoraRelay [~jmrelayfn@p5DE4A76C.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 19:02 -!- CgRelayBot [~CgRelayBo@p54866B19.dip0.t-ipconnect.de] has joined #joinmarket 19:05 -!- AgoraRelay [~jmrelayfn@p54866B19.dip0.t-ipconnect.de] has joined #joinmarket