--- Day changed Sun Jul 31 2016
00:52 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]
04:07 -!- belcher [~user@unaffiliated/belcher] has joined #joinmarket
05:05 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
05:06 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #joinmarket
06:04 <+JM-IRCRelay> [AlexCato] waxwing: read the 0.2.0-thread now. This runs on the btc-testnet only, so far? I've only ever run the main chain of bitcoin, running the testnet requires another bitcoind instance to be run as well, i assume?
06:04 < waxwing> you can run both on the same instance iirc
06:04 < waxwing> ports are different
06:07 < waxwing> not actually sure, maybe someone else is. i have a vague memory of doing it, but atm i'm running testnet on a separate machine anyway
06:54 < belcher> you could also run testnet using blockr.io instead of a node
07:01 < waxwing> yes, very good point. in fact, i just remembered, i am doing that myself :) although i have testnet Core running there's some reason i forgot why i didn't attach the bots to it.
07:01 < waxwing> belcher: did you see my response to the size suggestion?
07:02 < belcher> nope
07:02 < waxwing> <waxwing> ah conditional on transaction size, interesting belcher_ 
07:02 < waxwing> <waxwing> but no, the taker doesn't have to commit to the tx size before getting ioauth
07:02 < waxwing> <waxwing> i mean he can lie about it
07:02 < waxwing> i've got the age thing working OK now, although getting tests running properly for all the scenarios is what's difficult
07:03 < waxwing> i haven't done the coin value part yet but that should be quite simple.
07:03 < waxwing> my guess is we just put fairly lax default values, tell everyone to leave them unchanged, and see what happens.
07:04 < belcher> so the taker only sends the utxo commitment, not the utxo itself
07:04 < waxwing> you send the utxo in the 'reveal'
07:05 < waxwing> in the fill just the commitment, that's the idea right, to have it not reveal your private info
07:05 < belcher> yep
07:05 < belcher> and reveal is over an encrypted message
07:05 < waxwing> yes
07:05 < belcher> oh wait but does the reveal happen after the maker sends his utxos  ?
07:06 < waxwing> step 4 in the updated gist: https://gist.github.com/AdamISZ/baf93ce2589854a7992383b3c69fae13
07:06 < waxwing> "O" = open
07:06 < waxwing> reveal is the taker revealing his commitment utxo. if passes, then maker does !ioauth then.
07:06 < belcher> ok
07:06 < waxwing> 4,5 there
07:07 < belcher> so in this protocol the taker could lie about the bitcoin amount because the single commitment utxo could legitimately not be of high enough value (because it will be combined with other inputs)
07:08 < waxwing> hmm i think i was wrong now
07:08 < waxwing> i forgot, the amount is set in !fill
07:09 < waxwing> sorry for confusion. but it seems like it might be too strict to require the commitment utxo to be as big as that?
07:09 < waxwing> hmm, tricky. it's at least a very valid thought.
07:09 < belcher> i wrote about the game theory stuff here once https://github.com/JoinMarket-Org/joinmarket/issues/156#issuecomment-211661114
07:10 < belcher> if we required the full amount to be committed, it would mean there'd have to many commitments sometimes
07:10 < belcher> if the taker wants to coinjoin 1btc but has two utxos worth 0.5 and 0.6, he'd have to send over committments for both
07:10 < waxwing> right, i don't think in the "pure" sense it's very practical, but the general idea is good.
07:11 < belcher> whats the pure sense?
07:11 < waxwing> that there is a correlation between the size of the commitment and the size of the coinjoin
07:11 < waxwing> like, 0.01 commitment might be fine for 0.05 tx but no good for 10 btc coinjoin.
07:11 < waxwing> oh sorry you were asking the opposite
07:12 < waxwing> the pure sense is that you have to commit to exactly (or more than) the coinjoin amount, which has the obvious problem you mention
07:12 < waxwing> or are you thinking that we should just deal with that and force the commitment to every utxo
07:13 < adlai> it's not a gamebreaker to require the commitment >= cj_amount
07:13 < belcher> yes, i think the pure sense is okay
07:13 < adlai> just forces people to do multiple coinjoins, which isn't a bad thing anyway
07:14 < belcher> the downside is just that more data has to be transmitted, which isnt too bad
07:14 < waxwing> adlai: it's not a gamebreaker for all, but it's going to create meaningful issues for some users
07:14 < belcher> or a single coinjoin with sum(commitments) >= cj_amount
07:14 < adlai> requiring multiple commitments is an option too
07:14 < waxwing> re: extra data transmitted, well, i tend to agree, but it could be a pretty big chunk. look at what "O" contains in the gist.
07:15 < belcher> yep, its 6x64 bytes ?
07:15 < adlai> hmm, forcing multiple joins is iffy, because it could cause conflation of utxos from separate depths
07:15 < waxwing> sure but we could cut it down. oh, 5 not 6.
07:16 < adlai> revealing correlations to makers
07:16 < waxwing> could be binary cut it in half. but still a lot of data.
07:16 < waxwing> (binary because under enc so b64)
07:16 < adlai> btw, i was wondering... while 0.2.0 is unfinished, could we do a bandaid patch on develop which just ignores repeated utxos?
07:17 < adlai> without the commitment; just on the basis of the signature
07:17 < waxwing> i'm kinda overwhelmed trying to get this finished.
07:18 < belcher> and then get it deployed, hopefully avoiding creating the impression that its totally fixed
07:18 < waxwing> what really takes up the time is making tests.
07:19 < waxwing> i kind of like "lower bound size correlated to coinjoin size" as a compromise
07:20 < waxwing> thing is, the value/size aspect of the utxo is less important than the age in my opinion.
07:20 < waxwing> because once you have X utxos of amount A, all you really need is to keep cycling them through bitcoin transactions.
07:20 < waxwing> so the only actual cost is time and bitcoin tx fees.
07:21 < belcher> i worry that might make the taker's user experiance worse
07:21 < waxwing> the attacker is in a race with the set of makers: the faster makers churn their utxos through joins, the less time the attacker has to ping and get the full set of utxos to allow isolation of taker outputs
07:22 < waxwing> and ofc the whole yg algo thing which might just defeat the attacker partially
07:22 < waxwing> belcher: true but if everything is working normally they will be using utxos they immediately consume in transactions
07:23 < belcher> i dont understand that last thing :)
07:23 < waxwing> but yeah like tumbler if you have 10-100 blocks it creates issues
07:23 < belcher> you're proposing the taker's utxos will have to be of a certain age
07:24 < waxwing> sure age is an issue, for at least two cases - 1, completely new user, so new wallet and 2, tumbler or other repeating over short time
07:25 < waxwing> but with utxo coin amount, like i say, i don't see how much of a restriction that'd be since you can just refresh them (like 10-50 of them) easily just doing 1 transaction with only bitcoin tx fee cost
07:26 < belcher> agreed, though id argue all of joinmarket relies on that
07:26 < belcher> someone who owns a huge amount of bitcoins can be the maker in everyones coinjoins
07:26 < waxwing> i disagree, i think the dynamics are different.
07:26 < waxwing> swamping the orderbook doesn't prevent others doing the same
07:27 < waxwing> whereas 1 snooper can snoop the whole orderbook with sufficient utxos (in this commitment model)
07:27 < waxwing> he just needs one "set" of utxos and is then only bound by confirmation time
07:28 < belcher> that set needs be worth more than 200btc 
07:28 < belcher> just checked the orderbook, theres no more 200btc offers
07:28 < belcher> but about 6 of them higher than 50btc
07:29 < waxwing> if we require coinjoin amount for commitment, yeah. but say they have 100 btc, hardly difficult for attackers.
07:29 < waxwing> they don't have to spend it after all
07:29 < belcher> remember the attacker can only use his utxo set on one offer, after they get banned he has to do a blockchain transaction
07:29 < waxwing> yeah they just need to wait a confirmation, that's what i meant
07:29 < waxwing> if we don't require any age
07:30 < waxwing> i think the attack is kind of a race, albeit one that the attacker easily wins today because activity in the pit is not that great
07:30 < waxwing> would you consider an age of 3-4 blocks unreasonable instead of 1?
07:30 < waxwing> push them back to 30+ minutes at least
07:30 < belcher> the race view is helpful, a good way to think of it
07:31 < waxwing> i think hoping the attackers are money-bounded might prove sadly wrong, given we know the kind of funding some people have...
07:31 < belcher> the issue with not requiring the size is it means even a utxo worth 1mbtc can spy on a maker with 50btc
07:32 < belcher> so maybe both kinds of protection should be done? value and age
07:32 < waxwing> this was my conclusion too
07:33 < waxwing> what i didn't consider is having it be a ratio to the coinjoin amount. i can't see any disadvantage to that.
07:33 < waxwing> except the rare example of an honest taker who is inconvenienced by it.
07:33 < waxwing> i had in mind just a fixed minimum, but this is better.
07:34 < waxwing> i know you want to send *all* but apart from the data transfer i worry about how complex that gets, because after all sometimes it fails
07:34 < waxwing> and then not only do you have to deal with the data transfer but also putting together some *other* utxos to get the right total, or above. it's just too much for now imo.
07:35 < belcher> wouldnt you send the same utxos you'll use for the coinjoin?
07:35 < waxwing> yes, but as i say, sometimes it fails
07:35 < belcher> the ones that come out of select_utxos()
07:36 < waxwing> yes it's already like that, kind of, in that i currently have it selecting one of those first, and if that fails, falling back to the whole wallet, and if that fails, falling back to an external list
07:36 < waxwing> "fails" in the sense that the taker himself looks at those and sees whether he already used them, and (currently) if age is old enough (that part is obviously up in the air now)
07:36 < belcher> oh right, so it fails because it might already be banned
07:36 < belcher> i forgot about that
07:37 < waxwing> yes this setup creates meaningful fragility, i think the only way to address it is to give the Taker lots of scope to choose utxos
07:37 < waxwing> part of that was the "retries" concept with NUMS points, the other part was allowing any old utxo.
07:38 < waxwing> now what's left is figuring out some reasonable condition on utxo(s). right now i've done age, and i think a limit on size is sensible (even if the slight extra restriction might create more failure cases for Takers)
07:38 < belcher> what if the taker chooses another maker if they get their utxos banned
07:39 < waxwing> if *any* maker rejects a tx, then they just have to retry up to the retry limit and then use another utxo. even though currently there is no "broadcast" feature.
07:40 < belcher> oh yes duur
07:40 < waxwing> so in other words, i view it as: the Taker assumes that any podle that he sent can never be used again.
07:40 < waxwing> where there are 3 podles per utxo (where 3 is taker_utxo_retries)
07:41 < waxwing> i think without external utxos being allowed, we wouldn't be able to get a reasonable balance between usability and defence against snoopers. because we'd have to be so lax with retries that the snooper can create an overwhelming amount.
07:42 < belcher> yes i see it nwo
07:43 < waxwing> i'm thinking to be reasonably lax to start. like, amount = coinjoin amount/5 age = 5 blocks.
07:43 < belcher> ok
07:43 < waxwing> just thinking aloud. tbh i think an attacker with some reasonable funds could still achieve their goal in that scenario.
07:43 < waxwing> but, only because the volume in the pit is low.
07:44 < belcher> it might be worth trying to model it, so finding how much an attacker needs to own to deanonymize people if those are the parameters
07:44 < waxwing> maybe we should just spend a lot more time analyzing yg algos. because that's critical.
07:44 < waxwing> yeah some modelling might be possible, true.
07:44 < belcher> if you remember in bitcoin.pdf, there's the calculation for how much a miner needs to own to reverse transactions, which was quite convincing
07:45 < waxwing> yes, sounds like a good job for .. someone :)
07:47 < belcher> ill think about it
07:47 < belcher> i.e. ill try to do it
07:48 < waxwing> belcher: the fly in the ointment is tumbler vs age requirement. one fix might be to flag up a problem for the user who tries to set short time waits
07:48 < waxwing> depending on their wallet, they might be able to go fairly fast anyway
07:48 < waxwing> but that's really hard to work out
07:51 < belcher> we'll just tell tumbler users to it slow down
07:54 < waxwing> belcher: yes i agree, but i suppose what it says to me is that very large age requirements aren't very realistic (like, several hours)
07:54 < belcher> yes
08:10 < waxwing> shower thought: privacy preserving yg algo is one that enforces cycling through subsets (ie mixdepths) after txs, and refuses to cycle otherwise. so between transactions 1/5 (optimistally) of offered utxos remain opaque no matter the fill amount.
08:11 < waxwing>  i think -basic is similar to that, i forgot the exact algo.
08:12 < waxwing> by shower thought i mean i haven't thought it through at all, it's more just: we should come up with the "ideal" yg algo for privacy.
09:03 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket
11:42 -!- Cory [~C@unaffiliated/cory] has quit [Remote host closed the connection]
11:46 -!- Cory [~C@unaffiliated/cory] has joined #joinmarket
12:36 < waxwing> nkuttler: whenever convenient, please update your bots. also delete joinmarket.cfg before running to create a new default one (new settings at bottom in POLICY section, don't change them)
13:25 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket
13:31 < nkuttler> up and running
13:31 < waxwing> nkuttler: thanks
13:47 < nkuttler> np, yw
14:15 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Ping timeout: 244 seconds]
16:16 -!- rdymac [uid31665@gateway/web/irccloud.com/x-gqckkztkapfrwvtc] has quit [Quit: Connection closed for inactivity]
16:47 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
17:28 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket
18:50 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-csjodsspivzyrwkg] has quit [Quit: Connection closed for inactivity]
19:10 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection]
23:05 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Remote host closed the connection]
23:40 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket
23:45 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-glvprelrcxlkwpev] has joined #joinmarket
23:53 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]
23:54 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has joined #joinmarket