--- Day changed Thu Dec 06 2018
02:10 -!- Giszmo [~leo@pc-73-164-161-190.cm.vtr.net] has joined #joinmarket     
03:46 -!- raedah [~x@184.75.221.3] has quit [Ping timeout: 268 seconds]     
05:37 -!- GitHub39 [GitHub39@gateway/service/github.com/x-ntimmndfzwzdrftl] has joined #joinmarket     
05:37 < GitHub39> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fpMyM
05:37 < GitHub39> joinmarket-clientserver/master 42060db undeath: remove slowaes
05:37 < GitHub39> joinmarket-clientserver/master d71efb6 AdamISZ: Merge #243: remove slowaes...
05:37 -!- GitHub39 [GitHub39@gateway/service/github.com/x-ntimmndfzwzdrftl] has left #joinmarket []     
05:37 -!- GitHub28 [GitHub28@gateway/service/github.com/x-jcxqxoqlymcfkryz] has joined #joinmarket     
05:37 < GitHub28> [joinmarket-clientserver] AdamISZ closed pull request #243: remove slowaes (master...remove-slowaes) https://git.io/fpwmh
05:37 -!- GitHub28 [GitHub28@gateway/service/github.com/x-jcxqxoqlymcfkryz] has left #joinmarket []     
05:59 < waxwing> i guess we really shouldn't be ignoring this warning in tests? (venv)/local/lib/python2.7/site-packages/mnemonic/mnemonic.py:78: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
06:00 -!- GitHub174 [GitHub174@gateway/service/github.com/x-fsfevahhxkhkwuia] has joined #joinmarket     
06:00 < GitHub174> [joinmarket-clientserver] AdamISZ pushed 3 new commits to master: https://git.io/fpM9S
06:00 < GitHub174> joinmarket-clientserver/master d33cc5c undeath: clean up Maker interface
06:00 < GitHub174> joinmarket-clientserver/master a43eceb undeath: add very basic JMMakerClientProtocol test
06:00 < GitHub174> joinmarket-clientserver/master 94c1580 AdamISZ: Merge #245: add basic test case for JMMakerClientProtocol...
06:00 -!- GitHub174 [GitHub174@gateway/service/github.com/x-fsfevahhxkhkwuia] has left #joinmarket []     
06:00 -!- GitHub135 [GitHub135@gateway/service/github.com/x-ozrldwhspiytxuzc] has joined #joinmarket     
06:00 < GitHub135> [joinmarket-clientserver] AdamISZ closed pull request #245: add basic test case for JMMakerClientProtocol (master...test-twisted) https://git.io/fpoMf
06:00 -!- GitHub135 [GitHub135@gateway/service/github.com/x-ozrldwhspiytxuzc] has left #joinmarket []     
06:32 < waxwing> https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/464346004#L3892 <-- undeath : something wrong here, i only tested locally on py2, maybe it's a py3 thing with the new test?
06:33 < waxwing> undeath not here, please ping him with that if he comes later
06:39 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
06:39 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
06:40 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
06:46 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
07:47 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 250 seconds]     
07:50 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
08:10 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 272 seconds]     
08:37 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 244 seconds]     
08:50 -!- lnostdal [~lnostdal@151.251.248.99] has joined #joinmarket     
08:54 -!- lnostdal [~lnostdal@151.251.248.99] has quit [Ping timeout: 246 seconds]     
09:09 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
09:22 < waxwing> https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/464346004#L3892 <-- undeath : something wrong here, i only tested locally on py2, maybe it's a py3 thing with the new test?
09:26 < undeath> yes, something wrong with the test
09:37 < undeath> shall i push a fix to master? or do you want a pr?
09:41 < waxwing> undeath, oh no feel free to push to master
09:44 -!- GitHub112 [GitHub112@gateway/service/github.com/x-lsjylyzmaxajpcsn] has joined #joinmarket     
09:44 < GitHub112> [joinmarket-clientserver] undeath pushed 1 new commit to master: https://git.io/fpDYm
09:44 < GitHub112> joinmarket-clientserver/master 12705b5 undeath: fix TestMakerClientProtocol failing with py3
09:44 -!- GitHub112 [GitHub112@gateway/service/github.com/x-lsjylyzmaxajpcsn] has left #joinmarket []     
09:47 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
10:05 -!- rdymac [uid31665@gateway/web/irccloud.com/x-luczdczbwqzlqcgn] has joined #joinmarket     
10:26 -!- mr_paz [~mr_paz@84.39.112.84] has joined #joinmarket     
10:52 < waxwing> i closed the old py3 branch, still have it locally in the (unlikely!) case there was anything useful in it
11:09 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
11:10 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
12:21 < undeath> waxwing: re: CJXT: how is a N-party LN channel managed? I mean, who gets to decide what endpoints to connect to, who accumulates puzzles and who decides to close the channel?
12:24 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
12:25 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
12:33 < belcher> anyone as long as they agree beforehand
12:33 < belcher> CJXT is orthogonal to a coordination mechanism
12:35 < undeath> does that mean all parties need to stay in contact until the channel is closed?
12:35 < belcher> i guess so
12:36 < belcher> btw there is another way to beat amount correlation, which i havent published yet, which involves obtaining such a big anonymity set that n-choose-k results it it becoming huge and so nobody can do the calculations required to solve the amount correlation problem
12:37 < belcher> but its quite hard to do because all the txes in the PTG have to be segwit, so an adversary can remove non-segwit txes from their searching... and since only around 40-50% of txes today are segwit an adversary can find yout PTG fairly easily
12:42 < undeath> according to the blog post all txes within the PTG are linked to a previous PTG one. Isn't it fairly easy anyway to identifiy the PTG?
12:45 < belcher> no because some of the outputs from txes in the PTG will get spent in other transactions which were not part of the PTG
12:45 < belcher> an adversary cant tell between txes in the PTG and not in the PTG
12:46 < belcher> thats the ideal case
12:46 < undeath> ah, so A doesn't even know they are dealing with a PTG to begin with
12:47 < belcher> A is an adversary or Alice ?
12:47 < undeath> adversary
12:48 < belcher> yes     
12:48 < belcher> so imagine if someone withdraws bitcoins from a KYC exchange and dont want anyone to know where they went, so they send their bitcoins through a PTG
12:48 < belcher> the KYC spy might suspect a PTG is happening but they wouldnt know, and they wouldnt know where the PTG ends
12:50 < belcher> because the PTG txes can be anything, the CJXT application could make them perfectly mimic the natural transaction graph due to normal economic activity in bitcoin
12:50 < undeath> but assuming we need N-of-M multisign for all PTG txes I guess this isn't worth much without any signature aggregation mechanism?
12:52 < belcher> we dont need N-of-M multisig in the PTG
12:52 < belcher> we only need N-of-N for the very first tx (which is called the funding tx i think)
12:53 < belcher> and the N-of-N can be with schnorr or ecdsa-2p so that its not visible on the blockchain that its an N-of-N
12:55 < undeath> ah, we only need it for the first tx, that was a misunderstanding on my part then. but yes, makes sense
12:56 < undeath> both of those mechanisms don't work yet with bitcoin, do they?
12:57 < belcher> ecdsa-2p does/could
12:57 < belcher> another way could be to have 2-of-3 multisig with a fake third key, so its effectively 2-of-2
12:57 < belcher> 2-of-3 is very common on the blockchain today, about 15% of spends use it iirc
12:58 < undeath> yeah, that's why I said N-of-M
12:58 < undeath> 15%? wow
12:58 < undeath> didn't expect that many
12:58 < belcher> hold on ill find the exact number
12:58 < belcher> lots of exchanges use it for security
13:03 < belcher> 2-of-3 is around 2 million UTXOs, the total number of UTXOs is around 50 million
13:04 < belcher> so 1%
13:04 < belcher> so i was incorrect :p
13:04 < belcher> wait, thats 4% not 1%
13:04 < belcher> around 4% of all utxos are 2-of-3 multisig
13:04 < undeath> :) thanks for digging out that number
13:08 < waxwing> yeah you seem to understand it pretty well. re: needing N of N through the graph: kinda yes, kinda no. what you need is shared control at each step.
13:08 < waxwing> overall i'd envisage this working with N of N schnorr or perhaps ecdsa2pc
13:08 < undeath> for every tx?
13:08 < waxwing> also, i take it you got the idea that 'promise' utxos mean more than one entry point.
13:08 < undeath> yes     
13:10 < waxwing> hang on iirc the requirement's stricter, you actually need each "connector" utxo to be dual control, and/or promise utxos. hmm maybe i didn't think about this carefully enough, i always just went with 2/2 or N/N connectors.
13:11 < undeath> what do you mean by connector utxo?
13:11 < waxwing> but you understood the idea of Coinjoin Unlimited, I can see, because you got the idea that without amount correlatoin the boundary is unknown. amount correlation is a huge deal in all of these systems. Conf. Trans. or similar ZKP is kinda needed to get rid of this.
13:11 < waxwing> undeath, i mean the outputs from TXN to TX_N+1 need to require sigs from both parties to be spent
13:11 < waxwing> otherwise they could just spend them elsewhere and break the atomicity
13:11 < undeath> ok     
13:11 < waxwing> or, we can treat them all as promise utxos and have backouts at each step.
13:12 < waxwing> i hadn't actually considered that tradeoff, i just kept it simple as every step has co-control.
13:12 < undeath> yes, I was actually thinking tha tto be the case
13:12 < waxwing> the gist is written in a bit more technically succinct way than the blogpost, but i guess either gives you what you need, it's not a particularly fancy idea.
13:13 < undeath> oh, I do think it is :)
13:13 < waxwing> re: whether it's doable, dual funding is not currently implemented in lnd, c-lightning, but aiui it'll be in LN 1.1
13:14 < waxwing> but, shrug, there may be some interest/value in doing it without that extra.
13:14 < belcher> you can also solve amount correlation by having a big anonymity set, because n-choose-k gets big quickly
13:14 < belcher> so that can be done without any SF like CT or zkp
13:16 < waxwing> to me the core value of the coinjoinxt structure was to violate what i called heuristic 3, i.e. you can't assume that coins going from bob's wallet to alice's means bob paid alice.
13:16 < waxwing> coinswap of course also does that, in an even more powerful way, i guess
13:17 < undeath> true, since you spread the inputs and outputs over mulitple txes there is no need any more for same-value outputs
13:19 < undeath> couldn't you choose random(2,5) outputs per participant and put each output into a different mixdepth?
13:20 < undeath> (mixdepth is probably not a good term here, but you get the idea)
13:20 < waxwing> huge design space.
13:21 < waxwing> you can say 'account' in bip32 parlance if you don't want to talk JM specific.
13:22 < undeath> we would kind of end with a hybrid of cj and cjxt, where the cj part tries to circumvent the amount correlation
13:23 < waxwing> yeah it's actually hard to say whether people would mix the two, or avoid the equal sized coinjoin. seems like a tradeoff.
13:23 < undeath> I think it sounds pretty promising
13:23 -!- rdymac [uid31665@gateway/web/irccloud.com/x-luczdczbwqzlqcgn] has quit [Quit: Connection closed for inactivity]     
13:24 < undeath> (I'm trying to avoid the LN channel because I'm not sure how it would actually work in practice)
13:25 < undeath> and with the PTG you even don't give the receiver a clue about the anonymized funds
13:25 < waxwing> yes i've flirted with the idea of sticking it as another offertype in JM. big-ish job, main Q would be about PTG templates
13:25 < waxwing> also it requires the wallet to maintain some state
13:26 < undeath> sounds like a cool idea
13:27 < belcher> how does the cj part circumvent amount correlation?
13:27 < undeath> you have various outputs of varying size that are not used together anymore
13:28 < undeath> mh, doesn't quite defeat subset sum I guess
13:29 < undeath> you could mix in some same-amount outputs maybe
13:29 < undeath> those can be chose across the PTG at random
13:31 < waxwing> it'd be cool if we wrote a primitve template language for Takers to define their own custom PTG :)
13:31 < waxwing> hmm "language" may be a slight stretch there :)
13:31 < undeath> is creating the PTG such a big issue?
13:32 < waxwing> not creating it, no; but agreeing it, perhaps
13:32 < undeath> the taker proposes it, the makers check if they receive enough funds and are happy?
13:32 < waxwing> i think you could imagine this almost like OTC trading vs exchange trading :) instead of fill and then examining orderbook, you'd have to propose a custom price for a custom contract, and just see who agrees.
13:33 < waxwing> ofc the easy way to avoid all that crap is to have a couple of standard templates to start with
13:34 < waxwing> undeath, don't forget you have to agree times as well as amounts, and one single amount may no longer cover the full description.
13:34 < waxwing> then, if there's going to be promise utxos, which i think there should be, that's another source of complexity.
13:36 < belcher> amount correlation can be beaten with a high anonymity set and multi-txes, for example say you had 5 output txes from a privacy tech, assuming each block has 5000 outputs then if you wait half a day (72 blocks) you'll find nCk(5000*72, 5) =~ 2^80
13:36 < belcher> so an adversary needs to do 2^80 operations to solve the amount correlation problem
13:36 -!- mr_paz [~mr_paz@84.39.112.84] has quit [Ping timeout: 245 seconds]     
13:37 < waxwing> that probably gives a sense, but with cjxt the task is to find a contiguous set of txs with a partition. if i had to guess i'd think it was probably just as hard :) but don't have a good sense.
13:37 < belcher> can you explain contiguous set with a partition?
13:38 < belcher> when i analyzed CJXT with this method i assumed it perfectly matches the pattern of the txes made by the rest of the economy, so an adversary doesnt know where the PTG ends and so have to consider almost all txes in all blocks
13:38 < waxwing> a set of e.g. 10txs that are all connected via utxos, where you can take the ins and partition them (ins1, ins2) and a partition of outputs (outs1, outs2) s.t. ins1=outs1 and ins2=outs2
13:39 < waxwing> here ins and outs are like sources and sinks for the whole 10tx set
13:39 < belcher> right ok
13:39 < belcher> but an adversary doesnt know which 10 tx to consider, or that the PTG even has 10 txes ?
13:39 < waxwing> exactly, that's why i set it's probably just as hard :)
13:39 < belcher> yes     
13:40 < waxwing> but i really have no idea. also i suspect the 2^80 would not work in practice because there'd be heuristics to dump out lots of non-possible cases.
13:40 < waxwing> it's that average-case vs worst-case hard thing
13:40 < belcher> yes, my calculation is the upper bound
13:40 < belcher> but i mainly aim to show that beating amount correlation is possible
13:40 < belcher> instead of waiting 72 blocks you can always wait 7 days instead
13:41 < undeath> that's making the whole think a bit less practical though
13:41 < waxwing> yes, it's good to point out that it's possible.
13:41 < belcher> the only cost of waiting for more blocks is price volatility?
13:41 < undeath> who'd want to lock up their funds for so long?
13:41 < belcher> and time value of money
13:41 < undeath> for makers it also limits the amount of cjs they can do
13:42 < belcher> so they'd demand higher fees (assuming the privacy tech uses market forces to find liquidity)
13:42 < belcher> 7 days isnt much... im imagining in the long-term future when block space is really costly and we just accept that blockchains are slow
13:42 < belcher> for private instant txes we'll use LN instead
13:44 < belcher> (ofc there are cases where LN isnt appropriate, but you still need fast txes)
13:44 < waxwing> anyway, on the whole amount correlation thing, that's why i kept using the term 'deniability' in a loose sense. the best way to beat the adversary is always for them not to even see you.
13:45 < waxwing> which is why i'd tend to think you wouldn't want the equal-sized out option. but it can for sure be argued.
13:46 < belcher> yes, that also massively increases the anonymity set
13:46 < belcher> because regular txes happening in the normal economy add to your anonymity set... unlike today in joinmarket where your anonymity set is basically only other joinmarket txes
14:14 < waxwing> it looks like i probably shouldn't even attempt to make PyQt4 work with Python3. not sure though, searching for info on it.
14:27 < undeath> :/     
14:27 < undeath> pyqt4 is really old, but not having a gui on py3 isn't nice
14:28 < undeath> I guess it greatly increases jm's user base
14:29 < waxwing> i really don't know, but:
14:29 < waxwing> python3-pyqt4 is installable on ubuntu, trying it out
16:01 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
17:33 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
17:34 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
17:51 -!- AgoraRelay [~jmrelayfn@p5DE4A802.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]     
18:06 -!- AgoraRelay [~jmrelayfn@p5DE4ADFE.dip0.t-ipconnect.de] has joined #joinmarket