--- Day changed Sun Feb 19 2017 00:22 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 01:08 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection] 03:21 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection] 03:22 -!- juscamarena [~justin@47.148.176.74] has joined #joinmarket 03:22 -!- juscamarena [~justin@47.148.176.74] has quit [Client Quit] 03:27 -!- MaxSan [~one@194.187.251.155] has joined #joinmarket 04:13 -!- MaxSan [~one@194.187.251.155] has quit [Ping timeout: 260 seconds] 05:04 -!- MaxSan [~one@194.187.251.155] has joined #joinmarket 05:21 < waxwing> was just thinking again about possible #693 solutions, copy-pasting here in case anyone has any thoughts on it (693 is the "one wallet, duplicate bots" problem) 05:21 < waxwing> it's almost like, what you want is a crypto primitive that creates an object O that preserves privacy, but when you combine O1 and O2, if one of the hidden components inside them is equal, it triggers an event, such as changing the result to zero, or results in some other kind of failure 05:21 < waxwing> another thought; not scalable but *otherwise* makes sense? each maker publishes !hp2 (u1) !hp2 (u2) .. (all his utxos) along with his offer. 05:21 < waxwing> where here hp2s are still podles, but now only one globally agreed basepoint (no 3 tries etc.) 05:21 < waxwing> keeps privacy, but now cannot re-use across different bots. 05:21 < waxwing> as new txs are created, publishes new podles 05:21 < waxwing> this isn't scalable in the publish (e.g. 50 utxos) and is also a bit unwieldy in the protocol, as would have to send the taker podle signatures on each used utxos. 05:21 < waxwing> is there something else wrong here apart from scalability though? 05:47 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #joinmarket 06:36 < belcher> waxwing so spent utxo podles cant be revoked? 06:37 < waxwing> i was thinking it would make sense to ban only the second publisher of any one podle, because otherwise a DOS maker can just republish the previous maker to get him banned, based on the idea that podles are not predictable in advance this makes sense, BUT: 06:37 < waxwing> the problem there is, if you disconnect and come back on with a different nick, you "republish". 06:38 < waxwing> belcher: yeah good point that'd have to function like !cancel i guess. 06:38 < belcher> if you have the cancel, why is it not scalable? it still just announces O(#utxos) 06:38 < waxwing> it's a *lot* of publishing going on 06:39 < belcher> takers download O(#all maker's utxos) data 06:39 < belcher> an alternative to cancel could be timeouts 06:39 < waxwing> ok yeah i mean, it's not bad scaling, my mistake using that word; it's more 'scale' than 'scaling' 06:39 < belcher> so a disconnected and rejoining bot can wait for the timeout and reannounce... BUT a malicious DOSer might reannounce first which would be bad 06:40 < belcher> waxwing could the commitment somehow include the time? so the commitments become invalid after some time 06:40 < waxwing> yeah it seems to me quite a *lot* of this category of ideas suffers from this kind of "kick off other people by behaving in a way that would be bad if you were them" :) 06:40 < waxwing> belcher: i would think so yeah 06:41 < waxwing> we could operate in time slices, one base point per time slice 06:41 < belcher> ah yes because you can generate new points in a deterministic sequence 06:42 < waxwing> global time is left as an exercise to the reader :) 06:42 < belcher> global time just comes from the blockchain 06:42 < waxwing> oh yeah, i knew bitcoin was useful for something :) 06:43 < waxwing> codebase has 256 pre-set NUMS points already. not that it matters really. 06:43 < belcher> so the only downside is the data..? we've already seen the 'announcing lots of offers' method for forcing takers to download lots of data 06:44 < waxwing> i don't know maybe; i'm still not clear whether time can solve the problem of republishing being OK for you, but not for an attacker. 06:45 < waxwing> i was wondering whether some kind of signing could solve that problem. 06:45 < belcher> you need the private key to create the podle i believe 06:46 < waxwing> also i'm worried that there are privacy implications, simple example being that when you re-join the pit, you no longer have anonymity wrt your previous connection 06:47 < belcher> my thinking was the DOSer can stop you if you disconnect/reconnect and they announce your PODLEs first, but with the timeout they only stop you for some time rather than forever 06:47 < waxwing> yeah but if an attack is only to re-publish the hp2 itself, there is no requirement for privkey. it's about whether we ban at the republish step itself. 06:47 < waxwing> belcher: yeah, gotcha 06:48 < waxwing> well, hmm if you rejoin in a different time slice, maybe there's still some delink of identity, but it rather depends on time granularity too 06:48 < belcher> although you lose privacy between connections, any spy still only learns your commitments rather than any utxos 06:49 < waxwing> yes, absolutely, i was worried that it kind of devolves to the "fixed nick" case, and that number of utxos also leaks. to be fair, people used to actually use fixed nicks anyway. 06:50 < waxwing> i mean it doesn't literally devolve all the way to that, but maybe some of the way. 06:50 < belcher> i cant think why leaking #utxos is a bad thing 06:50 < waxwing> what would of course be nice is to somehow "wrap up" the long list of podles, eg a tree, but when you go down that road it's too easy to mess around faking or tweaking the list. i guess. 06:50 < belcher> one thing is all our talking about first and second announcements happen each time a taker says !orderbook, every time that happens the true maker and the DOSer will be in a race to reply to the taker 06:51 < waxwing> ah hmm yes you're right, it's really more about the response-to-orderbook, not so much the public channel 06:53 < belcher> so the issue with podles is they can be replayed 06:54 < belcher> how about challenge-response, a taker says !orderbook [nonce] and each maker replies with a podle that includes the nonce and therefore cant be replayed 06:54 < waxwing> well in general it isn't an issue when they function as commitments. but if we take banning action on them, before opening, then yeah it's an issue. 06:55 < waxwing> yeah something like that could work. i was thinking more about signing, but that's good - it takes advantage of the fact that we're already in an interactive scenario. 06:55 < belcher> on the other hand.. it means it can only work with taker's saying !orderbook and not with just annoucing to the public channel 06:55 < waxwing> so to be clear, we're ignoring the public channel messages here? 06:55 < waxwing> snap :) 06:56 < belcher> so long-running takers would have to say !orderbook every so often, which is bad for scale/amount of data transmitted 06:56 < belcher> so maybe challenge-response for !orderbook combined with time-ticking-podles for public channel announcements 06:57 < waxwing> i'm not clear whether that's an issue per se. consider tumbler - it only needs to update its orderbook when it does a new tx, not very common. 06:57 < waxwing> just basically tumbler acting as a sequence of sendpayments would. 06:57 < belcher> thats true, and the same is true for bitcoin-qt-integration where it could say !orderbook before every transaction 07:00 < belcher> waxwing remember makers have an incentive to keep the number of their utxos low because it costs miner fees to spend more of them 07:01 < waxwing> hmm was i overcomplicating things, could we delay ban until commitment opening? 07:01 < belcher> how does that work? 07:01 < waxwing> no, sorry, confused 07:01 < waxwing> i forgot which attack we're defending against :) 07:02 < belcher> but the data usage thing is an issue as we saw with the publish-lots-of-offers thing that AlexCato was fixing 07:02 < waxwing> yes, i think it's a fairly big issue without a better message channel. 07:02 < waxwing> we can truncate hp2s to 16 bytes, maybe a bit less with encoding. 07:03 < belcher> the issue with that fix of limiting offers-per-nick, but a DOSer can connect with many nicks 07:03 < waxwing> sorry 16 bytes = 32 chars hex i meant 07:03 < belcher> how was the too-many-offer thing actually a DOS? 07:03 < belcher> was it any more than just annoying.. since service wasnt denied i dont think 07:03 < waxwing> not clear at all; but do you remember that sql cursor crash thing? 07:04 < belcher> yep 07:04 < waxwing> if you remember i had great trouble reproducing, but i tend to think more likely than not, it was a result of that 07:04 < belcher> another issue is right now the sql database is in RAM, but it would be fine to make sqlite store it on disk instead 07:04 < belcher> the sql cursor thing was almost certainly a synchronization issue i think 07:05 < waxwing> but just generally why should we allow people to publish huge quantities of data to IRC? it's like, even if they're wrong that they're getting an advantage, it's *much* better to just kill it and forget about it. 07:05 < waxwing> well it was two threads trying to access db at same time, no doubt about that. 07:05 < belcher> yep 07:05 < waxwing> my only doubt was whether it was happening because of huge offer-lists, i think so, but can't be sure. 07:06 < belcher> so the limit-number-of-offers-per-nick works to stop people doing dumb things that dont actually help them (which is a good outcome) but doesnt stop a determined DOSer, although a determined DOSer cant do much anyway 07:06 < waxwing> yes, let's say. i'm reasonably confident nobody was trying to kill the system via DOS, I think they were just trying to get advantage. 07:08 < belcher> do you want to write up the maker-utxo-podle-commitment idea into a gist/blog post? 07:09 < waxwing> sure,but it's ill formed at the moment. i'll write down the outline to 693 though. 07:10 < belcher> whats ill-formed about it? 07:10 < waxwing> i *think* your nonce idea is a good one. that probably improves it a bit. 07:10 < waxwing> ill-formed, well i mean more like not fully formed. 07:10 < belcher> ah 07:11 < belcher> writing a blog post or gist hopefully helps with that because it makes the author have to think it all through 07:11 < waxwing> yes, but i think i'll write an outline to 693 first. give those interested a bit more time to digest, including me. 07:11 < waxwing> you can add your additional thoughts there 07:12 < belcher> ok 07:17 < belcher> the idea seems good so far :) it might solve the issue 07:17 < waxwing> someone needs to get cracking on #650 then :) 07:18 < waxwing> i started writing it but will probably -> dinner now, so later 08:24 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 08:27 -!- coins123_ [~coins123@37.159.49.112] has joined #joinmarket 08:29 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 260 seconds] 08:35 -!- MaxSan [~one@194.187.251.155] has quit [Ping timeout: 268 seconds] 08:39 -!- stachrom [d4338865@gateway/web/freenode/ip.212.51.136.101] has joined #joinmarket 08:58 -!- coins123_ [~coins123@37.159.49.112] has quit [] 08:58 -!- coins123 [~coins123@37.159.49.112] has joined #joinmarket 08:58 -!- coins123 [~coins123@37.159.49.112] has quit [Changing host] 08:58 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 10:02 < waxwing> https://github.com/JoinMarket-Org/joinmarket/issues/693#issuecomment-280936089 10:06 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection] 10:07 < waxwing> hmm,no, error - the way i proposed using the nonce there doesn't work. 10:07 < waxwing> will have to think about it again. 10:07 < waxwing> oh ofc, just do H(P2||nonce) yeah. will edit. 10:42 -!- MaxSan [~one@194.187.251.155] has joined #joinmarket 11:10 -!- MaxSan [~one@194.187.251.155] has quit [Ping timeout: 260 seconds] 11:48 -!- bsm117532 [~mcelrath@135.84.167.210] has quit [Ping timeout: 260 seconds] 12:09 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Ping timeout: 240 seconds] 13:04 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 13:16 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 260 seconds] 13:20 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket 13:49 < zxccxz> how to put electrum server to joinmarket.cfg 14:03 < belcher> zxccxz idk sorry 14:03 < belcher> waxwing thinking of copypasting our above conversation to that issue, also i read your post, its good 14:04 < waxwing> zxccxz: you mean 1 specific electrum server? 14:04 < waxwing> at the moment you could just edit the default server list in the electruminterface.py file; it just chooses one of them randomly at the moment. 14:06 < zxccxz> most are missing, some give a connection refused or something, have to start 5-6 times until it works 14:08 < waxwing> zxccxz: yes that was my experience too (at least, sometimes). it's just a stopgap solution, although improvements are welcome. 14:08 < waxwing> it suddenly occurs to me though, i didn't test it over a socks connection 14:32 < waxwing> i did mention that reconnect issue in the last paragraph of the announcement here: https://www.reddit.com/r/joinmarket/comments/5qe2tn/new_blockchain_interfaces_electrum_and/ 14:35 < waxwing> doh, i just noticed you can actually set the electrum_server in the config, see that ^ announcement. i just forgot, sorry. ping zxccxz 14:37 < waxwing> syntax as per https://github.com/JoinMarket-Org/joinmarket/blob/develop/joinmarket/electruminterface.py#L18-L33 15:03 -!- cbits [~cbits@47.148.176.74] has joined #joinmarket 15:03 -!- cbits_ [~cbits@47.148.176.74] has joined #joinmarket 15:05 -!- cbits_ [~cbits@47.148.176.74] has quit [Client Quit] 15:06 -!- stachrom [d4338865@gateway/web/freenode/ip.212.51.136.101] has quit [Ping timeout: 260 seconds] 15:16 -!- cbits [~cbits@47.148.176.74] has quit [Quit: Leaving] 15:48 -!- waxwing [~waxwing@185.65.132.137] has quit [Ping timeout: 256 seconds] 15:56 -!- q-biq [q-biq@unaffiiliated/q-biq] has quit [Ping timeout: 240 seconds] 15:57 -!- q-biq [q-biq@153.92.126.244] has joined #joinmarket 15:57 -!- q-biq [q-biq@153.92.126.244] has quit [Changing host] 15:57 -!- q-biq [q-biq@unaffiiliated/q-biq] has joined #joinmarket 16:01 -!- waxwing [~waxwing@185.65.135.88] has joined #joinmarket 16:34 -!- cbits_ [~cbits@47.148.176.74] has joined #joinmarket 16:34 -!- cbits [~cbits@47.148.176.74] has joined #joinmarket 16:34 -!- cbits_ [~cbits@47.148.176.74] has quit [Remote host closed the connection] 16:46 < JM-IRCRelay> [zed] hey guys, i have a newb question about jm tumbling 16:47 < belcher> so ask your question and somebody may answer :) 16:48 < JM-IRCRelay> [zed] so i am new to btc as well, and i've read the wiki but i'm a little confused. the wiki page on bitcoin core says if you don't use it, coinbase can unmix all your transactions, but the page on tumbler.py makes no mention of this 16:48 < JM-IRCRelay> [zed] if you try to tumble without using bitcoin core, is coinbase able to link it together? 16:49 < belcher> yes thats right, using bitcoin core is required to be private 16:49 < JM-IRCRelay> [zed] so tumbling without bitcoin core doesn't really do anything? 16:49 < belcher> it depends what your privacy needs are, some people might not mind coinbase.com knowing all their transactions, but most people do mind 16:50 < belcher> it does, theres many ways to have your privacy ruined and coinbase.com learning is just one of them 16:50 < JM-IRCRelay> [zed] *nod* 16:50 < belcher> so for example if you're trying to be private against some 4chan skiddie with too much time, tumbler will be great because the skiddie cant read coinbase's logs 16:51 < JM-IRCRelay> [zed] but if you're trying to escape coinbase, thats bad 16:51 < belcher> yep 16:51 < JM-IRCRelay> [zed] i see so, i started tumble.py with the default settings and no bitcoin core, is it ok to just control + c it? 16:52 < JM-IRCRelay> [zed] or will it need to finish? 16:52 < belcher> yep 16:53 < JM-IRCRelay> [zed] ok, thanks for the info, i'll have to look into bitcoin core then 17:07 -!- MaxSan [~one@86.125.14.100] has joined #joinmarket 17:11 -!- IRCFrEAK [~gk.1wm.su@2a03:4a80:3:43d:43d:23b:2e38:2839] has joined #joinmarket 17:11 -!- IRCFrEAK [~gk.1wm.su@2a03:4a80:3:43d:43d:23b:2e38:2839] has left #joinmarket [] 17:14 -!- MaxSan [~one@86.125.14.100] has quit [Ping timeout: 260 seconds] 17:29 -!- MaxSan [~one@109.163.226.153] has joined #joinmarket 18:06 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 20:17 -!- madgoat [~gk.1wm.su@2a03:4a80:5:41e:41e:efdd:c10d:1c12] has joined #joinmarket 20:17 -!- madgoat [~gk.1wm.su@2a03:4a80:5:41e:41e:efdd:c10d:1c12] has left #joinmarket [] 21:19 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 264 seconds] 21:24 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #joinmarket 23:40 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]