--- Day changed Wed Jan 09 2019
01:35 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
03:07 -!- grubles__ [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection]     
03:21 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has quit [Ping timeout: 252 seconds]     
03:37 -!- Giszmo [~leo@ip-244-228-107-190.nextelmovil.cl] has joined #joinmarket     
04:02 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Ping timeout: 245 seconds]     
04:59 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #joinmarket     
05:01 < waxwing> arubi, bit of a mystery here: see this line: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/286/commits/2258d3c273cf99200d68ce55a9db5d065a831393#diff-576538bae99191302c0fec61fe1c9af9L5
05:02 < waxwing> that was removed in the commit; but strangely, while all the other tests passed, one failed and showed that line as present (i.e. as if the code change hadn't happened) and failed because of it
05:02 < waxwing> specifically this job failed: https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/477257027
05:04 < waxwing> in fact it's not just that line .. it seems that all the flake errors from the previous commit, that  were fixed in that commit, reappeared; it looks like the test was using the wrong version of the files?
05:05 < waxwing> notice how here it passes: https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/477257028#L504
06:47 -!- Giszmo [~leo@ip-244-228-107-190.nextelmovil.cl] has quit [Ping timeout: 244 seconds]     
07:02 -!- Giszmo [~leo@45.232.32.21] has joined #joinmarket     
08:15 -!- gruble___ [~grubles_@unaffiliated/grubles] has quit [Remote host closed the connection]     
08:17 -!- grubles__ [~grubles@unaffiliated/grubles] has joined #joinmarket     
08:52 < arubi> waxwing, that is indeed very weird
08:53 < waxwing> is there some kind of caching error possible? i've never actually figured out what the difference between the various jobs is
08:55 < arubi> it seems that travis was checking commit 5048dde in that job.  the difference is OS and python versions (2 vs. 3)
08:56 < arubi> this is the actual job for "fix flake errors" https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/builds/477257039
09:02 < arubi> so build 961 \ 477257039 was testing commit 2258d3c (which fixed flake), and 960 \ 477257025 was testing 5048dde where the unused imports were still present
09:03 < arubi> I     
09:05 < arubi> I'm not sure why specifically for your PR's travis runs two job variants, one "pr" and second is "push", but they were checking different commits.  maybe a timing issue on github\travis' end
09:10 < arubi> ah, it's checking two branches.  "pr" is checked against master and "push" is checked against your private colorlog branch
09:17 < arubi> so yea I'm almost positive it's a timing thing.  maybe github was "busy" applying your changes to the colorlog branch and travis' clone and checkout of the #286 PR didn't include the changes yet.  I'm wondering if restarting now would fix it.  in any case this is kinda worrying :)
09:21 < waxwing> yeah super weird
09:21 < waxwing> anyhoo here's a bit of fun https://mastodon.social/web/statuses/101387762796750634
09:22 < waxwing> :)     
09:22 < arubi> nice :)  let's see
09:22 < waxwing> i tried asciinema-ing which is kinda cool but i don't know how you can really make it slick if you have two terminals concurrently
09:23 < arubi> tmux? :P
09:24 < waxwing> i just recorded them at the same time but telling people "hit play on both at the same time is ridiculous :)
09:24 < waxwing> arubi, i was wondering that; does it work?
09:24 < waxwing> well i was thinking of screen cos i'm used to it
09:24 < arubi> oh I dunno, never tried
09:24 < waxwing> but thanks for hitting that point i can doubtless research and find out
09:27 < arubi> gonna ask you in private if I got the amount right
09:28 < arubi> aw :(
09:57 < arubi> so nothingmuch got the right amount just after I did (also on the second try), but he says "..this is based on a heuristic that is hard to justify, namely that payment amounts typically have low entropy in their representation, which doesn't seem robust", which I don't agree with.  satoshi amounts might look random, but I'm betting that a lot of the times the payment value in USD\CAD\whatever /is/ actually low entropy
09:59 < arubi> a chain analysis company would probably a database of historical prices they can check a payment amount against, and if some 0.387572 kinda matches 10k CNY or whatever, then it's probably it
09:59 < arubi> would probably have*
09:59 < belcher> iv been calling that "round numbers"
10:00 < belcher> none of the output in that tx seem very round to me...
10:01 < arubi> yea the actual amount is "hidden" in the payjoin
10:01 < belcher> one of them is quite close 55 USD...
10:01 < arubi> ah specifically for this example, the real payment is a round number (in satoshi)
10:02 < belcher> also for any analysis using round numbers you'd need to have a range of around +- 5% because thats what spread usually are
10:02 < arubi> true, but the method is probably useful for deciding which possibilities /not/ to consider
10:02 < belcher> oh is that a payjoin? yes then theres a lot we cant tell
10:02 < nothingmuch> arubi: isn't that just generalizing? in this case if the binary or decimal representation "looks" random but then no longer does given additional information such as fiat exchange rates, then it'd be lower entropy?
10:03 < nothingmuch> or is the "doesn't seem robust" the part you disagree with?
10:03 < arubi> right, I don't agree with doesn't seem robust
10:04 < arubi> it seems easy here because of the round satoshi amount payment, but also the fiat value needs to be considered, and I /think/ that it's a viable test for chain analysis to do
10:04 < belcher> how do you measure entropy or randomness in a number/bits ? even if all the bits were 1 that is still possible
10:04 < arubi> but it would have less chance of being change
10:05 < arubi> also sorry I didn't realize you're in the channel :)
10:06 < arubi> but it /would/ be very hard to know which satoshi amount to test exchange rates against if the payer\payee input correlation is very hard, unlike this example payjoin
10:07 < belcher> oh yes UIH1 can be used there, i just read nothingmuch's tweet (what are mastodon tweets called?)
10:07 < arubi> hehe good question
10:07 < nothingmuch> i think they're called "toots" (or in my case "brainfarts")
10:08 < belcher> ah toots
10:08 < arubi> Toots!
10:08 < arubi> yea     
10:08 < belcher> another great way of finding the change address is if RBF gets used, since presumably successive replacement txes will take away miner fees from the change address
10:09 < belcher> so maybe you could have it taken away from the payment amount instead, or taken away equally from both (or a mixture of all these techniques)
10:09 < nothingmuch> re entropy per amount - i think that's relative to distribution of amounts in the entire blockchain, that a low entropy number has its digits clostered together in the place values
10:09 < arubi> sequence is 4294967294, RBF opt-out :)
10:10 < nothingmuch> s/(?=that)/and/
10:10 < arubi> oh well rbf is out of the question anyway, as you re-sign by everybody
10:11 < belcher> no its not, you can pre-sign all the txes
10:11 < belcher> if you use nlocktime then they can trustlessly be given to some always-on server which broadcasts the replacements once they become valid
10:11 < arubi> you mean pre-sign for rbf if needed?
10:11 < belcher> yes     
10:11 < arubi> right
10:12 < belcher> iv written a github issue somewhere about how that can be used to add RBF to joinmarket
10:12 < arubi> yea now I remember I actually mentioned that for cjxt
10:12 < arubi> well, something close to that
10:12 < belcher> yes     
10:14 < belcher> i wonder if this could be used to find change addresses too https://en.wikipedia.org/wiki/Benford%27s_law
10:14 < belcher> The law states that in many naturally occurring collections of numbers, the leading significant digit is likely to be small.[1] For example, in sets that obey the law, the number 1 appears as the leading significant digit about 30% of the time, while 9 appears as the leading significant digit less than 5% of the time. If the digits were distributed uniformly, they would each occur about 11.1% of the time.[2] Benford's law also makes 
10:14 < belcher> predictions about the distribution of second digits, third digits, digit combinations, and so on. 
10:14 < belcher> apparently its used by tax and fraud offices to help detect when someone is cooking the books
10:14 < arubi> oh that's really interesting
10:15 < belcher> it arises in distributions that span many orders of magnitude, which bitcoin outputs would do
10:16 < belcher> even so its only statistical not exact
10:16 < belcher> for the detecting fraud you use it to raise suspicion to investigate further, and there are many many numbers... but in a bitcoin transaction theres are only 2 numbers
10:16 < belcher> so im not sure how useful it is actually
10:18 < belcher> also if you're aware of the law you can replicate it when cooking your books
10:18 < arubi> yea :)
10:19 < arubi> I'm wondering if it makes sense to always have >2 outputs in a payjoin.  say in the case of 3, maybe payer got two change outputs back or maybe it's payee who was paid to two addresses.  and more combinations are possible if >3 outputs are used.  eventually the problem is as hard as input correlation is hard in a specific tx I think
10:20 < belcher> i think using >2 outputs would reduce the anonymity set, payjoins are trying to blend in with normal payments
10:20 < belcher> >2 outputs means batching which i imagine is less common(?)
10:20 < arubi> hm, maybe if more exchanges do it?
10:20 < nothingmuch> IIRC electrum has a mode where it allows splitting of change outputs
10:21 < arubi> well anything that isn't strictly two outputs is definitely something unusual, at least currently
10:23 < arubi> adding outputs (or not) just depends on if we want to hide the fact that this is a payjoin, or if we want to hide the amount of the payment in a payjoin.  if batched tx's become more common, both can be achieved in a payjoin with >2 outputs
10:23 < arubi> I think ^ :)
10:25 < belcher> theres a website somewhere that tracks the amount of batching
10:26 < arubi> https://p2sh.info/dashboard/db/batching?orgId=1 ?
10:27 < belcher> so maybe 40% of all outputs were batched at the peak
10:27 < belcher> but a much smaller % of txes of course
10:28 < belcher> i dont know if you could use payjoin to hide the payment amount, you can give more possibilities but not enough to be impossible to search
10:29 < belcher> if you're thinking of the situation where alice said she spent $950 on her vacation, and someone searches the entire blockchain for an amount of $950, i dont think payjoin can stop that
10:29 < nothingmuch> can you elaborate on trying to blend in with payments? the main design goal is to create ambiguity when assigning spent outputs to a specific entity, right?
10:29 < waxwing> fwiw the payjoin code currently uses (version 2, locktime current block, and non-rbf); but that can be changed/randomized
10:29 < arubi> what if she pays in multiple transactions?
10:30 < belcher> nothingmuch id say the main goal of payjoin is to break the common-input-ownership heuristic
10:30 < waxwing> nothingmuch, yes but 'blend in' is super-important - we want to make transactions that are not immediately flaggable as coinjoins, too
10:31 < arubi> I guess she could do that without payjoin too, which would hide the true amount of full payment
10:31 < belcher> arubi yes thats the only way i know of to hide amounts apart from CT
10:31 < waxwing> belcher, may be better 'the main goal is violate CIOH but not in an immediately identifiable way' .. debatable i guess.
10:31 < arubi> yea I see your point belcher 
10:31 < belcher> yes, it cant be identifiable otherwise obvious payjoins can be excluded
10:33 < belcher> arubi then the privacy comes from the size of nCk(), so for example if alice pays in 6 transactions then an anonymity set 3000*40 is private, because log(nCk(3000*40, 6), 2) =~ 2^91 (i.e. 91 bits of operation are required to go through every possibility)
10:33 < belcher> (i chose 3000*40 because a block has around 3000 outputs in it, so the above means alice needs to wait 40 blocks)
10:34 < belcher> hopefully my reasoning/maths are right, im only half-sure myself
10:34 < waxwing> i may be wrong but i don't think benford will apply when you're using algos to determine amounts and it gets mostly set by distribution of existing utxo amounts.
10:35 < belcher> yes     
10:35 < belcher> also it works statistically, and one transaction with payment+change is only 2 outputs which is a tiny sample size, so statistics cant help much i think
10:41 < nothingmuch> in the space of a single transaction, if both sender and receiver have multiple outputs then amounts can be obscured
10:42 < arubi> I think it really depends on how hard it is to identify input correlation 
10:42 < nothingmuch> (more or less same logic as the knapsack mixing paper, but applied to payjoin)
10:42 < arubi> if it's really hard, then you do have a lot of options and payment amount is obscured, but I tend to agree with with belcher that eventually the number of possibilities remain very small
10:42 < waxwing> yes, that's basically it; the payment amount is a 'free variable', albeit you can find specific cases where it isn't obscured, it's at *least* an ambiguity of 2 possibilities, often might be 4, and could be considerably more in complex transactions.
10:43 < belcher> i think the knapsack problem only gets too big if the number of outputs becomes impractically huge
10:43 < waxwing> right. i've always just dismissed even attempting to get ambiguity combinatorially, it doesn't feel like a good direction to me.
10:44 < waxwing> but ok, that's too simplistic a position to take :)
10:44 < belcher> also, the combinatorics thing is only an upper bound, there could be even more privacy because of false positives
10:44 < nothingmuch> it scales up quite fast (Bell(43) =~ 2^128), but i think the main weakness is that it also reduces very fast as sub-branches in the partition space are pruned
10:45 < waxwing> right, worst-case vs average case. all seems very meh.
10:45 < belcher> in the alice spending $950 example, if she pays in 3 transactions and an adversary finds the sum of every combination of 3 outputs on the blockchain, the number of results which are close to $950 might be huge just by chance, and that would provide privacy anyway
10:46 < nothingmuch> there's also two distinct scenarios - finding tx(s) of a known amount, vs. inferring amount from tx(s)
10:47 < belcher> yes     
10:47 < waxwing> yes, true. i've always focused more on the latter.
10:47 < waxwing> former seems too hard, and is probably a rare case for analysis
10:48 < nothingmuch> for the latter, multiparty payjoin (but doesn't really apply to joinmarket style negotiation) seems to me like it could benefit from sharding of the payment or change outputs
10:48 < belcher> i think the latter can only be helped by adding a small number of other possibilities, or with CT
10:49 < waxwing> 'sharding' outputs always helps, but it costs
10:50 < belcher> doesnt it only add at most around 20 other possibilities for what the amount is?
10:52 < nothingmuch> if there are n payments with 2n participants and m >= 2n inputs, then i think that's the same as the partition problem over 2n, but with an additional n unknowns
10:52 < nothingmuch> sorry, partition problem over m, not 2n
10:53 < belcher> so m is the number of outputs and n the number of participants?
10:53 < nothingmuch> yes, where it looks like a wasabi style coinjoin but extended with a hypothetical payjoin like mechanism
10:54 < belcher> increasing m costs block space, im trying to find now how quickly the number of required operations grows as m goes up
10:56 < nothingmuch> bell number in the optimal case
10:56 < nothingmuch> (~ exponentially)
10:57 < nothingmuch> as for block space costs - i think that that's somewhat true anyway considering the problem of consolidating inputs without advance knowledge of amounts required to be paid
10:59 < nothingmuch> by combining UTXO consolidation with payjoin (in order to create a maximally useful distribution of spendable coins) i think the cost of that kind of sharding can be kept reasonable (basically front loading the cost of efficient coin selection)
11:35 < waxwing> weird, github bot seems to have gone awol
11:45 < qubenix> waxwing: i think its because of github services being deprecated, irc bot is broke everywhere.
11:46 < waxwing> qubenix, gotcha. i had a memory about that but wasn't sure.
12:27 -!- blabla [534cea7e@gateway/web/freenode/ip.83.76.234.126] has joined #joinmarket     
12:53 < waxwing> arubi, restart build fixed it. yeah must be some weird caching thing i guess.
12:56 < arubi> ah cool.
13:08 -!- grubles_ [~grubles_@unaffiliated/grubles] has joined #joinmarket     
13:12 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit [Ping timeout: 246 seconds]     
13:15 -!- blabla [534cea7e@gateway/web/freenode/ip.83.76.234.126] has quit [Ping timeout: 256 seconds]     
13:31 -!- grubles_ [~grubles_@unaffiliated/grubles] has joined #joinmarket     
13:57 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
14:15 -!- Giszmo [~leo@45.232.32.21] has quit [Ping timeout: 240 seconds]     
14:19 < belcher> does anyone have any thoughts at whats up with this wallet cluster? https://www.walletexplorer.com/wallet/MtGoxAndOthers
14:20 < belcher> i wonder if lots of coinjoins ended up in one cluster which the website operator called "mtgox and others"
14:20 < belcher> apparently mtgox would allow you to import privkeys which it would spend, which would add them to other clusters and thats why it got the name mtgox
14:21 < waxwing> yeah that's what i heard just recently .. can't remember where exactly, but someone pointed out that that's a big pain for (historical) blockchain analysis
14:21 < qubenix> belcher: iirc that wallet could be called "things i don't understand on the blockchain"
14:22 < belcher> that cluster still has transactions going on today
14:22 < belcher> hmm it might be because of address reuse from people who also at some point used mtgox
14:22 < belcher> even so, 8.6 million transactions and 3.6 million addresses
14:23 < qubenix> i think it started as mt. gox and then other stuff (coinjoin) got dumped into it
14:23 < belcher> i dont think joinmarket or wasabi wallet txes are involved
14:24 < belcher> maybe sharedcoin from blockchain.info is though
14:24 < waxwing> we know it's based on CIOH, but how does walletexplorer go "forwards" so to speak, does it have any change identification heuristic? or is it really just CIOH and address reuse?
14:25 < belcher> it doesnt attempt to identify change
14:25 < belcher> unless it can with address reuse
14:27 < belcher> another weird thing, i looked a donation address belonging to thepiratebay (and found 1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM) and when i put it into walletexplorer.com it seems to say that thepiratebay earns a million dollars a day from donations
14:27 < belcher> https://www.walletexplorer.com/wallet/00005c945dba011c?from_address=1z8Tep4BNS79W3kYH8CHA8tWj6nuHYcCM
14:28 < belcher> i think this is explained by thepiratebay using an exchange deposit address as their donation address
14:31 < nothingmuch> waxwing: i believe laurentmt said it here: https://twitter.com/LaurentMT/status/1078638385256902656
14:32 < nothingmuch> at least that's where i first heard of this
14:35 < waxwing> yes, thx
14:36 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has joined #joinmarket     
14:42 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit [Remote host closed the connection]     
14:43 < belcher> oh wow, ive just found one of my addresses is in MtGoxAndOthers
14:43 < belcher> this joinmarket donation payout transaction pays to MtGoxAndOthers according to walletexplorer https://www.walletexplorer.com/txid/5567d2f29518ecdb6c8a33d140258eb8338b7407cfbede0ff5e6d960c1703fe8
14:44 < belcher> turns out one of those addresses belongs to me
14:44 < belcher> the other address belongs to someone else (i wont say who because privacy)
14:44 < waxwing> yeah istr one of my addresses at some point showed up in there.
14:44 < belcher> but both are joinmarket addresses
14:44 < waxwing> in the mtgoxandothers
14:44 < belcher> so looks like some joinmarket transactions are in MtGoxAndOthers
14:45 < waxwing> yeah an address in one of my jm wallets
14:45 < waxwing> basically it's all rubbish, but it is interesting to try to figure out how something like that happens
14:45 < belcher> yeah thats whats confusing me slightly
14:45 < belcher> basically MtGoxAndOthers is a cluster with many coinjoins, including mtgox who started doing doing it before it was cool
14:46 < waxwing> hmm .. back in the day it was possible to use your bitcoind wallet with Jm, right. that could possibly explain it?
14:46 < waxwing> or ... /confused
14:46 < belcher> who knows :D
14:47 < waxwing> basically, Tibanne is running joinmarket
14:48 < belcher> this also looks like another massive cluster https://www.walletexplorer.com/wallet/00000014ea8b260f
14:48 < belcher> 22 million transactions and 13 million addresses
14:48 < belcher> so about 10x bigger than MtGoxAndOthers
14:49 < belcher> it also once donated to joinmarket which is how i just found it
14:50 < belcher> see in this example it knows the other address is a change address because the address 1AZgQ... was reused https://www.walletexplorer.com/txid/2488b1a647c4add674775cefb6fa5fda8309be49d7100d07dc68eb50bc52a471
14:50 < belcher> but then in another example the change is not labelled as change (?!) https://www.walletexplorer.com/txid/d3b517eea7b11a6772c0b3080678f8ffd3294dd90729745bdaefa691ad24dd84
14:52 < nothingmuch> scarily, there was a talk at SHA2017 where the speaker claimed that walletexplorer was used as evidence in a dutch court case with no technical details given for its heuristics: https://www.youtube.com/watch?v=ogpNvgrL_BQ
14:53 < nothingmuch> 35:40
14:53 < waxwing> yeah, think i saw that.
14:53 < belcher> astonishing
14:54 < waxwing> if they just use it as circumstantial evidence, and *then* build actual evidence, it's not really wrong. but as i've said a few times, someone is going to get wrongly convicted at some point because of this.
14:55 < nothingmuch> unfortunately i have not been able to find any followup information, at the time of the talk it wasn't brought to trial yet
14:59 < belcher> has anyone emailed that guy?
14:59 < belcher> he says at the end of his talk that he doesnt understand the algorithm walletexplorer uses but it would be good if hackers/developers talked to lawyers more
15:00 < belcher> ty for the video nothingmuch 
15:00 < waxwing> belcher, sjors has posted details on a number of dutch cases on twitter in the last 6 months, with similar points of note
15:01 < waxwing> e.g. he points out a case where a dutch court accepts chainalysis as evidence black box, and when the defence questions they say "show us evidence from a different tool"
15:01 < waxwing> part of the problem is that money laundering is completely beyond reason, it's "guilty until proven innocent".
15:02 < belcher> it shouldnt be too hard to explain COIH and all the situations where its wrong
15:02 < waxwing> in this circumstance kerckhoff's law approaches to cryptographic security are not as helpful as they seem
15:02 < waxwing> heh, good luck explaining it to a judge.
15:02 < belcher> to provide enough reasonable doubt, though as you say if the law is "guilty until prove innocent" then theres not much chance
15:03 < belcher> i dont think its that hard? judges are intelligent people arent they? you can have a big diagram of a bitcoin transaction with inputs and outputs and then explain how COIH implies all the inputs are owned by the same person and how that gives rise to these clusters
15:03 < waxwing> it is indeed too hard imo. for such scientific things they rely on expert advice.
15:03 < nothingmuch> yeah i was just looking for those tweets, haven't found them yet
15:04 < waxwing> was a while back, sorry. maybe summer-autumn ish. there were quite a few. i think he also blogged a little bit about the problem.
15:06 < waxwing> but while it's too hard, i do think it's scandalous to accept black box "evidence" from a company. stuff like that does happen in law, though, i think in other fields too (not an expert of course).
15:06 < nothingmuch> here's one thread linking to an article that has a few more of his tweets linked https://twitter.com/provoost/status/984466076812574721 
15:07 < nothingmuch> https://twitter.com/provoost/status/980103155110305793 i think this is the one
15:07 < waxwing> ah earlier, sorry
15:08 < waxwing> yes that second one was the one i was thinking of
15:16 < waxwing> interesting, just reading Henninger et al's new "biased nonce-sense" paper and they quote that 40M out of 440M keys on the blockchain have made more than one signature
15:16 < belcher> i suppose show that COIH sometimes doesnt work isnt the same thing as showing a concrete false positive case 
15:17 < waxwing> https://eprint.iacr.org/2019/023.pdf
15:17 < belcher> more than one signature, so address reuse?
15:17 < waxwing> belcher, yeah probably there should be an initiative to prove failure
15:17 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has quit [Ping timeout: 246 seconds]     
15:17 < waxwing> yeah i'm reading that as implying address reuse .. only of tangential interest i guess.
15:18 < waxwing> i guess multisig etc etc so it's prob not exactly true
15:18 < belcher> that could happen if you had one of the addresses belonging to MtGoxAndOthers and used it to buy drugs and then someone else who also had a MtGoxAndOthers and is also a legit exchange pays money to someone
15:18 < waxwing> oh but "8% of the signatures in our snapshot
15:18 < waxwing> had been generated by one of these keys."
15:18 < waxwing> sorry that's 58%
15:19 < waxwing> and "one of these keys" means one of the ones multi-used
15:24 < nothingmuch> fwiw the linked court documents mention R. Jonkers, the speaker in that talk. i'm having a hard time making sense of the google translated version
15:25 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has joined #joinmarket     
15:28 < nothingmuch> sorry, no the speaker, his partner at that firm
15:46 < belcher> waxwing i see they didnt resync an ethereum node like they did for bitcoin
15:46 < belcher> because sync'ing an ethereum node seems to be impossible :p
15:48 < waxwing> heh, good catch
15:49 < waxwing> also the corresponding figure is 95% , somewhat interesting
15:51 < nothingmuch> isn't that because of its account (as opposed to txo) based model?
15:52 < waxwing> yeah i guess so (hence my 'somewhat' .. not an expert, but it's *probably* not surprising)
15:59 < nothingmuch> https://twitter.com/provoost/status/1036592110940684288 # another interesting thread from sjors
16:07 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has quit [Ping timeout: 268 seconds]     
16:08 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has joined #joinmarket     
16:49 -!- grubles_ [~grubles_@unaffiliated/grubles] has joined #joinmarket     
16:53 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit [Ping timeout: 250 seconds]     
17:32 -!- grubles_ [~grubles_@unaffiliated/grubles] has joined #joinmarket     
17:44 -!- AgoraRelay [~jmrelayfn@p5DE4ABC7.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
17:54 -!- v_unimportant_pe [~user@185.244.215.51] has quit [Ping timeout: 244 seconds]     
17:55 -!- AgoraRelay [~jmrelayfn@p5DE4ABD0.dip0.t-ipconnect.de] has joined #joinmarket     
18:05 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds]     
18:08 -!- AgoraRelay [~jmrelayfn@p5DE4ABD0.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]     
18:16 -!- achow101 [~achow101@unaffiliated/achow101] has joined #joinmarket     
19:00 -!- Nam1 [187de310@gateway/web/freenode/ip.24.125.227.16] has joined #joinmarket     
19:00 < Nam1> hello
19:05 -!- Nam1 [187de310@gateway/web/freenode/ip.24.125.227.16] has quit [Ping timeout: 256 seconds]     
19:10 -!- Giszmo [~leo@pc-247-63-74-200.cm.vtr.net] has quit [Ping timeout: 268 seconds]     
19:28 -!- Giszmo [~leo@ip-95-228-107-190.nextelmovil.cl] has joined #joinmarket     
20:25 -!- AgoraRelay [~jmrelayfn@p54866768.dip0.t-ipconnect.de] has joined #joinmarket     
20:38 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds]     
20:39 -!- grubles__ is now known as grubles     
20:49 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #joinmarket     
21:06 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit [Remote host closed the connection]     
21:08 -!- grubles_ [~grubles_@unaffiliated/grubles] has joined #joinmarket     
21:39 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit [Remote host closed the connection]     
21:51 -!- grubles_ [~grubles_@unaffiliated/grubles] has joined #joinmarket     
21:55 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit [Ping timeout: 272 seconds]     
22:19 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds]     
22:33 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #joinmarket