--- Day changed Thu Jul 14 2016
00:00 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
00:06 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
01:09 -!- proslogion [~proslogio@2.127.106.111] has joined #joinmarket
01:14 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
01:19 < proslogion> waxwing: "and a signature of his encryption pubkey with that btc pubkey (but note currently: the utxo is not sent at this step, so the utxo's status is not queried by the maker at this step)." surely you can extract a pubkey from the signature? what stops a maker from go looking up the utxo?
01:44 < gmaxwell> the whole reason for the poodle stuff was to solve that. :-/
01:58 < proslogion> " But the current design does not prevent using a fictitious btc pubkey, with no attempt to to receive signatures, but only with the goal of receiving knowledge of the maker's current utxos." so go look up the pubkey, if it doesn't have any output, ignore?
02:00 < proslogion> yeah that's defence #1 in the doc, but it doesn't tell me clearly the reason why it doesn't get implemented is the computational infeasibility or something else
02:00 < proslogion> not 'implemented', but adopted
02:06 < adlai> proslogion: see https://github.com/JoinMarket-Org/joinmarket/blob/master/joinmarket/maker.py#L169
02:07 < adlai> this doesn't prevent reuse, but it does require that the auth utxo is one of the taker inputs
02:08 < proslogion> so the attack scenario is basically one taker will use a legit utxo, then after the maker sends the utxos, abandon the trade?
02:08 < adlai> yes
02:09 < adlai> the only 'reuse prevention' right now is that actually reusing utxos would be a double spend... breaking off the protocol means that the taker doesn't spend, and is able to reuse the inputs indefinitely
02:09 < proslogion> but in which case, the blacklisting rule sounds quite arbitrary, it's very often not unreasonable for the taker to abandon a trade, sometimes for reasons he can't control, sometimes because he has a market watcher that finds a better deal for him...
02:10 < adlai> correct. but this happens ~every~ time for a snoop, as opposed to ~some~times for an honest taker
02:10 < adlai> the 'better deal' thing sounds, uh, unimplemented :P
02:11 < proslogion> yeah sure, but you can't assume people not to build such stuff themselves, especially given the zeal that is palpable
02:12 < adlai> i don't think the zeal is so crazy to reduce maker fees by a tiny amount. people seem to still be using the randomized algorithm which hardly ever selects the "best deal"
02:12 < proslogion> maybe the maker group will eventually form factions with each enforcing its own blacklisting rules, hopefully
02:13 < adlai> or everybody will use this because it'll reduce their spam and there's hardly any reason not to?
02:13  * proslogion shrugs
02:13 < proslogion> everybody agrees with Vitalik on the happy land of the other coin as well
02:14 < adlai> not really
02:14 < proslogion> there is no reason not to, historically it has been proven that if you do, the price goes up, correlation totally equals causation it seems 
02:14  * adlai knows several people who were all ether-happy during the big rally, but only one of them still expresses the same sentiment today
02:14 < adlai> "that if you do" -> do what?
02:15 < proslogion> accepts the will of the great leader Vitalik
02:15 < adlai> oh well
02:16 < adlai> ethereum is a steeming heap anyways :P
02:18 < proslogion> just commenting in general that the community 'seems' to be in overwhelming agreement with something doesn't imply it's the right thing to do, probably captain obvious
02:20 < adlai> 9 out of 10 economists predict that captain obvious wins every keynesian beauty contest
02:20 < adlai> but that last one... Economists Hate Him!
02:21 < adlai> become a contrarian with this one weird trick!
02:46 < proslogion> bitcoin is a teeming stack while ethereum is a steeming heap
02:47 < gmaxwell> ethereum has a lot of people interested in it, the magical things you can do when you spend something like 8 million dollars on marketing and pay off a lot of people with printed money.
02:47 < proslogion> oh the list goes on and on
02:47 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
02:48 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
02:48 < proslogion> also uses a high level imperative language that is deliberately designed to please the script kiddies at the cost of security to write their smart contracts
02:53 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection]
02:54 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
03:26 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection]
03:26 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
03:33 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
03:47 < waxwing> proslogion: your point at the start of this discussion: yes, sending the sig reveals the pubkey, but the pubkey is already revealed explicitly in that message (!auth)
03:47 < waxwing> the purpose of that signature is for MITM prevention; you might remember, you were one of only 3 people here when we discussed it :)
03:49 < proslogion> waxwing: well fwiw, you may have seen it, i disagree with the blacklisting approach as a whole after thinking about it
03:49 < waxwing> proslogion: ok, but to be clear, any blacklisting approach is separate from the above point, right
03:50 < proslogion> yes i was just trying to figure out what's the problem, turns out the gist was an outdated summary of the situation
03:50 < waxwing> which gist? there are a few now
03:50 < waxwing> :)
03:51 < proslogion> the one you showed arubi in the tlsnotary channel
03:51 < waxwing> btw one you may not have seen is this, it's what we've currently got for an updated protocol, but it's probably not going to stay intact! https://gist.github.com/AdamISZ/baf93ce2589854a7992383b3c69fae13
03:52 < waxwing> proslogion: you mean the one with 3 defences?
03:52 < proslogion> yes
03:53 < arubi> https://gist.github.com/AdamISZ/9cbba5e9408d23813ca8  <<
03:53 < waxwing> ok but that one doesn't show handshake step by step. poor documentation on my part, but i did several times ask for comments on https://github.com/JoinMarket-Org/JoinMarket-Docs/blob/master/encryption_protocol.txt back in the day, maybe you remember
03:53 < waxwing> that's still pretty much exactly current
03:54 < waxwing> notice line 17
03:54 < waxwing> whereas the 0.2.0 above as you can see got quite a *lot* more complex.
03:55 < waxwing> anyway, re blacklisting, i'm inclined to agree, if i was forced to pick a side, but what's the alternative?
03:58 < proslogion> i agree that it may even threaten JM's existence if necessary measures are not taken, but I can't help be reminded of how completely voluntary spam blacklist eventually leads to our status quo, in which it becomes practically infeasible to operate a email sever from a residential address
03:58 < proslogion> when your list becomes big and complex, people don't check it, they just subscribe
03:58 < proslogion> and there is no alternative than really checking it
04:01 < arubi> true.  what if there wasn't a public blacklist but makers would track a list themselves?
04:02 < waxwing> yeah that's what i was wondering about the other day. it's tricky to come up with any definitive decision when you consider that makers, annoyed by snoopers, might decide to share the list externally anyway.
04:03 < waxwing> when i say "share" i mean just broadcast, they wouldn't have to know each other or something
04:03 < arubi> it also means that any maker is vulnerable to an attacker at least once
04:03 < waxwing> yeah private has the large disadvantage that you can reuse utxo with everyone N times, where N is their policy for retries
04:04 < waxwing> public has the disadvantage that a maker who is trying to jam the system can broadcast every honest commitment as a failure (and just not allowing tx to complete is good enough for that)
04:06 < waxwing> in case there isn't enough to think about, i also remember that it might make sense to drop the MITM prevention on the taker side, just leave it on maker side. i think putting it both sides was unnecessary.
04:12 -!- mkarrer [~mkarrer@190.red-81-35-195.dynamicip.rima-tde.net] has quit [Ping timeout: 260 seconds]
04:17 < waxwing> re: from yesterday the steemit post: "Joinmarket usually only has 2 participants, DASH has t least 3 people mixing together:" <-- this is how carefully people analyze
04:18 < waxwing> much like the previous day's "shapeshift coins went through joinmarket" fact-free journalism
04:20 < proslogion> i have many Qs about ethereum, but i wouldn't make the effort to go ask people over there
04:20 < proslogion> the entire 'community' is a big pump group
04:20 < proslogion> the worst of all is they don't admit it and disguise it
04:21 < proslogion> e.g., r/ethereum is almost free of trading content
04:21 < waxwing> no, they have a trading subreddit
04:21 < proslogion> yeah i know
04:21 < waxwing> but really you do seem to be fascinated, i think you should join all the #slacks and whatnot :)
04:21 < proslogion> i meant r/bitcoin is very open about their enthusiasm about price 
04:22 < proslogion> while r/ethereum is not
04:22 < waxwing> oh, the narrative of "we're better", yes that's interesting sociologically
04:22 < waxwing> that's back to our philosophising about the term "community"
04:23 < proslogion> they do this sort of passive-aggressive pumping with weasel words, and glittering description of their technology that has very little information
04:23 < waxwing> is there really anything surprising? i mean, do you think the discourse on r/bitcoin during a bubble time is particularly high quality? :)
04:24 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection]
04:24 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
04:24 < proslogion> no, but it's very helpful if i can tell what is about what
04:24 < proslogion> if you ostensibly are talking tech while subconsciously pumping, well
04:25 < proslogion> we are not completely non-guilty of this, how many years had we sold Bitcoin as a network where payment is almost free
04:25 < proslogion> but at least, atm, i can acquire Bitcoin information with a much higher SNR ratio
04:25 < waxwing> i can definitely claim innocence on that, i never thought that made a lick of sense
04:26 < proslogion> i am not, and many others, i didn't mean you
04:26 < proslogion> and well, yeah, it should have been even more rampant before you joined
04:26 < waxwing> yeah, for sure.
04:26 < waxwing> and back then it was factually accurate, just short sighted
04:26 < proslogion> correct
04:27 < proslogion> like we can't be assed to spend a bit more effort..
04:28 < proslogion> also i read the original Reddit post about Gavin's 'scale Bitcoin to VISA tx volume' stuff
04:29 < proslogion> if you just read the comments over there, the 'overwhelming consensus' claim would be right
04:29 < proslogion> the most vocal oppositions amounted to indecision or nitpicking
04:32 < adlai> this is not blacklisting.
04:32 < adlai> coins are supposed to be usable once only, this is the whole point of bitcoin
04:33 < waxwing> well, it becomes semantics, but blacklist is an emotive term, maybe there's a better one.
04:33 < proslogion> filtering or whatever
04:33 < adlai> and i don't think anybody is suggesting doing even the most minimal "tracking" to detect closures or cycling to create fresh utxos
04:34 < adlai> how about QoS
04:34 < adlai> it's really just spam filtering
04:34 < adlai> each utxo gets one chance to merge with you, period
04:35 < waxwing> it would be easier if it really was just *spam* we were trying to prevent, unfortunately the nature of the system is that we're trying prevent semi-private information leaks too.
04:35 < proslogion> each utxo gets used once but nothing stops it from being broadcasted multiple times
04:35 < proslogion> it's like the frequently confusing term 'double spending'
04:35 < adlai> bitcoin stops that
04:35 < proslogion> no Bitcoin doesn't 'stop' it from being broadcasted multiple times
04:36 < proslogion> people very often failed to 'double spend' because they thought it's the wrong thing to do
04:36 < proslogion> due to the confusion
04:38  * adlai isn't sure what proslogion is talking about
04:38 < adlai> the hebrew term for double spending is quite helpful here, because it literally translates back to english as "double utilization"
04:38 < proslogion> i said "nothing stops it from being broadcasted multiple times", and you said "bitcoin stops that", i was like what the hell
04:39 < adlai> which is what we should prevent here
04:40 < adlai> sorry about the misunderstanding
04:41 < arubi> if an honest taker wants to double spend against his own cj, he'd probably want to create a double spend of his own that is not a cj
04:41 < arubi> so double spending within jm should be "frowned upon" by parties, imo
04:42 < adlai> but, the issue at hand isn't double spending. it's double (triple, quadruple, etc) utilization of the only possible 'identity' we have for participants 
04:42 < adlai> it's currently free to create new identities
04:43 < adlai> or rather, reusing identities is free, and we should make them once-only
04:43 < waxwing> arubi: yeah in a way; but notice we already have to specifically allow it in case a maker gets independent requests from takers to use up the same utxos
04:44 < waxwing> after negotiation, the maker is completley unaware whether the broadcast is going to happen, and can't force it himself. he just has to wait and assume it won't happen until he sees it on the network
04:44 < waxwing> people occasionally complain that double spends happen, unfortunately it's inevitable (or "inevitably possible")
04:45 < arubi> hm I see.  right
04:47 < waxwing> but yeah more generally someone double spending "out" of their coinjoin is an annoyance, but not sure there's much to be done there.
04:47 < arubi> there isn't and there shouldn't be
04:49 < proslogion> there are basically two ways to filter spams, voluntarily maintained lists or proof of work
04:49 < proslogion> so far Bitcoin seems to be the only system that doesn't make heavy use of the former and survives
04:49 < proslogion> over a long time, it seems impossible to stop people from being tempted to utilize list-based filtering
04:50 < adlai> i don't think anybody is proposing preemptively blocking lists of inputs because somebody tells you they're undesirable
04:51 < adlai> each input gets a chance to talk to each maker
04:51 < arubi> I think proslogion is right that it would gravitate to that though
04:51 < adlai> no, it wouldn't.
04:51 < adlai> sometimes slippery slopes exist, and sometimes they don't
04:51 < proslogion> the tragic history of Email demonstrates otherwise
04:51 < proslogion> when the list becomes big, people just subscribe without checking
04:51 < adlai> that comparison doesn't hold if you examine it further
04:51 < arubi> even a short while ago folks were all over reddit with the 'bitcoin-cli setban (some aws ip range)'
04:52 < adlai> makers will still listen to any incoming input - ONCE
04:52 < arubi> that's enough for private info leak though
04:53 < arubi> and creating utxo's is very easy, and can be used across multiple makers, if there is no public list
04:53 < adlai> it puts a cost on the leakage
04:53 < adlai> getting all a maker's utxos requires probing many different coinjoin sizes
04:53 < waxwing> and even that is certainly not guaranteed to get all of them
04:54 < adlai> if the snoop has to flood bitcoin with transactions creating new inputs to keep snooping... This Is Actually Good News
04:54 < waxwing> adlai: i agree with your perspective on those points, what is concerning me is the malicious maker jamming takers by dropping their attempted honest txs, forcing them to get new utxos
04:55 < adlai> my suggestion is that we deal with that problem when it arises, since it won't immediately, and might not at all
04:56 < adlai> a taker is only *forced* to get new inputs if all the makers are malicious, in which case - they're fucked anyways
04:56 < waxwing> well, but it depends on if makers broadcast commitments, and if other makers choose to listen
04:57 < adlai> i don't think we should be doing that, at least not yet.
04:57 < waxwing> i might agree, but that's why we're having the discussion about whether broadcasting happens organically
04:59 < waxwing> adlai: btw if you have time, pls keep track of #171, that's where we're kind of "logging" progress towards 0.2.0
04:59 < waxwing> more eyes, other suggestions etc
04:59 < waxwing> stuff gets lost here :) not complaining, but nature of the thing
04:59 < adlai> do we still need the newprotocol branch?
05:00 < adlai> or is it obsoleted by 0.2.0
05:00 < waxwing> i suggested in that thread to just lose it, it's probably too old
05:00 < waxwing> but that doesn't mean there might not be something there to feed back in
05:00 < waxwing> i think it's from like june 2015 :)
05:03 < proslogion> the problem with the jamming attack is that it is costless, so whether it's effective or not, nvm trying
05:04 < proslogion> hmmm...right, i don't seem to understand
05:04 < proslogion> what decides who gets to put a commitment on the public list?
05:04 < adlai> can we merge #423?
05:06 < waxwing> huh completely forgot that one, looking again
05:07 < waxwing> proslogion: we just haven't decided yet on that q, or whether it even means something to make a decision; i guess that's what we're discussing
05:08 < proslogion> hmmm...finally get what people are discussing after 2 hours into the meeting, i am progressing! :)
05:09  * waxwing adjourns meeting for tea and reading adlai's code
05:11 < adlai> i'm quite hesitant to brainstorm how to spam filter a public spam filter list... i think we should agree to leave these lists private
05:12 < proslogion> adlai's saucy list of the 10 outputs most likely involved in paying for strippers. Subscribe? [Yes/No]
05:16 < waxwing> adlai: does it still need the FIXME comment?
05:23 < waxwing> adlai: could you rebase it off latest develop and write a small test that tests 1 tx with maker having no change?
05:23 < waxwing> tbh i won't complain if you just merge it, but we should have tests for everything
05:25 < waxwing> wow that's quite something: https://twitter.com/EdConwaySky/status/753164809538039808
05:27 < proslogion> what's that, Edward Snowden+a con man+octskyward?
05:29 < waxwing> lol http://www.theregister.co.uk/2016/07/14/gov_says_new_home_sec_iwilli_have_powers_to_ban_endtoend_encryption/
05:33 < arubi> haha I always love seeing these "ban encryption" headlines
05:33 < waxwing> "will have powers" .. magical powers perhaps?
05:35 < arubi> "will be circumstances where it is reasonably practicable for a company to build in a facility to de-encrypt the contents of communication"  power to create "circumstances"
05:36 < waxwing> i think Putin recently proposed a similar law, see the recent russian vpn news, i.e. like Feinstein bill "you will provide access to the facility to decrypt on request". calling it "ban e2e encryption" is misleading of course.
05:38 < arubi> sigh, fascism
05:47 < proslogion> this is one of the most entertaining kind of news for me
05:48 < proslogion> that they can't wrap their mind around why their all-curing formula of 'rule of law' doesn't work here
05:48 < proslogion> wonder how long before there is a rude awakening
05:49 < arubi> I like how it says "de-encrypt" :P
05:50 < arubi> "de-lock your door now!"
06:26 -!- mkarrer [~mkarrer@190.red-81-35-195.dynamicip.rima-tde.net] has joined #joinmarket
06:27 -!- lnostdal_ [~lnostdal@168-195-11.connect.netcom.no] has quit [Read error: Connection reset by peer]
06:32 -!- HeySteve [~Lizard__W@unaffiliated/heysteve] has joined #joinmarket
06:54 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection]
06:54 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
07:14 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]
07:14 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has joined #joinmarket
07:38 -!- coins123_ [~coins123@ip-244-225.sn1.clouditalia.com] has quit [Read error: Connection reset by peer]
07:39 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket
08:05 -!- HeySteve [~Lizard__W@unaffiliated/heysteve] has quit [Ping timeout: 276 seconds]
08:43 -!- lnostdal_ [~lnostdal@168-195-11.connect.netcom.no] has joined #joinmarket
09:38 -!- proslogion [~proslogio@2.127.106.111] has quit [Ping timeout: 244 seconds]
09:50 -!- proslogion [~proslogio@130.159.234.124] has joined #joinmarket
10:21 -!- molz [~molly@unaffiliated/molly] has joined #joinmarket
10:23 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:22 -!- fqtw [~me@x5d801adc.dyn.telefonica.de] has quit [Ping timeout: 246 seconds]
11:24 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:26 -!- moli [~molly@unaffiliated/molly] has joined #joinmarket
11:30 -!- fqtw [~me@x5d801adc.dyn.telefonica.de] has joined #joinmarket
11:43 -!- HeySteve [~Lizard__W@unaffiliated/heysteve] has joined #joinmarket
11:49 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 250 seconds]
13:03 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-kccfrqpobwcfhmhs] has joined #joinmarket
13:14 -!- lnostdal_ [~lnostdal@168-195-11.connect.netcom.no] has quit [Quit: lnostdal_]
13:21 < waxwing> consider: joinmarket fails to provide its role if the makers are swamped by sybils (highly arguable, but let's say). therefore, broadcasting of failed podle commitments can be considered "valid" if > N makers broadcast it. thus, a single maker broadcasting a H(P2) will be noted but ignored, but multiple repeats will flag it as being worthy-of-blacklisting.
13:21 < waxwing> i know this is a somewhat shitty argument, but i'm struggling to come up with better.
13:21 < waxwing> the problem with "just don't broadcast" is, I think, it gives way too much scope for usage, especially when you consider "only one use" is probably too strict anyway.
13:23 < waxwing> ("noted but ignored" i mean, of course, increment a counter)
13:41 < gmaxwell> waxwing: What I was suggesting is that you do poodle with up to N generators where N is the number of reuses you want to allow.
13:42 < waxwing> gmaxwell: yes, absolutely, but that doesnt' really change the above
13:42 < gmaxwell> well then after you see a repeat you blacklist it for some span of time.
13:43 < waxwing> i mean, say you choose a small number, you are going to be blocking honest use a lot, if a large number, you can allow a very large "ping" rate and not stop snooping.
13:43 < waxwing> but what is still bothering me is that the maker who is malicious can jam quite effectively, if participants broadcast/share the used up commitments
13:43 < waxwing> (whatever their policy is on reuse allowance)
13:44 < waxwing> and if people don't broadcast, or ignore others announcements, reuse across the whole maker set could be so easy as to make the effect of commitments very weak
13:45 < proslogion> maybe there is something harebrained you can do
13:45 < proslogion> like calculating the set distance of two blacklists, if it's large and yet they still block the same commitment
13:45 < proslogion> then redflag it
13:46 < proslogion> some random stupid metrics etc
13:46 < gmaxwell> waxwing: I don't see it. when the attacker isn't active, what is the normal failure (thus reuse) rate?
13:47 < waxwing> gmaxwell: low-ish for sure, but the problem is that tx completion depends on everyone having no problems. that failure rate is maybe .. 5%? 10%?
13:47 < waxwing> sometimes Tor plays a role, but there are other things too i guess
13:48 < waxwing> but indeed it's a practical/empirical question and if the failure rate is ultra low (<1%) then i agree there may not be an issue
13:49 < waxwing> in my own experience i get ultra-low failure rate during most periods, but i use -P and pick makers for my sends, maybe that matters.
13:50 < waxwing> otoh, that's the point isn't it: if a maker *can* get a jamming effect by using some aspect of what we implement, then a malicious actor may exactly choose to do it for that reason, and increase the failure rate.
13:50 < gmaxwell> well for some given failure rate, N can be picked to make the incidence of users being blacklisted as small as you want... failure rate gets raised to the Nth powe.r
13:51 < gmaxwell> sure but his own outputs get banned at a rate of "everyone else to him"
13:51 < waxwing> the scenario i had in my head was; sybils swamp the "bottom" of the orderbook, where takers tend to go (cheap), drop txs, cause takers commitments to get blacklisted.
13:51 < waxwing> gmaxwell: it sounds like you are considering a scenario where all participants need to make the commitments, is that right?
13:52 < gmaxwell> yes.
13:53 < gmaxwell> I think partial versions can be done that could help somewhat.
13:55 < waxwing> the situation is quite asymmetrical in that makers must give utxos to takers to construct tx, but not the other way round.
13:56 < waxwing> the way we have it now is that the taker must provide the commitment opening before getting the maker's utxos
13:56 < gmaxwell> I suppose you could make N different on each side.
13:56 < waxwing> also takers come and go, are transient
13:57 < waxwing> well, in principle, that doesn't matter i guess. bit tricky.
14:06 < waxwing> i posted this before but for anyone wanting to chime in on the proposed sequence of messages: https://gist.github.com/AdamISZ/baf93ce2589854a7992383b3c69fae13
14:06 < waxwing> still preliminary ofc... :)
14:13 -!- submav [~athena@185.65.134.81] has quit [Remote host closed the connection]
14:25 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket
15:02 <+JM-IRCRelay> [AlexCato] [waxwing] gmaxwell: low-ish for sure, but the problem is that tx completion depends on everyone having no problems. that failure rate is maybe .. 5%? 10%? <-- higher in my experience; probably around 20-25% as seen from my makers. Have 2 makers running, one is at 10% failure today (9/10 successful joins), the other at 33% (4/6 successful joins). Long-
15:02 <+JM-IRCRelay> term its around the same
15:03 <+JM-IRCRelay> [AlexCato] even if UTXOs are blacklisted after X attempts... if i was the attacker, i'd use an UTXO until its blacklisted everywhere. Then be a maker for 1 satoshi fee, and have 2 fresh UTXOs for free shortly after
15:03 < waxwing> oh of course makers failure rate is much higher, i was talking about takers. maker failure rate is affected by the snooping attack
15:03 <+JM-IRCRelay> [AlexCato] sadly, i cant see a defense against that
15:04 <+JM-IRCRelay> [AlexCato] no, i'm filtering the snooping. With that, it'd be 99% failure
15:04 < waxwing> but i wouldn't argue if someone said like, 20%, i'm just not sure.
15:05 < waxwing> re your other comment, agree, but re: "everywhere" it depends on whether we broadcast. that can mean 1 use = effectively used for all makers, in the extreme.
15:05 < waxwing> but, again, see all the back and forth above.
15:06 <+JM-IRCRelay> [AlexCato] been gone for a few days, didnt catch up on all of it yet. Will read it tomorrow :) AFK for now, again
15:07 -!- fqtw [~me@x5d801adc.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
15:08 < proslogion> broadcast maybe the way to go
15:08 < proslogion> or the snooper can just go test each maker to see if he is blacklisted
15:08 < proslogion> and if not, snoop him
16:11 -!- HeySteve [~Lizard__W@unaffiliated/heysteve] has quit [Ping timeout: 258 seconds]
16:27 -!- gielbier [~giel____@095-096-096-058.static.chello.nl] has joined #joinmarket
16:27 -!- gielbier [~giel____@095-096-096-058.static.chello.nl] has quit [Changing host]
16:27 -!- gielbier [~giel____@unaffiliated/gielbier] has joined #joinmarket
17:15 -!- proslogion [~proslogio@130.159.234.124] has quit [Ping timeout: 276 seconds]
17:27 -!- proslogion [~proslogio@2.127.106.111] has joined #joinmarket
17:47 -!- giel__ [~giel____@095-096-096-058.static.chello.nl] has joined #joinmarket
17:50 -!- gielbier [~giel____@unaffiliated/gielbier] has quit [Ping timeout: 264 seconds]
17:57 -!- proslogion [~proslogio@2.127.106.111] has quit [Ping timeout: 276 seconds]
22:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
22:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket