--- Day changed Wed Jan 16 2019
02:26 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
03:03 < d3spwn> finally finished migrating my node to linux :)
04:42 < waxwing> belcher, oh i'm dumb, 5 *rounds*. yeah i couldn't understand that at all, must have been some confusion.
04:43 < waxwing> i tried to find where it was discussed just now, but i can't recall if this was ever discussed anywhere in public, i wish i'd directed a Q at narayanan about the 5 number.
04:43 < waxwing> all i could find on twitter was this, which wasn't a particularly helpful response on my part: https://twitter.com/waxwing__/status/898904612731854848
05:42 < belcher> waxwing i think im going to post your talk at the milan meetup from september 2017 on reddit, and it will be stickied soon after
05:43 < waxwing> ok, great, thanks. hope it's visible/audible enough; from what i remember it's not too bad.
05:44 < waxwing> btw another appeal for anyone who wants to try out payjoin with me as an experiment. i'm basically done coding, writing a usage guide now. also if anyone feels inclined to do any code review that'd be appreciated.
05:44 < waxwing> this is the PR https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/279
05:59 < waxwing> some comments that might help potential reviewers: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/279#issuecomment-454787945
06:21 < qubenix>  what does "Verification failed for nick: xxx" mean? I haven't seen a tx since my maker switched to running master, and when trying to test a sendpayment the taker gets that verification failed message about my maker.
06:24 < waxwing> hmm. i'm running master and seen a few today.
06:25 < waxwing> there is actually i suspect a corner case causing that 'verification failed for nick:..'. theoretically it can be someone just using borked code that makes an invalid nick/pubkey pair, but i have a suspicion it's a bug that is just very rare to trigger.
06:25 < waxwing> do you have any log that you can share? i mean, it wouldn't be *your* nick anyway, but it might help us to figure something out.
06:27 < qubenix> there's not much in the log except that verification failed message. the makers log on joinmarketd looks completely normal (aside from not being able to connect to agora irc) and the taker log only mentions that verification failed message.
06:28 < waxwing> i see, interesting. so you're testing a payment with yourself; i guess you're using -P to do it right?
06:28 < qubenix> yep     
06:28 < waxwing> and the nick for which verification failed, is the nick of your maker?
06:28 < qubenix> yes     
06:29 < waxwing> ok so without revealing any private info, there's one more bit of information that might pin it down:
06:29 < waxwing> just restart the maker and try again.
06:29 < waxwing> i'm betting it works fine then.
06:29 < waxwing> and if so, it seems you have triggered this corner-case bug i was worried about, although i'm still not 100% sure it exists.
06:30 < waxwing> if that is as we expect, could you open an issue and describe as much as possible without revealing info. i think i'll be able to figure it out, although it'll take me a while (busy).
06:30 < qubenix> still verification failed after this restart, which is the 5th or so restart. sure, i'll report it.
06:31 < waxwing> oh, hmm. something else going on. well i'm fairly lost in that case.
06:31 < waxwing> especially since as i say i'm running master myself.
06:31 < waxwing> i don't suppose you know the commit you switched from (i.e. when it started happening)?
06:32 < waxwing> damn that is weird ... i don't think we ever had any problems with the nick verification when we switched from secp256k1-py to coincurve (nor should we, of course) ... i can't really easily imagine what causes this.
06:32 < qubenix> i'm pretty sure it was the irc fix commit
06:33 < waxwing> the new server one? or you prob mean the one that times out on failure
06:33 < waxwing> hmm     
06:33 < qubenix> yeah, the one that fixes a down irc
06:33 < waxwing> it may be that in some weird way it interacts badly with a separately-run daemon. huh.
06:34 < qubenix> i've got another bot on commit c08adf9848be636425b12081a4a16cc2ae2b8b0c without this problem.
06:36 < waxwing> ok; it sounds quite easy to trigger, if you have a chance, maybe check the commit before the IRC one is OK.
06:37 < qubenix> yeah, i will when i have a chance and report back.
06:38 < qubenix> well this is weird, i just switched that taker to master and now im getting verification failed for all nicks.
06:39 < waxwing> not that you should necessarily do this right now, but consider doing a fresh ./install.sh at some point. i'm having a hard time believing this is code, rather than dependency related.
06:39 < waxwing> although tbh i have no idea :)
06:40 < waxwing> just double checked, been running in-sync master last day or so at least (i'm usually on master), not seeing any issues but i will do a couple more checks.
06:41 < qubenix> ok, i'll try running install and see what happens. i never run that script typically, just `setupall.py --all`.
06:43 < waxwing> yeah looks like 4 or 5 joins since last night.
06:43 < waxwing> oh one thing qubenix can you check that client side, you're seeing this: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/c9622395c4c1ec385d7bfed1f3d8a575a4cb0ba6/jmclient/jmclient/client_protocol.py#L113
06:43 < waxwing> that debug message should be the reason, but it could also be the hash check one a few lines down
06:46 < waxwing> just a random thought, but i wonder if running daemon and client on different versions of python, or different code commits, or slightly different dependency versions, could cause strange behaviour like this
06:46 < waxwing> since everyone else just runs it all in one they don't have to think about it.
06:57 < qubenix> most everything should be the same between the vms that run the daemon and the wallet because they both have the same template. only thing that is changes is the home dir.
07:02 < waxwing> ok good. can't be that then.
07:05 < belcher> https://www.reddit.com/r/Bitcoin/comments/agly1o/onchain_contracts_adam_gibson_talks_about/
07:26 < waxwing> belcher, cheers
07:51 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]     
08:19 -!- GitHub56 [GitHub56@gateway/service/github.com/x-qwlnhvtcpojyazec] has joined #joinmarket     
08:19 < GitHub56> [joinmarket-clientserver] AdamISZ pushed 1 new commit to master: https://git.io/fhlsX
08:19 < GitHub56> joinmarket-clientserver/master dbac8ed AdamISZ: remove electrum references and add multiwallet ref to USAGE.md
08:19 -!- GitHub56 [GitHub56@gateway/service/github.com/x-qwlnhvtcpojyazec] has left #joinmarket []     
08:25 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
08:25 < waxwing> belcher, thanks for the review of that commit, btw i just pushed a payjoin usage guide md file, maybe have a quick read through it at some point and see if anything stands out as not making sense. cheers.
08:36 < belcher> iv read it waxwing it looks pretty understandable to me
08:39 < waxwing> thanks. it just occurred to me that i really ought to add a small section about withdrawing with sendpayment -N0 for those who, like it says at the start, are only reading that and are not using normal Joinmarket.
09:39 -!- Sonnenmann [~PaddyF@p5B0B7317.dip0.t-ipconnect.de] has joined #joinmarket     
10:02 -!- v_unimportant_pe [~user@45.74.60.133] has quit [Remote host closed the connection]     
10:02 -!- v_unimportant_pe [~user@45.74.60.133] has joined #joinmarket     
11:05 -!- Sonnenmann [~PaddyF@p5B0B7317.dip0.t-ipconnect.de] has quit [Quit: bbl]     
11:21 < qubenix> well i finally got everything to work right (relocation, systemd) in my setup by specifying python3.5 everywhere instead of just python3. didn't need to run the install script. after all that effort and i don't even get to see the colors now in journalctl.
11:24 < waxwing> qubenix, wow. so it was a delta between py3.5 and another version that caused it? which one, py3.4?
11:24 < waxwing> that's ... slightly disturbing. also i didn't get the comment about colors, are you talking about the new logging in JM, or..?
11:25 < waxwing> has anyone here done any testing on py3.4? i wonder if we actually have a requirement of 3.5 and above and should document it? i have a vague memory that *maybe* there is some issue like that?
11:26 < qubenix> no idea on the python version stuff, i didn't really dig deep. just kept trying different install methods until one clicked. yeah, the log colors dont show up in journalctl from joinmarketd. im going to see if it will work if i `tee` the log to a file and tail that.
11:30 < qubenix> huh, in the tee'd file the colored text doesn't even show up.
11:34 < waxwing> qubenix, ah: chromalog deliberately doesn't attempt to color file streams
11:35 < waxwing> coloring is just for the terminal, so i guess if you pipe it here and there it will be removed. or something.
11:35 < qubenix> yep. thx for your help today.
11:36 < waxwing> yw, it's useful having someone try things out and actually report back! like this py version thing should def be checked at some point so that at least we know.
13:23 -!- GitHub128 [GitHub128@gateway/service/github.com/x-agvzkxpducclaweq] has joined #joinmarket     
13:23 < GitHub128> [joinmarket-clientserver] kristapsk opened pull request #300: Add hostid to "On disconnect fired, nicks_seen is now" log message (master...on-disconnect-fired) https://git.io/fhlMI
13:23 -!- GitHub128 [GitHub128@gateway/service/github.com/x-agvzkxpducclaweq] has left #joinmarket []     
13:30 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
13:54 -!- emilr [~emilr@unaffiliated/goregrind] has quit [Ping timeout: 244 seconds]     
13:54 -!- emilr [~emilr@unaffiliated/goregrind] has joined #joinmarket     
14:34 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
15:37 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
16:36 < belcher> waxwing you remember the idea that joinmarket with off-chain fees would be a good thing? i did some thinking and realized the best off-chain tech for this is chaumian ecash servers, they could have a contract coded in them where the money only goes to the makers if the coinjoin tx gets confirmed
16:37 < belcher> takers pay makers in ecash tokens, the chaumian server(s) would have to be run by someone and would be part of the joinmarket infrastructure like the irc networks
16:39 < belcher> each of the taker and makers would have the pay the same amount of on-chain miner fees for privacy, but the taker could reimburse the makers off-chain if like today the taker pays most of the miner fees
16:41 < nothingmuch> belcher: have you seen my preferred value series idea?
16:41 < belcher> nope
16:41 < nothingmuch> i basically reached the same conclusion but from working up from zerolink
16:41 < nothingmuch> https://gist.github.com/nothingmuch/544cdd47dd18ef8fe923b54e0d5ee141
16:42 < belcher> from my memory zerolink doesnt have coinjoin peers paying each other for liquidity?
16:42 < nothingmuch> currently stuck on a related rabbit hole, which is coming up with improved on chain privacy metrics
16:42 < nothingmuch> yes, which i believe is a flaw
16:42 < belcher> oh iv read this (but skim-read so forgot)
16:42 < nothingmuch> note it's been updated several times
16:42 < belcher> oh ok
16:43 < nothingmuch> tl;dr - each coinjoin round has e-cash minted for input registration, which participants then spend to create outputs
16:43 < nothingmuch> already mixed coins can be given a preferrential rate by the server
16:43 < nothingmuch> after all e-cash for a round is spent normal coinjoin signing commences
16:44 < belcher> i think thats slightly different to what i was talking about, which is that coinjoins happen in joinmarket as normal (so taker knows all the links) but the coinjoin fees are paid off-chain instead of on-chain within the coinjoin
16:44 < nothingmuch> is the goal to obscure who is maker and who is taker?
16:45 < belcher> to obscure that from passive observers of the blockchain, yes
16:45 < nothingmuch> in my proposal the goal was to make it possible to unlink the fee payment from the mixing, so similar goal
16:45 < belcher> it would mean that a user could do a single JM coinjoin and have pretty good privacy (right now a single JM coinjoins isnt very useful as the inputs can be easily split into taker and maker inputs)
16:46 < belcher> i see, yes cool
16:47 < belcher> i realize now the "only transfer ecash if txid gets confirmed" can be totally separate from the ecash server itself
16:47 < belcher> the first part can be some semitrusted oracle that sends or doesnt send decryption keys (but we have to make sure its not colluding with makers somehow... but even if it is no great loss)
16:48 < belcher> its probably simpler to have the two roles combined i guess
16:50 < belcher> actually they have to be combined otherwise you get a double spending problem
16:50 < nothingmuch> i think if the taker is the final signer, and uses pay to contract sig, then it could trustlessly pay the makers over lightning
16:50 < belcher> the maker must only get paid if the tx confirms, is that compatible?
16:50 < nothingmuch> no     
16:51 < nothingmuch> in this case if the tx is bcast they would be able to obtain payment preimage (and i think i'm confusing pay to contract with the other sig tweaking trick)
16:52 < nothingmuch> though the incentive for them to flood the mempool is arguably small if the amounts are small
16:52 < belcher> the fees will be coinjoin fee + miner fee, which might be significant
16:53 < belcher> the worries are that the server(s) are trusted (but the yieldgens can be coded to periodically withdraw funds) and that its all a bit of an effort to code
16:54 < nothingmuch> in the infrastructure e-cash model case?
16:54 < belcher> yes     
16:56 < nothingmuch> i think the preferred value series idea might still work even for normal coinjoin
16:56 < nothingmuch> basically if taker & maker all have the same sized inputs & outputs for the mix denomination
16:56 < nothingmuch> and smaller denominations paid by the taker only (as separate coins) cover the mining & mixing fees
16:57 < belcher> what do you mean by normal coinjoin
16:59 < nothingmuch> basically same logic as the "roundedness" discussion of a few days ago - such fixed denominations are very round and if everyone uses the same value series, would be largely matched for all
16:59 -!- adlai [~adlai@unaffiliated/adlai] has quit [Read error: Connection reset by peer]     
16:59 -!- adlai [~adlai@unaffiliated/adlai] has joined #joinmarket     
16:59 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 245 seconds]     
16:59 < nothingmuch> no protocol or tx format changes from current jm operation, it's just that the coin selection changes
17:00 < belcher> i think i missed that discussion on roundness
17:00 < nothingmuch> ah i thought you introduced that term
17:00 < belcher> what was the discussion on roundedness about?
17:01 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
17:01 < belcher> is that about round numbered output values? like 1.0 btc or $10 in bitcoin?
17:03 < nothingmuch> waxwing's p2ep example with the 0.6 amount, and whether or not such amounts are a robust heuristic, entropy of amount values
17:03 < nothingmuch> but in this context, basically imagine that you have e.g. 0.321, you could make a first tx as taker to split up into e.g. 0.2, 0.1, and 0.02, assuming 0.001 covers the mixing & mining fees exactly
17:03 < nothingmuch> at that point you have values which are more readily mixable, if everyone uses the same value series
17:03 < nothingmuch> spending small denominations on fees entirely and keeping the input/output sizes identical for the larger values would mean that for the bulk of the tx, there's no clear way to identify which input belongs to the taker and which to the makers
17:04 < nothingmuch> yep, only in this case coin selection & output creation tries to optimize to only make values corresponding to a preferred value series, such as powers of 2, or 1-2-5 in decimal
17:04 < nothingmuch> it results in more outputs, but i think that amortizes with change outputs and the ability to make change-less payments
17:04 < belcher> right i see, so thats similar to how money works in physical banknotes and coins where you have standard denomination sizes
17:04 < nothingmuch> exactly
17:05 < belcher> you should do some maths on the last point to see whether it really does amortize the cost, my intution is that it doesnt
17:05 < belcher> because a change output is one output while all these denominations would result in many outputs
17:05 < nothingmuch> yes, that is an empirically testable claim
17:06 < nothingmuch> with 1-2-5, up to 3 outputs per decimal digit (8) but normally 2 or 1
17:06 < nothingmuch> with powers of 2, it's popcount of value
17:06 < nothingmuch> consolidation and coin selection is where i think that cost is recouped though
17:07 < nothingmuch> anyway, i will study that more rigorously instead of speculating, but it'll take me a while, currently i'm more concerned with the on chain anonymity properties of this
17:08 < belcher> yes     
17:09 < belcher> well back to the joinmarket-with-off-chain-fees, it will probably always have a place in situations where users want to make a fast on-chain transactions.. maybe if they're selling bitcoin to someone who doesnt own any yet
17:09 < belcher> the example was given if you do that today with a sendpayment then the receiver can see which inputs are yours and therefore get a lower bound of your total wealth
17:10 < nothingmuch> fwiw in that regard the main motivation for using such values is to faciliate the creation of switching network type mixes
17:12 < nothingmuch> wouldn't that be solvable by coin selection too?
17:13 < belcher> from what i see the only way to solve it with coin selection is to introduce this constraint of standardized denominations as in your proposal
17:13 < nothingmuch> e.g. if you provide multiple inputs into the coinjoin, can't the lower bound be brought down arbitrarily close to the sent amount?
17:14 < nothingmuch> if you include additional inputs spoofing makers?
17:15 < belcher> because joinmarket fees are on-chain then by examining a JM coinjoin you can usually see which inputs are takers and which are makers
17:16 < nothingmuch> i mean specifically using payjoin like logic to obscure that payment
17:16 -!- AgoraRelay [~jmrelayfn@p5DE4AD62.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
17:18 < belcher> how does payjoin solve this problem in joinmarket?
17:18 < nothingmuch> if it's obvious which input paid the fee, but that input is small, and that also includes the taker "paying" its own larger input for the actual payment mix by constructing two change addresses, then it's not clear which large input belongs to the taker
17:19 < nothingmuch> so the lower bound on the taker becomes the maker input closest to the sent amount
17:20 < nothingmuch> note not payjoin, just p2ep like input/output assignments
17:21 < nothingmuch> using fixed denominations would make that more likely to be possible, but it's not actually required for masking the fees
17:23 < belcher> i think any solution involving fixed denominations will use too much block space
17:23 < belcher> for example, if a user wants to pay $10 in bitcoin, they pay 0.00277858 btc, which would need many different denominations there
17:24 < nothingmuch> forget fixed denominations, we can get back to that after i've studied that
17:24 < belcher> we can work out how much, suppose we round it to 0.002779, that would need a 0.002 + 0.005 + 0.002 + 0.0005 + 0.0002 + 0.00005 + 0.00002 + 0.00002
17:25 < belcher> so thats eight outputs
17:25 < belcher> theres no change address so its only 7x more block space
17:26 < belcher> another issue is it damages divisibility, which is an important property of money just like fungibility (a big reason we dont use cows as money is you cant chop off a cow's head and pay with it because its value changes)
17:26 < belcher> imagine you're an entrepreneur and you make your business 5% more efficient so you can lower your prices by 5%, if you use fixed denominations then you get a totally different miner fee
17:26 < nothingmuch> how does it damage divisibility? it's just a bias to dividing in a certain way
17:26 < nothingmuch> ah, i see
17:27 < nothingmuch> well, i can put the time into looking at existing on chain data, consolidation txs, and also look at batching
17:27 < nothingmuch> but i'm far from that point, i think it's bet put off
17:27 < nothingmuch> best*
17:27 < nothingmuch> even without them, the same idea of the taker providing 2 inputs, one that mimics a maker, and another which covers all fees, can still be done
17:28 < belcher> consolidation only works because demand for block space changes (demand is less on a sunday night) but it doesnt change the total amount of block space used
17:28 < belcher> bitcoin is scalable in a very important way: a single UTXO can hold any amount of bitcoin value in it with O(1) scaling, meaning anything from 1 satoshi to 21 million bitcoins can be held with the same amount of block space, and this is one reason why layering and LN work for scalability... using fixed denominations damages this property so IMO its a good clue that the idea wont work
17:29 < nothingmuch> the number of outputs scales with the number of significant digits in the representation, not the magnitude of the amount
17:29 < nothingmuch> so i'm not convinced that it's not workable (e.g. use arbitrary amounts for small values, or some other middle ground)
17:30 < nothingmuch> but either way cases for and against are better made using real data and real cost estimations
17:30 < belcher> this is just my intuition, yes someone needs to do the maths
17:31 < nothingmuch> i promise i'll spend time on it, it'll just take me a while
17:31 < belcher> the maths has to work when miner fees are 1000 sat/b like they were in late-2017 too, so each additional output costs an extra $5 or so
17:31 < nothingmuch> in the case of using arbitrary amounts, the cost is at least 1 more change output, and possibly one additional input if the taker doesn't already include >= 2 inputs
17:34 -!- AgoraRelay [~jmrelayfn@p5DE4AE81.dip0.t-ipconnect.de] has joined #joinmarket     
17:38 < nothingmuch> e.g. suppose i have 1.0, and 0.1, and i want to sendpayment 0.2, i can find one or more makers with ~0.2, and input my 1.0, taking back 0.8 + maker fee as change, and deduct the real maker fees as well as my spoofed one & miner fees from the 0.1 value's change
18:07 < belcher> waxwing iv done a short writeup of this idea, hopefully its readable https://gist.github.com/chris-belcher/c8219fe6283b8f97116aeccaf1190c07
18:18 < nothingmuch> what mechanism did you have in mind for the refund?
18:19 < nothingmuch> esp. re ability of the ecash server to identify taker vs. makers?
18:43 -!- nothingmuch [~user@213.152.161.211] has quit [Killed (tepper.freenode.net (Nickname regained by services))]     
18:43 -!- nothingmuch [~user@213.152.161.211] has joined #joinmarket     
19:29 -!- raedah [~x@184.75.223.219] has quit [Quit: WeeChat 2.3]     
21:02 -!- raedah [~x@184.75.223.219] has joined #joinmarket     
23:39 < d3spwn> qubenix: do you have systemd run yield-generator?