Transcript for #bitcoin-dev 2017/10/06

02:48 ananteris so, if someone has a private key and passphrase of an ec-multiplied BIP38 wallet can they
02:48 ananteris generate other keys like with a hd wallet?
02:50 arubi isn't the point of ec multiplied keys to be able to generate more keys without the password?
02:52 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)
02:53 ananteris sort of like how it does if you reveal the private key of something with a known xpub IIRC
02:55 luke-jr ananteris: what are "ec multiplied bip38 keys"? note that bip38 is advised against use
02:56 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
02:56 ananteris luke-jr: circa 2014 keys
02:58 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
02:59 arubi revealing one means only the private key itself and not the password?
03:00 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
03:01 ananteris so the passphrase would have to be considered "revealed" if theres hints for it floating around ect
03:01 ananteris and someone could crack it successfully
03:06 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
03:07 arubi but really I don't know if anybody will be trying to brute force that scrypt stuff
03:08 arubi well depends on how much it's worth really :)
03:10 arubi oh wait the process is more complicated than that, I don't know if it's dangerous or not. it's too confusing :)
03:15 ananteris hah right? at the same conclusion reading the BIP
03:17 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"
03:21 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
03:24 ananteris so 192 bits and two rounds of sha256
03:24 ananteris and an ecmultiply.. eesh
03:34 arubi so if you know the original key and factorb I think you can just ecmul (original key * factorb) * G
03:34 arubi and get the new private key
03:36 ananteris or divide the key you know by a guessed factorb to generate another
03:36 ananteris ?
03:38 arubi dividing numbers is just multiplying by the inverse so it's just like trying a different factorb
03:41 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
03:45 ananteris I don't see where in the BIP the original key is mentioned.
03:46 arubi by original key I mean the passfactor
03:48 arubi seems to be passphrase -> passfactor -> passpoint, then you can generate more keys by multiplying a random factorb by the passpoint
03:49 arubi the owner of passphrase can regenrate passfactor and by knowing factorb can then get the private key for the new encrypted point
04:01 ananteris okay, so if they can generate passfactor, they can generate passpoint. Meaning they could still derive the other keys by brute forcing factorb
04:03 arubi yea, it's a huge amount, but still a lot less secure than just a random private key
04:12 ananteris alright.. arubi thanks alot man
04:12 arubi cheers
06:45 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?
11:16 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
11:16 thermoman
11:16 thermoman any idea what might have caused this?
11:20 thermoman and even more important: what's the reason for doing this?
11:22 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
16:09 esotericnonsense thermoman: it may depend on the length of time it's been running (depends how long the SIGKILL timeout is)
16:10 esotericnonsense thermoman: if you have a high value for dbcache then it can take a long time to flush during shutdown
16:10 esotericnonsense hm, only 300mbthere.. odd
16:11 esotericnonsense i suspect that killing it during a flush is bad for the chainstate in any case
16:51 thermoman esotericnonsense: the problem was me. I enabled the service manually bit forgot to enable the service to be shutdown on system reboot/shutdown
16:51 thermoman esotericnonsense: so the process only got the SIGTERM and a couple of seconds later the SIGKILL
16:52 esotericnonsense aha
16:52 thermoman with my init script stopping the service the script will wait until no more process with the PID
16:52 thermoman I had dbcache=12000
16:53 thermoman stopping bitcoind with dbcache=12000 took many minutes
16:53 esotericnonsense thermoman: ah ok, it's just that in the log there you have low dbcache (guessing you didn't enable it again?)
16:53 thermoman esotericnonsense: right. I modified dbcache to defaults before rebooting the node
16:53 esotericnonsense thermoman: it depends how full the cache gets (how long it's been open usually, particularly during IBD), but yeah
16:53 esotericnonsense thermoman: if you check debug.log it will tell you the approximate size used
16:54 thermoman it was in IBD, so dbcache was most certainly full
16:54 esotericnonsense :)
16: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
16:55 thermoman it's sometimes the dirty hacks like symlinking manually in /etc/rc2.d/ instead of using update-rc.d that fucks up everything
16:55 thermoman :)
16:55 esotericnonsense as long as it actually waits forever :P i've had it take 2-3 minutes to close before
16:56 thermoman at least it wasn't a production system
16:56 thermoman yeah, there is no timeout in the init.d script stopping the service
21:02 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
21:25 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
21:34 eck on unix there's a file command that will tell you the file type, the bitcion wallet will be a berkeleydb database
21:57 jb55 I'm looking for a simple cli program where I can decode, encode and more importantly *evaluate* bitcoin scripts. Any ideas?
23: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.