--- Day changed Fri Apr 14 2017
00:30 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has joined #joinmarket     
03:01 -!- MaxSan [~one@185.156.175.59] has quit [Ping timeout: 252 seconds]     
03:35 -!- MaxSan [~one@185.156.175.59] has joined #joinmarket     
04:06 -!- MaxSan [~one@185.156.175.59] has quit [Ping timeout: 252 seconds]     
04:31 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket     
05:04 -!- loddar [6c3daa9b@gateway/web/freenode/ip.108.61.170.155] has joined #joinmarket     
05:05 < loddar> hello
05:05 < loddar> I have a small issue with joinmarket and hope somebody here can help me :)
05:06 -!- loddar_ [6c3daa9b@gateway/web/freenode/ip.108.61.170.155] has joined #joinmarket     
05:07 < loddar_> test
05:07 < loddar_> i sent btc to the 6 adresses in level 0
05:07 < loddar_> small issue with jm
05:10 -!- loddar [6c3daa9b@gateway/web/freenode/ip.108.61.170.155] has quit [Ping timeout: 260 seconds]     
05:10 -!- loddar [6c3daa9b@gateway/web/freenode/ip.108.61.170.155] has joined #joinmarket     
05:10 < loddar> sorry I have a bad connection
05:12 -!- loddar_ [6c3daa9b@gateway/web/freenode/ip.108.61.170.155] has quit [Ping timeout: 260 seconds]     
05:13 < waxwing> don't ask to ask, just ask
05:15 < loddar> test
05:15 < loddar> okay ;)
05:15 < loddar> I sent btc to the first 5-6 addresses in JM
05:16 < loddar> only to notice later on that blockr.io is not syncing to the network
05:16 < loddar> okay I thought they will fix it within a day or two surely
05:16 < waxwing> loddar: what OS?
05:16 < loddar> did not happen yet
05:16 < loddar> ubuntu
05:16 < waxwing> ok. so blockr.io is not connecting, or just out of sync?
05:16 < loddar> out of sync
05:17 < loddar> since 100hrs
05:17 < waxwing> wouldn't surprise me, they seem to have been getting worse.
05:17 < loddar> yes     
05:17 < loddar> then I tried connecting it to a friends bitcoin node
05:17 < loddar> which apparently worked since it showed me the wallet overview blazing fast
05:17 < waxwing> i'm afraid you migh tneed to just use Core. there are bc.i and electrum interfaces but they're not well enough tested/not functional enough.
05:17 < loddar> but now the wallet reset and begins at the first inde
05:17 < loddar> index
05:18 < loddar> i tried to enter the seed into electrum and raised the gap limit to 1000
05:18 < loddar> but to no avail
05:18 < waxwing> no you can't do that, the seed does not work on electrum
05:18 < waxwing> if you can't sync, and you don't have Core, i think the only option is to export the private keys to electrum/other wallet.
05:18 < loddar> it works but apparently the bip32 structure is anotehr one 
05:19 < loddar> yes but I only know the address , not the index height of them
05:19 < loddar> is there a way to export the privkey that way?
05:19 < waxwing> do wallet-tool.py --help . so hang on, you can't sync at all right.
05:19 < loddar> yes     
05:20 < loddar> i mean it seemed to sync with the friends bitcoin-rpc
05:20 < loddar> but begins from start
05:20 < loddar> and my addresses where somewhere at indext 90-120 i remember ;)
05:20 < waxwing> oh it's as high as that? i guess that's because you used it before, i see.
05:20 < loddar> yes     
05:21 < waxwing> so you tried using -g ?
05:21 < loddar> not yet
05:21 < loddar> what's the exact syntax?
05:21 < loddar> python wallet-tool.py wallet.json -g ....
05:22 < waxwing> python wallet-tool.py -g 150 -p wallet.json
05:22 < waxwing> maybe something like that
05:22 < loddar> thanks
05:22 < loddar> trying that now
05:22 < waxwing> but it's a bit of a weird situation to say the least :)
05:22 < waxwing> obv you trust your friend so you don't mind that you're importing those addresses into his Core wallet.
05:22 < loddar> yes :)
05:22 < loddar> yes 
05:23 < waxwing> is there any particular reason for a large gap, do you think?
05:23 < loddar> i know where he lives at ;-)
05:23 < waxwing> i mean, say you're on address index 100, but you were using the previous 100? as taker or maker?
05:23 < loddar> taker
05:23 < loddar> 2017-04-14 06:22:50,258 [MainThread  ] [INFO ]  requesting detailed wallet history from Bitcoin Core client 2017-04-14 06:22:51,390 [MainThread  ] [INFO ]  too few addresses in [(0, 0), (0, 1), (1, 0), (1, 1), (2, 0), (2, 1), (3, 0), (3, 1), (4, 0), (4, 1)] at [0, 0, 0, 0, 0, 0, 0, 0, 0, 0] 2017-04-14 06:22:51,732 [MainThread  ] [INFO ]  importing 600 addresses into account joinmarket-wallet-9be960
05:23 < waxwing> oh hang on, there is a problem that causes this.
05:24 < waxwing> because you didn't use that wallet on that Core instance before, his Core instance must be restarted with -rescan
05:24 < waxwing> it's in this particular case that rescan is needed - when you restore a JM wallet on a new Core instance.
05:24 < loddar> okay then new problem here. I don't have ssh access
05:24 < loddar> and my friend left for the mountains :)
05:25 < waxwing> yes, so basically we need you to be able to see the private keys for an arbitrary index without a wallet sync. hmm.
05:25 < loddar> is there a way to print the privat keys of the first 150 or so at once?
05:25 < loddar> the best solution would be to have an option to print the key specific for an address
05:25 < loddar> i wonder what the reason was to add it for a specific height only
05:26 < loddar> but okay I am not knowledgeable enough to understand :) no critic here. JM is a wonderful project
05:26 < waxwing> so hang on. you can connect to blockr, it's just out of sync right.
05:26 < loddar> yes     
05:26 < waxwing> so it seems to me, you should be able to use -g 150, using blockr. it'll be a bit slow though.
05:27 < waxwing> i'll take a quick look how easy it is to extract the keys without sync.
05:27 < loddar> the tx happened at a blockheight that blockr.io has not synced yet
05:27 < loddar> it is stuck over there
05:27 < waxwing> yeah but syncing will still go forwards down the index, if you specify -g, even if there are no transactions recorded on it.
05:28 < waxwing> but hang on, is it that you don't even know what index it is?
05:29 < waxwing> or, no, i guess, you know the address, just not the index (yet)
05:29 < loddar> yes     
05:29 < waxwing> ok i'll take a bit of time to look for the easiest way
05:29 < loddar> thanks so much :)
05:29 < loddar> take all the time needed
05:30 < adlai> loddar: you can print the private keys, and import to electrum; but first, do a wallet-tool -g 999 (or some other number large enough to guarantee fresh addresses), then when you import to electrum, send to a new address
05:30 < adlai> but make sure the addresses are imported to the bitcoin node BEFORE you send
05:30 < waxwing> yeah we got that far adlai but he would have to wait on a slow blockr sync.
05:30 < waxwing> no he doesn't have Core
05:31 < waxwing> he has access to a friend's Core remotely, but can't rescan
05:31 < adlai> this is a workaround for that
05:31 < adlai> loddar: you can print private keys with a flag to wallet-tool, either all, or specific ones
05:31 < waxwing> well yeah i already said that :)
05:31  * adlai doesn't remember the exact syntax, but -h does
05:32 < adlai> 12:25:14       waxwing | yes, so basically we need you to be able to see the private keys for an arbitrary index without a wallet sync. hmm. << doesn't this exist?
05:32 < waxwing> JM shuts down and asks for rescan adlai . maybe by increasing addr_req_count you get round that, hack style
05:32 < adlai> it doesn't know you haven't rescanned, though. it trusts the bitcoin node.
05:33 < adlai> loddar: https://github.com/JoinMarket-Org/joinmarket/blob/master/wallet-tool.py#L262-L269
05:33 < waxwing> hmm yes i *think* that that might work.
05:33 < loddar> one sec, reading and trying to understand :)
05:34 < adlai> that's the best way to learn :D
05:34 < waxwing> adlai: ah yes you're quite right. i hadn't remembered that the individual key patch allows specifying index.
05:34 < loddar> yes :)
05:34 < waxwing> his problem though is that he doesn't know the index, only the address.
05:34 < adlai> even if it didn't, -g 999 -p
05:34 < waxwing> so we might have to help him write a tiny script to iterate.
05:34 < waxwing> adlai: that wouldn't work if the sync doesn't succeed
05:34 < adlai> aka "IMPORT ALL THE THINGS", and maybe use a fresh wallet afterwards because some rando electrum server gets your everything
05:35 < adlai> it imports the first time, and prints the privkeys when you rerun
05:35 < loddar> okay I have to admit I am a little lost now
05:36 < loddar> so I have done : python wallet-tool.py -g 150 -p wallet.json
05:36 < loddar> and it imported them
05:36 < adlai> i recommend you NOT use this again
05:36 < adlai> because then it will print all your privkeys, and there are some things you just do not want to know
05:37 < loddar> I would have raised it to 500 now and done it again?
05:37 < adlai> nah     
05:37 < adlai> if you're certain 150 is enough, then it's enough
05:37 < loddar> 99% certain ;)
05:37 < adlai> but use dumpprivkey this time
05:37 < loddar> okay let me try
05:37 < adlai> dump a couple addresses, import to electrum, see if you catch the right one
05:37 < loddar> correct syntax would be?
05:37 < belcher> you know theres also -H
05:38 < adlai> if you're really impatient, you could use -p, but that will print ALL the privkeys
05:38 < adlai> right, that's what i'm suggesting loddar use
05:38 < loddar> i would use -p and then work them backwards 
05:38 < waxwing> adlai: you're remembering that in the case it asks for rescan it doesn't actually show the addresses right? or is it me that's remembering thatwrong.
05:38 < adlai> loddar: wallet-tool.py -H m/1/2/3/45 -g 150 blabla.json dumpprivkey
05:39 < adlai> except instead of that path, use one that makes sense for the mixdepth + address that you suspect
05:39 < adlai> again, you ~could~  use -p this time but i strongly recommend you print single privkeys each time rather than printing all of them
05:40 < adlai> a reasonable path to try could be m/0/0/1/90, which would be the 90th internal address in mixdepth 0
05:40 < adlai> oh, you should use external addresses, because you deposited.
05:40 < adlai> so m/0/0/0/90
05:41 < loddar> wallet-tool.py -H m/0/0/0/1 -g 150 wallet.json dumpprivkey
05:41 < loddar> would print the first 
05:41 < loddar> or is 0 the first?
05:43 < waxwing> 0 is the first
05:44 < loddar> okay
05:45 < loddar> i wonder is there no public blockchain explorer available where I can set the gap limit? then I could just scan the xpub and see the bip32 hight where the addresses are
05:45 < loddar> if it supports the JM key deviation method of course
05:45 < loddar> hmm     
05:46 < loddar> okay trying them backwards now from 150
05:47 < waxwing> ok, i see my mistake, dumpprivkey is a noscan method, makes sense
05:48 < waxwing> but yes it'd only be a tiny step to have a noscan method that showed an arbitrary range of addresses, or privkeys, or both
05:50 < loddar> yeah
05:50 < loddar> found the first one :)
05:50 < loddar> you guys are so great
05:52 < waxwing> loddar: yw, in other news, blockr.io is a complete bust again ...
05:53 < loddar> yes, coinbase -> surprise ;)
05:54 < loddar> okay first one was easy to sweep with electrum
05:54 < loddar> but the next ones all give me a mempool conflict?
05:55 < waxwing> loddar: well, but if you're trying to sweep funds from a key that is reported to have funds, from blockr.io, but blockr is out of sync?
05:55 < waxwing> i'd guess it would be that the funds were already spent out of that address right.
05:55 < loddar> electrum notes me about it. not blockr.io
05:56 < waxwing> yeah but how did you choose which keys to sweep?
05:56 < loddar> i found the first one at 140
05:56 < loddar> that sweeped it
05:56 < loddar> then used the privkeyof 139
05:56 < waxwing> yes, but how did you decide that was the one to sweep?
05:56 < loddar> bit signals a conflict
05:57 < loddar> when entering the privkey in electrum it checks for a balance 
05:57 < loddar> and shows it or returns a error if empty
05:57 < waxwing> ok. but if 'mempool conflict', it suggests that that address already had a transaction in unconfirmed state, right
05:57 < loddar> yes     
05:57 < loddar> but that isn not the case 
05:58 < loddar> god     
05:59 < loddar> ingore it
05:59 < loddar> so stupid
05:59 < loddar> i went down with the gap limit instead of the index *facepalmÜ
05:59 < loddar> *facepalm*
05:59 < loddar> to much happiness :)
06:06 < loddar> I have recovered them all
06:06 < loddar> awesome :)
06:06 < loddar> whom do I tip now ? :)
06:09 < loddar> and later I will test out the electrum plugin since that uses the specific electrum servers and not blockr.io ..until I have setup my own node ;-)
06:11 < loddar> is the Donation address: 1AZgQZWYRteh6UyF87hwuvyWj73NvWKpL for JM current?
06:11 < belcher> https://twitter.com/lopp/status/852869636999839744
06:11 < belcher> yes loddar 
06:12 < belcher> alternatively ask waxwing adlai for addresses since they're the ones that helped you
06:12 < loddar> then all three of t'em ;)
06:12 < waxwing> nah main donation address is fine
06:12 < loddar> waxwing adlai  please drop me a address
06:13 < loddar> this will be pretty , you shouldn't miss out ^^
06:13 < waxwing> loddar: i'd be happy to receive a donation on the electrum plugin thing if you give it a try, otherwise that ^ addr is fine, it's a group address.
06:13 < belcher> the main donation address goes to them too :P
06:13 < loddar> alright then I will donate to JM and AdamISZ donation adresses correct?
06:14 < loddar> Just ask for a bit of time since I first want to cj them anew 
06:14 < loddar> but incoming within 24hours max!
06:14 < loddar> thanks guys. really appreciated!
06:17 < belcher> :)     
06:17 -!- loddar [6c3daa9b@gateway/web/freenode/ip.108.61.170.155] has left #joinmarket []     
06:18 < waxwing> DAE feel bad when people are really grateful for getting their coins out of our application? :)
06:19 < belcher> i feel bad for coding the blockr.io code
06:19 < belcher> anyone know how to contact this wozz fellow who coded the electrum interface https://github.com/JoinMarket-Org/joinmarket/commits/develop?author=wozz
06:20 < waxwing> right what a sad state of affairs that is.
06:20 < belcher> ill try the email in his commits
06:20 < belcher> im thinking of merging some of these PRs and then going for a new release
06:20 < waxwing> oh right, no, it's a shame he didn't pick it up again.
06:20 < waxwing> yeah, thanks for that if you find time
06:22 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has joined #joinmarket     
06:25 -!- sudoPacman1 [kc@gateway/vpn/mullvad/x-ukndvioimocjwgds] has joined #joinmarket     
06:44 < adlai> ahh loddar left already >_<
06:50 < adlai> looks like he solved his issue though
06:56 < adlai> who knows, maybe he 'donated' to us via maker fees :)
07:21 < GithubBot5678> [joinmarket] chris-belcher pushed 1 new commit to develop: https://git.io/vSQOb
07:21 < GithubBot5678> joinmarket/develop 82c297f chris-belcher: Merge #722: Import privkey non-interactively...
07:38 < GithubBot5678> [joinmarket] chris-belcher closed pull request #679: Allow no/empty password (Implements #674) (develop...allow_empty_password) https://git.io/v1G98
07:39 < adlai> waxwing: btw, re: gratefulness - cf google's "our goal is to get people off our website as quickly as possible"
07:40 < adlai> JM's primary usecase is indeed moving coins, not holding onto them
07:40 < GithubBot5678> [joinmarket] chris-belcher pushed 2 new commits to develop: https://git.io/vSQsr
07:40 < GithubBot5678> joinmarket/develop ce23bc7 Adam Gibson: lock db access from taker scripts to avoid cursor exceptions
07:40 < GithubBot5678> joinmarket/develop 107f33a chris-belcher: Merge #708: lock db access from taker scripts to avoid cursor exceptions...
07:40 < belcher> speak for yourself, im mostly using it to hold
07:41 < belcher> incentently iv got some code that calculates the % annualized yield for every week/month
07:41 < adlai> if it so happens that it's easier to put coins somewhere, than to get them out... that's true of bitcoin in general
07:41 < belcher> should make it nice and make it a PR
07:41 < adlai> belcher: i think the number of people using jm as a wallet is rather lower than those who use it as a tumbler
07:41 < belcher> oh certainly
07:42 < adlai> also fairly certain (but any numbers would be pulled out of my ass) that the monthly volume exceeds the liquidity by an order of magnitude
07:42  * adlai should be adding nice things to cjhunt, such as non-asspulled numbers
07:43 < adlai> graphing liquidity would be tricky, given that we can't scrape makers anymore :D
07:45 < GithubBot5678> [joinmarket] chris-belcher pushed 2 new commits to develop: https://git.io/vSQGe
07:45 < GithubBot5678> joinmarket/develop 064e31e Bryan Stitt: Add "extend_mixdepth=True" to yieldgen...
07:45 < GithubBot5678> joinmarket/develop 887fa6c chris-belcher: Merge #725: Add "extend_mixdepth=True" to yieldgen...
07:45 < belcher> have you read our issue about makers committing to their wallest
07:45 < belcher> which stops the one-wallet-multiple-makers problem
07:46  * adlai has not studied it in depth recently
07:49 -!- adlai is now known as others     
07:49 -!- others is now known as adlai     
08:06 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #joinmarket     
08:57 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 240 seconds]     
09:10 -!- waxwing [~waxwing@38.132.120.4] has joined #joinmarket     
09:11 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Quit: (┛◉Д◉)┛┻━┻]     
09:14 < grubles> https://twitter.com/lopp/status/852869636999839744 <- blockr.io borked?
09:14 < waxwing> yeah according to reports
09:27 < belcher> for those interested in monero http://monerolink.com/monerolink.pdf
09:27 < belcher> theres a weakness with choosing the inputs which allows unmixing
09:28 < belcher> Weakness 2.  Monero mixins are sampled from a distribution that does not resemble real transaction inputs, and thus the real inputs can usually be identified.
09:28 < belcher> sounds like it could be fixed by just sampling from the correct distribution
09:34 -!- coins123 [~coins123@unaffiliated/coins123] has quit []     
09:35 < belcher> is there anything anyone wants to do before the next release? cc waxwing AlexCato1 
09:36 < waxwing> belcher: no, no hold up here, thanks
10:02 < belcher> hold on is anyone running the develop branch...
10:02 < belcher> that would be useful, iv realized im not since my other computer doesnt even have git installed
10:02 < belcher> well i only ever use yg these day anyway and nothing has changed there
10:15 < waxwing> belcher: i run it (yg and occasionally sp, but not tumbler apart from *very* rare test). if you're pushing a few PRs, yes, wait and hopefully people run it a bit.
10:17 < belcher> yep good plan
10:44 < belcher> hey so whats the story on the electrum blockchain interface? it works but its a bit slow?
10:45 < waxwing> belcher: yeah, i would say so. but i wouldn't be surprised if it's not robust.
10:45 < waxwing> at the time i was testing it, they didn't have the testnet interface out, since then that's been added, so better testing can be done.
10:46 < waxwing> but even the current slowness would probably make it a write-off for Maker side, i'd only consider it for taker side.
10:47 < belcher> yield generators should only be used with bitcoin core, but yes for patientsendpayment other stuff could be useful
10:48 < belcher> oh wow so blockchain.info interface was merged too?
10:49 < waxwing> yes, but apart from the obvious, it also seemed to be slow, and also can't be tested on testnet (that hasn't changed).
10:50 < waxwing> i would not be at all upset if that were removed; it would be nice if the electrum one stayed. i put them in as a kind of fallback. i think i noted it on reddit.
10:50 < belcher> yeah ill just put it in the release notes with some text
10:50 < waxwing> in both cases iirc the original author dropped out
10:51 < waxwing> this shadowbrokers new dump is quite something, seems like
10:52 < arubi> waxwing, "Receiving objects: 100% (11782/11782), 330.95 MiB | 3.96 MiB/s, done." :)
10:53 < waxwing> arubi: :)
10:56 -!- stachrom [d4338865@gateway/web/freenode/ip.212.51.136.101] has joined #joinmarket     
10:57 < waxwing> arubi: lol this quote: "Is being too bad nobody deciding to be paying theshadowbrokers for just to shutup and going away. TheShadowBrokers rather being getting drunk with McAfee on desert island with hot babes"
11:02 < arubi> hahaha, geeks have truely inherited the earth
11:34 -!- zxccxz [d41590e3@gateway/web/freenode/ip.212.21.144.227] has quit [Ping timeout: 260 seconds]     
11:41 -!- MaxSan [~one@185.156.175.59] has joined #joinmarket     
12:17 -!- stachrom [d4338865@gateway/web/freenode/ip.212.51.136.101] has quit [Ping timeout: 260 seconds]     
12:23 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]     
12:26 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has joined #joinmarket     
12:33 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
12:37 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has joined #joinmarket     
12:42 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has quit [Ping timeout: 252 seconds]     
12:47 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has joined #joinmarket     
13:17 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
13:24 -!- sudo_pscience [kc@gateway/vpn/mullvad/x-ytcjgovidaxasgtk] has quit [Quit: Leaving.]     
13:24 -!- instagibbs [~instagibb@pool-100-15-117-236.washdc.fios.verizon.net] has joined #joinmarket     
13:36 -!- sudo_pscience1 [~kc@141.105.67.3] has joined #joinmarket     
13:46 -!- coins123 [~coins123@2.43.185.190] has joined #joinmarket     
13:46 -!- coins123 [~coins123@2.43.185.190] has quit [Changing host]     
13:46 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket     
14:03 -!- ananteris [~user@unaffiliated/ananteris] has joined #joinmarket     
14:16 -!- zxccxz [d41590e3@gateway/web/freenode/ip.212.21.144.227] has joined #joinmarket     
14:27 -!- MaxSan [~one@185.156.175.59] has quit [Ping timeout: 260 seconds]     
14:44 < belcher> just had a thought, this electrum and bc.i interface is taking the project in the wrong direction :(
14:44 < belcher> i mean the code is already written, but people will judge us for it :p
14:45 < belcher> "hey so blockr.io was a really bad idea, well here's two more!"
14:45 < belcher> i guess querying public APIs is just too damn easy
14:46 < adlai> how about we just make them opt-in, with the default being local bitcoin
14:46 < adlai> so people can leak their correlation if they have an urge to footgun, but it will require them to affirmatively edit the config to match
14:48 < adlai> since such a change only affects the default config, it doesn't break anybody's existing setup
16:14 -!- MaxSan [~one@185.156.175.59] has joined #joinmarket     
16:21 < belcher> maybe we should do a release candidate since its not so tested
18:01 -!- mode/#joinmarket [+o belcher] by ChanServ     
18:01 -!- belcher changed the topic of #joinmarket to: Welcome to JoinMarket: Increase Fungibility and Subsidise Your Fees | http://github.com/Joinmarket-Org/joinmarket | @joinmarket r/joinmarket | friends: #bitsquare #tlsnotary-chat | Live View: https://joinmarket.me/ob | Latest release 0.2.2 | Also on ssl 6dvj6v5imhny3anf.onion:6697 #joinmarket
18:12 -!- lnostdal [~lnostdal@62.90-149-73.nextgentel.com] has quit [Ping timeout: 260 seconds]     
18:21 <@belcher> the twitter account now has the icon made by chuckymcgee
18:21 -!- mode/#joinmarket [-o belcher] by belcher     
19:17 < gmaxwell> belcher: exactly what is needed in these queries? can we make a public API that gives the required data without trashing privacy?
19:18 < belcher> not really, it needs a mapping from address to utxo and history
19:19 < belcher> im planning to write something where the user points joinmarket to their own full node and it sync's from there, which would be private
19:19 < gmaxwell> What does history mean precisely? 
19:19 < belcher> whether an address was used on the blockchain before
19:20 < gmaxwell> and it needs this only as of the current height, right?
19:20 < belcher> yes     
19:24 -!- MaxSan [~one@185.156.175.59] has quit [Ping timeout: 260 seconds]     
19:25 < gmaxwell> so, if I make a table of 128 bit hashes of txid|vout|scriptpubkey|amount|used_flag  for the whole UTXO set the database would be 738 MB, maybe half that size if dust addresses were filtered. and maybe 10x smaller if you just instead eliminate all reuse (which I suspect you might be able to ban?).  
19:26 < gmaxwell> I think it would not be completely unreasonable to have a thing where users just download the whole thing, check its hash against varrious observers and get diffs-- especially if you could eliminate dust and reuse.  Alternatively, it wouldn't be completely unrealistic for people to have PIR servers that can query this data.
19:27 -!- MaxSan [~one@185.156.175.59] has joined #joinmarket     
19:28 < belcher> so that i understand, is that hash(txid|vout|scriptpubkey|amount|used_flag), and then if you know a UTXO you can check whether it exists?
19:29 < gmaxwell> Yes, so someone you're trying to join with would need to already know their UTXO, and you could query this to tell if it exists.  If you can't do that then you need a real database and not a set-- which could be done but would be a couple times bigger-- not out of the question, but getting less attractive vs a full node.
19:31 < belcher> yes this scheme would help certainly
19:31 < gmaxwell> For the PIR approach the server must scan the entire database for every query (though some batching can be done) and do non-trivial computation. All in all computational PIR is more expensve than just transfering the data under most cost models... but perhaps a cost model that says user inconvience is roughly infinitely bad might be a more fair reflection of reality because users will reliably do some
19:31 < gmaxwell> thing stupid instead if you impose any cost on them.
19:32 < belcher> there is another idea for sync'ing wallets where people connect to any peers out there on the network and download full blocks starting from the wallet creation date, that gives almost full privacy but spv security, and issue with that for joinmarket is market makers send their UTXOs and takers can check whether those UTXOs are real or not, so this scheme with hashing everything would allow takers to check(!)
19:32 < belcher> also what does PIR mean?
19:32 < gmaxwell> belcher: there are some "full block SPV" mode patches to bitcoin core that do somethings like that.
19:33 < gmaxwell> belcher: private information retrevial.  Basically there are a set of crypto techniques which let you query a remote database without the database learning your query.  They're implemented and in the same kind of efficiency class as things like confidential transactions.
19:34 < belcher> that sounds interesting for sure, reading a bit now
19:35 < gmaxwell> There are two broad kinds of PIR,  Information-theoretic PIR, which is much more efficient but depends on there being M of N servers which do not collaborate to violate your privacy.  And there is computational PIR which can work with a single untrusted server and makes a cryptographic assumption and is cpu heavy (like doing an ellpitic curve operation for every record, for every query). 
19:35 < gmaxwell> Percy++ is a library that implements both kinds, there are several other such libraries.
19:36 < gmaxwell> They've had very little use in practice because "just transfer the whole damn database" is often cheaper under reasonable assumptions of cpu vs bandwidth costs. (or at least close enough that the complexity of dealing with PIR isn't worth it)
19:36 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection]     
19:36 < gmaxwell> But we know the whole world wide number of CJs can't be more than a couple per second.
19:37 < kanzure> also pester bramc for PIR things
19:37 < gmaxwell> Which basically means that like a couple servers at blockstream using their idle capacity could probably satisify the worldwide need for JM queries. 
19:37 < gmaxwell> and since it's cryptographically private it probably doesn't matter if there is a bit of centeralization in the servers for it.
19:38 < belcher> yes that could work
19:41 < belcher> iv been wondering about ways to solve the maker-might-send-fake-utxos problem for a while now, and looks like this would be a solution :)
19:43 < gmaxwell> PIR natively gives you a private array access.  So if what you need is a map you have a couple options: one is that you order the data and construct a small index for your map which you just send to ever user, (and since it's small thats no big deal) then they use private array access to get the entrie(s) they need.  Another option is you build a n-ary search tree,  and put each level of the tree in a
19:43 < gmaxwell>  seperate PIR database, and users just query each level to find their records. 
19:44 < gmaxwell> To prevent the server from silently giving bad results you merkelize the database, and in each leaf record include the membership proof,  and the server publishes and signs the root... if the server starts putting out bad roots everyone will see. 
19:44 < gmaxwell> (like the (not-yet)commited bloom filter proposals)
19:46 < belcher> right ok
20:17 -!- MaxSan [~one@185.156.175.59] has quit [Ping timeout: 260 seconds]     
20:47 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.]     
22:22 -!- juscamarena [~justin@47.148.176.74] has joined #joinmarket     
22:22 -!- juscamarena_ [~justin@47.148.176.74] has joined #joinmarket     
22:22 -!- juscamarena_ [~justin@47.148.176.74] has quit [Remote host closed the connection]