--- Day changed Mon Jun 27 2016
00:51 -!- molly [~molly@unaffiliated/molly] has joined #joinmarket
00:54 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
01:30  * adlai investigates an odd bug; brushing dust off a wallet unused for a while, there's an endless loop of address importation. printing the wallet index reveals that it's stuck on the same index
01:31 < adlai> this is happening with two wallets, one on a different computer from the one used to run the yield generator, and one on the same computer (!)
01:34  * adlai adds more log.debug
02:03 < adlai> joy, looks like bitcoind wallet corruption. getaccount returns 85 times ^A for these addresses
02:04 < adlai> has much thought been given to a mode not dependent on the wallet/account feature? it'd be a lot less efficient, but more robust in the face of bitcoind wonkyness
02:29 -!- dont [68eea957@gateway/web/freenode/ip.104.238.169.87] has joined #joinmarket
02:30 < dont> what sup?
02:53 < adlai> nice nick
02:53 -!- dont [68eea957@gateway/web/freenode/ip.104.238.169.87] has quit [Ping timeout: 250 seconds]
02:54  * adlai is manually importing addresses with mystery failures
04:00 < waxwing> adlai: mystery failures, what error msg?
04:01 < waxwing> i did some analysis of the wallet import, came to the conclusion that normally you just need to rerun multiple times, and preferably bump addr_req_count in the code first.
04:01 < waxwing> re: not depending on wallet/account feature, that's actually why i like the idea of something like the electrum plugin, albeit there's a lot to figure out there.
04:02 < waxwing> adlai: (progress on that here: https://github.com/AdamISZ/electrum-joinmarket-plugin) - it works as a first stab at it, but of course it's not really joinmarket yet...
04:30 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
06:19 -!- kcud_dab is now known as bad_duck
06:32 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket
06:32 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Client Quit]
06:37 < belcher_> oh my 16% miner fees
06:38 < belcher_> its probably partly from the perverse incentives in joinmarket regarding miner fees
06:38 < belcher_> makers can send any number of UTXOs knowing the takers will pay for them all to be mined
06:39 < waxwing> belcher_: you prob saw my comment, but while that's 100% true, i think even totally normal maker behaviour can end up with > 100k fees quite easily
06:39 < belcher_> ok
06:39 < waxwing> like eg 3kB tx size with 50k /kB
06:40 < belcher_> i guess joinmarket txes dont really have a need to be confirmed quickly
06:40 <+JM-IRCRelay> [AlexCato] also the bitcoin-core fee estimation seems to adjust downwards very slowly... even though the mempool is empty (or only containing very low fee transactions), the btc-fee-estimation is still very high
06:40 < belcher_> ah
06:40 < belcher_> iv read some of the code for https://bitcoinfees.github.io/
06:41 < belcher_> it uses a monto carlo to solve a model for the tx fees
06:43 < belcher_> the 6-block fee is the most volatile, going from a low of 5000 satoshi to 58000 sometimes
06:44 < belcher_> i guess its harder to model for higher block delays, but data for a delay of 144 blocks (24 hours) could be useful, since some people wouldnt mind waiting
06:45 < belcher_> in the long term, coinswap on joinmarket could replace today's tumbler script and be cheaper
06:45 <+JM-IRCRelay> [AlexCato] makers re-use their unconfirmed transactions after 10 hrs though, right?
06:45 <+JM-IRCRelay> [AlexCato] havent looked at the code, just seen the config
06:45 < belcher_> not to my knowledge, unless its been added by someone else and i didnt see
06:46 < belcher_> there is code for timing out of unconfirmed txes, but its only used by tumbler
06:48 < belcher_> ah, the tumbler doesnt even make use of the timeout for the tx being confirmed
06:48 < belcher_> so by default it will timeout after 6 hours, printing a message 'timed out waiting for confirmation' and then do nothing else
06:49 < belcher_> though its coded to always pay high fees so thats unlikely to happen
06:51 < belcher_> looking at the recent blocks, total fees are 0.5 - 1btc, i remember when it was <0.1btc, that looks good for the eventual transitioning to miners funded by fees
06:51 <+JM-IRCRelay> [AlexCato] but its true, unless fees go down somehow soon, there probably should be some kind of warning that tumbling small amounts is very, very expensive compared with centralized tumblers
06:51 < belcher_> yes agreed, maybe on the wiki guide 
06:51 < adlai> make people type in the fee to confirm sending! no excuses for ignorance.
06:52 < belcher_> ofc its irritating for users of on-chain transactions, we'll have to be as efficent as we can with the scarce blockchain space
06:52 < belcher_> definitely more configuration for miner fees might be useful, like a ceiling on fee/byte paid
06:52 < belcher_> adlai: do you know about how #156 is being actually exploited now ?
06:53 < belcher_> this: https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b which i will post everywhere when i get the chance
06:53 < adlai> belcher_: i noticed it, it's quite annoying
06:55 < adlai> i think p2ch is the right solution, because it's a flat overhead for tumbler runs, but linear for people doing individual sendpayments (or spying)
06:55 < belcher_> g2g afk
06:56  * adlai doesn't see how coinswap is not vulnerable to this attack, if makers still begin the protocol for free
07:25 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #joinmarket
07:47 < belcher_> adlai: ok ill remove it since im not 100% on it
08:02 < waxwing> belcher_: there is a ceiling on fee/byte paid
08:03 < waxwing> PR a month or two back
08:03 < belcher_> ok nice
08:30 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
08:32 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
09:13 -!- raedah [~x@172.58.40.9] has joined #joinmarket
09:13 < raedah> chain analysis  https://www.youtube.com/watch?v=BNqGW96BWe0&t=12m30s
11:03 < gmaxwell> I don't know why the high overhead technique of p2ch would get implemented before the input reuse blacklisting (e.g. using the proof of equivilent discrete log) would get implemented first.  With the blacklisting, someone could use each input once, but without having to move their coins before every transaction.
11:05 < OverlordQ> Oh wow, new mining pool, HaoBTC
11:13 <+JM-IRCRelay> [AlexCato] @waxwing: requested logs sent via email
11:13 < waxwing> thanks
11:14 < waxwing> any update on what you saw? it just wouldn't reconnect, but after manual restart, it did?
11:14 <+JM-IRCRelay> [AlexCato] theres both a successful recover and a non-recovery in there, so hopefully it helps
11:14 <+JM-IRCRelay> [AlexCato] and yes, manual restart solved it. Automatic recovery did not work
11:14 < waxwing> hmm weird; like i said i did a manual kill and it reconnected fine.
11:15 < waxwing> it should really, that part of the code is unchanged apart from that it flags the message channel state
11:15 < waxwing> anyhoo i'll look at the log in a bit, cheers
11:15 <+JM-IRCRelay> [AlexCato] yeah, non-deterministic bugs just suck. I have no explanation so far
11:15 < waxwing> gmaxwell: yeah well that was our general feeling, but it seems there are still things to consider
11:16 < waxwing> gmaxwell: i wrote a blog post about PoDLe and some thoughts about how to do it: https://joinmarket.me/blog/blog/poodle/
11:16 < waxwing> comments/corrections welcome
11:16 < gmaxwell> Cool.
11:18 <+JM-IRCRelay> [AlexCato] oh, in the log there's some entries which you will not have seen before, waxwing... thats my way to block the spammer, which sadly is security-by-obscurity and would not work if everyone did it that way. You can safely ignore messages like the one in timestep 7075 and 7077 of the log
11:19 <+JM-IRCRelay> [AlexCato] they have nothing to do with the bug though
11:22 < gmaxwell> waxwing: if you want to allow reuse three times, have three alternative generators.
11:22 < gmaxwell> waxwing: and the user is allowed to use any of the three.
11:22 < gmaxwell> their choice (which they pick at random excluding the ones they've already used)
11:23 < waxwing> ah, coincidence, i was thinking about the idea of using multiple different generators in a different context. yes, that's a nice idea, thanks.
11:23 < waxwing> alexcato got it, noted
11:23 < belcher_> nice blog post waxwing
11:23 < waxwing> ah ok, i posted it before, never sure when things will get seen :)
11:24 < belcher_> a good summary
11:24 < waxwing> re: i was thinking earlier, i was thinking this: xG, x^2G, x^3G etc .. where each one is proved to be the same as x as the last.
11:24 < waxwing> build a polynomial .. but, just a thought :)
11:25 < waxwing> (i know this is not what you meant, just a vaguely similar concept)
11:27 < gmaxwell> instead of using a broadcast medium you could use N servers, and then reject if any of them tell you of a conflict. This would be more bandwidth efficient. 
11:28 < waxwing> yes, i guess that's what we effectively have now on the new multiple message channel PR. currently a couple of us are running our bots on multiple IRC servers.
11:29 < waxwing> re: multiple NUMS generators, i guess one plays the same coerce trick as previously (hashing x) ad infinitum.
11:30 < waxwing> i remember that the monero guy started out with 123456 :)
11:31 < belcher_> binary digits of pi ? sha256 of the first lines of the iliad ?
11:31 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 276 seconds]
11:31 < waxwing> i have long been of the opinion that the NSA has backdoored the number 7 :)
11:32 < gmaxwell> waxwing: you need to start with the existing generator just to prove it wasn't generated with respect to the nums number you're coming up with.
11:32 < gmaxwell> H(G||index||counter) or whatnot. 
11:39 < waxwing> gmaxwell: if G_2 is nums, why wouldn't G_3 = H(G_2.x) be ok as another nums?
11:41 < gmaxwell> Thats good too, though you may need a counter H(G_2.x) may not be on the curve.
11:41 < gmaxwell> (you don't want to just increment x because that will result in a non-uniform point selection, ... not that it matters for this)
11:41 < waxwing> right, the issue like was had the first time. but ofc not saying your suggestion isn't good, it sounds neater really.
11:43 < gmaxwell> when I did CT I found that one of the reasonable seralizations of the pubkey gave me a point on the curve, so I didn't need to add an explicit counter.
11:50 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #joinmarket
12:02 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
12:04 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
12:20 < OverlordQ> Lawl, so easy to get de-anon agent to poke his head up
12:21 < OverlordQ> Just need to figure out the best way to hook in to ignore it's requests
13:34 < OverlordQ> Coudln't resist: http://hastebin.com/tulapupequ.xml
13:47 < fluffypony> my talk from Arnhem is finally up
13:48 < fluffypony> let me find the JoinMarket bit
13:48 -!- fqtw_ [~me@x5d803014.dyn.telefonica.de] has joined #joinmarket
13:48 -!- fqtw [~me@x5d8042ca.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
13:51 < fluffypony> https://www.youtube.com/watch?feature=player_detailpage&v=YVlQE-ObEXk#t=847
13:51 < fluffypony> there ya go
13:53 <+JM-IRCRelay> [AlexCato] great!
13:53 <+JM-IRCRelay> [AlexCato] sadly the url is kinda not readable in the vid and probably wasnt in the live event either :)
13:54 <+JM-IRCRelay> [AlexCato] oh, you're saying it. nvm!
13:55 < fluffypony> yup don't worry
13:55 < fluffypony> I noticed
13:55 < fluffypony> lol
14:03 < waxwing> thx fluffypony
14:03 < waxwing> think i'll watch the first half :)
14:04 < fluffypony> feel free - it's mostly reasons why we need financial privacy, and then a criticism of bad Bitcoin privacy mechanisms like mixers
14:10 < waxwing> issues with secp256k1, i wonder what you were thinking of there? (as separate from ecdsa)
14:11 < fluffypony> waxwing: http://safecurves.cr.yp.to 
14:11 < waxwing> "MPC"!! 
14:11 < waxwing> (sorry in joke)
14:12 < fluffypony> spoke to djb and Tanja Lange about it at Ei_PSI's "Security in Times of Surveillance" conference, and I asked them if the issues they highlighted could lead to practical attacks
14:12 < waxwing> fluffypony: yeah i know but a lot of stuff ends up being "djb said it" but it turns out mostly it depends on implementation
14:12 < waxwing> sorry 'yeah i know' refers to the safecurves page
14:12 < fluffypony> they basically said that the issues were largely theoretical, but that many theoretical attacks become practical alter on 
14:13 < waxwing> a lot of people end up thinking you can't be sidechannel safe unless you go full djb :)
14:13 < fluffypony> I don't prescribe to the Cult of djb, but I also don't ignore what he and Tanja say
14:15 < waxwing> e.g. there are people who actually say "you should use ed25519 because it has deterministic signing", like you can't do it with ecdsa...
14:15 < fluffypony> oh yeah those people are dumb
14:16 < fluffypony> in fact those people exist in many places
14:16 < fluffypony> such as here: https://github.com/zcash/zcash/issues/715
14:16 < waxwing> so while i'm on the topic, what is the story re: pruning and monero? afair that's the objection usually raised.
14:17 < fluffypony> waxwing: txos are never provably spent, so no utxoset; we prune down to the full txoset + the key image set (1 key per actually-spent output)
14:18 < OverlordQ> Ignore my spamming in the pit lol, just (ab)using the person trying to datamine txo's
14:18 < fluffypony> so we can still prune down pretty small, but not as relatively small as Bitcoin
14:19 < waxwing> OverlordQ: i wouldn't bother, although if you're fingerprinting for your own purposes, good for you, obv it can't permanently work
14:20 < OverlordQ> well I did get somebody zlined :) so hopefully a small reprieve
14:20 < gmaxwell> it would be good to figure out who is attacking the system and why.
14:21 < waxwing> would it? i'm not so sure, the problem is that their behaviour isn't fundamentally different from good behaviour and the nearer they get to normal behaviour the more dodgy it'll get to counter-attack them
14:22 < OverlordQ> Well I've noticed some things it does that can fingerprint them, but wont say it in here, since they're probably watching
14:22 < gmaxwell> Because certan strategies might be more effective against different parties?
14:24 -!- grubles is now known as dingus
14:25 < gmaxwell> In addition to the technical improvements which are obvious must do, there are additional steps that can be taken E.g. is it a commercial deanon service?  Making it clear their actions are unlawful might be highly effective.  Is it someone just lulzing? reducing attention may be effective.  Is one one of those crappy "mixer" services? responding by a campaign to make sure no one ever uses their servic
14:25 < gmaxwell> e to put them out of business may be effective.
14:25 < gmaxwell> Even among the technical measures, having some idea how much these attackers may be willing to spend might inform development priorities.
14:26 < fluffypony> gmaxwell: you think it might be Chainalysis or similar?
14:26 < fluffypony> never even considered that possibility
14:26 < gmaxwell> These companies sybil attack the bitcoin network.
14:27 < fluffypony> I remember 
14:27 < gmaxwell> it's a possibility.
14:30 < waxwing> tbh i always assumed it was one of those :) or at least, i put it at a high probability
14:31 < waxwing> specifically, the recent behaviour starting about a month ago
14:31 < fluffypony> they certainly have the money
14:33 < gmaxwell> Well, not really, once you consider the legal exposure they're taking on.
14:33 < waxwing> PR with legal/contractual agreement would be accepted :)
14:33 < waxwing> well, depending on the terms, obv :)
14:36 < gmaxwell> Right.
14:38 < gmaxwell> Regardless of what legal stuff in in JM though any JM user harmed by this would have an independant civil cause of action.
14:45 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket
14:45 -!- grubles is now known as buttsniff
14:55 -!- fqtw [~me@x5d8065d6.dyn.telefonica.de] has joined #joinmarket
14:57 -!- buttsniff [~grubles@unaffiliated/grubles] has quit [Ping timeout: 260 seconds]
14:57 -!- fqtw_ [~me@x5d803014.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
14:58 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 246 seconds]
14:59 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #joinmarket
15:08 -!- dingus is now known as grubles
15:12 -!- Iriez [wario@distribution.xbins.org] has quit [Quit: changing servers]
15:13 -!- Iriez [wario@distribution.xbins.org] has joined #joinmarket
15:14 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
15:17 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
15:43 -!- fqtw_ [~me@x5d804b8a.dyn.telefonica.de] has joined #joinmarket
15:46 -!- fqtw [~me@x5d8065d6.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
15:47 < OverlordQ> aww yeah, working good till they fix their bug, bug *shrug*
15:59 -!- fqtw [~me@x5d803563.dyn.telefonica.de] has joined #joinmarket
16:02 -!- fqtw_ [~me@x5d804b8a.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
17:11 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 250 seconds]
17:16 -!- waxwing [~waxwing@62.205.214.125] has joined #joinmarket
17:33 -!- fqtw_ [~me@x5d803bf9.dyn.telefonica.de] has joined #joinmarket
17:36 -!- fqtw [~me@x5d803563.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
18:38 -!- fqtw__ [~me@xd93257c5.dyn.telefonica.de] has joined #joinmarket
18:42 -!- fqtw_ [~me@x5d803bf9.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
18:55 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 276 seconds]
19:08 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #joinmarket
21:12 -!- fqtw [~me@x5d80118b.dyn.telefonica.de] has joined #joinmarket
21:14 -!- fqtw__ [~me@xd93257c5.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
22:29 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 260 seconds]
22:51 -!- Cory [~C@unaffiliated/cory] has joined #joinmarket
22:54 -!- fqtw_ [~me@x5d803df9.dyn.telefonica.de] has joined #joinmarket
22:55 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
22:57 -!- fqtw [~me@x5d80118b.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
23:40 -!- MattRK [~MattRK@ip98-168-128-134.ok.ok.cox.net] has quit [Quit: Leaving]
23:41 -!- MattRK [~MattRK@ip98-168-128-134.ok.ok.cox.net] has joined #joinmarket
23:56 -!- p15 [~p15@155.91.145.64.unassigned.bringover.net] has joined #joinmarket