1 2012-10-26 00:30:50 <forrestv> hm... a "assimilatewallet" rpc command would be really helpful. i have a folder full of random wallet backups
 2 2012-10-26 00:31:51 <forrestv> is there any way to do something like that besides using pywallet to extract the private keys and using importprivkey?
 3 2012-10-26 00:51:17 <Luke-Jr> forrestv: probably things in that area will get better now that LevelDB is merged
 4 2012-10-26 00:51:29 <Luke-Jr> forrestv: once sipa's HD wallets get done, bdb will be import-only ;)
 5 2012-10-26 01:07:47 <gmaxwell> forrestv: there is that wallet recovery tool. cat them all into one file and run it on them.. only works for non-encrypted wallets.
 6 2012-10-26 01:08:17 <gmaxwell> forrestv: I actually got a small amount of bitcoin and a bunch (like 30 BTC worth) of lite by running that crazy tool on my systems..
 7 2012-10-26 03:04:11 <jgarzik> w00t
 8 2012-10-26 03:04:31 <jgarzik> picocoin just generated its first bitcoin address, from a key stored in its encrypted wallet
 9 2012-10-26 03:09:14 <jgarzik> all the other binary structure stuff is done
10 2012-10-26 03:09:25 <jgarzik> now it's time to download a block chain, and see if we can find payments to us
11 2012-10-26 03:09:43 <conman> jgarzik, btw any interest in what we talked about?
12 2012-10-26 03:10:24 <jgarzik> conman: definitely
13 2012-10-26 03:10:36 <conman> hokay
14 2012-10-26 03:12:10 <gmaxwell> oh secret conman jgarzik kernel miner backdoor.
15 2012-10-26 03:12:29 <conman> right
16 2012-10-26 03:12:56 <slush> "Luke-Jr: sipa: when was this? last I heard slush was opposed to standardizing it"
17 2012-10-26 03:14:22 <Luke-Jr> slush: BIP isn't just a meaningless assignment
18 2012-10-26 04:43:49 <UukGoblin> gmaxwell, not off the top of my head, no
19 2012-10-26 04:44:28 <UukGoblin> secure secret ballot elections... what about ensuring that only one person can vote, while also making sure no-one can force other people to vote on someone particular?
20 2012-10-26 05:51:58 <gmaxwell> UukGoblin: sometimes distinguishing people is already solved for you.
21 2012-10-26 05:53:41 <gmaxwell> so if you can agree on who can vote, people create ballots, encrypted with the keys of all the partipants, then the votes go into a track of ZKP mixers. Then everyone decrypts everyone. You end up with a stack of decrypted ballots that everone agrees are authentic but no one knows whos is whos.
22 2012-10-26 06:11:28 <UukGoblin> ah, right, so not exactly suitable for general presidential elections
23 2012-10-26 06:11:37 <UukGoblin> and there's nothing that does it? :-O
24 2012-10-26 06:12:03 <UukGoblin> the dutch guys did some multi-party computation to determine a price on a double-betting thing
25 2012-10-26 06:13:09 <UukGoblin> http://viff.dk/
26 2012-10-26 06:15:48 <UukGoblin> gmaxwell, ^ that might do, maybe?
27 2012-10-26 06:36:51 <thermoman> sipa, gmaxwell: rolled back yesterday and i'm now downloading a fresh blockchain with 0.7.1 that i will use to migrate the 0.3.24 clients next week - hopefully i don't need any options in DB_CONFIG any more
28 2012-10-26 06:37:20 <sipa> thermoman: loadblock didn't work?
29 2012-10-26 06:40:07 <thermoman> sipa: was too slow yesterday so we had to rollback anyway
30 2012-10-26 06:40:20 <thermoman> now i'm starting fresh with 0.7.1
31 2012-10-26 06:40:32 <sipa> well it will be faster than downloading from network!
32 2012-10-26 06:52:24 <thermoman> sipa: yes, that might be. but what if the data in these blk* files is corrupt in the first place?
33 2012-10-26 06:52:52 <thermoman> no problem if it takes 2 or 3 days now - the old client is running in production and we will try migration next week
34 2012-10-26 06:54:07 <thermoman> is it normal that with 0.7.1 117400 blocks loaded = 200MB on disk for blk* together. with 0.3.24 the current size of blk* is 4.7GB <--- ??
35 2012-10-26 07:00:46 <sipa> thermoman: you deleted blkindex.dat without deleting blk000*.dat
36 2012-10-26 07:01:37 <sipa> thermoman: and -loadblock imports blocks as if they had been received from network, but it runs at 100% import speed because there's not network overhead/delay
37 2012-10-26 07:01:50 <sipa> so it's perfectly safe to -loadblock non-trusted data
38 2012-10-26 07:01:59 <sipa> (or potentially corrupt data)
39 2012-10-26 07:02:19 <thermoman> what happens if the blk* files are corrupt?
40 2012-10-26 07:02:26 <thermoman> does the client then load things from network?
41 2012-10-26 07:03:06 <thermoman> i did like you said: moved blk00* to /var/tmp, deleted blkindex*, ran daemon with -load... /var/tmp/ -load... /var/tmp
42 2012-10-26 07:03:36 <thermoman> it imported blocks, yes.
43 2012-10-26 07:04:11 <thermoman> but it would have taken some hours - and we didn't have this time. so we rolled back to backups we had made before the migration
44 2012-10-26 07:04:36 <sipa> depends what kind of corrupted, the client detects certain types anywhere, other types in the last 2500 blocks, and yet other types nowhere
45 2012-10-26 07:04:59 <sipa> in general corruption shouldn't happen, but in practice we've seen more than enough cases where it did
46 2012-10-26 07:05:26 <thermoman> so what happens if i use -loadblock and the file is massively corrupt? does the client simply stop importing or does the client switch to loading the remaining blocks from network?
47 2012-10-26 07:06:24 <thermoman> i want to make sure the blockchain is 100% fine - so i now load them from the network where it doesn't matter if it takes one or 4 days
48 2012-10-26 07:07:54 <sipa> loadblock is always safe; you can feed /dev/urandom into it
49 2012-10-26 07:08:08 <sipa> it will try to find blocks in the file you give it, and import those
50 2012-10-26 07:08:18 <sipa> whatever is invalid or missing will be ignored
51 2012-10-26 07:08:51 <sipa> and it does full validation, like normal blocks received over network are validated
52 2012-10-26 07:09:19 <thermoman> what happens with blocks that are missing? are they fetched from network the next time i run without -loadblock ?
53 2012-10-26 07:16:11 <sipa> they'll just be downloaded when loadblock is finished
54 2012-10-26 07:24:19 <thermoman> is it possible to export wallet.dat to ascii and import it to eliminate any corruptions in the BDB file?
55 2012-10-26 07:32:33 <kinlo> thermoman: there is a tool for that, but I don't know if it can handle encrypted wallets
56 2012-10-26 07:33:04 <kinlo> thermoman: https://github.com/jackjack-jj/pywallet
57 2012-10-26 07:33:41 <kinlo> note that most things are now possible with the rpc right in the bitcoin client
58 2012-10-26 07:38:22 <sipa> thermoman: db4.8_dump wallet.dat >wallet.dump
59 2012-10-26 07:45:46 <thermoman> sipa: thanks, i thought of something like this
60 2012-10-26 09:09:18 <Eliel> sipa: have you thought of renaming ultraprune? the name is too confusing as it is since there's no actual pruning going on.
61 2012-10-26 09:11:48 <Eliel> calling it simply "utxodb" would probably cause less confusion :)
62 2012-10-26 09:14:17 <sipa> "the 0.8 engine"
63 2012-10-26 09:15:29 <sipa> i agree by the way, i should have renamed it a long time ago
64 2012-10-26 09:16:19 <sipa> but now that it's merged, i hope i don't need to refer to the name of the branch anymore often
65 2012-10-26 09:16:31 <MC1984> ultrachain man
66 2012-10-26 09:16:57 <MC1984> in fact i sincerely hope pruning WONT ever go on by default
67 2012-10-26 09:17:10 <MC1984> cos i dont like this archive node business
68 2012-10-26 09:17:21 <MC1984> i want the chain to be able to survive a KT event
69 2012-10-26 09:19:07 <sipa> right now, we're losing a lot of full nodes in favor of spv nodes or non-nodes, because the resource requirements are nontrivial
70 2012-10-26 09:19:27 <Eliel> it's quite hard to figure out a monetary incentive for people to keep publicly available archive nodes. Those who are downloading the archive most likely can't pay yet.
71 2012-10-26 09:24:50 <MC1984> sipa really?
72 2012-10-26 09:24:53 <MC1984> you have metrics?
73 2012-10-26 09:27:17 <sipa> no, just a guess
74 2012-10-26 09:27:55 <sipa> abd most of it is probably mostly because the reference client is too slow, and not because it eats too much disk or ram or cpu
75 2012-10-26 09:41:01 <MC1984> theres too much take and not enough give in satoshi atm
76 2012-10-26 09:41:53 <MC1984> im sure most people would be happy to give a huge chunk of thier computer resources to support the network, as long as the cient gives them functionality straight away