--- Day changed Sun Sep 01 2019
01:27 -!- Giszmo [~leo@2407:7000:9d28:5100:40a3:b13a:6bd6:ce10] has quit [Quit: Leaving.]     
02:20 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
05:28 -!- MaxSan [~four@109.202.107.10] has joined #joinmarket     
05:50 -!- MaxSan [~four@109.202.107.10] has quit [Ping timeout: 244 seconds]     
06:02 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds]     
06:07 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
06:48 < waxwing> arubi, belcher i sent an email with the draft as-is. thanks for feedback.
06:49 < waxwing> arubi, also arguably you should be co-author, i wasn't sure, but i did give you strong credit in "Credits" as basically the author of v01.
08:27 < waxwing> belcher, so i'm (re)reading your tumbler ideas, and i'm struggling with this no-change part. wrt "A naïve question might be why doesn't the tumbler script only create such no-change-coinjoins? The answer is then it would be easy to follow the trail of coins, because makers virtually-never create no-change-coinjoins."
08:28 < waxwing> i'm confused .. is the idea that you could track a series of no-change coinjoins in sequence ... but then if we ignored sendpayments and assumed every taker was using tumbler, wouldn't it be the case that all transactions had that pattern anyway?
08:30 < waxwing> it occurs to me, thinking on this topic, that one way to do it would be if say you had 5 utxos in a mixdepth at the start of the tumble, you could make zero change using one utxo only (or two) and then the last could sweep whatever's left. is this the kind of thing you had in mind for that "naive" scenario?
08:30 < waxwing> i guess it must be.
09:27 < arubi> yea waxwing I saw the email on the ML web access earlier, nice!  re. co-author, I'm counting on you to mention me where you see fit :)  you did all the writing and probably also working on an implementation.  (afk for a bit)
11:22 < belcher> waxwing if everyone used sweep coinjoins then the amount would give away ownership
11:23 < belcher> think of 8-9 sweep coinjoins with basically the same amount
11:23 < belcher> ygens dont follow that pattern at all, they basically never make sweeps
11:24 < undeath> do sweeps offer any anonymity other than plausible deniability?
11:25 < belcher> i would say yes
11:25 < belcher> they join together many different transaction graphs
11:26 < undeath> but the sweep tx itself is in 99% easily broken by subset sum
11:27 < belcher> is that any worse for non-sweep coinjoins?
11:28 < undeath> for non-sweep tx that's only true for change outputs
11:29 < belcher> subset sum analysis on the amounts doesnt work for finding the change of sweeps because they dont have it... subset sum analysis can be used to learn which inputs are owned by the same person, but that also works for non-sweep coinjoins i think
11:29 < undeath> i guess it depends on what direction your analysis starts at. if you get paid through a cj sweep it's easy to identify the corresponding cj input
11:30 < undeath> assuming you were paid by the taker
11:30 < belcher> thats true for non-sweeps too isnt it?
11:30 < belcher> if you want to pay someone privately with joinmarket you need to use tumbler
11:31 < undeath> indeed
11:33 < belcher> the subset sum analysis thing is interesting, at first you'd think you could always break JM coinjoins with it, but it seems sometimes theres multiple possible input/output subsets
11:36 < undeath> an interesting question would be how often that ambiguity happens for the taker input(s)
11:38 < belcher> this is all i know about that https://gist.github.com/chris-belcher/7e92810f07328fdfdef2ce444aad0968#appendix
11:38 < belcher> 33% of the time according to some academics who wrote a paper in 2016
11:38 < undeath> that sounds pretty high
11:38 < belcher> that also includes when their algorithm found it too computationally infeasable to do the subset sum analysis
11:39 < belcher> and back then JM almost entirely made 3-party coinjoins with a little bit of 4-party and 5-party mixed in
12:04 < belcher> waxwing arubi in the snicker proposal, have you considered doing precomputed fee bumping, i.e. the proposer creates more than one proposed transaction with RBF enable, those transactions are the same except their miner fee increases and their nlocktime increases, then the receiver can sign all of them and broadcast them one-by-one if they dont get confirmed in order to fee-bump (also the broadcasting can be done by a third party, this is 
12:04 < belcher> trustless because of the rising nlocktime time)
12:17 < waxwing> belcher, yes i agree it's possible. it's probably one of a few additional features that could enhance it but i didn't want to list all of them. i think i should have added that to the future enhancements section though, at least.
12:17 < waxwing> but also note in the email i pointed at that section as something that needs review (the transaction construction details).
12:18 < waxwing> some other people will doubtless complain at the idea of using PSBT because they think to make this practical requires making the tx proposals small. this wouldn't help with that. although i don't really agree with the idea that compacting the size is really that helpful.
12:18 < waxwing> (scale vs scaling kinda thing)
12:21 -!- reallll [~belcher@unaffiliated/belcher] has joined #joinmarket     
12:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Disconnected by services]     
12:24 -!- reallll is now known as belcher     
12:25 < belcher> the precomputed fee bumping can be done by just publishing each signature and what the different miner fees should be, that would be enough information to figure out each entire fee-bumped transaction
12:26 < belcher> so sure it does require more data but not that much (though admittedly signatures are a big part of transactions)
12:49 < waxwing> yes. same principle as for the tx proposal itself, which could be far less bytes than it is in the current draft, but like i say, i'm not that convinced by arguments it needs to be smaller.
12:50 < waxwing> the reason i haven't added optimisations and have proposed what i have is to fix as much as possible to existing standards and to keep it simple.
12:50 < waxwing> simple could be better here to avoid watermarking different proposers, perhaps. and easier to understand etc etc
12:51 < waxwing> i guess rbf bumped versions are a pretty good idea though, i'd say
13:33 < arubi> right so basically there's no way around fee bumping requiring that many more signatures.  say a proposal carries 3-4 signatures (one minimum right), without the bulletin board being "indexed to keys", the amount of data that a receiver must download easily doubles
13:34 < arubi> well, it doubles either way, but with indexing to keys it's probably manageable
13:34 < belcher> indexing to keys is IMO the only way to make the scheme practical
13:35 < arubi> I was also leaning towards hashcash as means of payment for publishing proposals
13:35 < arubi> seems clean
13:35 < belcher> well maybe not if it gets combined with some other antispam measure, maybe have proposers pay with LN
13:35 < belcher> what do you set the difficulty as?
13:35 < belcher> the hashcash difficulty i mean
13:35 < arubi> not sure, say one second to generate?
13:35 < arubi> on a medium phone
13:36 < belcher> i fear it could still be spammed by botnets
13:36 < belcher> or even just one computer, if 1 second to generate thats 80k proposals per day... those proposals hang around for a while dont they
13:36 < arubi> yea probably, at one second even if the botnet is small
13:37 < arubi> hm yea
13:37 < arubi> well even at 10 seconds, a dedicated troll could spam for a day no problem
13:37 < arubi> payment helps, but then how much do you pay?
13:40 < arubi> maybe the bulletin board shouldn't really keep records.  make it like an irc chaneel where messages just stream through and if a receiver is online, then they see it :)
13:40 < arubi> jm-style I guess :)
13:41 < arubi> any way you choose has its pros and cons though.  an irc channel reduces non-interactivity by a lot
13:44 < arubi> rsync is kinda interesting in how it works, where when you sync a file, it's split into (I think) 128kb chunks.  so if there's a large file in the source and destination, and only a few chunks differ then it's not the entire file being re-copied
13:45 < arubi> so maybe the initial download of the bulletin board contents is.. tens of megabytes, but from then on it's just incremental?  hand-wave
13:52 < waxwing> i remember having a similar thought about incremental. feel like the scalability problem per se is less important than the spam problem. not that they're entirely distinguished of course.
13:53 < arubi> no you're right, even a perfect incremental solution can still be spammed
13:53 < arubi> so maybe hashcash where the server keeps your proposal for so long based on some ratio against the hash difficulty that you've chosen for yourself
13:54 < waxwing> i'm dubious about hashcash in the same way that everyone always is (and as belcher mentioned here). it wouldn't be terrible though, and stupidly easy to implement.
13:57 < arubi> yea, the thing about paying for listings is that interferes with fees, and kinda annoying if proposer only has one utxo
13:57 < waxwing> what bothers me most about the spam problem is that it seems to skew the incentives in the wrong direction. like, whatever you come up with to stop it means expense for the Proposer, which means likely Proposers would not be incented to do the work unless they were paid. but the system would grow much more healthily if Receivers paid zero or less.
13:57 < waxwing> because the concept is more like 'no effort acceptance in wallets for ordinary users' (see the alisa/bob example in the blog).
13:58 < waxwing> maybe it just ends up with quasi-centralized proposers.
14:00 < arubi> did bitmessage use hashcash for spam prevention?
14:00 < waxwing> i have a vague memory of that, not 100% sure
14:02 < arubi> yea not sure either.  kinda seems like it was something like that from a quick search
14:03 < qubenix> iirc it was pow, and you could increase the pow needed to send a message to you
14:05 < arubi> oh yea..  that's kinda nice.  so something like that might help the receiver when he fetches data that interests him, but not the bulleting board
14:05 < arubi> bitmessage didn't have the latter problem because it wasn't keeping records iirc
14:05 < waxwing> i mean everyone could be on a p2p network doing this and then use that same mechanism. but that's too hard (for some simple wallet).
14:06 < arubi> right, and it's only somewhat non-interactive at that point
15:04 -!- kristapsk___ is now known as kristapsk     
15:45 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.5]     
15:46 < harding> Thinking about the snicker bulletin board spam problem makes me wonder whether the proposal psbt even needs to be encrypted.  That is, as long as the receiver's outputs are generated using secret data (and the proposer's outputs are themselves unidentifiable), then you have coinjoin privacy even if there multiple other publicly-knows psbts that don't get fulilled.  If the psbts aren't encrypted, then 
15:46 < harding> bulletin board can restrict the number of proposals for a particular UTXO with attached signature (e.g. a max of 10,000 or whateve0).
15:48 < harding> Even if that's not the case, the bulletin board can implement spam protection in the form of people having to sign with their UTXO and limiting the number of database entries allowed per UTXO.
15:48 < waxwing> you at least need to encrypt the signature(s)
15:49 < waxwing> previously i had it that you also needed encryption for the tweak, but now the proposal has it generated from the keys so it could be implicit (though it's nice to be explicit for sanity checking, but maybe that should be ditched)
15:50 < waxwing> but you have a point about spam control there.
15:51 < harding> Why do the signatures need to be encrypted?
15:51 < waxwing> well i mean if there are two inputs and you send a signature it's easy to verify which one it comes from .. i guess you could argue that it doesn't matter, but i like the extra ambiguity. perhaps my perspective on that is wrong .. not sure.
15:52 < waxwing> still overall you're making an interesting point here, needs thinking about for sure.
15:52 < waxwing> doesn't it feel like revealing which input comes from the Proposer is a degradation in the privacy achieved?
15:53 < harding> I was thinking it doesn't matter because it'd be easy for a spy company to just create lots and lots of UTXOs and so receive a high percentage of all proposals themselves.
15:55 < waxwing> well that's the old debate point we've had from the start ... given M "honest" participants, does N additional "spy"/non-honest participants make the situation worse .. always seems a bit debatable.
15:57 < harding> Well, I think it clearly does make it worse for snickers because, at least initially, proposers will probably need to create hundreds or thousands of proposals before one gets accepted by one of the few snicker receivers.  By corollary, that means someone with 1/100th or 1/1000th of all utxos eligible for use with snicker will probably be able to identify most UTXOs that proposers have ever tried to 
15:57 < harding> use.
15:59 < waxwing> harding, hmm i'm tending to come around to your point of view, because signatures specifically could provide our needed anti-spam.
16:00 < waxwing> the mental block here was that the original proposal was always absolutely requiring encryption for tweaks, but with arubi 's switch to ecdh derivation of the tweak (which works for both versions), that no longer applies.
16:01 < waxwing> there probably still is an argument for encryption, but the fact that signatures on utxos provide a natural mechanism to stop spam, seems an extremely strong argument.
16:01 < waxwing> and, without encryption, it'd be even easier to implement (although that's just a detail really).
16:02 < harding> Yeah, the encryption seemed natural to me.  I wouldn't have given it a second thought if it weren't for the spam discussion above.
16:02 < waxwing> i'm not sure the initial bootstrap is as much of a problem as you think. but that's a detail and it depends on practical realities, so put that to one side.
16:03 < waxwing> it's late here but if you have more thoughts i'm always on in this channel.
16:03 < harding> I have a couple points written up in a reply to your list email, but I'm still chewing on your proposal.
16:04 < harding> (So nothing right now.)
17:08 -!- AgoraRelay [~jmrelayfn@p54866C96.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]     
17:09 -!- CgRelayBot [~CgRelayBo@p54866C96.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]     
17:15 -!- Giszmo [~leo@143.120.252.27.dyn.cust.vf.net.nz] has joined #joinmarket     
17:21 -!- AgoraRelay [~jmrelayfn@p5DE4AB06.dip0.t-ipconnect.de] has joined #joinmarket     
17:22 -!- CgRelayBot [~CgRelayBo@p5DE4AB06.dip0.t-ipconnect.de] has joined #joinmarket     
19:11 -!- tabularasa36 [aed60c26@38.sub-174-214-12.myvzw.com] has joined #joinmarket     
19:11 -!- tabularasa36 [aed60c26@38.sub-174-214-12.myvzw.com] has quit [Remote host closed the connection]     
20:30 -!- tabularasa36 [aed60c26@38.sub-174-214-12.myvzw.com] has joined #joinmarket     
20:35 -!- l0rdquasi [49e76bcd@c-73-231-107-205.hsd1.ca.comcast.net] has joined #joinmarket     
20:44 < tabularasa36> Hi I’m new to joinmarket and Linux. I want to run the yield generator on my headless pi. How do I keep the yg running in the background after I log off ssh?
20:48 -!- adlai [~adlai@unaffiliated/adlai] has quit [Ping timeout: 258 seconds]     
20:54 -!- adlai [~adlai@unaffiliated/adlai] has joined #joinmarket     
21:12 -!- tabularasa36 [aed60c26@38.sub-174-214-12.myvzw.com] has quit [Remote host closed the connection]     
21:39 -!- jdm [~jdm@unaffiliated/user1138] has quit [Quit: Quitting.]     
21:41 -!- jdm [~jdm@unaffiliated/user1138] has joined #joinmarket     
22:34 -!- l0rdquasi [49e76bcd@c-73-231-107-205.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
22:41 < CgRelayBot> [cgan/AlexCato1] hi tabularasa36, there's a few options, see here: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/153
22:42 -!- l0rdquasi [49e76bcd@c-73-231-107-205.hsd1.ca.comcast.net] has joined #joinmarket     
23:29 -!- Mandy29Balistrer [~Mandy29Ba@ns334669.ip-5-196-64.eu] has joined #joinmarket