--- Day changed Wed Dec 05 2018 01:38 -!- Giszmo [~leo@168.196.203.86] has joined #joinmarket 01:38 -!- Giszmo [~leo@168.196.203.86] has quit [Client Quit] 01:55 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket 02:49 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 03:21 < waxwing> Lightsword, could you squash before I merge? thanks 04:41 < waxwing> i guess i should have noted somewhere that i've been testing with python3.5 and python3.6 .. difference between them being whatever is default on my 1604 ubuntu and 1804 ubuntu. what's the latest, i think there's a 3.7? 04:42 < waxwing> what's the chance that different py3 versions could cause issues? 04:44 < Sentineo> I have 3.6.7 on 18.04 system, if that was the question :) 04:45 < belcher> python 3.6 has an added feature called f-strings, so if you use them then the source files wont work on <3.6 04:45 < belcher> probably other added features too, but either way as long as you dont use very new features it should be fine 04:46 < waxwing> right. i wonder what the lowest valid version of py3 is. 04:47 < waxwing> i know some people run on very conservative systems with very old versions of things. 04:50 < undeath> requireing py3.5 should be ok 06:49 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3] 08:18 -!- mr_paz_ [~mr_paz@84.39.112.83] has joined #joinmarket 09:04 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 09:30 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 09:31 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 10:41 < Lightsword> waxwing, rebased 10:42 < Lightsword> I was testing against 3.5 myself 11:00 -!- Giszmo [~leo@pc-73-164-161-190.cm.vtr.net] has joined #joinmarket 11:06 -!- GitHub27 [GitHub27@gateway/service/github.com/x-eqczaqzqbtnqjsnj] has joined #joinmarket 11:06 < GitHub27> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fp12W 11:06 < GitHub27> joinmarket-clientserver/master 6dc3504 James Hilliard: Convert jmclient to py3 style 11:06 < GitHub27> joinmarket-clientserver/master e70519a AdamISZ: Merge #241: Convert jmclient to py3 style... 11:06 -!- GitHub27 [GitHub27@gateway/service/github.com/x-eqczaqzqbtnqjsnj] has left #joinmarket [] 11:06 -!- GitHub186 [GitHub186@gateway/service/github.com/x-hxrjpszqmmixhvgs] has joined #joinmarket 11:06 < GitHub186> [joinmarket-clientserver] AdamISZ closed pull request #241: Convert jmclient to py3 style (master...future) https://git.io/fpVeP 11:06 -!- GitHub186 [GitHub186@gateway/service/github.com/x-hxrjpszqmmixhvgs] has left #joinmarket [] 11:58 < Lightsword> waxwing, any idea what might be causing this failure? I’ve seen it pop up somewhat randomly a few times and rerunning generally fixes it https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/463994090 11:59 < waxwing> Lightsword, yes, it's a source of serious annoyance - because I was sure I'd fixed it! Somehow it crept back in. I'll have to do some digging to figure it out. 12:11 -!- Giszmo [~leo@pc-73-164-161-190.cm.vtr.net] has quit [Quit: Leaving.] 12:39 < waxwing> ok actually reading it properly, i see it's something different, and actually quite simple to fix. thanks for prodding me, i kept putting it off :) 12:49 -!- GitHub25 [GitHub25@gateway/service/github.com/x-sqdzfwddwezodzts] has joined #joinmarket 12:49 < GitHub25> [joinmarket-clientserver] AdamISZ pushed 1 new commit to master: https://git.io/fp1X7 12:49 < GitHub25> joinmarket-clientserver/master 19fbef1 AdamISZ: Fix nondeterministic failure in test tumbler tweak... 12:49 -!- GitHub25 [GitHub25@gateway/service/github.com/x-sqdzfwddwezodzts] has left #joinmarket [] 13:07 -!- mr_paz_ [~mr_paz@84.39.112.83] has quit [Ping timeout: 250 seconds] 13:08 < Lightsword> waxwing, btw what’s the reason for using bencoder for wallets? wouldn’t just using sqlite make more sense? 13:09 -!- mr_paz_ [~mr_paz@185.156.175.181] has joined #joinmarket 13:09 < undeath> sqlite is such a complicated format 13:10 < Lightsword> undeath, the format itself or the interface? 13:10 < undeath> bencode is simple and supports binary data, it was an overall upgrade to json, which was used before 13:10 < undeath> the format itself 13:10 < Lightsword> why does that matter? 13:10 < undeath> I like to understand what's going on :P 13:11 < undeath> and it didn't occur to me to use sqlite and I'm unsure about the advantages 13:12 < Lightsword> well sqlite is extremely well tested and resistant to forms of corruption that other simpler formats are not 13:12 < undeath> since our data is encrypted, corruption is going to break everything anyway 13:13 < belcher> i didnt review the wallet code at the time, but what was the reason for moving away from json? 13:13 < undeath> json doesn't support binary data 13:14 < belcher> which binary data does the wallet use? 13:14 < undeath> well, if you don't hex-encode everything… everything :P 13:14 < belcher> ok 13:15 < Lightsword> undeath, AFAIK sqlite has built in anti-corruption for things like poweroff and other application crashes 13:15 < belcher> sqlite is used for storing the orderbook in memory, since i thought it might grow very large, but that ended up not happening (but there's still time for more adoption!) 13:16 < undeath> Lightsword: the wallet is never "hot-changed" and encrypting the db will make the anti-corruption useless 13:16 < Lightsword> sqlite is generally what most wallets use for their on disk storage(well other than bitcoin core but that’s for legacy reasons) 13:17 < undeath> what wallets do use sqlite? 13:17 < Lightsword> undeath, anti-corruption prevents corruption using things like journals, so I don’t see why that wouldn’t work for encryption as well 13:18 < undeath> if your encrypted data on disk gets damaged you will receive garbage when decrypting 13:18 < undeath> because CBC 13:18 < Lightsword> undeath, you wouldn’t encrypt the file, you would encrypt the data that’s inserted into it 13:19 < undeath> that sounds like a lot of overhead 13:19 < undeath> a new iv for every single key? 13:19 < undeath> what wallets do use sqlite for wallet storage? 13:20 < Lightsword> here’s one example https://github.com/ciphrex/mSIGNA 13:21 < undeath> any popular ones? :P 13:23 < Lightsword> undeath, I think breadwallet does as well 13:24 < undeath> if they do they're not importing it 13:24 < Lightsword> https://github.com/breadwallet/breadwallet-ios/blob/e205f8b1e3fe1df26c8e494db52f8406d687398a/breadwallet/src/CoreDatabase.swift 13:25 < undeath> ah, not in their c lib 13:27 < undeath> but when looking at that code I'm not sure you can convince me sqlite is superior to bencode 13:28 < undeath> the python dict we have to store data in is incredibly easy to use 13:30 < Lightsword> well it can make runtime updates easier 13:31 < undeath> what kind of runtime updates? 13:31 < Lightsword> would probably be useful for metadata 13:32 < undeath> oh, you mean updating the db during runtime 13:32 < Lightsword> yeah 13:33 < undeath> the only thing joinmarket needs to update is the key indices, and they are still recoverable 13:34 < undeath> but not having to rewrite the whole file every time is an advantage, true 13:36 < Lightsword> undeath, there’s probably other useful things that could be done with it such as UTXO metadata which could be used for improving privacy in regards to UTXO selection 13:37 < undeath> utxos are currently not stored at all 13:38 < Lightsword> yeah, would have to store those as well 13:38 < undeath> the backend supports storing them, but there was no use in doing so, since we sync on start anyway 13:39 < undeath> and that is bound to be more accurate than the stored entries 13:39 < Lightsword> thinking may be good to tag UTXO’s in some way to indicate how well mixed they are or something like that 13:39 < undeath> that's done using the mixdepths 13:40 < undeath> there is no need to save that for individual utxos because we know it from the scripts they belong to 13:43 < Lightsword> undeath, well things get tricky when spending from different mix depths and also using a yield generator I think 13:43 < undeath> in what way? 13:44 < undeath> spending from multiple different mixdepths is generally not what you should do 13:45 < Lightsword> undeath, well say you have a bunch of utxo’s in mix depth 4 that has been running as a yield generator and you then want to spend some of the coins in multiple transactions, it would be useful it there was a way to have the wallet prioritise utxo’s that have been in many maker transactions vs ones that may have recently been spent as a taker 13:48 < undeath> all transactions in mixdepth 4 have been through at least four coinjoins each (as cj-output, not change) 13:49 < Lightsword> undeath, when spending from say mixdepth 4 as a taker the change goes back into mixdepth 4 right? 13:49 < undeath> yes 13:49 < undeath> your change can be tainted 13:49 < Lightsword> undeath, so you would want to tax that change utxo potentially to avoid immediate reuse if you need to spend from mixdepth 4 again 13:49 < Lightsword> want to tag* 13:50 < undeath> your change can potentially always be tracked back to any change you had in that mixdepth 13:50 < undeath> using change outputs isn't really safe 13:51 < undeath> not if you have used another change output from the same mixdepth before for anything 13:51 < undeath> that's actually why I wrote #246 13:51 < belcher> iv been vaguely thinking it might be nice to mark addresses that have been used before, to stop dusting probe attacks 13:52 < Lightsword> undeath, once the change gets used in a few maker transactions it’s then generally going to be safe right? 13:52 < belcher> but those attacks dont work very well with coinjoin anyway... also maybe you dont need to store any metadata to do this 13:52 < undeath> no, the remainder will (almost) always be able to be linked to your previous change 13:53 < Lightsword> in what way? 13:54 < undeath> assume a n-2 cj with cj value 100 and inputs (90, 30, 60, 190) and outputs (100, 100, 20, 150) 13:54 < undeath> now go figure what input's have what change output 13:55 < undeath> it's a bit more complicated in reality due to fees but it still works pretty well in practice 13:56 < belcher> i think Lightsword is talking about the situation with more than one coinjoin 13:56 < undeath> well, still 13:56 < undeath> if you can link the 20 to (90, 30) you can also link the next change output to the 20 13:57 < Lightsword> I think it gets significantly more difficult the more utxo’s you have in the mixdepth being used in maker transactions 13:57 < belcher> in that old paper about joinmarket the authors were only able to do that for about 60% of coinjoins 13:57 < belcher> because equal input amounts come up surprisingly often it seems 13:58 < undeath> only 60%? wow 13:58 < belcher> actually ill check that, i could be bsing 13:58 < undeath> that's surprising 13:58 < belcher> well imagine if there was a 7-party coinjoin, thats 7 utxos created with exactly the same amounts 13:58 < belcher> if the taker uses one or two of those makers for another coinjoin, they might use those utxos 13:59 < undeath> we're talking about change only 13:59 < Lightsword> this would be why one would want utxo metadata, so that change isn’t used in privacy damaging ways based on various factors such as how many parties there are and how many maker transactions the utxo’s have been in since last spend 13:59 < belcher> coinjoin outputs still get used as inputs though 13:59 < undeath> yes, but you can still usually link change outputs to the new change outputs 14:00 -!- mr_paz_ [~mr_paz@185.156.175.181] has quit [Ping timeout: 240 seconds] 14:00 < undeath> even if you can not link all input transactions to a specific change output 14:00 < undeath> *change output 14:00 < Lightsword> even with 5 party maker transactions with the maker selecting their inputs from say a dozen different utxo’s at that mixdepth? 14:00 < belcher> right ok 14:02 < undeath> doesn't matter from how many utxos you select your inputs 14:03 < belcher> it seems i remembered wrong, the "join me on a market for anonymity" paper doesnt contain the figure i was thinking of 14:03 < undeath> unless you manage to input the same amount as another participant (which isn't really possible because as a maker you don't see others' inputs until you get the final tx) your change outputs can be linked 14:04 < undeath> it may be possible that, on coincident, mulitple subsets of inputs can be linked to two or more very similar change outputs 14:04 < undeath> but that's nothing I would bank my anonymity assumptions on 14:05 < undeath> using change isn't safe if you do it more than once 14:05 < undeath> or using change on a mixdepth where you deposited to ofc 14:06 < Lightsword> so you’d want to ensure change is tagged to prevent reuse then right? 14:07 < undeath> yes 14:07 < undeath> and preferably also never put back change from sweeps back into the wallet 14:08 < undeath> (meaning 0 hop sweeps) 14:08 < belcher> what do you mean by sweeps? 14:08 < belcher> sweeps dont have change, by definition? 14:08 < undeath> i mean directly spending from an address 14:09 < undeath> sorry, wrong term 14:09 < belcher> oh you mean, non-coinjoin spending 14:09 < undeath> yes 14:09 < Lightsword> undeath, so what’s the proper way to delink the change output? 14:09 < belcher> spend it in some coinjoins that dont have change 14:09 < belcher> (there might be other ways) 14:09 < belcher> this area could use more study i guess 14:10 < undeath> i wonder how well it would work to link the inputs in that case using subset sum 14:10 < undeath> assuming you only do a single cj 14:10 < belcher> tumbler.py aims to do lots of coinjoins of varying amounts but which all end in a sweep 14:11 < belcher> so ideally it isnt just one cj 14:11 < undeath> yes, de-linking taintable change outputs is not trivial 14:12 < Lightsword> I’m thinking how best to maker utxo selection is done to improve privacy and how to avoid using bad change outputs when spending utxo’s then as a taker, the mixdepth model doesn’t seem to really do that properly 14:12 < undeath> so yes, what belcher says, you'd probably have to run them in tumbler.py to sufficiently de-link them again 14:13 < belcher> for privacy you always need multiple coinjoins really 14:13 < waxwing> sorry was away during discussion, but one thing i mentioned a few days ago, two good, simple updates would be utxo freezing and "coin control" (choose your inputs) 14:13 < belcher> i imagined that sendpayment is only used on your yieldgen wallet or after you've already used tumbler 14:13 < waxwing> the freezing came out of those dust tainting attacks but it could be useful otherwise 14:14 < belcher> in theory, dusting attacks shouldnt work that well on a wallet that only does coinjoins, because the information obtained from the common-input-ownership heuristic isnt useful 14:14 < belcher> but certainly it would be good to avoid spending from reused addresses 14:14 < Lightsword> undeath, would it be possible for a maker to do more or less what tumbler.py does but without becoming a taker? 14:14 < waxwing> yes that's the best way to use sendpayment if at all, or also ofc don't forget with -N0 to withdraw, but .. it's also worth considering our discussion the other week about how a near-zero fee coinjoin with sendpayment takes out its biggest weakness. 14:15 < undeath> Lightsword: in general a maker has very high de-linkage but you should not put change back into your wallet 14:15 < waxwing> i think one could easily write such a maker; just change the algos of the YieldGenerator class to siphon out to a pseudo-mixdepth that had your destinations. 14:15 < belcher> waxwing yes, so also encouraging patientsendpayment would also help 14:16 < belcher> thats an interesting idea... yieldgen that pays out to an external wallet slowly 14:16 < waxwing> it'd be more encouraging if we had it at all :) 14:16 < belcher> oh yeah i forgot :p 14:16 < waxwing> it might be better to just write that custom yg than to do patientsendpayment. well, one can do a bunch of things i guess. 14:17 < belcher> custom yg seems more private to my mind.. 14:17 < waxwing> kind of shim in a mixdepth 5 say that isn't really a mixdepth but just a list of external addresses. 14:17 < belcher> if you do stuff like send to an external address only once every 10 coinjoins 14:17 < belcher> since patientsendpayment would send them all from the same mixdepth 14:21 < undeath> it might also be interesting to mix various cj outputs across mixdepths 14:21 < waxwing> we used to have one variant that pushed the output to the largest to concentrate i think. 14:21 < undeath> to prevent mapping those "closures" (or what did you call them?) 14:21 < waxwing> we had several variants actually 14:22 < waxwing> undeath, ah you mean in the tumbler algo, don't have the whole set of txs from mixdepth N go to mixdepth N+1? 14:22 < undeath> tumbler and maker 14:23 < waxwing> i can't remember for sure but i'm pretty sure we had a yg that chose the destination mixdepth at random, too. 14:23 < undeath> should just be different than the change one I guess 14:23 < undeath> although it would still not matter? 14:23 < waxwing> now it's just simple, with a slight tweak for randomness of published data and minimizing order reannouncement. 14:23 < waxwing> i dunno this stuff is a bit fiddly. really hard to be sure sometimes. 14:24 < undeath> you mean on the improved anonymity vs damaging anonymity? 14:24 < waxwing> yes it's hard to know for sure the effects of slightly different algos. perhaps. 14:24 < undeath> yes, true 14:25 < waxwing> maybe you newer peeps aren't aware we had this: https://github.com/JoinMarket-Org/custom-scripts 14:25 < waxwing> it actually tbh came out of me being annoyed at having to maintain 4 different yg scripts :) 14:25 < undeath> lol 14:26 < waxwing> at least we don't have code duplication like we did back then. but it'd be great if people independently maintained different yg scripts. 14:26 < Lightsword> so thinking makers should maybe try and make create a utxo that matches the change of another participant 14:26 < undeath> not possible 14:26 < undeath> makers don't know the inputs of others until they get the final tx 14:26 < waxwing> as an example, consider the comment here: https://github.com/JoinMarket-Org/custom-scripts/blob/master/yield-generators/yg-randomizer.py#L115-L127 14:27 < waxwing> here we're *avoiding* the most coin mixdepth, to avoid re-announcing, which has a negative privacy component. 14:27 < Lightsword> undeath, can they negotiate the amount in the same way the taker negotiates the amount being spent? 14:27 < undeath> and optimizing for that without hurting privacy by publishing your utxo amounts to all participants isn't really feasible i guess 14:27 < undeath> if possible at all 14:28 < undeath> yes, avoiding announcing is also important 14:29 < Lightsword> thinking negotiate change addresses after podle commitments are sent? 14:29 < undeath> you could also only announce significant changes of available funds 14:29 < waxwing> Lightsword, huh, sounds like a clever idea, i actually think that might be possible 14:30 < waxwing> because: obv the Taker doesn't want to announce their full cjamount+change in public to avoid exposing their utxos, but: 14:30 < Lightsword> so basically makers will attempt to create matched change addresses with each other, so eventually left over change should get consumed by someone matching you 14:30 < waxwing> hmm, no maybe it's a bit dodgy. they'd have to send the full amount and effectively the set of input utxos to the Makers. 14:30 < waxwing> i suspect it isn't possible no. 14:30 < Lightsword> I think you would only negotiate change after podle commitments 14:30 < undeath> I don't think you can do that without hurting privacy 14:31 < waxwing> yeah but podle defends makers from takers, who ping incessantly to gather info from makers. 14:31 < belcher> this scheme is like trading away privacy between coinjoin peers in return for privacy on the blockchain 14:31 < waxwing> here the problem is that takers would be giving info to makers; don't forget that takers are intended to get max privacy here. 14:31 < belcher> so it might be worth it, depending 14:31 < Lightsword> well the change amounts are going to be public on the blockchain anyways 14:31 < undeath> but anonymity on the bc is not an issue if you don't use change outputs 14:32 < waxwing> Lightsword, but this exposes input set. 14:32 < waxwing> yes ofc change is not an issue, at all, it's already exposed (at least, the inputs-change linkage, is) 14:32 < undeath> isn't that what Lightsword is trying to "fix"? 14:32 < waxwing> well, true, good point. 14:33 < waxwing> but this would expose takers to makers who don't complete protocol. 14:33 < Lightsword> I’m trying to come up with a way for a maker to automatically restore privacy to utxo’s used as change in their own taker transactions 14:33 < waxwing> i dont' think it flies, there is no coinjoin protocol (including the clever ones) that can stop malicious counterparties from simply not completing, if they have your full input amount, they can deduce all your input utxos. 14:34 < belcher> thinking more long term, coinjoin uses a lot of block space relative to the privacy it gives, iv long had the view that things like coinswap will be better 14:35 < belcher> not that its not worth fixing/improving joinmarket and other coinjoin apps 14:35 < undeath> schnorr signatures? :) 14:35 < waxwing> also the taker's input set would be identifiable as the one not having a dangling change, no? you'd have equal sized cjs, equal sized changes, and then non-equal changes, except taker wouldn't have it .. unless you purposely allow it, in which case you're talking about a double-coinjoin 14:35 < belcher> schnorr signatures they dont improve the cost of privacy 14:35 < belcher> since non-privacy coinjoins get the same benefits 14:35 < Lightsword> well you would only advertize the change amount after podle and not the input’s themselves 14:36 < waxwing> but the change amount identifies the input set 14:36 < waxwing> belcher, yeah it's a good observation re: schnorr, you've made it before, but i think p2ep at least is different right 14:37 < belcher> hmm.. idk.... ill think 14:38 < undeath> wouldn't schnorr signatures significantly reduce the tx size? couldn't you combine all input signatures? 14:38 < waxwing> it's kinda orthogonal i think 14:38 < waxwing> since p2ep is not a space-using construction anyway 14:38 < belcher> undeath almost all transactions benefit from schnorr, so it doesnt give privacy-coinjoins much advantage 14:38 < undeath> ah, that's what you mean 14:38 < Lightsword> waxwing, well you have that issue regardless right? but I think this would help on the blockchain at least by delinking the change outputs right(by negotiating matching)? 14:39 < undeath> well, txs with more inputs benefit more, and a cj usually has more inputs than average txs 14:39 < belcher> yeah, schnorr and other efficency savings make fees go up not down... in terms of economics they make the demand curve change shape, since people are willing to pay more because they can get more done with the same block space 14:39 < waxwing> Lightsword, you don't hvae the issue today that the makers know the set of inputs of the taker. 14:40 < Lightsword> waxwing, I think you could do the change negitiation only between makers then? 14:40 < waxwing> the makers hand over their utxos to the taker, and the taker constructs whole tx, preserving privacy of their own inputs from all makers. that's the taker's extra privilege (well, one of them, there are others) 14:40 < waxwing> Lightsword, hmm, well i guess it'd be possible. 14:41 < waxwing> but atm the Taker is very much intended to be the "central coordinator" of the join. even if not literally a server. 14:41 < undeath> would that work without the makers identifying each other? 14:41 < undeath> (which would obv be bad again) 14:41 < belcher> makers only need their pubkeys to be known 14:41 < belcher> i think they already have known pubkeys, for the multi-irc-server feature 14:42 < undeath> i'm not sure if you can actually come with a change negotiation that doesn't significantly hurt maker privacy 14:42 < waxwing> yeah ephemerally, change it every time they reconnect 14:42 < belcher> they could encrypt their change amount and send it to the taker who forwards it to all other makers 14:42 < belcher> however if the taker coinjoins with a maker that he also controls then he'll be able to read the change amount 14:42 < undeath> then you would know which makers were involven in a certain cj 14:42 < undeath> right now only the taker knows that 14:42 < belcher> yes true 14:43 < waxwing> people often end up thinking about this stuff in coinjoin. i remember it was in the OP, also nopara has recently spent time thinking about whether multiple equal sized outputs might actually be more optimal. 14:43 < waxwing> difficult to come up with clear mathematical arguments. 14:43 < belcher> this scheme seems to trade away privacy between joinmarket peers in return for more privacy on the blockchain... so even with all these privacy problems it still might be worth it 14:43 < belcher> many joinmarket peers are hopefully anonymous behind tor, while the blockchain is forever 14:44 < undeath> but if you don't spent from change outputs you have no privacy problems on the bc 14:44 < belcher> what do you do with the change outputs instead? 14:44 < belcher> you mean like, hodl them forever? 14:44 < undeath> no, don't don't use them for external payments 14:45 < waxwing> unless you're lucky or clever, it's best to assume that all the addresses in a mixdepth are linked. 14:45 < undeath> and don't put back change from external payments back into your cj wallet 14:45 < undeath> well, cj outputs should not be possible to link to any other addresses in your wallet 14:46 < waxwing> undeath, yes, but cj outputs should explicitly not be in the same mixdepth as the one being spent from 14:46 < waxwing> anyway i'm sure we're not arguing here 14:46 < undeath> actually, when selecting a random mixdepth destination, does it matter? 14:47 < belcher> ooooh, so non-cj payments 14:47 < waxwing> rather than more-than-one-equal-size type ideas, i'd be more interested in considering features like; freezing utxos; giving better coin control to user; some kind of pay-to-endpoint feature (i think better call it "payjoin") 14:48 < belcher> yes all utxos in a mixdepth should be assumed to be linked 14:48 < belcher> perhaps they should be renamed "identities" or "pockets" which is what darkwallet called them (though it only had two) 14:48 < undeath> why would you have to assume that cj outputs in a mixdepth are linked to other outputs in the same mixdepth? 14:49 < waxwing> "cj outputs in a mixdepth", you mean coins *received into the mixdepth* as cj outputs? 14:49 < belcher> they may be spent together in the same coinjoin which might reveal they are in the same mixdepth 14:49 < undeath> yes 14:49 < waxwing> the answer would be because you have to spend them at one point. 14:49 < undeath> but when you spend them you can decide to only use cj outputs 14:49 < waxwing> we're not asserting they're linked to the origin coins, only to the coins in that new mixdepth. 14:49 < undeath> but even that I don't think is true 14:50 < undeath> cj output only being non-change output 14:50 < waxwing> undeath, right when you start talking about coin control of the utxos in the mixdepth, that's why i said "lucky or clever". atm joinmarket doesn't have such a feature, it just chooses utxo on simple criteria. 14:50 < undeath> ah, I see 14:50 < waxwing> clearly, if you explicitly control which utxos you're spending, you can create isolation almost any way you like. 14:50 < undeath> I usually manually select my utxos anyway 14:50 < waxwing> well, within the limits of the amount you're trying to spend, ofc 14:51 < waxwing> right, hence my above 'i'd be more interested ...' statement, i think coin control is probably an obvious feature to add, since our userbase is mostly expert. 14:52 < waxwing> we could try to make it somewhat easy for some use cases, but that's another discussion i guess. 14:52 < undeath> agree 14:52 < waxwing> for now the advice has always been "don't spend from more than one mixdepth together, try to keep them separate", that's about the best we can say to users for now. 14:52 < undeath> that's definitely a safe recommendation 14:54 < waxwing> lol this guy is funny sometimes https://twitter.com/TheStalwart/status/1070424929777135617 14:57 < belcher> on twitter im in the middle of educating some guys on why joinmarket actually doesnt necessarily have a lower anonymity set than wasabi wallet https://twitter.com/LukeDashjr/status/1070451048756711425 14:58 < belcher> in the schnorr-future i imagine joinmarket will actually end up pivoting to a way to coordinate schnorr coinjoins 14:58 < belcher> which have unequal output sizes, and are just done to save miner fees and not for privacy 14:59 < waxwing> yeah there was a whole section at the london meetup (maybe the day before you arrived) where grand schemes were devised for schnorr coinjoin negotiation. i'm afraid the market mechanism doesn't get as much love as it should. 14:59 < undeath> that sounds like fun 14:59 < belcher> any idea why not? i though we were all market fundamentalists around here :p 15:00 < undeath> easy to dos I guess 15:00 < waxwing> belcher, well unequal output sizes, but also like p2ep stuff. that would be the ideal, if admittedly doesn't seem too plausible today. 15:00 < belcher> undeath any coinjoin is easy to dos 15:00 < waxwing> yeah, i think that's a fair summary. 15:00 < belcher> im still slightly confused at why wasabi wallet chose to not allow paying for liquidity... at the end of it all you get what you pay for 15:00 < waxwing> central server based is nowhere near as easy to DOS. 15:01 < waxwing> but they have to use banning, so .. hard to say 15:01 < belcher> what is a way of DOSing a market solution that a central server doesnt have? 15:01 < waxwing> belcher, well there's an obvious reason why you might deliberately avoid using a market within the coinjoin at least 15:01 < belcher> for privacy as you said? 15:01 < waxwing> namely if the fees are in the coinjoin, it reduces its effect, yeah 15:02 < belcher> the issue there is how the payment happens on-chain... a solution would be to pay for liquidity off-chain 15:02 < waxwing> re: DOS, i guess i wasn't thinking too clearly, it isn't really about markets i think maybe it's more about being resolute/insistent on P2P. 15:03 < waxwing> i guess you could also say that a market incentivises DOSing more (to make money), but that doesn't seem like the biggest issue overall. 15:03 < belcher> is P2P more or less fitting with market solutions? 15:03 < waxwing> sorry resolute/insistent on zero identified parties. i think i should get a drink :) 15:03 < undeath> oh, could you actually dos that by refusing to sign? 15:03 < belcher> yep 15:03 < waxwing> undeath, referring to what? 15:04 < belcher> in terms of schnorr, the only incentive to use it is to save miner fees, so market forces are already involved *shrug* 15:04 < belcher> schnorr signature aggregation* 15:04 < undeath> the cj for fee reduction market 15:04 < belcher> ah yes 15:05 < belcher> all coinjoins can be DOS'd since they all require two rounds 15:05 < waxwing> not snicker :) 15:05 < belcher> everyone needs to see the unsigned tx, everyone needs to send back signatures 15:05 < belcher> ah true... 15:05 < belcher> good catch 15:05 < undeath> snicher? 15:05 < belcher> because with snicker the parties deduce what the unsigned tx looks like beforehand 15:05 < belcher> undeath https://joinmarket.me/blog/blog/snicker/ 15:05 < waxwing> which is why i spent a lot of that london meeting trying to pump it, people got bored of me talking about it after a while :) 15:06 < undeath> thanks, I need to give that a read 15:06 < belcher> id recommend put aside some time to read all the blog posts on that blog if you havent already 15:07 < belcher> they're just really good IMO :D 15:07 < undeath> :) 15:07 < belcher> im working on a kind of summary paper about everything privacy related in bitcoin, still not finished it yet (writing always takes me ages) 15:08 < waxwing> sounds good. we don't have much that would fit that bill (if anything). i.e. comprehensive. 15:08 < belcher> as for the change coinjoin idea, it might be really worth it 15:08 < belcher> the blockchain is forever after all, joinmarket peers arent 15:09 < belcher> im imagining that the takers payment and change output are both coinjoin'd, and each maker has three outputs 15:09 < waxwing> joinmarket logs can be forever 15:09 < undeath> it can be easily exploited by data collectors 15:09 < belcher> yes you're right 15:19 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3] 15:20 < belcher> i wonder if people also dont like paying for liquidity because they feel like they might be paying sybil attackers? although a system where liquidity is free can also get sybil attacks (but at least you're not paying for the privilege) 17:09 -!- Giszmo [~leo@pc-73-164-161-190.cm.vtr.net] has joined #joinmarket 17:26 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Quit: bye] 17:26 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 17:54 -!- AgoraRelay [~jmrelayfn@p5DE4ABA0.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds] 18:08 -!- AgoraRelay [~jmrelayfn@p5DE4A802.dip0.t-ipconnect.de] has joined #joinmarket 18:54 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 18:54 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 19:24 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has quit [Ping timeout: 245 seconds] 19:28 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #joinmarket 19:45 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has quit [Ping timeout: 246 seconds] 19:55 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #joinmarket 20:11 -!- Giszmo [~leo@pc-73-164-161-190.cm.vtr.net] has quit [Quit: Leaving.]