--- 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.]