--- Day changed Mon Dec 31 2018
01:42 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
02:10 < undeath> til: when you use the github functionality "start review" in a pr, your comments will not get published until you press that other button
02:31 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
02:56 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Quit: ZNC]     
02:56 -!- Lightsword [~Lightswor@107.170.253.193] has joined #joinmarket     
02:57 -!- v_unimportant_pe [~user@185.244.215.51] has quit [Remote host closed the connection]     
02:57 -!- v_unimportant_pe [~user@185.244.215.51] has joined #joinmarket     
03:12 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
03:23 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
04:29 < waxwing> undeath, thanks, working on it. (i never bothered with that start review thing, just seems like it's adding another layer of complexity that isn't needed).
04:48 < undeath> actually I pressed the wrong button on accident, never used it before
04:48 < undeath> but I was confused when I didn't see the other comments I made the other day on the pr while not being logged in, that's when I checked what was up
04:49 < undeath> the "start review" thing is just something to pile up your comments and publish them all at the same time it seems
05:54 < belcher> it gets used when reviewing PRs for bitcoin core, then the comments can be "marked as resolved" if that line of code gets edited or if you click the button
05:55 < undeath> that's also possible when using individual code comments
06:12 < waxwing> yeah i kinda like the 'mark as resolved' feature, although i wouldn't want to be wedded to it (well; prob just an advantage of working on a smaller project :) )
06:13 < waxwing> oh btw belcher arubi (and others ofc) there were further comments on that gist , would be interested to hear further thoughts on the evolution of the discussion.
06:18 < belcher> UIH2 isnt really a heuristic but an attack on p2ep
06:19 < belcher> well heuristics are attacks..
06:20 < waxwing> where i left it is, in the last post, i can't decide if i should be focusing on per-utxo or per-counterparty. i see the logic for the latter - those inputs may already be clustered - but i kinda don't like it, because according to that rule it'll be *much* harder to avoid triggering UIH2
06:20 < waxwing> and obv which one you focus on may determine how you do the coin selection. i guess.
06:22 < belcher> hmm i didnt get that, what do you mean by focusing either on per-utxo or per-counterparty
06:23 < waxwing> belcher, well i mean take the simple example where Alice pays bob 0.01
06:24 < waxwing> if she pays with a 1btc input, it's very different than if she pays with 100 0.01 inputs
06:25 < belcher> yes     
06:25 < waxwing> bob's going to have an easier time to avoid UIH2, if interpreted as "no single utxo input is bigger than any output", if the inputs are fragmented, so to speak
06:25 < waxwing> but if it's interpreted as contributions from two parties, pre-clustered, then it makes no difference
06:25 < belcher> ok     
06:26 < belcher> to me its obvious that per-utxo is what should count (i.e. using 100 inputs worth 0.01btc each is better) because the adversary doesnt know about the counterparties
06:26 < belcher> 100 inputs would fool walletexplorer.com, but not one 100btc input, to put it another way
06:27 < waxwing> i agree but i wouldn't call it obvious, simply based on what if alice's inputs are already clustered in walletexplorer.
06:27 < belcher> assuming she doesnt reuse addresses, they wont be clustered
06:27 < waxwing> i think i will work on that basis though. but what prompted the thought is that laurentmt just treated inputs from each party as two objects.
06:28 < waxwing> oh yes, i see your thinking. pre-spending you don't have clustering unless via some more unusual method.
06:28 < belcher> clustering happens because of the CIOH, and that only happens when the inputs are actually spent
06:29 < belcher> address reuse is what walletexplorer.com uses as well as CIOH, but in theory the adversary could run electrum servers that spy on wallets too and link together addresses that way
06:29 < belcher> but in terms of just looking at the blockchain, clustering happens with address reuse and CIOH
06:31 < waxwing> so let's say greedy selection for alice; then, for bob, he can at least check if his selection violates uih2 or not. if it violates it (i.e. 1 input *is* larger than any output), seems like an open question as to what should be done.
06:32 < belcher> add more of his own inputs if possible, as that will increase the value of his output and so avoid the mentioned problem
06:36 < belcher> actually, say if the tx was (10btc, 5btc --> 6btc, 9btc) where 10btc paid 1btc to 5btc, if 5btc also adds another input it could become (10btc, 5btc, 6btc ---> 9btc, 12btc), that avoids the attack
06:37 < belcher> (id like it if the phrase UIH2 didnt catch on as numbering names it less descriptive, maybe "oversized input attack", its an attack which only applies to p2ep)
06:39 < waxwing> belcher, didn't we discuss that point? it's still a useful heuristic for categorisation outside p2ep, no? something which has that property is not an ordinary payment to a single payee. could be batch for example.
06:39 < waxwing> well "is not" is too strong, heuristic etc etc
06:40 < belcher> i dont remember the discussion, maybe i misunderstood it at the time
06:40 < belcher> batching means more than 2 outputs which p2ep never has
06:52 < waxwing> belcher, yeah, i'm saying: if you see UIH2 violation, i.e. one input bigger than any output, you can choose to interpret that as meaning there is not a normal payment going on.
06:52 < waxwing> so if anything i'm saying that if you want p2ep to share the same anon set as all normal payments, you want to avoid that case.
06:53 < belcher> yes     
06:53 < belcher> so what i mean is adding an extra input would avoid the UIH2 violation
06:53 < belcher> (would sometimes avoid, if the amounts are right)
06:53 < waxwing> oh; but that's what i was saying too :) first alice and then bob.
06:54 < waxwing> it's kind of weird, alice will just "do her best" and then bob's left either figuring out if he can do it, or if not, i guess just accept that he can't.
06:56 < belcher> another issue is if bob is a merchant then p2ep will result in his utxo getting higher and higher valued, so eventually it will start breaking UIH2
06:56 < waxwing> there probably is actually stuff to work out here.
06:56 < waxwing> yes that kind of dynamic occurred to me too. if we sweep and aggregate a lot, we can't keep doing that.
06:58 < belcher> if bob the merchant then receives a non-p2ep payment, then he now owns a new small utxo
06:58 < belcher> p2ep doesnt have to be applied to *every single* tx in order to break the CIOH
06:58 < belcher> so maybe its perfectly fine for bob the merchant to not do p2ep when he cant, and just accept a normal payment instead
07:25 < belcher> ill post a summary of this on the gist i think
08:41 < qubenix> the releases page should have belcher's key fingerprint
08:42 < belcher> qubenix would this be appropriate? where it has links to my fingerprint on different platforms https://github.com/chris-belcher/electrum-personal-server/releases/tag/eps-v0.1.6
08:42 < belcher> i could also add the fingerprint itself as you say, it wouldnt hurt
08:43 < qubenix> The two sentences where it says to verify with your key should have the fingerprint.
08:44 < qubenix> you should attest it in as many places as possible for verification
08:45 < belcher> iv edited it, tell me what you think https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.5.0
08:46 < qubenix> wrap in ``, but otherwise +1
08:47 < belcher> good idea, done
08:49 < belcher> its also worth noting that a signature for can be created by anyone, as the procedure deterministically produces the .zip files from the git repos
08:50 < belcher> also if one day i become evil and upload bad signatures for something else, then its possible to prove it (although i dont think i can change the .zip file links without getting into the github website)
10:15 < arubi> ugh TIL github "helpfully" sorts commits in a PR by the commit's date instead of the actual order they were applied and appear in the log.. what a weird thing to do.  /me reads backlog
11:12 < arubi> good stuff.  yea there's a lot more to p2ep that I wasn't considering.  so I'm wondering what if a constraint is applied to alice, that when she wants to pay bob X amount, she always has to use some n>1 inputs, and that they all have to be smaller than the payment?
11:17 < waxwing> that's kinda what i mean by 'greedy', our select algo(s) which favour sweeping up as many smaller utxos as possible
11:18 < arubi> ah alright, so now alice's change, it has to be smaller than all input amounts used, right?  for it to be a "sensible" normal spend
11:19 < arubi> trying to figure out what's bob strategy in this case, which seems like the best scenario to start with (although I might be wrong)
11:21 < arubi> so LaurentMT says the total input amounts from bob should be larger than alice's change, and he should probably run the same algo, all individual inputs should be larger than the change as well
11:22 < arubi> (first IF)
11:23 < arubi> yea I think that makes sense?  hides the payment amount and at least for looking like a normal payment, but yea it does reveal exactly which output is change
11:43 < arubi> and bob can't add his own change for confusion because now the tx is not "normal" anymore..  but I'm wondering, was p2ep's original use case something else than hiding payment amount?
11:48 -!- viasil [~viasil@165.231.102.6] has quit [Ping timeout: 246 seconds]     
11:50 < belcher> arubi the use case of p2ep is breaking the common-input-ownership heuristic (COIH)
11:50 < belcher> it cant hide amounts because you can always work them out, you have 4-6 options instead of 1-2
11:53 < belcher> (actually i dont think it can ever be 6 possible payment amounts, the maximum is 4)
11:53 < arubi> ah you're right, that makes sense.
11:54 < arubi> so for the tx to look like a normal payment (like what I listed above) makes sense correct?  I'm having a hard time justifying the second scenario where the tx is obviously "weird" but it's hard to distinguish which output is change
11:56 < belcher> hmm, i think iv confused myself a bit..
11:57 < belcher> if the p2ep is "weird" then an adversary could exclude it from the COIH clustering
11:58 < arubi> but if it looks like a normal payment, then they have false positives, which is nice
11:58 < arubi> arguably, nice-er imo :)
12:01 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
12:05 < belcher> arubi i reread all the gist comments and your last irc messages here, i think you're just talking about the UIH2 issue
12:05 < belcher> ?     
12:06 < arubi> belcher, I think that's basically it yea, I don't see a justified use for the second scenario
12:06 < belcher> whats the second scenario?
12:07 < arubi> creating a tx that acts weird wrt output amounts, "..This heuristically implies that no output is a payment.." as waxwing put it
12:08 < belcher> ah yes, you're saying a tx that breaks UIH2 would never be created by normal wallets, i think i agree except for batching
12:08 < belcher> so id put it as "txes which break the UIH2 and which have only two outputs dont happen in the wild"
12:09 < arubi> right, exactly.  the two outputs thing is key here too
12:11 < arubi> I think at best, the tx could be made to look like a coinjoin
12:11 < belcher> (btw iv changed my mind and UIH2 probably is a good name)
12:11 < arubi> I mean, with n_outputs > n_inputs and outputs sharing same amounts except for change ones
12:12 < belcher> i convinced myself that if a p2ep cant be made without breaking UIH2 then it shouldnt be made at all
12:12 < belcher> to break COIH on a large scale you dont need every single tx to be a p2ep, just some of them
12:14 < belcher> i wrote about it on the gist, if bob the merchant cant make a UIH2-resistant p2ep then he should accept a regular bitcoin payment, which would also give him a new small-valued UTXO that he can use in future P2EPs
12:16 < arubi> indeed.  yep, I agree
12:17 < belcher> this discussion in the last few days is a great example of how you never really understand something until you try to code it
12:20 < belcher> i wonder if a batched p2ep transaction makes sense i.e. a tx where one entity pays many people at once, but somehow the receivers contribute their own inputs to the transaction
12:24 < arubi> it might, and at that point you might as well make it look like a coinjoin jm-style, but it would require non trivial amount of cooperation.  maybe if all receivers already hang out in the pit with their bots
12:24 < arubi> maybe they just run a maker during times when not accepting payment, I mean it could work
12:25 < belcher> we could do it with raw transactions next time the joinmarket donations get distributed, could be a fun experience
12:25 < belcher> another thing worth noting; joinmarket or wasabi wallet txes dont break CIOH, because those txes are visible as coinjoins so they can be excluded, and its often possible to group together which inputs are owned by the same entity with the help of the clearly-visible change outputs
12:27 < belcher> joinmarket breaks walletexplorer.com today, but thats only because the operator hasnt coded it to ignore them (and apparently there are some false positive 3-coinjoins)
12:31 < arubi> it's frustrating that amount obfuscation in blockchains exists but bitcoin doesn't have it yet :)
12:33 < belcher> you can also break amount tracking without any soft forks, if you have a big anonymity set
12:33 < arubi> ah you mean like if all amounts are strictly 
12:33 < arubi> er, say 1.0 btc, right?
12:34 < belcher> that would work too, but it damages the divisibility of bitcoin as money
12:34 < belcher> im thinking of this:
12:35 < belcher> imagine you're using coinswap where the transactions look like normal transactions made by anybody, if you paid people with 6 transactions instead of 1, and assuming each block has ~3000 outputs in it and you wait 40 blocks, then the amount of calculation needed by an adversary to find 6 txes that add up to your payment amount is nCk(3000*40, 6) > 2^80
12:35 < belcher> the security comes from how quickly the n-choose-k function gets big
12:36 < belcher> if you want to pay with 5 transactions instead of 6, then you need to wait 1 day (144 blocks) to get above 2^80
12:37 < belcher> thats only an upper bound btw, somewhere iv written down an argument based on false positives which requires you to wait less time and you dont need to make as many transactions
12:37 < arubi> oh yea I see, yes that's a very good point.  like a compounding payment and you can strategically broadcast transactions as they fit the current anonymity set
12:38 < belcher> yes     
12:38 < belcher> coinswap requires segwit which only about 40% of transactions use today, so realistically you'd get around 1500 outputs of anonymity set per block rather than 3000... but thats ok you just need to wait longer
12:41 < arubi> sounds reasonable really, for being able to take advantage of this kind of very low signal payment
12:43 < belcher> also remember blockchains are slow anyway, especially in the high-miner-fee future where they'll be a tx backlog, so waiting a bit will be usual
12:46 < arubi> hmm now I wonder if bi-funded LN channels by using coinswap are a thing.  you coinswap where the outputs are to LN channels, and when you wanna actually make the payment you just LN it and close the channel strategically
12:48 < arubi> so you coinswap first, then the actual payment spends the coinswap's output which was already confirmed a long time ago when the channel was opened
12:49 < arubi> well bi-funded is not a good term here.  the other destination of the coinswap doesn't matter.  yours just pays to a channel open.  maybe I'm just reinventing waxwing's cj-xt
12:50 < belcher> the thing with LN is it works best for smaller amounts, so you couldnt reasonably do it with 1000 bitcoins for example
12:53 < arubi> hm right.  if it's a really big amount then a channel isn't really an option
16:09 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
17:53 -!- AgoraRelay [~jmrelayfn@p5DE4AB10.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]     
18:04 -!- AgoraRelay [~jmrelayfn@p5DE4AC24.dip0.t-ipconnect.de] has joined #joinmarket     
18:32 -!- viasil [~viasil@165.231.102.6] has joined #joinmarket     
20:20 -!- viasil [~viasil@165.231.102.6] has quit [Read error: Connection reset by peer]     
20:25 -!- viasil [~viasil@165.231.102.6] has joined #joinmarket     
23:02 -!- raedah [~x@192.30.89.142] has quit [Read error: Connection reset by peer]