--- Day changed Tue Jul 05 2016
00:29 -!- megaddin [aladdin@gateway/shell/fnordserver.eu/x-vritdoyunelfccnt] has quit [Quit: https://fnordserver.eu]
00:52 < phantomcircuit> belcher_, wasn't this always known to have not perfect privacy properties?
00:53 < phantomcircuit> also isn't that basically entirely mitigated by a scheme which bans utxo's for not completing the protocol?
00:54 < waxwing> phantomcircuit: yes, we have discussed this at length and i've written some code (a start towards that goal)
00:54 < phantomcircuit> waxwing, is there an overview of the various proposed methods for doing that?
00:54 < waxwing> i'm afraid the tone of the announcement gives the impression we have no idea how to solve it, but that certainly isn't the case
00:54 < waxwing> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8
00:55 < phantomcircuit> yeah seems a bit over the top
00:55 < waxwing> well, it's just a matter of emphasis really
00:55 < phantomcircuit> defense not defence
00:55 < phantomcircuit> :P
00:55 < waxwing> i'm british :)
00:56 < phantomcircuit> i wasn't aware that was a britishism
00:56 < phantomcircuit> interesting
00:56 < waxwing> i was aware that defense was an americanism :)
01:03 -!- megaddin [aladdin@gateway/shell/fnordserver.eu/x-avnyfvfjimkxjjgb] has joined #joinmarket
01:52 -!- p15 [~p15@160.91.145.64.unassigned.bringover.net] has quit [Excess Flood]
01:54 -!- p15 [~p15@160.91.145.64.unassigned.bringover.net] has joined #joinmarket
02:41 -!- proslogion [~proslogio@2.127.106.111] has joined #joinmarket
03:10 < proslogion> so did you decide to go the PoDLE way?
03:12 < waxwing> proslogion: no
03:13 < waxwing> speaking for myself, i wanted to get started making a PR to propose doing it that way, but so much work needed doing on wallet sync (ironically because of snooper) and message channel availability (IRC goes down regularly)
03:13 < waxwing> but, at least one person prefers the p2ch way
03:14 < waxwing> one interesting Q is, we could do it by introducing a new ordertype and thus not affect old users, but then until people start using the new ordertype, there would be no defence :)
03:15 < waxwing> there's already that podle.py module, but after a point by gmaxwell the other day it seems clear it can be introduced by having multiple "slots" (multiple alternate generator points) so you can retry N times
03:15 < waxwing> s/introduced/improved/ sorry
03:59 < belcher_> reworded announcement to make it clearer than we can fix it
03:59 < belcher_> ===What will happen now?===We have a pretty good idea how to fix this. See the github issue for details. It generally involves limiting spy takers ability to get maker's UTXOs for free.
04:00 < waxwing> belcher_: thanks. don't mean to nitpick. i actually think it's sensible to err on the side of pessimism. it's not like we *need* people to use this thing :)
04:01 < belcher_> yeah joinmarket is quite immature
04:01 < waxwing> meanwhile i continue to tie myself up in knots figuring out the right way to deal with people squatting nicks on multiple servers...
04:02 < belcher_> keep changing nicks until you're able to get the same nick across all servers ?
04:02 < waxwing> well, but some people might not want or be able to connect to all servers.
04:02 < belcher_> makers will need to connect to all possible servers, but yes takers dont have to
04:02 < waxwing> that's one angle though: the "insist all makers on all message chans" approach. but it's a quite icky idea.
04:03 < belcher_> well they already have an incentive to do it, they want their offers to be as widely known as possible
04:03 < waxwing> yes, that's true. in that case we must have an official list, which includes only servers with good privacy (tor).
04:03 < waxwing> "official", but you get my point
04:04 < waxwing> also servers go down and come back up, you need to make sure you're first to get back on...
04:04 < belcher_> maybe we could code it to retry sending messages? so if a maker sends a message to a nick on one server which turns out to be a squatter, they could simply try resending to another server
04:04 < belcher_> why do you need to be the first back on? you could just change nicks if you cant i think
04:05 < waxwing> taker does orderbook publically (several servers), entry point is order announce in privmsg, the question is which one do you take up
04:06 < waxwing> belcher_: yeah that's true, but if one went down and you're waxwing on 3, you want to come back up as waxwing on the one that restarts say. but maybe it's not an issue unless you're in the middle of a tx.
04:06 < belcher_> i dont understand the first bit you said "taker does orderbook publically"
04:06 < waxwing> i mean !orderbook. then the responses !relorder etc in private
04:07 < waxwing> deciding where to do !fill based on that.
04:07 < belcher_> just pick a server randomly?
04:08 < waxwing> this is kind of where we got to yesterday, the idea that at the point of !fill you lock to 1 message channel. it's a bit of a pain to code, but what's worrying me at the moment is that it might not even be the right solution.
04:09 < belcher_> in my multiirc branch every message was sent through a random server, so !fill might've been through one server, !ioauth through another
04:09 < waxwing> right now the code just allows dynamic switching based on where the nick was last seen, which was me just going gung ho on "maximize availability", but of course this is useless given that nicks can be squatted elsewhere.
04:10 < belcher_> but it was a bit easier since it didnt have the many messagechannels in one part
04:10 < waxwing> but what would happen if a different bot had the same nick on a different server?
04:11 < belcher_> retry, is the only thing i can think of
04:11 < belcher_> actually the lock-to-one-messagechannel-per-tx makes more sense now
04:11 < waxwing> yes even the "it's E2E encrypted argument is no good, since it's at least DOS
04:11 < waxwing> if you send to the wrong guy he can't understand it but he just doesn't respond or sends garbage
04:12 < waxwing> yes it feels like the sanest approach, unfortunately it's by far the most annoying one to code :)
04:12 < belcher_> mmm
04:14 < belcher_> "annoucing orders" and "exchanging information needed to make coinjoins" are two different jobs of the messagechannels
04:14 < waxwing> right, absolutely
04:15 < belcher_> the first one is the one that needs censorship resistance the most
04:15 < belcher_> so that one makes sense to replicate on every irc server, while the second one is able to timeout and retry so censorship can at least be detected, so its okay to just use a single server
04:18 < waxwing> is there any way to fudge in "nick based on private info" ... the hidden service p2p for tx negot. model looking good here. onion address as public key as identifier.
04:19 < waxwing> i mean, given we already set up encryption pubkeys authorised with bitcoin keys, it seems silly using something as weightless as an IRC nick
04:19 <+JM-IRCRelay> [AlexCato] the announcement even made it to the monero forums (also /r/bitcoin and /r/btc): https://np.reddit.com/r/Monero/comments/4rbrmr/known_vulnerability_on_joinmarket_exploited/  https://twitter.com/MoneroPromotion/status/750256726222344193
04:19 < belcher_> of course :p
04:19 < waxwing> that's one trick that would not be missed :)
04:21 < waxwing> how about IRC nick = first bytes of hash of pubkey (i am ignoring for the moment whether there is a protocol change)
04:21 < belcher_> why have that?
04:22 <+JM-IRCRelay> [AlexCato] sorry, did not intend to disturb the discussion. Agree with belcher that multiple irc channels are needed for the makers for reducing possible censorship; still think that the actual TX by a maker can be done on one random irc server. Imho the taker doesnt even have to connect to more than one IRC server, which should make coding quite easy? Only needs
04:22 <+JM-IRCRelay> to choose another one if the selected irc is down
04:23 < waxwing> well yes, i proposed that yesterday, i'm still not convinced its' the "right" way, but it's one approach.
04:23 <+JM-IRCRelay> [AlexCato] if the taker only uses one irc server, there's no nicks to be stolen
04:23 < belcher_> the taker should at least connect to two or three, otherwise the single irc server can make you meet only its sybils
04:23 < waxwing> yes, we lose something in all versions, except the "lock to one channel during tx", i *think*
04:24 <+JM-IRCRelay> [AlexCato] shouldnt that solve itsself by the inherent self-interest of makers to be on all IRCs?
04:24 < waxwing> belcher_: why have that: i am thinking that a bot can verify itself against its nick, it can't then be squatted
04:24 < waxwing> such a keypair can be ephemeral for the lifetime of the bot instance, i suppose
04:29 < belcher_> it can still be squatted even if you dont know the pubkey
04:29 < belcher_> unless the irc server itself somehow enforces it in the irc protocol that you need the pubkey before you can /nick <pubkeyhash>
04:29 < waxwing> yes, but like i say the bot can verify itself against the nick
04:29 < waxwing> again, "ignoring for a moment whether there is aprotocol change"
04:29 < belcher_> can you explain a bit more? i dont get it
04:30 < waxwing> i mean like when it sends a message, it could append something ~ a sig against a key which fits the nick
04:30 < waxwing> so yeah you can still squat on other servers, but can't produce valid messages
04:31 < waxwing> so yeah, fleshing it out, there's certainly no way to do that without protocol change
04:31 < belcher_> ok, so nick as pubkeyhash protects against learning about a !relorder and then sending !fill to a squatter
04:32 < waxwing> yeah. DOS, snooping and tx "stealing" i guess are the three attacks here
04:32 < waxwing> although snooping here might only mean finding out the parameters of transactions that a taker is requesting
04:33 < waxwing> but, that's details
04:33 < belcher_> i think thats better solved by requiring makers to connect to all servers
04:33 < waxwing> basically the attacker-maker can't initiate private messaging in that model.
04:33 < belcher_> since they have an incentive to do that anyway
04:34 < waxwing> i'm not convinced it's clean enough w.r.t server restarts and also it's a very rigid model
04:36 < belcher_> why is it rigid?
04:36 <+JM-IRCRelay> [AlexCato] i'd prefer not to *force* makers to use all irc servers. I prefer only to use the ones which can be connected to via TOR, for example. Since this is all about improving privacy, there probably are other makers seeing it the same way
04:37 < waxwing> rigid because we have to have global agreement on *the* servers, people cannot make their own choices.
04:37 < belcher_> yes ok so they wouldnt be forced, if takers only connect to 2 or 3 servers they cant tell if makers are not on every single server, but makers would be compelled by market forces
04:37 < belcher_> like if you're selling apples you put it up on every noticeboard in town, and it would be the same if you're selling coinjoins
04:37 < belcher_> ah
04:37 < waxwing> also what if one person cannot connect to server A and another person can?
04:38 < belcher_> i imagined that the server list would be a file somewhere in joinmarket, if we encourage people to make their own choices on it they have to organise themselves with some out of band method
04:39 < waxwing> it's not so much that; there's nothing wrong with us providing "the" list; it's more about whether they want to choose a subset, although also organically people might choose something else too.
04:39 < waxwing> but now i think my objection above is even more important; connectivity is not guaranteed to be global
04:39 < belcher_> so you mean, someone from china might not be able to connect to some servers?
04:39 < waxwing> just in general. it's not unheard of right.
04:40 < belcher_> if they're a maker, they'll have to fix their internet or work around it, if they're a taker they dont need to connect to every single server
04:40 < waxwing> makers are passive, connections go down.
04:41 < waxwing> i understand you can make a practical case for that approach, as one can for several others. i think the pubkey way is the "right" way.
04:41 < waxwing> you need to "own" the nick.
04:41 < waxwing> if we have to do it without protocol change today, i'd tend to favour the lock-to-one-channel during tx approach.
04:42 < waxwing> but the all makers on all servers approach at least does work, today
04:42 < belcher_> i agree with favouring lock-to-one-chan-per-tx
04:42 < waxwing> so it's got that going for it :)
04:42 < belcher_> what happens if someone takes *your* nick ?
04:42 < belcher_> what about using nickserv? at least then you can /ns ghost if someone squats
04:43 < belcher_> oh hold on got it, if someone takes your nick they cant announce orders in your name because orders require a signature
04:43 < waxwing> well but i don't want to have to manage my nick on multiple servers, like, say i don't want to use one server or don't know about it or it doesn't support my Tor setup or whatever
04:43 < waxwing> orders? the order announce doesn't have a signature
04:43 < belcher_> ok i misunderstood then
04:43 <+JM-IRCRelay> [AlexCato] what's the upside, what does a taker gain by splitting his communication accross several IRC servers? What am I missing? I dont see how a sybil attack is more likely if the taker connects only to one server
04:43 < waxwing> or are you talking about the new proposal?
04:44 < waxwing> alex, it loses a bit on censorship resistance
04:44 < belcher_> alexcato with only one server, that single server can censor everyone else so you only meet its sybils
04:44 < waxwing> it is a viable way of doing it today though
04:44 < waxwing> as in, it's not a decrease of security from where we are today
04:44 < belcher_> a taker gains protection from this attack by connecting to two or three servers
04:45 < waxwing> actually this is the reason i cooled off on the taker-only-one-server idea:
04:45 < waxwing> liquidity is split then
04:46 <+JM-IRCRelay> [AlexCato] alright, that makes sense. So to keep censorship resistance, a taker should connect to more servers and request the !orderlist from all of them. But as soon as he has the orderlist, the single-server-communication-approach should work
04:46 < waxwing> if the majority of makers are on server A, then the takers are incented to always go there. they won't want to be randomly forced onto other servers with less liquidity. but, it's still not a bad thing, because it gives redundancy/failover.
04:46 < belcher_> i dont see the problem of encouraging market forces to force the makers to connect to every server
04:48 <+JM-IRCRelay> [AlexCato] i'm fine with market forces, just didnt want the protocol to enforce it by requiring to be on all of them to be able to be a yieldgen;
04:48 < waxwing> well, we'll need to find at least 3 servers with tor support i guess? or perhaps 2 is enough.
04:48 < belcher_> yep
04:48 < belcher_> ideally the servers in our list are only servers that support tor
04:49 < belcher_> but since the server cant attack joinmarket in this new model, it would be okay for people involved in bitcoin and joinmarket to run them
04:49 < waxwing> but i am of the opinion that is an icky solution, which won't solve the problem properly and is lacking in flexibility, and connection issues can cause problems like DOS.
04:49 < belcher_> (right now its better that we're on a server that has nothing to do with bitcoin, so its operator wont care enough to attack)
04:50 < waxwing> but on balance it's better than today.
04:50 < belcher_> maker-connects-to-everything is quite inflexible you're right
04:51 < waxwing> imagine a maker uses tor and has a flaky connection; if they don't babysit it, they could get squatted while they are away
04:51 < waxwing> it's not some huge attack, but it's a weakness right
04:51 < belcher_> cant they just change nicks and re-annouce their orders ?
04:51 < waxwing> yeah, when they come back
04:52 < waxwing> oh you mean in the code right
04:52 < belcher_> yes
04:52 < waxwing> yeah, that can make sense i think
04:52 < belcher_> multiirc branch would do that, keep /nick'ing until no server gave a "nick in use" message
04:52 < belcher_> multiirc branch would do that, keep /nick'ing on every server until no server gave a "nick in use" message
04:54 < waxwing> yes, that makes me feel a bit more positive about it.
04:55 < waxwing> makers all-on-all does have the weakness that you need to be able to connect whenever anyone else can
04:56 < waxwing> if you can't connect on one, you have to shut down completely right?
04:56 < waxwing> if you stay up on 2 out of 3, but stay down on the 3rd, you can be squatted
04:56 < waxwing> and then we lose the availability gain from multiple servers
04:56 < belcher_> yes
04:57 < belcher_> for example if someone wants to only use tor and dont want to connect to any clearnet servers
04:57 < belcher_> that means our list of servers must include only tor-enabled ones
04:58 < waxwing> yes, but specifically i'm saying that unless you assume that connectivity to a server is global, you can't safely continue to operate unless all message channels are connectable
04:58 < waxwing> so under those assumptions, joinmarket availability for makers at least, is actually worse than before
04:58 < waxwing> well, for everyone: because if a server does go down, all makers go down
04:59 < belcher_> so the worst situation is if one server is partially down, down for some locations but not for others
04:59 < waxwing> belcher_: but the problem is you don't know if it's partial
04:59 < belcher_> yes
04:59 < belcher_> what if makers were coded to not mind if one server was down, carry on as normal
04:59 < waxwing> then squatting is possible if their connection loss is due to them, not the server
05:00 < belcher_> ok
05:00 < belcher_> how bad is squatting?
05:00 < belcher_> its a DOS-only i think
05:01 < waxwing> DOS, plus order reading (mild snooping), plus tx stealing is *possible* but depends how it's coded i think.
05:01 < waxwing> by "stealing" i mean just getting the chance to fill the order
05:01 < belcher_> from the point of view of the taker, tx stealing is absolutely fine
05:02 < belcher_> reading the order fills means the squatter learns the coinjoin amounts
05:02 < waxwing> yes, mild snooping. amounts is bad, but not as bad as utxos.
05:03 < waxwing> i guess i still have the same overall impression: it's a bit fragile and imperfect, but it's not awful. i think owning the nick is the right thing, and will make everything much cleaner.
05:03 < belcher_> one thing i dont understand yet is what it means to own a nick
05:04 < waxwing> it just means: have a keypair for one bot instance; make a nick which you can verify against (use a pubkey), if you can't verify it your privmsgs are ignored.
05:05 < belcher_> so every privmsg has a signature attached ?
05:05 < waxwing> yes i think so
05:05 < waxwing> maybe not the E2E stuff, but the handshake stuff
05:05 < belcher_> and the orderbook stuff will have to be signed too right?
05:06 < waxwing> i'm not sure about the public order announce, i guess so, not sure
05:06 < waxwing> have to worry about replay
05:06 < belcher_> yep
05:06 < waxwing> maybe it just needs to be on privmsg first step, ie order announce that starts the conversation
05:07 <+JM-IRCRelay> [AlexCato] One last attempt, wall of text incoming
05:08 <+JM-IRCRelay> [AlexCato] How about this: 1) makers connect to all the irc servers they're comfortable with. Could be all of the default configuration ones or a subset of it
05:08 <+JM-IRCRelay> [AlexCato] 2) takers connect to all the irc servers which are available. Ask !orderbook on all of them, take note of the offers, nicks,  *and the irc servers they came from*
05:08 <+JM-IRCRelay> [AlexCato] 3) Taker filters for uniqueness of offers, then choose the offers to be taken, just like now. If the same offer from the same nick is received on multiple IRCs, randomly choose one. Optional: Taker then disconnects from all server from which he did not choose an order
05:08 <+JM-IRCRelay> [AlexCato] 4) Start the coinjoin, use !fill privmsg on the server the offer came from
05:08 <+JM-IRCRelay> [AlexCato] Results: no DoS possible (noone can "steal" the join by having the same nick on another server), no censorship possible (still gets all offers from everyone), no new effects on snooping, no sybil attack.
05:08 <+JM-IRCRelay> [AlexCato] Another upside: makers arent forced to be on all servers
05:09 < belcher_> so the crucial thing is replacing maker's "nick" with "nick+server"
05:09 < waxwing> funnily enough i explicitly rejected this approach in the code :)
05:09 < waxwing> https://github.com/AdamISZ/joinmarket/blob/mc-collection/joinmarket/message_channel.py#L284-L293
05:10 < waxwing> but sure, a variant of lock-to-one-mc really, right
05:10 < belcher_> i think it sounds good
05:10 < belcher_> there's be split liquidity, but economically rational makers will still connect to every server
05:10 < belcher_> makers would be able to choose not to connect to some servers, e.g. if they want to trade privacy for money
05:11 < belcher_> e.g. they are a patientsendpayment.py
05:12 < waxwing> Alex, how do you see that description above as different to "lock to one message channel for the transaction"?
05:13 < belcher_> its "lock to one message channel per tx, the same message channel you received the offer from"
05:13 < waxwing> well, that's what it was, in the sense that the lock happens when the privmsg order announce is received
05:14 < waxwing> but i think here it's "consciously choose 1 message channel" which is subtly different
05:14 < waxwing> like i said in that comment, i was balking at the idea architecturally. putting the message channel in the order data .. not a fun idea :(
05:14 < belcher_> it could be done by renaming the "counterparty" variable
05:15 < belcher_> or rather, defining it, it used to mean irc nick and now it would mean irc nick + server name
05:15 < waxwing> it's essentially equivalent to saying that a counterparty is a (counterparty + message channel) object
05:15 < waxwing> yes
05:15 < belcher_> yes, or some string that represents the message channel object
05:15 < belcher_> probably the server hostname
05:15 <+JM-IRCRelay> [AlexCato] what belcher said, though i always assumed it to be that way anyways; no real difference. When i wrote that, new to me was how offers are filtered by the taker. An attacker using an existing nick on another irc server still could send the same offer as the original maker; yet with that approach, he only has a statistical chance to be actually chosen
05:15 < waxwing> the problem is that, going in that direction is somehow conceptually equivalent to saying that the same bot on different message channels are different entities.
05:16 <+JM-IRCRelay> [AlexCato] before that, he could make it an 100% certainty by delaying his offers privmsg
05:16 < waxwing> that's what makes it architecturally icky. the whole point of this update is to try to increase availability by letting the *same* entity communicate over more than one mc.
05:16 < belcher_> why is it icky?
05:16 < belcher_> alexcato we could make it that if two offers from different servers conflict, pick the best one
05:17 < waxwing> joinmarket logic shouldn't know about any such thing as "message channel".
05:17 < belcher_> or yes, best but with some randomness
05:17 <+JM-IRCRelay> [AlexCato] then i'd be the attacker, taking all avaialble nicks and then be 1 satoshi cheaper than the original's offers
05:17 < belcher_> if you redefine what counterparty is, i think it wont need to
05:18 < belcher_> anyway i g2g now i think
05:18 < belcher_> good progress in this chat, we should save the chatlog
05:18 < waxwing> it breaks backwards compat. too i think.
05:18 < waxwing> you're changing the order data structure
05:19 < belcher_> that has to be done eventually anyway
05:19 < waxwing> well then i think nicks should be owned :)
05:19 < belcher_> when we issued on those big alerts on irc /topic people updated quickly
05:19 < waxwing> much more logical idea imo
05:19 <+JM-IRCRelay> [AlexCato] dont think so, unless I'm not fully understanding. From a makers perspective nothing changes, the offers/coinjoin-privmsgs are the same
05:19 < belcher_> the downside to owning nicks is all messages are larger in bytes because they must contain crypto signatures
05:19 <+JM-IRCRelay> [AlexCato] from an older taker perspective, he only connects to 1 server anyways
05:20 < belcher_> not all messages, some of them
05:20 <+JM-IRCRelay> [AlexCato] so the takers data structures being old dont really matter, the old one needs not to keep track of nicks+servers
05:20 < belcher_> afk now
05:21 <+JM-IRCRelay> [AlexCato] the maker doesnt care about the structures either
05:21 <+JM-IRCRelay> [AlexCato] so newer taker-versions should be able to communicate with outdated makers just fine?
05:21 < waxwing> yes i think you're right about that, not 100% sure though
05:22 < waxwing> i'm surprised though that people don't agree with me that owning nicks is obviously the right architecture.
05:22 < waxwing> these other ideas are essentially lower-level hacks for a higher-level arch. problem.
05:22 <+JM-IRCRelay> [AlexCato] i dont disagree :)
05:23 <+JM-IRCRelay> [AlexCato] from my not-fully-into-the-code understanding, creating higher complexity for a problem which could be solved by lower complexity as well
05:24 <+JM-IRCRelay> [AlexCato] is not always desirable. But I believe belcher and you have to agree what's best looking forward; i dont see the whole picture just yet
05:24 < waxwing> as for adding another sig into the data being sent, well, all our proposals to solve the snooping attack also require that. ~32 bytes isn't going to cause much difference in the grand scheme of things.
05:25 < waxwing> but otoh the idea isn't fleshed out, so it's probably more practical to go with something less advanced for now.
05:25 <+JM-IRCRelay> [AlexCato] nah, dont care about the bytes. Just *seems* to me overly complex. If it needs to be done anyways in the future, then there's no harm doing it right away
05:26 < waxwing> what seems overly complex? making the nick the hash of a pubkey? i was going the other way: locking message channels is more complex to me, but maybe just in the sense that to cover all the edge cases, test etc..
05:27 < waxwing> what bothers me in particular is if we have to edit the joinmarket code to account for multiple message channels, that just seems quite awful somehow
05:28 <+JM-IRCRelay> [AlexCato] guess i'm not understanding where the difference is between nick+hash vs. nick+ircserver
05:29 < waxwing> ok, i mean like: nick=hash(pubkey), then privmsg !relorder + .... +sig , taker recovers pubkey from sig and !relorder... and then hashes to verify, if not match, drop and ignore 
05:29 < waxwing> well, truncated hash for nick of course
05:30 < waxwing> in this case you wouldn't need to change the structure of the order database or anything like that, it's just about whether messages are accepted or not
05:31 < waxwing> to me the goal was always that messages be transparently multiplexed; they could be sent anywhere/everywhere and received anywhere/everywhere
05:36 <+JM-IRCRelay> [AlexCato] sounds like a good solution; my the gut instinct of "adding new signatures/hashes = complex" might be wrong. This also does handle communication with makers, which for example are only on one irc server?
05:37 < waxwing> nothing changes there; it's just insisting that your nick *belongs* you, no one can impersonate it and get away with it
05:37 < waxwing> i remember at the beginning i made a (mild) argument for having a long-lived private key for communication, but it was rejected (rightly) as being unnecessary; we want bots to be ephemeral
05:38 < waxwing> maybe i'm wrong, but i think that can be reinstated, but just for the lifetime of one bot instance
05:38 < waxwing> so bot A becomes identity A1, runs, and during that time no one else can pretend to be A1, no matter where they are.
05:38 < waxwing> and then next time they're A2 etc.
05:41 < waxwing> it is true that "nick ownership" already exists in IRC, with nickserv and whatnot, but it doesn't seem reliable enough (and it' IRC specific which we're trying not to be)
05:44 <+JM-IRCRelay> [AlexCato] yes, agree on that. Plus reserving nicks would be a waste, as most are only used by joinmarket once
06:01 < waxwing> what's funny is, after all that discussion i am even less sure of what to do next :)
06:08 <+JM-IRCRelay> [AlexCato] i'd say... go with your idea then. This might have been a bikeshed-problem: my idea was easy to understand and works, your is harder to understand, works too, but is actually easier to implement and better for the architecture
06:08 <+JM-IRCRelay> [AlexCato] if both achieve the same outcome, yours is to be prefered given that simplified conclusion above is correct
06:09 < waxwing> well; i think my idea is *somewhat* easier, but (a) it's a protocol break and (b)it needs thinking through. i just think it's the better long term solution. probably not the right thing to do today.
06:10 < waxwing> whereas, if we lock the message channel, with your approach, it's concrete and can be done now, but i think it's going to involve very broad code edits (because of how we use 'nick' everywhere)
06:10 <+JM-IRCRelay> [AlexCato] thats true; my idea is backwards compatible (i think) while yours is not
06:11 < waxwing> if we just lock the message channel without adding the server to the order entry (what we discussed yesterday), it's also quite complicated, but it doesn't affect code outside of messagechannel.py
06:12 <+JM-IRCRelay> [AlexCato] then that might be a viable solution for the short term
06:48 -!- molly [~molly@unaffiliated/molly] has joined #joinmarket
06:51 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
07:20 -!- proslogion [~proslogio@2.127.106.111] has quit [Ping timeout: 260 seconds]
07:29 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #joinmarket
07:33 -!- proslogion [~proslogio@130.159.234.85] has joined #joinmarket
07:44 -!- rdymac [uid31665@gateway/web/irccloud.com/x-wvgmmuafrwdvekjr] has joined #joinmarket
09:10 -!- Einherjer [~einherjer@69.64.40.177] has quit [Ping timeout: 244 seconds]
09:23 -!- gielbier_ [~gielbier@2001:981:9573:1:b418:49c6:d274:ebcb] has joined #joinmarket
09:27 -!- gielbier_ [~gielbier@2001:981:9573:1:b418:49c6:d274:ebcb] has left #joinmarket ["Leaving"]
09:28 <+JM-IRCRelay> [AlexCato] that's an interesting idea: https://www.reddit.com/r/Bitcoin/comments/4rbj9g/joinmarket_is_under_attack/d5057bh
09:29 <+JM-IRCRelay> [AlexCato] (snoop defense by sometimes offering UTXOs which dont belong to your Yieldgen)
09:46 < belcher_> waxwing: i think heres a way for someone to still squat on your nick even with the pubkeyhash. on one server a bot A has a nick=pubkeyhash and announces an offer with a correct signature, on another server a squatter B sets his nick to pubkeyhash but doesnt say anything, a taker is on both servers, he sees the offer from A but ends up sending !fill to the squatter B
09:47 < belcher_> depends on exactly how the pubkeyhash system works
09:47 < belcher_> but i think it too will also have a have a rule where the taker sends !fill only using the same irc server
09:48 < waxwing> well, i guess it gets into details now, but with an "owned nick" in that sense, messages unverified would be ignored, so even if you used the rule "always send to the last channel on which a message is received", it would still work
09:48 < waxwing> the reason i went with that (in retrospect, dumb) rule was to maximize availability
09:48 < waxwing> but there are a ton of things to think through to make such a system work, so i accept it's not practical today
09:49 < belcher_> in my situation, the bot A does correctly sign its offer on the first server
09:49 < waxwing> yes but the taker wouldn't send to B
09:49 < belcher_> squatter B doesnt say anything, it only sets its nick to the same as bot A, so theres no message to verify or not verify
09:49 < waxwing> he'd only send to the last channel on which a verified message was seen
09:50 < belcher_> right ok
09:50 < belcher_> so if bot A is on two servers, taker may see the offer on both servers and can freely send !fill through either server
09:50 < waxwing> yeah
09:51 -!- proslogion [~proslogio@130.159.234.85] has quit [Ping timeout: 244 seconds]
09:51 < belcher_> and in alexcato's system, the taker would see the offers twice and consider them different offers
09:51 < belcher_> actually i realise now thats really arkward because the taker might choose to fill both offers which turn out to be from the same maker's wallet
09:51 < waxwing> right, one needs to think carefully about doing the order filtering correctly in that system
09:52 < waxwing> i've been sitting here trying to come up with the best, simplest solution that can be done now. i think it's just locking mc for duration of tx, but even that isn't simple really.
09:52 < waxwing> i have to kind of wind back a fair bit of what i was doing along the lines of making it "transparent".
09:53 < belcher_> im starting to think the nick = pubkeyhash system is best then
09:53 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
09:53 < belcher_> its an identity across many servers
09:53 < waxwing> yeah; i'm wondering though whether need sigs for every message, which wouldn't be the end of the world, but un-ideal 
09:53 < waxwing> and ofc it's a protocol update
09:54 < belcher_> that will happen whatever we do, because of #156
09:54 < waxwing> yes i was still thinking of merging a multi-mc in advance of protocol update, but, shrug, don't know
09:54 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
09:54 < belcher_> and we know that when we use the /topic alert, people update quickly
09:54 < waxwing> maybe just better to do it right first time
09:55 < waxwing> if we do a pubkey hash we could do something like [versionbyte][hash:12] or something
09:55 < waxwing> we have to be a bit careful that identifiers have different rules on different messaging systems
09:55 < belcher_> right, to allow versioning
09:58 < waxwing> i'll think a bit more, specifically about which messages must have sig, and preventing replay
09:59 < belcher_> perhaps we include the server name in there to stop replaying on another server
09:59 < belcher_> i think only offers need signatures
10:00 < waxwing> i was leaning the other way; if we want the underlying message channel to be transparent, maybe better if everything is signed
10:00 < belcher_> what does transparent mean?
10:00 < waxwing> i mean higher level code and logic doesn't have to know that there are any message channels, or whether they're being switched during the conversation
10:01 < belcher_> so the tradeoff is between less signature operations vs not changing the codebase too much
10:02 < waxwing> i think there will just be too many corner cases to worry about, where attacks can lurk, if we try to use kind of "network level" defence against impersonation.
10:02 < waxwing> it's not only about keeping the code simple, although that's a factor too
10:05 < belcher_> do you think its worth worrying about impersonation by colluding with the irc server? the regular irc protocol pretty much guarentees that someone's nick wont be changed, but the irc admin could still do that
10:05 < belcher_> wait for a bot to announce some orders and then force change his nick
10:05 < belcher_> that kind of attack would be stopped by signing everything
10:05 < waxwing> not really (we haven't so far, right) but that's another thing this defends against
10:06 < waxwing> yeah
10:06 -!- proslogion [~proslogio@2.127.106.111] has joined #joinmarket
10:06 < belcher_> how small could a signature be ?
10:06 < waxwing> yeah another thing i was wondering about in the back of my mind .. exactly what do we need here, how small can it be.
10:07 < belcher_> 256bits is 32 bytes, converted to base64 thats 43 bytes ?
10:07 < waxwing> hmm, earlier i said 32 but i don't think there's a scheme allowing sub 64 bytes
10:07 < waxwing> to be fair we are regularly sending messages of 2kB and larger atm :)
10:08 < belcher_> isnt there that trick for deriving the pubkey from the message and signature
10:08 -!- p15 [~p15@160.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 276 seconds]
10:08 < belcher_> so we dont need to transmit the pubkey like bitcoin transactions do now
10:08 < waxwing> yes, i included that in the above discussion with alex
10:08 < waxwing> but still sig, that's 64 at least i think
10:08 < waxwing> consider that if we implement podle we end up having to send something like P, P2, U, s, e :)
10:09 < waxwing> it's nice if the handshake messages are small but in the grand scheme of things i don't think this is a huge concern.
10:09 < belcher_> yes so an ecdsa signature is (r, s) and each of those are 256 bits
10:09 < waxwing> yes and schnorr is (s, e) so similar
10:09 < belcher_> podle is only for !fill right ?
10:09 < waxwing> i forgot encoding, so it's bigger by some fraction
10:09 < waxwing> yeah something like that
10:10 < gmaxwell> waxwing: gah, only shitty schnorr is s,e
10:10 < waxwing> ok :)
10:10 < waxwing> a few bytes here, a few bytes there ... soon you're talking real signatures!
10:10 < gmaxwell> waxwing: s,e construction is morstly garbage; there are a few cases where its useful.  s,e vs r,s is NOT the schnorr vs ecdsa distinction, and a schnorr signature can be r,s too.
10:11 < gmaxwell> why are you talking about adding persistant identity to the communications channel?
10:11 < waxwing> we're not; we're talking about adding identity for the duration of a bot run
10:11 < belcher_> it can be used across many irc (or matrix) servers 
10:12 < belcher_> and yes the identity only lasts until the bot restarts
10:12 < gmaxwell> okay, but the why part of the question?
10:12 < waxwing> it's completely ephemeral in the sense that it's only to ensure you can't impersonate while running
10:12 < waxwing> if you use multiple message channels
10:13 < belcher_> it stops squatting, in cases where bots choose not to join all possible servers
10:15 < waxwing> so what's the right schnorr construction? i actually thought it was s,e .
10:20 < gmaxwell> r,s; same as ecdsa.
10:20 < gmaxwell> s,e is lame for a number of reasons, including that it's inherently slower to verify.
10:23 < waxwing> ah, i see, it's slower, that's true
10:24 < waxwing> you don't need to do the EC part if you just pass the nonce point "K" or whatever
10:25 < waxwing> no that's not right, sorry
10:26 < belcher_> if we only ever used a single messaging channel, there wouldnt be a need for identities
10:26 < belcher_> also these identities are only for makers
10:27 < waxwing> i think you may as well use them for takers too, although haven't thought about it much yet (i mean, in case there is some naughtiness achievable by a maker)
10:28 < gmaxwell> belcher_: you're just trying to prevent duplicate orders?
10:28 < belcher_> im still not clear on why every message needs to be signed, instead of just the advertising orders part
10:30 < belcher_> gmaxwell: no, its for squatting, so when a maker doesnt connect to all possible servers, a malicious bot choses the same nick as that maker on other server and can use it to dos any takers
10:31 < waxwing> i know i'm being dumb, but i don't see the difference in performance with (r,s) vs (s, e): in both cases you construct sG+eP, but in one case you check if hashes are equal, in other you check if points are equal.
10:31 < gmaxwell> so why isn't this key actually per request?
10:31 < gmaxwell> waxwing: you can't batch verify s,e.
10:31 < gmaxwell> which is an asymptotic 2x performance difference.
10:31 < waxwing> batch verify, i see, thanks
10:32 < waxwing> there is already a kind of key-per-request: the key used to do ECDH and then start the tx negotation. that's per request.
10:33 < belcher_> maker's offers exist between requests gmaxwell, right now they're linked to the irc nick, but in a multi-irc system it cant be exactly like that
10:33 < gmaxwell> gotcha.
10:40 < waxwing> belcher_: a small detail but nick cycling wouldn't be a problem as long as there's enough space at the end for underscores.
10:40 < belcher_> or just generate a new random one
10:40 < waxwing> well, but while running it might want to keep the old one if a tx is ongoing. maybe a small side case.
10:41 < waxwing> i guess in that case mostly things fail anyway
10:41 < belcher_> going afk in a sec
10:42 < belcher_> the way im thinking now, signing is only needed for the offer messages, thats enough to stop squatting
10:42 < waxwing> yes i do understand, i'm still strongly inclined though to enforce throughout privmsg, because it avoids having to think about annoying dos scenarios
10:47 < waxwing> it would mean not a single message could be sent succcessfully as an impersonation ... maybe that's greedy thinking :)
10:57 < nkuttler> i just see that one tx can contain multiple inputs from the same depth, is that correct?
10:57 < waxwing> nkuttler: sure, that's the rule. inputs are only combined from the same mixdepth
10:58 < nkuttler> waxwing: cool. 
10:58 < nkuttler> yeah, makes sense :)
10:59 <+JM-IRCRelay> [AlexCato] quick electrum plugin feedback: tested it on a new tails 2.4 and sent a PR to enhance the installation instructions a bit. After the installation, which indeed is quite a hassle, the plugin worked beautifully. Tried a 1) normal sendpayment and a 2) sweep sendpayment. The tx fees were quite high, but not out of the normal (no config available? The
10:59 <+JM-IRCRelay> electrum fee setting got ignored).
10:59 <+JM-IRCRelay> [AlexCato] no unexpected troubles
10:59 < waxwing> alexcato: the fees are set within joinmarket, yes. and the config is in your ~/.electrum
10:59 < waxwing> thanks for the tryout :)
11:00 < waxwing> it's like ~/.electrum/joinmarket. sorry i think i forgot to write that anywhere
11:00 <+JM-IRCRelay> [AlexCato] if the installation can be made easier and tumbler integrated, this will make it awesome for normal users
11:00 < waxwing> right. just some small details to sort out first :) (like the whole system falling to bits)
11:01 <+JM-IRCRelay> [AlexCato] indeed, need to prioritize
11:01 <+JM-IRCRelay> [AlexCato] just saying... i liked what i saw
11:01 < waxwing> about the fee, it uses estimatefee sourced from electrum server
11:02 <+JM-IRCRelay> [AlexCato] if plugins can access the electrum settings, it could just use that one. Would make more sense when it's integrated
11:02 < waxwing> it would be nicer to get electrum to use its normal process of fee decision, that's a good point.
11:02 < waxwing> but i think it's a bit tricky, not sure.
11:02 <+JM-IRCRelay> [AlexCato] ya, thats nothing to worry about at first
11:19 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit []
11:20 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has joined #joinmarket
11:21 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit [Client Quit]
11:25 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has joined #joinmarket
11:26 < nkuttler> btw, here's my ipython notebook that displays some stats from yigen-statement.csv, https://gist.github.com/nkuttler/47709a0a426ed950bb8f355568458e9f
11:27 < waxwing> never played with that ipython notebook thing, looked interesting though
11:28 < nkuttler> yeah, me neither, but after seeing it at a talk i thought it's nice for presentations
11:28 < nkuttler> also does inline graphs, so no need to worry about displaying them
11:30 < waxwing> alex: edits look good indeed, thanks muchly
11:31 < waxwing> does sudo gedit work, i have a vague memory there's some problem with graphical stuff and sudo
11:31 < nkuttler> sudo gedit sounds evil
11:32 < waxwing> i think he's avoiding something like sudo vi due to it being for (relative) noobs
11:32 < waxwing> or is it just me that still uses vi :)
11:32 < nkuttler> ah
11:32 < nkuttler> nah, me too :)
11:33 < waxwing> what was it, gksudo or something
11:33 < nkuttler> kinda offputting to use a browser based editor in those notebooks, but ok for so little code
11:33 < nkuttler> there is gksudo, yeah
11:34 <+JM-IRCRelay> [AlexCato] waxwing: yes, sudo gedit works. I've tried everything in that tutorial just today
11:34 < waxwing> right, it probably depends on the exact linux flavour
11:50 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
11:53 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:09 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
12:11 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
12:25 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
12:28 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:56 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
12:57 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
12:58 < belcher_> IMO tumbler makes more sense as a standalone gui app rather than an electrum plugin
12:58 < belcher_> ipython notebook is great yes
12:59 < belcher_> the standalone app could do have a few different blockchain interfaces, including one where it just downloads whole blocks from the network from the wallet start date, so you'd get full privacy but spv security
12:59 < belcher_> or it could connect to your own full node like now
13:00 < belcher_> nkuttler: you can get ipython notebook to export as a pdf
13:01 < belcher_> i think it can do markup too, for putting into gists
13:01 < belcher_> anyway, afk now
13:06 < nkuttler> well, i don't want to share my data, just the code :)
13:06 < nkuttler> maybe the exported python can be re-imported, that would be better than json i guess
13:38 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 250 seconds]
13:48 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket
14:49 -!- belcher [~user@unaffiliated/belcher] has joined #joinmarket
15:54 -!- imposter [uid57046@gateway/web/irccloud.com/x-aamnxjosmgxxvtzd] has joined #joinmarket
17:22 -!- proslogion [~proslogio@2.127.106.111] has quit [Ping timeout: 276 seconds]
17:25 -!- belcher [~user@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
17:26 -!- belcher [~user@unaffiliated/belcher] has joined #joinmarket
18:45 -!- mkarrer [~mkarrer@48.red-83-47-111.dynamicip.rima-tde.net] has quit []
18:51 -!- fqtw__ [~me@x5d8013d5.dyn.telefonica.de] has joined #joinmarket
18:55 -!- fqtw_ [~me@x4d0b99fc.dyn.telefonica.de] has quit [Ping timeout: 244 seconds]
19:06 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:42 -!- fqtw [~me@x4d0b91ed.dyn.telefonica.de] has joined #joinmarket
19:45 -!- fqtw__ [~me@x5d8013d5.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20:06 -!- fqtw_ [~me@x4d0b91ed.dyn.telefonica.de] has joined #joinmarket
20:09 -!- fqtw [~me@x4d0b91ed.dyn.telefonica.de] has quit [Ping timeout: 250 seconds]
22:08 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
22:08 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
22:20 -!- p15 [~p15@166.91.145.64.unassigned.bringover.net] has joined #joinmarket
22:28 -!- dingus [~grubles@unaffiliated/grubles] has joined #joinmarket
23:56 -!- rdymac [uid31665@gateway/web/irccloud.com/x-wvgmmuafrwdvekjr] has quit [Quit: Connection closed for inactivity]