--- Day changed Tue Jan 01 2019
00:37 -!- raedah [~x@192.30.89.59] has joined #joinmarket     
01:52 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
04:11 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket     
05:04 < waxwing> undeath, let me know if you have further comments after that. i'm going to add one more trivial commit to allow mktx to create version 2 transactions, after that and a bit more testing i'll be looking to merge it.
05:22 < waxwing> on that topic, how would people feel about making an option for a user to create version JM coinjoins?
05:22 < waxwing> i can see the counterargument, but one could allow it if specifically set in the config (or cli), but leave the default at v1 as is
05:23 < belcher> what do you mean by version JM coinjoins?
05:24 < waxwing> sorry i missed '2'
05:24 < waxwing> and that wasn't clear, i meant bitcoin tx version 2
05:26 < belcher> iv forgotten what that means, is that bech32 addresses ?
05:26 < belcher> i.e. the recent PR
05:34 < waxwing> belcher, no i mean the version in a normal transaction serialization
05:34 < waxwing> it controls whether use can use CSV
05:34 < waxwing> not sure it has any other significance
05:34 < waxwing> but i think most wallets are using v2 nowadays.
05:45 < belcher> i suppose the taker chooses which version txes will be
05:46 < belcher> it might mark out transactions of people who havent updated? to avoid that it could be coded to only start making v2 txes after july 2019 by which time hopefully most people will have updated
05:48 < belcher> bip68 is the relevant one for version 2 and tx sequence numbers
05:49 < belcher> it might not be worth it because joinmarket doesnt use sequence numbers or OP_CSV... but i suppose you're thinking about it because of p2ep which would have to copy what the majority of txes in the wild do
05:49 < waxwing> belcher, yes that's the response i kind of anticipate. but my feeling is it's a bit like the bip69 argument.
05:49 < waxwing> well .. somewhat.
05:50 < belcher> i was hoping p2sh.info or a similar site would have a graph of transaction versions, but i cant seem to find it
05:50 < waxwing> does it matter that you're watermarking which *version* of Joinmarket you're using? i'd guess, not.
05:50 < waxwing> oh it doesn't? that's a shame. one of those guys has the data. i bet laurentmt does
05:51 < waxwing> it should be a completely backward compatible change in the sense that old makers will still handle an arbitrary version number.
05:52 < belcher> watermarking the joinmarket version shouldnt matter if most other joinmarket uses have also updated i think
05:52 < waxwing> yeah it's one of those classic ones, the first changer has the problem.
05:53 < waxwing> i won't try to add it for joinmarket yet. but it cropped up because i think it should be done for payjoin.
05:53 < waxwing> i think like core, electrum, probably most of the other actively maintained wallets use it.
05:53 < waxwing> greenaddress must do right.
06:06 < belcher> it certainly makes sense for payjoin
06:15 < undeath>  waxwing | does it matter that you're watermarking which *version* of Joinmarket you're using?
06:16 < undeath> yes, because it makes it easier to identify transaction created by a certain taker
06:19 < waxwing> undeath, yes i realised that was just wrong after writing it; hence the later sentences, i agree let's not do it now.
06:26 < waxwing> one other detail cropped up, i realised verify_tx_input is pretty badly misnamed, since it only checks that a signature over a tx input verifies; it doesn't actually check the input is valid (Script is not parsed). not relevant to us now but poss. in future if we want to start using more exotic tx types.
08:42 < qubenix> does anyone have a method of giving access to the funds in your jm wallet to non technical people in your absence? i saw the thread on reddit about recovering jm funds in other wallets, and it got me thinking about this. it seems like a wallet where the non tech person could just import the seed would be best, but when i tried this with samurai only addresses from mixdepth 1 showed up and one of the 
08:42 < qubenix> addresses showed no funds even though there were funds. i haven't tested a trezor yet.
08:51 < waxwing> qubenix, a common problem will be when other wallets only support one bip32 account; joinmarket's "mixdepth" is just an account. you can see the paths on the wallet display output.
08:51 < waxwing> in electrum i tested this about 1 year ago, and it allowed you to specify the path and import, but again it was only one account at a time.
08:51 < waxwing> on trezor it showed all 5.
08:52 < waxwing> i think it also worked on some other lightning wallet (eclair? hmm that really doesn't sound right does it .. but something like that)
08:52 < waxwing> there are others it def won't work on like greenaddress/bits which has its own special wallet. i *think* ledger claimed to be bip49 so maybe there.
08:53 < waxwing> you're basically just looking for bip49 but with that large caveat that often they don't support multiple accounts. annoyingly electrum's original design had multiple accounts but they deleted/removed that code.
08:53 < qubenix> seems like trezor will be the way to go for balance of ease and security. ive got one floating around here somewhere that ill dig out and test.
08:54 < waxwing> yes. it's at least likely that they are still fully supporting bip49; they were maybe the main authors of it.
08:54 < qubenix> thanks for your help. happy new year. :)
08:55 < waxwing> you too :)
08:55 < waxwing> if you find out anything different from above let us know, it'd be interesting
08:57 < qubenix> for sure
09:17 < undeath> qubenix: non-technical people should be able to import the xpriv key
09:18 < undeath> you get one for each mixdepth and internal/external branch
09:25 < qubenix> undeath: how can i get jm to print the xprivs?
09:25 < waxwing> undeath, when it comes to electrum, specifically, it allows you to specify the account in the m/... notation
09:25 < waxwing> but for other wallets, i'm not sure ... i think there might be an assumption of account 0 and you can only go via the seed? but that's actually an interesting point.
09:26 < waxwing> it could be another avenue with some wallets. i'm personally quite against making access to secret key material easier.
09:30 -!- d3spwn [53a19dc8@gateway/web/freenode/ip.83.161.157.200] has joined #joinmarket     
09:38 < undeath> qubenix: wallet-tool display with -P
09:38 < qubenix> ah, thanks
09:39 < qubenix> anyone else notice that wallet-tool is way slower now? is it coincurve?
09:40 < undeath> on display it's probably because of #246
09:40 < undeath> if you're running master
09:41 < undeath> if anything else is slower I have no idea
09:43 < qubenix> i don't think it's that, my latest commit is on dec. 27th and #249 was merged on the 29th. i'm on commit 9466b685c3e8acce804ee6daeb8c6129db5c3280
09:44 < undeath> in that case, no idea
11:24 < waxwing> qubenix, hmm that's a hard one, one thing that affects it is if you have a large transaction history in your Core wallet.dat
11:28 < qubenix> the wallet.dat has about a years worth of jm activity and nothing else. would that possibly create a large enough tx hist?
11:32 < arubi> hopefully the tx data source isn't set to something that isn't your bitcoin node?
11:33 < qubenix> arubi: you mean in jm.cfg? that's impossible, my jm vm has only access to my bitcoind vm. no internet.
11:34 < arubi> I see
12:16 < waxwing> qubenix, it makes a difference over time. you get duplicate records per transaction. by experience, if you have thousands of transactions it makes quite a meaningful time difference.
12:18 < qubenix> yeah, must have something to do with the wallet. i just loaded a new wallet, and a fresh jm wallet syncs just as quick as im used to.\
12:29 < qubenix> can the jm wallet.dat in bitcoind be created with disable_private_keys?
12:38 < waxwing> oh that's a good question, i think it should, but arguably it's not too critical as we only use watch only so wallet.dat never knows them
12:39 < waxwing> don't know if anyone's tried it, i presume it works but can't guarantee
12:39 < waxwing> undeath, err little py3 mistake i just noticed ... https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/268/files#r244647053
12:40 < waxwing> i guess ping Lightsword on that too, actually
12:41 < qubenix> wallet creation and initial display work normal with disable_private_keys wallet. haven't tested anything else.
13:33 -!- asymptotically [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]     
15:27 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
17:50 -!- AgoraRelay [~jmrelayfn@p5DE4AC24.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]     
18:04 -!- AgoraRelay [~jmrelayfn@p5DE4A98A.dip0.t-ipconnect.de] has joined #joinmarket     
18:32 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket     
18:55 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving]     
19:05 -!- grubles [~grubles@unaffiliated/grubles] has joined #joinmarket     
21:58 -!- d3spwn [53a19dc8@gateway/web/freenode/ip.83.161.157.200] has quit [Quit: Page closed]