1 2017-10-06 02:48:06 <ananteris> so, if someone has a private key and passphrase of an ec-multiplied BIP38 wallet can they
 2 2017-10-06 02:48:13 <ananteris> generate other keys like with a hd wallet?
 3 2017-10-06 02:50:02 <arubi> isn't the point of ec multiplied keys to be able to generate more keys without the password?
 4 2017-10-06 02:52:57 <ananteris> I think so, what i'm worried about is say I've generated three 3 ec multiplied bip38 keys, if I reveal the passphrase and private key of any single one of them to someone does it put the other generated keys at risk (without the encrypted private key being known)
 5 2017-10-06 02:53:20 <ananteris> sort of like how it does if you reveal the private key of something with a known xpub IIRC
 6 2017-10-06 02:55:59 <luke-jr> ananteris: what are "ec multiplied bip38 keys"? note that bip38 is advised against use
 7 2017-10-06 02:56:01 <arubi> if you generated each key by itself without context to the other keys then I'm not sure why it should reveal anything.  the part about bip32's xpub+child private key revealing the master xpriv is possible exactly because the keys are hierarchal
 8 2017-10-06 02:56:17 <ananteris> luke-jr: circa 2014 bitaddress.org keys
 9 2017-10-06 02:58:25 <ananteris> my use case is there are multiple keys generated with coins on them, not sure if revealing one is a risk to the others or not
10 2017-10-06 02:59:53 <arubi> revealing one means only the private key itself and not the password?
11 2017-10-06 03:00:35 <ananteris> well, it gets interesting.. my ex can't remember her password or its a webkit JS JIT bug.. either way we're considering putting it out as a bounty
12 2017-10-06 03:01:07 <ananteris> so the passphrase would have to be considered "revealed" if theres hints for it floating around ect
13 2017-10-06 03:01:25 <ananteris> and someone could crack it successfully
14 2017-10-06 03:06:53 <arubi> I think you could grind a revealed key and passphrase to generate more keys.  I haven't looked into bip38 too much but it seems you can just try different "lot" numbers
15 2017-10-06 03:07:22 <arubi> but really I don't know if anybody will be trying to brute force that scrypt stuff
16 2017-10-06 03:08:04 <arubi> well depends on how much it's worth really :)
17 2017-10-06 03:10:40 <arubi> oh wait the process is more complicated than that, I don't know if it's dangerous or not.  it's too confusing :)
18 2017-10-06 03:15:46 <ananteris> hah right? at the same conclusion reading the BIP
19 2017-10-06 03:17:54 <arubi> step 2 in "create new encrypted private keys given.." says "Generate 24 random bytes, call this seedb. Take SHA256(SHA256(seedb)) to yield 32 bytes, call this factorb"
20 2017-10-06 03:21:23 <arubi> so seems like new keys are generated at random from encrypted ones and the input is pretty big.  if you know the 24 bytes, or the 32 bytes hash and the original private key then I think you can easily get the new key.  24 bytes is pretty big, but it's a lot less than a normal private key
21 2017-10-06 03:24:29 <ananteris> so 192 bits and two rounds of sha256
22 2017-10-06 03:24:53 <ananteris> and an ecmultiply.. eesh
23 2017-10-06 03:34:07 <arubi> so if you know the original key and factorb I think you can just ecmul (original key * factorb) * G
24 2017-10-06 03:34:24 <arubi> and get the new private key
25 2017-10-06 03:36:34 <ananteris> or divide the key you know by a guessed factorb to generate another
26 2017-10-06 03:36:53 <ananteris> ?
27 2017-10-06 03:38:57 <arubi> dividing numbers is just multiplying by the inverse so it's just like trying a different factorb
28 2017-10-06 03:41:07 <arubi> there's no magic with numbers here like in bip32 (at least I don't think there is), you seem to need to keep all your bip38 encrypted keys even if you generated all of them from the same original passphrase
29 2017-10-06 03:45:54 <ananteris> I don't see where in the BIP the original key is mentioned.
30 2017-10-06 03:46:14 <arubi> by original key I mean the passfactor
31 2017-10-06 03:48:33 <arubi> seems to be passphrase -> passfactor -> passpoint, then you can generate more keys by multiplying a random factorb by the passpoint
32 2017-10-06 03:49:05 <arubi> the owner of passphrase can regenrate passfactor and by knowing factorb can then get the private key for the new encrypted point
33 2017-10-06 04:01:11 <ananteris> okay, so if they can generate passfactor, they can generate passpoint. Meaning they could still derive the other keys by brute forcing factorb
34 2017-10-06 04:03:42 <arubi> yea, it's a huge amount, but still a lot less secure than just a random private key
35 2017-10-06 04:12:29 <ananteris> alright.. arubi thanks alot man
36 2017-10-06 04:12:39 <arubi> cheers
37 2017-10-06 06:45:48 <rothman> Hey everyone. I’m developing software that traverses the blockchain, and I’m wondering about tallying address “balances” from the UTXO set. I’m wondering if there’s a good approach to this. If it needs to be only P2PKH, P2SH, and other variations that’s okay. Any ideas or words of advice?
38 2017-10-06 11:16:21 <thermoman> hi. I've setup a 0.15 full node. it was running without problems. today i rebooted the linux machine it was running on and after reboot it got out of control: Replaying blocks, Rolling forward
39 2017-10-06 11:16:25 <thermoman> https://pastebin.com/DgXRhQk1
40 2017-10-06 11:16:29 <thermoman> any idea what might have caused this?
41 2017-10-06 11:20:15 <thermoman> and even more important: what's the reason for doing this?
42 2017-10-06 11:22:41 <thermoman> ok I think I know the answer: unclean shutdown. doing a reboot before shutting down bitcoind will result in bitcoind being SIGKILLED because it's taking bitcoind too long to terminate after SIGTERM
43 2017-10-06 16:09:51 <esotericnonsense> thermoman: it may depend on the length of time it's been running (depends how long the SIGKILL timeout is)
44 2017-10-06 16:10:06 <esotericnonsense> thermoman: if you have a high value for dbcache then it can take a long time to flush during shutdown
45 2017-10-06 16:10:56 <esotericnonsense> hm, only 300mbthere.. odd
46 2017-10-06 16:11:34 <esotericnonsense> i suspect that killing it during a flush is bad for the chainstate in any case
47 2017-10-06 16:51:41 <thermoman> esotericnonsense: the problem was me. I enabled the service manually bit forgot to enable the service to be shutdown on system reboot/shutdown
48 2017-10-06 16:51:58 <thermoman> esotericnonsense: so the process only got the SIGTERM and a couple of seconds later the SIGKILL
49 2017-10-06 16:52:13 <esotericnonsense> aha
50 2017-10-06 16:52:30 <thermoman> with my init script stopping the service the script will wait until no more process with the PID
51 2017-10-06 16:52:45 <thermoman> I had dbcache=12000
52 2017-10-06 16:53:17 <thermoman> stopping bitcoind with dbcache=12000 took many minutes
53 2017-10-06 16:53:19 <esotericnonsense> thermoman: ah ok, it's just that in the log there you have low dbcache (guessing you didn't enable it again?)
54 2017-10-06 16:53:41 <esotericnonsense> thermoman: it depends how full the cache gets (how long it's been open usually, particularly during IBD), but yeah
55 2017-10-06 16:53:41 <thermoman> esotericnonsense: right. I modified dbcache to defaults before rebooting the node
56 2017-10-06 16:53:55 <esotericnonsense> thermoman: if you check debug.log it will tell you the approximate size used
57 2017-10-06 16:54:12 <thermoman> it was in IBD, so dbcache was most certainly full
58 2017-10-06 16:54:19 <esotericnonsense> :)
59 2017-10-06 16:54:54 <thermoman> just tested again with properly service stopping enabled and even with big cache now the init script waits until no more bitcoind process
60 2017-10-06 16:55:30 <thermoman> it's sometimes the dirty hacks like symlinking manually in /etc/rc2.d/ instead of using update-rc.d that fucks up everything
61 2017-10-06 16:55:33 <thermoman> :)
62 2017-10-06 16:55:34 <esotericnonsense> as long as it actually waits forever :P i've had it take 2-3 minutes to close before
63 2017-10-06 16:56:15 <thermoman> at least it wasn't a production system
64 2017-10-06 16:56:37 <thermoman> yeah, there is no timeout in the init.d script stopping the service
65 2017-10-06 21:02:26 <tomdickharry> hi there, i've a big problem....i have an original bitcoin wallet saved and and i changed the extension for security reasons...i can't remember which file it is....anyone any ideas on how to find it? Thanks
66 2017-10-06 21:25:15 <instagibbs> tomdickharry, well, if you know how much activity is on it you can sort based on file size. You could also just run a script trying to get it to load each file... probably better solutions out there
67 2017-10-06 21:34:19 <eck> on unix there's a file command that will tell you the file type, the bitcion wallet will be a berkeleydb database
68 2017-10-06 21:57:24 <jb55> I'm looking for a simple cli program where I can decode, encode and more importantly *evaluate* bitcoin scripts. Any ideas?
69 2017-10-06 23:12:12 <esotericnonsense> there's probably magic bytes in the file somewhere. might even be the header. could make a new wallet and see what the first 4 bytes are or whatever.