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