--- Day changed Sun Jan 06 2019
00:28 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 272 seconds]     
00:46 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket     
01:49 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
02:17 -!- M1 [~Michail@michail.com] has quit [Read error: Connection reset by peer]     
02:22 -!- M1 [~Michail@michail.com] has joined #joinmarket     
03:25 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Ping timeout: 256 seconds]     
03:39 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
05:08 < waxwing> belcher, i just realised it's kind of bizarre and perhaps annoying to people that we offer two donation addresses, neither of which can be donated to directly using joinmarket coinjoins :)
05:09 < belcher> even if we offered a p2sh address it would be known as our donation address
05:09 < belcher> found by google
05:09 < waxwing> good point :)
05:09 < waxwing> it would still look nicer though :)
05:10 < belcher> i could make one if you want
05:10 < belcher> the really private way would be for a server to give a new address each time
05:10 < belcher> but then its hard to do with accountability
05:15 < waxwing> belcher, no i was just quipping, clearly your counterargument is more than valid; and having bech32 is enough of a step forward.
05:16 < waxwing> and we could add donation stuff back into the code but i'm leery of it both for tech and non-tech reasons. just my personal opinion, i know it isn't necessarily shared.
05:16 < belcher> i agree, also nobody used it
05:17 < belcher> i wonder what the best way would be to have donations with privacy for the donator but accountability for project members
05:17 < belcher> i know darkwallet's stealth address scheme had two privkeys, one which allowed viewing and one which allowed spending
05:18 < belcher> maybe have a server that gives out signed donation addresses and then the donator has to email the address + signature to all project members
05:19 < belcher> an attack on that is to send a probe payment, donate $2 and then watch the blockchain and use CIOH to figure out what the other donations are
06:13 -!- nothingmuch [~user@213.152.162.89] has joined #joinmarket     
06:17 < waxwing> anyone know how to run a flake test locally so it catches whatever the rules are in setup.cfg?
06:24 -!- nothingmuch [~user@213.152.162.89] has quit [Ping timeout: 250 seconds]     
07:39 -!- nothingmuch [~user@62.102.148.185] has joined #joinmarket     
07:41 < waxwing> i'm completely bemused by this; all the tests fail with this error: https://travis-ci.org/JoinMarket-Org/joinmarket-clientserver/jobs/475995202#L2342
07:53 < qubenix> waxwing: maybe it could be because of the problem before that on line 2285?
07:54 < waxwing> that's the one about coverage not being compatible right? indeed, but we have often observed before that we always get that.
07:54 < waxwing> doens't prove it's unconnected, though, and i don't know what the story was behind that.
07:54 < qubenix> i have no idea, just throwing it out there
07:54 < waxwing> yes. not dismissing the observation.
07:55 < waxwing> coverage has basically always been borked for some obscure reason. not that we're anywhere good with coverage. amusingly back when is tarted this version of the repo i managed to get it to the high 90s, but then other things took over and now it'd be really low, i'm afraid, if it was actually measured.
08:00 -!- grubles_ [~grubles_@unaffiliated/grubles] has quit []     
09:27 < waxwing> it seems like theoretically we could allow p2ep functioning with any of (p2pkh, p2sh-p2wpkh, p2wpkh) wallets. i'm a bit wary of supporting our legacy wallet though.
09:27 < waxwing> the test already tries with mixes of types between the two participants. maybe this overcomplicates things.
09:48 < waxwing> ok, maybe that's kinda stupid, since we really don't want sender and receiver with different wallet types. but, i dunno, it would be nice to support p2wpkh especially. probably leave it for later.
10:04 -!- GitHub164 [GitHub164@gateway/service/github.com/x-fmalmnfcoitrtsgq] has joined #joinmarket     
10:04 < GitHub164> [joinmarket-clientserver] AlexCato opened pull request #281: Increase timeout waiting for coinjoin TX broadcast (master...patch-4) https://git.io/fhsRk
10:04 -!- GitHub164 [GitHub164@gateway/service/github.com/x-fmalmnfcoitrtsgq] has left #joinmarket []     
10:09 < arubi> waxwing, in case you still need it, the command to run flake is `flake8 jmbase jmbitcoin jmclient jmdaemon scripts test` .  you need to `pip install flake8` first
10:12 < arubi> wrt p2ep w/ p2pkh, dunno if it really makes a difference, but anything non segwit is malleable and might open some "annoyance vector" if any of payer\miners are malicious..  yea it's pretty weak, but worth to consider I think
10:15 < arubi> I'm assuming alice\bob might want to use the change\payment outputs right away for something else, so any txid change will be really annoying
10:23 < waxwing> seems a bit of a stretch; same could be said of any payment, right? generally coinjoin being one tx is good enough. not that i'm advocating using legacy/non-sw, there's no real advantage except some special situation where you want that anon set i guess.
10:38 < arubi> true.  anon set is a strong argument for supporting it
10:40 < arubi> also wrt weird tests errors in travis' native linux, could you try changing in 'requirements-dev.txt' :  "coverage" to "coverage==4.0.3" and "pytest-cov" to "pytest-cov>=2.4.0,<2.6" ?  obviously not urgent
10:41 < arubi> I managed to recreate the errors here locally and this seems to fix them.  looks related : https://github.com/z4r/python-coveralls/issues/66
10:42 < arubi> well that has been appearing on travis for a while now, but seems that the issue is related to python-coveralls\python-cov\coverage synergy
10:49 < waxwing> arubi, many thanks, will do
10:49 < arubi> errors in dockers are different.  I think it's because of an older core version.  everything passes for me
10:50 < arubi> gonna try getting it sorted and open a PR you can rebase on top of
11:00 < waxwing> arubi, k, thanks, i'll wait for that instead
11:01 -!- GitHub13 [GitHub13@gateway/service/github.com/x-orhcetnrebtbhxwc] has joined #joinmarket     
11:01 < GitHub13> [joinmarket-clientserver] fivepiece opened pull request #282: pin coverage+pytest-cov versions, upgrade core to 0.17.1 on docker (p2ep...p2ep-tests) https://git.io/fhs0S
11:01 -!- GitHub13 [GitHub13@gateway/service/github.com/x-orhcetnrebtbhxwc] has left #joinmarket []     
11:01 < arubi> here we go heh
11:01 < arubi> oh lol I opened it against the p2ep branch
11:03 < arubi> waxwing you want me to reopen against master?
11:10 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
11:20 -!- GitHub36 [GitHub36@gateway/service/github.com/x-ligsvuluhoaskdob] has joined #joinmarket     
11:20 < GitHub36> [joinmarket-clientserver] fivepiece opened pull request #283: pin coverage+pytest-cov versions, upgrade core to 0.17.1 on docker (master...master-tests) https://git.io/fhsEi
11:20 -!- GitHub36 [GitHub36@gateway/service/github.com/x-ligsvuluhoaskdob] has left #joinmarket []     
11:21 < arubi> easy enough I guess.  grab whichever and close the other one if I'm not around :)
11:35 < qubenix> i wonder if it would be helpful if makers tried to make an extra utxo of change to themselves that matches the takers destination amt. i was thinking this would make guessing the -N in a tx unreliable to an outside observer and also other makers.
11:36 < qubenix> i guess it wouldn't work if each participant only has 1 input
11:41 < arubi> if makers are the only one doing it then I think it would be pretty easy to pinpoint the taker's change
11:42 < arubi> actually, not sure if that's true.  feels like it is though but I'm not sure I could think it through after this long day :)
11:42 < qubenix> i think it's only useful to mask the number of takers, not sure it that is even helpful.
11:42 < qubenix> makers*
11:43 < arubi> makers are always n-1 the participants in the join though?
11:43 < arubi> unless something has changed
11:43 < arubi> ohh of course, might be more than 1 input
11:43 < arubi> hm     
11:44 < arubi> yea I think you're right, but I do still think it taints the taker's change completely
11:44 < arubi> (if taker isn't doing it too)
11:44 < qubenix> oh, more interesting now if takers does it too i think
11:45 < arubi> yea hm, so we say we wanna hide the number of makers.  belcher might know if this practice actually hides the amount.  there might be some subset sum game here if we know the exact amount of the payment (and we do)
11:46 < arubi> I mean, if we look through all the inputs' amounts and try to deduce some sane number of participants.  I guess it could also be that a single maker just uses "too many" inputs and sends themselves more than one change output which is also the amount
11:47 < arubi> yea I think that works..  if the maker isn't trying to be as efficient in his inputs and kinda makes it look like there are more than just him
11:48 < arubi> I mean, simplest case, one maker and one taker,  maker has many utxos and "acts" like many makers.  sure it could work, to a 3rd party it just looks like many makers
11:50 < belcher> whats the purpose of hiding the number of makers?
11:54 < arubi> good question :)  was really wondering if it's possible - but I think I answered myself there that it is
12:10 < waxwing> arubi, yes sure always master, i'll rebase
12:10 < arubi> cool
12:11 -!- GitHub92 [GitHub92@gateway/service/github.com/x-esofvkqabqddsbmw] has joined #joinmarket     
12:11 < GitHub92> [joinmarket-clientserver] fivepiece closed pull request #282: pin coverage+pytest-cov versions, upgrade core to 0.17.1 on docker (p2ep...p2ep-tests) https://git.io/fhs0S
12:11 -!- GitHub92 [GitHub92@gateway/service/github.com/x-esofvkqabqddsbmw] has left #joinmarket []     
12:12 < waxwing> qubenix, it's an observation that's been made a couple of times .. that in certain cases you could break up change to match cj amount. there's a utxo fragmentation downside, i think that's the only real counterargument against doing it, but it's nontrivial (after all that's why we don't just do 1000 0.01 equal sized outputs)
12:13 < waxwing> current coinjoin impls (joinmarket, wasabi) are going with the "payment and change output" for all parties, but people have often tried to analyze mathematically if some other splitting might be optional. problem is it's not trivial to optimize when you don't hvae a clear objective function.
12:14 < waxwing> coinjoins with sweeps are the best for this so you never have to worry about change
12:40 < nothingmuch> "might be optional" - can you elaborate? or did you mean optimal?
13:00 < waxwing> nothingmuch, sorry yes "might be optimal" indeed
13:08 -!- GitHub155 [GitHub155@gateway/service/github.com/x-qptkopahibofcbix] has joined #joinmarket     
13:08 < GitHub155> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fhs2K
13:08 < GitHub155> joinmarket-clientserver/master e0f8715 fivepiece: pin coverage+pytest-cov versions, upgrade core to 0.17.1 on docker
13:08 < GitHub155> joinmarket-clientserver/master bccbbbd AdamISZ: Merge #283: pin coverage+pytest-cov versions, upgrade core to 0.17.1 on docker...
13:08 -!- GitHub155 [GitHub155@gateway/service/github.com/x-qptkopahibofcbix] has left #joinmarket []     
13:08 -!- GitHub141 [GitHub141@gateway/service/github.com/x-dgegvatrxtsfauir] has joined #joinmarket     
13:08 < GitHub141> [joinmarket-clientserver] AdamISZ closed pull request #283: pin coverage+pytest-cov versions, upgrade core to 0.17.1 on docker (master...master-tests) https://git.io/fhsEi
13:08 -!- GitHub141 [GitHub141@gateway/service/github.com/x-dgegvatrxtsfauir] has left #joinmarket []     
13:25 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Remote host closed the connection]     
13:27 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
14:11 < waxwing> so bip21 doesn't make any sense for a command line payjoin, but i suppose (as istr you said belcher ) bech32 encoding of the request similar to bolt11 invoice does make sense.
14:29 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
15:26 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/]     
15:27 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
15:43 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Remote host closed the connection]     
15:45 -!- GitHub138 [GitHub138@gateway/service/github.com/x-mckjjhsxgywgwgaq] has joined #joinmarket     
15:45 < GitHub138> [joinmarket-clientserver] jameshilliard opened pull request #284: Default to python3 install (master...py3-default) https://git.io/fhsKQ
15:45 -!- GitHub138 [GitHub138@gateway/service/github.com/x-mckjjhsxgywgwgaq] has left #joinmarket []     
15:51 < waxwing> interesting, notice 106 in the cgan pit (minus about 5 non-bots), but my obwatcher only picks up 58 counterparties. my guess is that there's a timeout on reading the orderbook that's too low. don't really want to investigate right now, but maybe something to note.
15:52 < waxwing> ofc you also have both Taker (tumbler) bots but that'll never be more than a couple in current usage, and you can ofc have other ob-watcher bots. the question is whether some of them are "fake" and make no offers.
16:24 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
16:57 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
17:27 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]     
17:44 -!- AgoraRelay [~jmrelayfn@p5DE4AE9D.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
17:51 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket     
18:01 -!- AgoraRelay [~jmrelayfn@p5DE4AB67.dip0.t-ipconnect.de] has joined #joinmarket     
19:15 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has quit [Ping timeout: 245 seconds]     
19:20 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket