--- Day changed Thu Apr 26 2018
00:57 < belcher_> arubi: i thought of that, but realized the maker can add their own nonce too, sha256(utxo|takernonce|makernonce), then makernonce is revealed when opening the commitment
00:58 < belcher_> fundamentally podle commitments are useful because you can transfer them, and i believe with issue 693 we never need to do that
00:59 < belcher_> wait no that wont work, because then a multiple-maker-same-wallet attacker could just use difference nonces, doh
01:01 < belcher_> ok so what we need to do is commit to the utxo pubkey, sha256(utxo_pubkey|takernonce), since the pubkey isnt revealed until the utxo is spent
01:01 < belcher_> thats how podle works, it commits to the pubkey not the utxo itself, so an attacker cant iterate the entire utxo set because they dont know all pubkeys
01:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
01:48 -!- M1 [~Michail@michail.com] has quit [Ping timeout: 263 seconds]     
01:50 -!- M1 [~Michail@michail.com] has joined #joinmarket     
03:27 < waxwing> belcher_, curious about your 400MB. I see only 43 MB, and pretty sure that's most of my *-cs side logs.
03:28 < waxwing> maybe like 80MB overall, although i switched it off that was only a short while (like dec-jan).
03:28 < belcher> strange i guess
03:29 < belcher> its only like 3 days of blocks anyway, next time i restart ill just rm the entire directory
03:29 < waxwing> yeah nbd just curious
03:29 < belcher> in about a year and a half my hard drive will be full of blocks then ill have to enable pruning
03:29 < belcher> hopefully the rescan from X height works even if pruning is enabled as long as you have the blocks
03:29 < waxwing> yeah :) i have a new machine with 1TB SSD. not looking forward to transferring though :)
03:30 < belcher> i transferred the entire .bitcoin dir over usb2 onto a hard drive and it only took about 3 hours
03:31 < belcher> this was about 2 weeks ago
03:31 < waxwing> re: the above strand of discussion, yeah, podle helps by making it global (or transferrable), at first glance i'd have thought you'd still need that for the 693, but def needs thinking about.
03:31 < waxwing> hmm 3 hours. i can't remember, i did the same at some point, prob it was usb2 not 3, certainly took hours not sure how many.
03:32 < belcher> it was a situation where extrapolating works
03:32 < belcher> let it copy for 15 minutes, see how much has been copied, extrapolate until all 250gb+... turned out to be 3 hours and it did actually take that long
03:33 < belcher> for 693, i dont see how the commitments ever need to transferred... although it makes no difference except sha256 is a tiny bit smaller and faster than podle 
03:56 < waxwing> it's quite a bit smaller eh. even if you get a bit clever, i think you might struggle to get a podle proof less than 3 x the size of a sha2 digest
03:57 < waxwing> oh but, no that's wrong sorry wasn't comparing like with like
03:58 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 255 seconds]     
03:58 < waxwing> yeah the "claim" part is as you say very tiny difference. the "proof" part would depend on how the sha2 version worked. we were originally talking about merkle trees and various shenanigans. not much point just having commitments to single utxos is there?
03:59 < waxwing> hmm the whole thing is confusing me again
04:02 < belcher> no, no merkle trees here
04:02 < belcher> with sha256() the claim is the hash, the proof is the utxo_pubkey
04:03 < belcher> with podle the claim is the hash (same length i believe) and the proof is the utxo_pubkey plus 4 or 5 nonces
04:05 < belcher> having commitments to single utxos is needed to solve the 693 problem, then the taker can know that each maker has a unique wallet (so commitments from different makers must not have hashes in common)
04:07 < waxwing> podle can condense down to (s, e, P2) so ~ 3 (in code I've lazily added in at least one more field (P) but pretty sure not needed)
04:08 < waxwing> belcher, i don't get your point. what you're describing would require some commitment to all utxos in wallet? or not?
04:08 < belcher> yes     
04:09 < belcher> it would require a commitment to all utxos in the wallet
04:09 < waxwing> we had this concept of merkle trees so you just post one item as your commmitment and then use proof of non-inclusion (which we had various issues with). what's the alternative without merkle trees?
04:09 < belcher> merkle trees save bandwidth
04:09 < belcher> the alternative is to not use merkle trees but then bandwidth is higher
04:09 < belcher> bandwidth usage*
04:10 < waxwing> i see. interesting to cogitate on the tradeoffs.
04:11 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
04:12 < waxwing> so in the reveal step, the maker has to reveal all the utxos he committed to?
04:14 < belcher> no, he only reveals the utxos he wants to spend in that coinjoin
04:16 < waxwing> so probabilistic, ie. you may get caught if you happen to reveal the same ones in different bots?
04:17 < belcher> no     
04:17 < belcher> the taker can check that the utxo commitments dont overlap without the commitments being revealed
04:18 < waxwing> so are these utxo commitments hiding? i.e. are they using random nonces?
04:18 < belcher> yep, i imagined the taker says !orderbook <nonce> and each maker sends sha256(utxo_pubkey | nonce)
04:19 < waxwing> so but then you can't check overlap?
04:19 < belcher> you can
04:19 < waxwing> oh taker provided nonce, ok
04:19 < waxwing> i was just reading that version in the thread, there've been so many different versions
04:20 < belcher> yeah.. there was a lot of discussion
04:20 < waxwing> so back to your statement "the taker can check ... being revealed" above, which utxo commitments are being checked against, in that? i didn't quite grok your meaning there.
04:21 < belcher> the commitments are sha256(utxo_pubkey | nonce)
04:21 < waxwing> yes but i mean which utxos are you checking against? (checking the revelations against)
04:22 < belcher> when the maker sends which utxos they want to spend in the coinjoin, they have to open the commitments
04:22 < waxwing> oh i misread the sentence. i read "with" instead of "without", which is a very different meaning.
04:23 < belcher> ooh     
04:23 < belcher> ok     
04:23 < waxwing> but anyway i'm still not clear on what you're proposing. suppose you have commitments provided from maker to taker, sha2 and with a taker provided nonce. when you negotiate, you reveal, and taker can check it's part of the set committed to.
04:24 < belcher> yes     
04:24 < belcher> ?     
04:24 < waxwing> so how does it help with other makers?
04:25 < belcher> it solves the problem that different makers cant share utxos
04:25 < waxwing> is the taker using the same challenge nonce for each one?
04:25 < belcher> yes, the nonce is in !orderbook which all makers see
04:25 < belcher> the taker has commitments from all the makers, so it can check if theres any duplicate commitments
04:26 < waxwing> right. so every utxo has a unique commitment, but it's private between that taker and his makers. hmm.
04:27 < waxwing> hmm no hang on. if the nonce is public, a spy can churn through all utxos to get the actual utxo.
04:28 < waxwing> or well, more relevantly, the taker can do that and get all the maker's utxos.
04:28 < belcher> no, the thing being committed is the utxo_pubkey, not the utxo itself
04:28 < belcher> the utxo_pubkey is only known to the maker
04:28 < waxwing> ah, ok, that's a cool little detail.
04:28 < belcher> (assuming we're all using pay-to-pubkey-hash, which we are)
04:28 < belcher> it wouldnt work if we used pay-to-pubkey, or reused addresses
04:29 < waxwing> let's call it a token not a nonce, the cryptographers would get annoyed at us :)
04:30 < belcher> whats the difference? i thought "nonce" would work here
04:31 < belcher> or are nonces only numbers that you do arithmetic on, rather than just concatenate
04:31 < waxwing> well it means number used once. in most cases, that's a critical property of them (like ecdsa signatures for example)
04:32 < belcher> thats the case here isnt it? each taker uses a different nonce each time
04:33 < waxwing> well i was just thinking that it's in the !orderbook then it's gonna be used with all makers, for that particular tx right?
04:33 < waxwing> doesn't matter anyway
04:34 < belcher> oh i see yes, you're saying its used multiple times, once per utxo
04:34 < belcher> that is true
04:34 < belcher> used once per utxo, multiple times per orderbook request
06:01 -!- emzy_ is now known as Emzy     
06:03 -!- Emzy [~quassel@raspberry.emzy.de] has quit [Changing host]     
06:03 -!- Emzy [~quassel@unaffiliated/emzy] has joined #joinmarket     
06:21 < belcher> ill copypaste the above conversation to the github
06:22 < waxwing> belcher, oh, but i was barely thinking clearly through most of that .. :(
06:24 < belcher> this way you can read over it again to remind yourself?
06:24 < belcher> if some stuff confused you now, it can easily confuse other, or you later
07:05 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
07:08 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #joinmarket     
09:47 < arubi> at what point does a maker commit to all utxos (or pubkeys bearing utxos) in the wallet in this scheme?
09:49 < belcher> as a reply to the taker who says !orderbook <nonce>
09:49 < belcher> so before the taker even chooses which makers to coinjoin with
09:55 < arubi> I see, so later on when one of these utxos gets used as an input at a different cj, this same taker can know that it belonged to "this" maker right?
09:56 < arubi> not sure if it matters, we want to protect outputs, inputs don't really matter.  I'm trying to think what happens when a cjhunter can successfully map all inputs but one to makers
09:58 < belcher> no because the taker wont know the exact utxos, they only have commitments to those utxos
09:58 < belcher> the commitments are only opened if a utxo is used in the taker's coinjoin
09:59 < arubi> yes, but it's all hashed with their nonce, and even if it's not opened this time, it'll open sometime later on at a different cj
09:59 < arubi> so some future cj when the pubkeys are opened, the past taker can try sha256(pubkey|past-nonce) and see if it fits a commitment they got back then
10:00 < arubi> I think that if they successfully map all inputs but one to makers, they can at least pinpoint the cj's taker's change
10:12 < belcher> thats true
10:14 < belcher> would that attack also work when using podle commitments? i think it wouldnt because revealing the utxo pubkey isnt enough to calculate the commitment
10:14 < belcher> hmm, thats because the podle commitment requires knowledge of the privkey
10:14 < belcher> so you could keep using sha256 with sha256(pubkey|takernonce|proof-of-knowledge-of-privkey)
10:15 < belcher> proof-of-knowledge-of-privkey is just a signature of course
10:15 < belcher> though at this point the differences between using sha256() and podle are even less, now they both also require ec operations for every utxo
10:17 < arubi> does it matter if you add more things to the hash?  eventually what's missing is the maker's pubkey which ends up being revealed
10:18 < belcher> what do you mean? so sha256(proof-of-knowledge-of-privkey|takernonce) would also work?
10:18 < belcher> and then reveal the utxo pubkey alongside, it doesnt have to be inside the sha256
10:20 < arubi> this proof of knowledge, what is it exactly?
10:21 < arubi> knowledge of the privkey*
10:22 < arubi> I'm confused because just a simple signature would reveal the pubkey by simple pubkey recovery
10:22 < arubi> well, for it to be proof of knowledge of the privkey the thing that's signed has to be some form of the pubkey
10:25 < belcher> proof is knowledge is just a signature
10:25 < belcher> literally just that, signature where the message is some fixed message
10:25 < belcher> sign("hello world")
10:27 < arubi> well it /has/ to sign some form of the pubkey for it to be a proof of knowledge of the privkey
10:28 < belcher> the pubkey doesnt have to be in the message
10:28 < belcher> the revealing can include the pubkey, the pubkey can be hashed to get the pubkeyhash and prove its associated with that utxo, then use the pubkey and signature to prove the privkey was known
10:30 < belcher> or we could just use podle, as mentioned before the scheme are very similar now, and podle might be good because all that code can be reused
10:31 < belcher> podle is almost like doing a signature but on another curve point instead of G
10:43 < arubi> I forget how podle commitments work now, assuming a maker gives you podles for all their pubkeys, what information are you missing to be able to also open them all?
10:44 < belcher> there would still be a taker nonce btw
10:45 < belcher> you need some numbers/points
10:45 < belcher> err, just finding it, but its like 4 numbers
10:46 < arubi> so say I have an unopened (simply unused in my current cj) podle commitment using P2, can I learn anything when some eventual P1 gets used in a cj?
10:46 < belcher> i think no
10:47 < arubi> note that I also end up learning the actual utxo
10:47 < belcher> utxo and its pubkey
10:47 < arubi> yes, what am I missing for making the mapping then?
10:51 < belcher> basically podle is very similar to that sha256() scheme we came up with above
10:51 < belcher> very very similar, only it uses another base point J instead of G
10:52 < belcher> and it makes a schnorr style signature instead of ecdsa
10:57 < arubi> right, so seems like it would be just the same in this case when commitments are given for all maker's points.  what I have from a taker is a schnorr sig and P2, and what I'm missing are P1 and utxo.  both can be learned later on by cjhunting
11:01 < belcher> no because you need some other numbers
11:01 < belcher> the schnorr signature numbers, e and s i think
11:02 < belcher> maybe waxwing will remember/know exactly
11:02 < belcher> otherwise that could be done for taker's podle commitments today, the point of podle is the commitments can be shared and the utxo will never be known unless revealed
11:05 < arubi> but I do have e,s no?  the podle itself is given to me with those.  it's just unopened for P1 unless I get the utxo.  currently only some of the maker's podles are given to me, with this new method, all of them are
11:06 < arubi> but yea, if I get it right then even now if I have unused, closed podles, I can map some makers in unrelated cj's once they happen
11:06 < belcher> currently only the taker's podles are given
11:06 < waxwing> arubi, you can't get P2 from P1 if you don't own it. although i may not be understanding what you're asking.
11:07 < arubi> waxwing, well specifically if I have an unopened podle given to me, then P1 and its utxo gets used on chain, can I map that podle to P1?
11:07 < waxwing> and the commitments are H(P2) btw. in case you weren't looking at it before, remember there's https://joinmarket.me/blog/blog/poodle/
11:07 < arubi> I wasn't and do need to re-read this :)
11:08 < waxwing> arubi, no an unopened commitment will not be correlatable to a utxo or pubkey
11:08 < arubi> ah, so maybe podle /is/ better in this method of giving podles for absolutely all pubkeys
11:08 < arubi> better than the sha256 method that is
11:08 < waxwing> that's the main thing you get over a hash(utxo or pubkey) but not what you get over hash(utxo|nonce) of course, the problem with the latter is it's not binding to *one* nonce so you can makelots
11:09 < waxwing> anyway the main chunk of that text is trying to tease out exactly that, i.e. what does this give you over using a hash commitment.
11:10 < arubi> I'll definitely reread this tonight
11:10 < belcher> funnily enough the sha256 method so far is very similar to the podle method, the hash used in the podle method is sha256
11:11 < arubi> but of P2, which is pretty much ephemeral - per podle run if I get it right
11:12 < belcher> the commitment we'd share in the 693 problem would actually be hash(p2|nonce), because the taker needs to provide a nonce
11:13 < waxwing> P2 is just xJ, just think of it as the same pubkey as P but on a different base, J instead of G
11:14 < arubi> ah so it's not P2 that's different, but the signature in the podle?
11:15 < waxwing> right, podle has been referred to as dleq elsewhere, proof of discrete log equivalence, i.e. a single schnorr signature that just proves two points have the same discrete log
11:15 < waxwing> (wrt to 2 different bases of course)
11:16 < waxwing> if you took (P2, P, J and G) as implicit then it only consists of (s, e) like a typical schnorr signature
11:16 < arubi> right, understood.  so the nice thing here is that eventual use of P1 and its utxo doesn't map back to a past podle of a P2
11:16 < waxwing> (except that people usually use (s, R) but (s,e) works)
11:17 < waxwing> arubi, well but i think not really? depends what you mean perhaps. but in revealing the counterparty knows P, P2, s and e.
11:17 < waxwing> i think the revelation is almost always going to be P2, s, e here, because we used H(P2) as the commit, so you need to reveal P2
11:18 < arubi> yea, this relates to backlog ^, if the sha256 method is used, then unopened commitments are still useful for a cjhunter in looking at other cj's on chain and mapping the unopened commitments they received to pubkeys and utxos used in those cjs by makers
11:18 < waxwing> that's one of the negatives on podle, you have a group element and two scalars, which'd be bigger than usual hash commitment revelations (preimage value + nonce)
11:21 < arubi> the idea was, collect as many unopened commitments as possible, then just listen to cj's on chain.  once one happens, map these commitments to makers' inputs and by knowing the amounts you can know which of the change outputs belong to the taker.  seems that with podle commitments this isn't possible anymore
11:22 < belcher> it also isnt possible with the sha256(signature|nonce) method, although in the end thats very similar to podle
11:22 < waxwing> arubi, so this was referring to the setup: !orderbook nonce (from taker), then maker commitments: H(utxo pubkey | nonce) is that right?
11:22 < arubi> yes.  now I'm thinking about the signature|nonce hash instead
11:23 < waxwing> oh, wait, signature? i need to read backscroll :)
11:23 < arubi> it's a fix to the issue of pubkey|nonce :)
11:23 < belcher> its basically the same, podle uses a different base point and uses schnorr style signatures instead
11:24 < waxwing> interesting, i'll have to think about this one.
11:24 < belcher> after this discussion my view is that the podle method is the best thing to do
11:25 < arubi> so just so I'm clear, the taker only learns "signature" if the commitments was actually used, right?
11:26 < belcher> if the commitment was opened, yes
11:29 < arubi> alright, so now I'm backtracking, how can we assert that a maker both has to give a taker commitments for all their pubkeys, and can't add false commitments (without some opportunistic "open this one" from a maker)?
11:31 < waxwing> oh i just realised what i got wrong earlier. i was thinking it was ok to use a public nonce because the maker cycles to new *addresses* for each proposal ... but they don't cycle to new utxos for every proposal, duh. so yeah H(pubkey|"nonce") doesn't work.
11:33 < waxwing> arubi, heh this discussion reminds me of writing this: https://gist.github.com/AdamISZ/afc1ed3542d0aefaace718c029dc4a81 .. we really got into the weeds with this stuff at some point :)
11:34 < arubi> ah yes, I read this one a few days ago when I was running through all the links and references :)
11:34 < waxwing> oh. it's relevant perhaps because in the middle it says "The question becomes, is there a gain to be had from repeating or adding fake utxos to this partition/set, as it is published in the offers, in !hp2 values."
11:36 < waxwing> if we assume that there's a scheme where each maker/wallet has to commit upfront, i was trying to say that if his only goal is to make more money, he won't gain advantage with fakes. i can't even really remember what i was thinking though.
11:37 < arubi> right, they can't monetize fake txos\commitments, but can they learn anything by publishing them?  maybe just something like "this taker is interested in this amount at least"
11:38 < waxwing> right, snooping, or DOS, but snooping is perhaps the more interesting one to consider.
11:38 < waxwing> well hmm not sure about that .. doesn't seem at first glance like that's much of an issue
11:39 < arubi> yea and not one you could easily defend anyway without the maker having to provide some disclosing info about utxos they actually own
11:48 < arubi> so rephrasing the fantastic beast ( :) ) I was describing yesterday, a maker has to prove two things - 1. some pubkey they own is a "child" of some "parent", and 2. that parent is the root of of all pubkeys in their wallet.  obviously there isn't an algorithm to do this now, but what it does is disallows two makers running off of the same wallet, even when each maker only commits to one single pubkey and not all (which I'm not sure we 
11:48 < arubi> currently can assert that they would)
11:48 < arubi> the question now becomes, for (1), can this be a pubkey which is different from the one that's in the actual utxo?  for (2), can the parent be obfuscated per taker request while still maintaining the parent->child relationship?  and finally, when two takers offer two pubkeys from two obfuscated parents, when they're actually the same parent, can the taker somehow figure this out and either ban or better, punish the (now obviously) singular 
11:48 < arubi> maker running two bots off of the same wallet?
11:49 < arubi> if only andytoshi was around to slap me around for suggesting unachievable magic :P
11:52 < arubi> though again, using the signature|nonce, if the maker running two wallets actively partitions commitments to a taker in such a way that commitments don't repeat, it's a bit weaker than what I'm suggesting but still makes them behave as if they're running two different wallets.  something we can't achieve even with this method since a single "person" can just run two wallets proper
11:53 < arubi> the difference would be a maker providing "all" commitments to their pubkeys\utxos vs. just one
11:54 < belcher> if a maker partitions their wallet then they have two wallets
11:55 < arubi> yep, the end result is the same.  the difference is really just the amount of data
11:55 < arubi> the amount of data relayed to the taker that is
11:56 < belcher> yeah
11:56 < waxwing> arubi, re: the fantastic beast thing, i also find it really interesting to think about, but we fundamentally need a "set non-intersection proof" rather than a set membership proof
11:57 < waxwing> maybe you can make a ring signature such that if 2 people make ring signatures and any one entry overlaps, badness happens
11:57 < arubi> the non interaction is achieved by the root->child relationship, if you can prove two roots, you prove no interaction
11:57 < arubi> ah hmmm
11:57 < waxwing> interaction? or intersection
11:57 < arubi> intersection* yes
11:58 < waxwing> hmm yeah. maybe something. we're back to that earlier discussion about how bip32 style stuff can't do this but maybe some weird EC thing.
12:01 < waxwing> how about if your "tree" is just a line, a series of linear offset tweaks P, P+kG, P+k2G, ..
12:01 < waxwing> you can easily prove connection. ah but this is no good unless you fix everything upfront.
12:02 < waxwing> maybe your commitment is the merkle root of a tree of all the k_i s
12:03 < waxwing> merkle roots don't give the property i'm looking for there, of only revealing 1, oh well (not to mention all the other reasons it's crazy, just trying to get some idea to start with)
12:05 < waxwing> it'd be hard to get the crucial property "for any P that I present to you, I can present a compact proof that P \in W (wallet) (identified in advance), and that there is no way to grind it so that i can make another W' s.t. P \in W' "
12:05 < waxwing> i think hashing forwards does that, like in bip32 .. kinda?
12:09 < arubi> yea, if we use bip32 and you give me the parent chaincode, then you can only prove that child keys are in your wallet.  I'd still need to grind whatever path to make sure that none others are and there's no way to prove an absolute parent without giving away the seed
12:10 < waxwing> i wonder if the concept of "accumulator" is relevant.
12:12 < arubi> wish I knew more about accumulators to know :)
12:15 < waxwing> i just remember a paper that had some fancy-ish way of hashing stuff together so you could easily end up with set membership proofs. i guess i was vaguely thinking "you kind of need hashing for this to ensure someone can't grind out a new wallet for the same key"
12:15 < waxwing> but, obviously, just a vague thought
13:26 < waxwing> Section 5 of kanzure's linked (which i originally linked him, but lost :)) http://diyhpl.us/~bryan/papers2/security/cryptography/accumulators/Universal%20accumulators%20with%20efficient%20nonmembership%20proofs.pdf may be worth a read in this context.
13:26 < kanzure> i think that was from roasbeef originally
13:27 < waxwing> oh, ok. i remember raising it, but probably i just wasn't the first to do so :)
13:30 < waxwing> interestingly, it includes a zero knowledge range proof :)
13:33 < waxwing> they use RSA but note it carries over to other commitment schemes, including pedersen.
13:33 < waxwing> some of the steps (e.g. 2, 3) seem to be straightforwardly discrete log equivalence. step 6 is a range proof.
14:11 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: reboot .. brb]     
14:12 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
14:39 < luke-jr> is joinmarket dead? no commits since a year ago?
14:40 < luke-jr> belcher: 
15:33 < belcher> luke-jr no
15:33 < belcher> work has been done on joinmarket-clientserver
15:33 < belcher> which is a rewrite that we intend to move to /joinmarket but havent yet
15:33 < belcher> https://github.com/JoinMarket-Org/joinmarket-clientserver
15:34 < belcher> certainly not dead, i had like 40 coinjoins on my bot today (granted today seems to be unusually popular)
15:34 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://quanto.ga/]     
15:35 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
15:37 < luke-jr> belcher: any idea how I can see my balance and/or send it somewhere? joinmarket-qt.py doesn't seem to load it anymore :/
15:38 < belcher> is there an error message anywhere?
15:40 < belcher> if -qt.py doesnt work you could try with the cli wallet-tool.py
15:40 < luke-jr> no error that I can se
15:41 < belcher> what did you do from the start? i assume you had a mnemonic phrase that you wanted to recover from?
15:42 < luke-jr> wallet-tool says IOError: wallet file not found
15:42 < luke-jr> no, I have a wallet.json file
15:43 < belcher> you have to write wallet.json not wallets/wallet.json, thats a common thing that happens
16:13 < belcher> hopefully luke's silence means he found a solution
16:14 < belcher> for making -clientserver the main codebase, we just need to make sure "segwit = false" mode works
16:14 < belcher> then edit all the documentation to explain -clientserver and add a note that if people want to use the old pit they just set segwit = false
16:24 < belcher> waxwing did you finish with the bech32send branch on -clientserver? it might be worth deleting it to reduce clutter
16:50 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://quanto.ga/]     
16:52 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
17:37 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://quanto.ga/]     
17:39 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
17:45 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
18:40 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 240 seconds]     
18:49 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
19:46 < luke-jr> belcher_: it just hangs at 2018-04-26 22:44:53,157 [MainThread  ] [DEBUG]  downloading wallet history
20:09 -!- AgoraRelay [~jmrelayfn@p5DE4A328.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]     
20:25 -!- AgoraRelay [~jmrelayfn@p5DE4A4FB.dip0.t-ipconnect.de] has joined #joinmarket     
22:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Read error: Connection reset by peer]     
22:01 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
22:30 -!- Giszmo [~leo@pc-37-38-86-200.cm.vtr.net] has quit [Ping timeout: 256 seconds]     
23:03 -!- Giszmo [~leo@ip-44-226-107-190.nextelmovil.cl] has joined #joinmarket     
23:26 -!- Giszmo [~leo@ip-44-226-107-190.nextelmovil.cl] has quit [Read error: Connection reset by peer]     
23:42 -!- Giszmo [~leo@pc-37-38-86-200.cm.vtr.net] has joined #joinmarket