1 2012-09-24 00:00:34 <jgarzik> amiller: agreed RE range scan then ;p
2 2012-09-24 00:02:28 <amiller> getdata() seems like its the big one though
3 2012-09-24 00:03:14 <amiller> i could make like a super block serving index and just run it as a peer node and anyone that connects to it will get all their blocks super duper fast
4 2012-09-24 00:04:58 <jgarzik> amiller: yep, that's the idea of an archive node, in the future when there is a distinction between those who have the blockchain, and those who may just validate new transactions and blocks
5 2012-09-24 00:05:16 <jgarzik> amiller: and my idea of storing blocks in sendfile(2)-ready format would be helpful
6 2012-09-24 00:06:44 <kjj_> could pynode be hacked into that superseeder?
7 2012-09-24 00:07:11 <amiller> yeah totally it's almost there right now
8 2012-09-24 00:07:27 <kjj_> that it can only handle one connection at a time isn't a big deal. just make it disconnect when done.
9 2012-09-24 00:07:47 <jgarzik> kjj_: amiller fixed that limitation yesterday, by converting it to gevent
10 2012-09-24 00:07:57 <jgarzik> kjj_: now i can add multi-peer support easily
11 2012-09-24 00:07:57 <kjj_> ahh, even better
12 2012-09-24 00:08:07 <jgarzik> amiller: thanks again for that
13 2012-09-24 00:08:12 <amiller> rock on
14 2012-09-24 00:08:30 <kjj_> although, for this one particular purpose, inetd could have been sufficient
15 2012-09-24 00:08:33 <amiller> it's still hitting the database locked
16 2012-09-24 00:08:47 <amiller> there's one big lock around the leveldb
17 2012-09-24 00:09:01 <jgarzik> amiller: you'll just have to tolerate my idle rants about disliking gevent's model though ;p
18 2012-09-24 00:10:41 <amiller> so like 50% of the time is spent hitting the leveldb
19 2012-09-24 00:11:05 <amiller> quite a lot still in serialization
20 2012-09-24 00:11:15 <amiller> this is while catching up to a checkpoint
21 2012-09-24 00:11:25 <amiller> http://i.imgur.com/LJIBr.png
22 2012-09-24 00:13:07 <jgarzik> amiller: python copies data to hell and back
23 2012-09-24 00:14:03 <amiller> why is calcmerkle being called
24 2012-09-24 00:15:40 <amiller> ahaha i got it
25 2012-09-24 00:15:44 <amiller> efficient guided tour through the blockchain
26 2012-09-24 00:15:53 <amiller> so if you're validating a chain from scratch
27 2012-09-24 00:16:00 <amiller> rather than storing everything in a random access database
28 2012-09-24 00:16:11 <amiller> what you want to do is read from a stream
29 2012-09-24 00:16:18 <amiller> that gives you exactly the right data at exactly the right time
30 2012-09-24 00:16:52 <amiller> basically with every piece of information
31 2012-09-24 00:17:03 <amiller> you need to have an 'oracle' that predicts when you're going to need it next
32 2012-09-24 00:17:34 <gmaxwell> amiller: for a full validation you need all data twice, however. Once when it gets added to the chain, once when it's spent.
33 2012-09-24 00:17:42 <gmaxwell> Can only order data one way.
34 2012-09-24 00:17:43 <amiller> right but if you're catching up to the front
35 2012-09-24 00:17:48 <amiller> you know when both of those occur
36 2012-09-24 00:17:56 <amiller> so the first time you read it
37 2012-09-24 00:17:59 <amiller> you toss it out in front of you
38 2012-09-24 00:18:08 <amiller> you don't put it in a slow random access database
39 2012-09-24 00:18:13 <amiller> to be indexed and indexed forever
40 2012-09-24 00:19:36 <gmaxwell> One of the neat things a UTXO setup could do though??? have an on he wire protocol that gives you the O(1) positions with the txn, allowing you to save a bunch of local IO with a bit of network traffic..
41 2012-09-24 00:20:00 <gmaxwell> amiller: a hot-cache generally useful too, if you want to predict which transactions are more likely to be spent quickly.
42 2012-09-24 00:20:14 <jgarzik> amiller: keeping all block headers in RAM is not burdensome...
43 2012-09-24 00:20:41 <gmaxwell> Keeping all txouts in ram is not currently burdensom, in fact. :P
44 2012-09-24 00:20:51 <amiller> there's three things really
45 2012-09-24 00:20:54 <amiller> there's catching up to a checkpoint
46 2012-09-24 00:21:05 <amiller> there's catching up to the front from a checkpoint, validating along the way
47 2012-09-24 00:21:14 <amiller> and there's answering arbitrary tx validation questions about the current heat
48 2012-09-24 00:21:15 <amiller> head*
49 2012-09-24 00:21:27 <amiller> you need a random access utxo for answering arbitrary tx validation
50 2012-09-24 00:21:37 <amiller> you don't necessarily need one to catch up to the front from a checkpoint
51 2012-09-24 00:21:47 <jgarzik> don't focus so much on checkpoints
52 2012-09-24 00:21:53 <jgarzik> they are a hack, to speed things up
53 2012-09-24 00:22:09 <jgarzik> if signature checking was theoretically cost-free, we would not bother
54 2012-09-24 00:22:13 <amiller> hm
55 2012-09-24 00:22:45 <jgarzik> the other purpose of checkpoints -- to lock in block chain, preventing overly long reorg rewriting ancient history -- is largely a passive check
56 2012-09-24 00:23:20 <amiller> regardless, if you don't need a _random access_ utxo to do validation you can probably use a different structure
57 2012-09-24 00:23:26 <amiller> and get a gain in... parallelizability for validation there
58 2012-09-24 00:25:10 <gmaxwell> (To clarify jgarzik's 'passive check'??? the clear _threat_ of a checkpoint almostly costlessly mooting your enormous rewrite discourages investment in creating one.)
59 2012-09-24 00:26:16 <gmaxwell> they also stifel some stupid DOS attacks that will go away with header-sync.
60 2012-09-24 00:28:06 <amiller> checkpoints aren't a hack if you use them to make a backup or to clone new instances of your node
61 2012-09-24 00:28:29 <amiller> i'm not sure how i feel about letting you get away with the argument that it shouldn't be included because it makes it too easy to save time
62 2012-09-24 00:28:44 <amiller> and that there's a way of saving time that involves being vulnerable to trusting someone else
63 2012-09-24 00:29:07 <gmaxwell> amiller: well I fully support the self-backup case, its the trust that people simply don't have the information or patience to reason about.
64 2012-09-24 00:29:09 <amiller> how about a big warning, like the TSA, that says "are you sure you have previously validated this checkpoint yourself? have you ever relied on someone else to validate it for you?"
65 2012-09-24 00:29:40 <gmaxwell> amiller: that fails human factors; it will mostly get ignored; and when it doesn't it will stress out people.
66 2012-09-24 00:30:12 <gmaxwell> more-meta; things like that even if not ignored undermine trust in the system because people will expect them to be widely ignored.
67 2012-09-24 00:30:41 <gmaxwell> Better to just avoid the exposure; especially exposure created from really small microoptimizations.
68 2012-09-24 00:33:22 <amiller> how about this
69 2012-09-24 00:33:27 <amiller> validate the work of all the nodes, including your checkpoints
70 2012-09-24 00:33:44 <amiller> if there's a chain of headers with longer work, then switch to that or validate it concurrently or something
71 2012-09-24 00:35:26 <gmaxwell> amiller: ah, not influencing selection.. could call 'em amiller points. Only useful if you have the headers first. Might be a fine assumption.
72 2012-09-24 00:35:45 <gmaxwell> Certantly thats less of a concern.
73 2012-09-24 00:36:00 <amiller> honestly checkpoints written in the source code should undermine trust in the system more than anything else, it shows that the developers don't trust the users but expect the users to trust them
74 2012-09-24 00:36:25 <gmaxwell> degrades people to SPV security when they trust a random checkpoint found on the internet, not the end of the world.
75 2012-09-24 00:37:12 <gmaxwell> amiller: it's not about trusting the users. Its that the developers have actually spent non-trivial effort to understand and consider it, and most people haven't??? and if they have, it's trivial to twiddle the checkpoints in the source.
76 2012-09-24 00:37:39 <gmaxwell> amiller: moreover, it's not like we have automatic updates. Everyone still has to choose to install the software.
77 2012-09-24 00:38:00 <gmaxwell> (and of course, our ability to do malicious things in the software is otherwise unbounded except by that)
78 2012-09-24 00:38:23 <gmaxwell> s/install the software/install the update/
79 2012-09-24 00:38:35 <amiller> well the developers are only responsible for 'The Client'
80 2012-09-24 00:38:47 <gmaxwell> Yep. That too.
81 2012-09-24 00:38:58 <amiller> so it's a shame if more people use electrum or non-nodes because of 'The Client' being too restrictive
82 2012-09-24 00:39:09 <gmaxwell> I'm uncomfortable about the checkpoints; mostly because they're a distraction that complicates explaining the security model.
83 2012-09-24 00:39:31 <gmaxwell> amiller: you need to stop. you're getting annoying. :( You're obessing over minutia.
84 2012-09-24 00:39:42 <jgarzik> ah hah! just hit block 193,000. maybe my system will be usable again, upon switching from being disk-bound to CPU-bound
85 2012-09-24 00:40:14 <amiller> sorry, i don't really remember where i wandered off topic
86 2012-09-24 00:40:38 <gmaxwell> amiller: not having that option in the default software adds a not huge percentage of time in just the cases where the user might otherwise have some magic value. It's not worth the discussion we've had here about it. Certantly not compared to something like putting the whole sync in the background.
87 2012-09-24 00:42:35 <jgarzik> amiller: checkpoints will always be a pragmatic hack, not a key part of the security model
88 2012-09-24 00:42:53 <jgarzik> ACTION tends to be less aggressive about it than other devs, favoring a checkpoint no more recent than 6 months
89 2012-09-24 00:43:04 <amiller> i mean to just talk about checkpoints as a practical tool'
90 2012-09-24 00:43:12 <amiller> gmaxwell, you said something about the design needing to be completely changed or something like that
91 2012-09-24 00:43:19 <amiller> checkpoints are a way of understanding how background sync would work
92 2012-09-24 00:43:22 <gmaxwell> In the long term I hope the reference client, works like: new nodes should start as SPV??? so new users get instant-on, in the background pull the commited utxo set and become medium nodes, then pull the history when they get around it??? if they have the resources.
93 2012-09-24 00:43:27 <jgarzik> amiller: they can be helpful in validating reverse-header-sync
94 2012-09-24 00:43:32 <jgarzik> amiller: if you are coming at it from that angle
95 2012-09-24 00:43:37 <gmaxwell> amiller: I don't think checkpoints have any role in a background sync.
96 2012-09-24 00:44:01 <jgarzik> gmaxwell: you can know that the remote is wildly off-track at block 193,000
97 2012-09-24 00:44:24 <amiller> gmaxwell, see you left off the middle step
98 2012-09-24 00:44:31 <amiller> new users get instant on, but they're SPV so they can't validate transactions
99 2012-09-24 00:44:36 <amiller> nvm
100 2012-09-24 00:44:42 <amiller> you included the medium step and i didn't read it
101 2012-09-24 00:44:51 <amiller> yeah
102 2012-09-24 00:47:24 <gmaxwell> jgarzik: thats true. Fair. Though headers are so cheap...
103 2012-09-24 00:51:07 <jgarzik> woah! my pybond greenlets shite works better than the shite asyncore code with the shite asyncore
104 2012-09-24 00:51:25 <amiller> shits roses
105 2012-09-24 00:55:02 <jgarzik> amiller: pushed to pybond.git. credited you with the change, as it was mostly me porting over your code from your branch.
106 2012-09-24 00:55:26 <jgarzik> now to get the DHT converted to greenshite
107 2012-09-24 00:57:25 <amiller> you should backup your leveldb every so often, it can crash in an invalid state
108 2012-09-24 01:00:56 <jgarzik> amiller: for pynode, still on checkpoint+gdbm validation run :/
109 2012-09-24 01:25:52 <jgarzik> amiller: pybond DHT converted to greenlet. we should be good to go there.
110 2012-09-24 01:29:31 <amiller> hrm, badass would be to have the utxo on redis
111 2012-09-24 01:29:46 <jrmithdobbs> looks like there's finally onion-capable nodes beside me sipa and gmaxwell ;p
112 2012-09-24 01:32:04 <amiller> that will be fast and it will journal like a champ
113 2012-09-24 01:46:38 <jgarzik> gmaxwell: this requires protocol extensions, yes? https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
114 2012-09-24 01:47:02 <jgarzik> gmaxwell: current bitcoin only supports forward header walk, AFAICS
115 2012-09-24 01:48:22 <jrmithdobbs> looks like we've actually got some people bringing up brand new nodes with -onlynet=tor, glad to see that
116 2012-09-24 01:48:30 <jrmithdobbs> sipa: thanks for that, again
117 2012-09-24 03:21:20 <jgarzik> gah
118 2012-09-24 03:21:26 <jgarzik> the bitcoin P2P code is such shite
119 2012-09-24 03:21:46 <jgarzik> boost is verbose shite, but boost.asio would make bitcoin's shite less shitty
120 2012-09-24 03:21:57 <eian> lol
121 2012-09-24 03:22:45 <jgarzik> we create kernel threads just to open connections, then sleep for a long time. an easy task for async networking.
122 2012-09-24 03:42:46 <jgarzik> hmmm
123 2012-09-24 03:42:54 <jgarzik> I wonder if there is a way to make some coins "do not spend"
124 2012-09-24 03:43:01 <jgarzik> *mark
125 2012-09-24 03:43:35 <jgarzik> so that sendtoaddress/sendfrom does not wind up accidentally spending a smartcoin (colored coin)
126 2012-09-24 03:45:10 <jgarzik> lock/unlock coins, one could call it
127 2012-09-24 03:45:22 <Luke-Jr> that was one Coin Control use case
128 2012-09-24 03:45:36 <Luke-Jr> might be useful to label individual coins too
129 2012-09-24 05:12:46 <ThomasV> jgarzik: you can freeze some of your coins
130 2012-09-24 05:13:00 <jgarzik> ThomasV: oh?
131 2012-09-24 05:13:13 <ThomasV> right click + freeze
132 2012-09-24 05:13:23 <jgarzik> ThomasV: I'm using bitcoind
133 2012-09-24 05:13:44 <ThomasV> oh, sorry, I'm in the wrong channel. you can do that with Electrum :)
134 2012-09-24 05:17:35 <jeremias> oh that's cool, didn't know about that feature
135 2012-09-24 05:17:39 <jeremias> electrum rocks
136 2012-09-24 05:22:43 <ThomasV> jeremias: you can also prioritize some coins if you want them to be spent first
137 2012-09-24 05:24:29 <Luke-Jr> ThomasV: wrong channel? Electrum is on-topic here???
138 2012-09-24 05:30:04 <jeremias> ThomasV: so what's your situation nowadays, do you still develop electrum?
139 2012-09-24 05:30:14 <jeremias> or are you focusing on something new?
140 2012-09-24 05:33:16 <ThomasV> jeremias: I handed it over to genjix and Animazing
141 2012-09-24 05:33:37 <ThomasV> and yes, I am focusing on someething new
142 2012-09-24 05:33:56 <jeremias> bitcoin-related?
143 2012-09-24 05:34:00 <ThomasV> yes
144 2012-09-24 05:34:14 <jeremias> cool, is it secret? :)
145 2012-09-24 05:34:22 <ThomasV> no.. :)
146 2012-09-24 05:34:34 <ThomasV> a Diaspora node
147 2012-09-24 05:34:45 <jeremias> ahh yep, you told me about that already
148 2012-09-24 05:34:48 <jeremias> have to check it out
149 2012-09-24 05:34:53 <jeremias> when I have time :)
150 2012-09-24 05:35:04 <ThomasV> it's not finished now
151 2012-09-24 05:35:08 <jeremias> ok
152 2012-09-24 05:35:15 <jeremias> could I integrate that with localbitcoins?
153 2012-09-24 05:35:31 <jeremias> (I don't know the concept)
154 2012-09-24 05:35:34 <ThomasV> possibly. that's why I asked you about your api
155 2012-09-24 05:37:12 <ThomasV> you can have a look here: https://ecdsa.org/tags/bitcoin
156 2012-09-24 05:39:15 <ThomasV> but I still want to develop Electrum too
157 2012-09-24 05:39:34 <ThomasV> there are a few things that I plan to do for it
158 2012-09-24 05:39:52 <jeremias> I'm more interested towards developing some kind of "electrum utility" library
159 2012-09-24 05:40:00 <ThomasV> yes
160 2012-09-24 05:40:07 <jeremias> not a client, but a library which developers can use
161 2012-09-24 05:40:35 <ThomasV> well, you can see that there are a few scripts in the repo, but they are currently broken
162 2012-09-24 05:40:43 <jeremias> I'm generally interested more towards establishing libraries and utilities which could spawn a large bitcoin developer company
163 2012-09-24 05:40:48 <ThomasV> I want to fix them
164 2012-09-24 05:40:58 <jeremias> make it easy for everyone to make their own bitcoin website/service/etc
165 2012-09-24 05:41:09 <ThomasV> yes, a merchant solution
166 2012-09-24 05:42:18 <ThomasV> I have developed a script that uses a master public key and generates new bitcoin addresses for a website, and also detects payments
167 2012-09-24 05:42:30 <ThomasV> it's being used for my diaspora node
168 2012-09-24 05:42:37 <ThomasV> and I will add it to the repo
169 2012-09-24 05:43:05 <ThomasV> but I need to smooth it a little bit
170 2012-09-24 06:02:37 <lui_> Hi is it possible in bitcoin-qt 0.7.0 to add walletpath param or only -datadir?
171 2012-09-24 06:49:52 <_dr> iirc the wallet has to be in datadir for now, some restriction by DBD
172 2012-09-24 06:50:38 <Luke-Jr> bdb*
173 2012-09-24 06:50:54 <_dr> right :)
174 2012-09-24 07:00:08 <sturles> You could always make wallet.dat a symlink to your favourite location.
175 2012-09-24 10:48:35 <kjj_> is hopping on testnet really as simple as putting testnet=1 in the config file and changing the ports?
176 2012-09-24 10:52:18 <gavinandresen> kjj_: yes (-testnet=1 -rpcport=whatever is all you need)
177 2012-09-24 10:53:08 <kinlo> don't think you need to change the port tough...
178 2012-09-24 10:53:20 <kinlo> just putting testnet=1 should do the trick
179 2012-09-24 10:53:31 <gmaxwell> kinlo: you do it if you want to run it concurrently with a regular node.
180 2012-09-24 10:53:39 <kinlo> true
181 2012-09-24 10:53:43 <gavinandresen> "we" ought to change that
182 2012-09-24 10:54:22 <gmaxwell> Indeed. Didn't this question come up before? Why didn't we change it then?
183 2012-09-24 10:55:12 <gavinandresen> because "we" never got around to it....
184 2012-09-24 10:55:51 <gmaxwell> oh, good, just as long as it wasn't derailed by a long discussion of which port to use. :P
185 2012-09-24 10:56:51 <kjj_> need to duplicate the GetDefaultPort call in protocol.h?
186 2012-09-24 11:11:38 <kjj_> ok, silly question. in bitcoinrpc.cpp, there are two calls to GetArg for -rpcport, one takes 8332 as an integer, one takes it as a string
187 2012-09-24 11:11:53 <kjj_> ahh, never mind. I think I know what to do. overloading ftw
188 2012-09-24 11:21:13 <kjj_> ok, I guess you can't do that. two functions then
189 2012-09-24 11:42:02 <kjj_> hey, can someone look at a branch for me before I turn it into a pullreq?
190 2012-09-24 11:42:09 <kjj_> https://github.com/kjj2/bitcoin/commit/3733a29f2a00cfcf6754976763d45bd605e2865d
191 2012-09-24 11:55:59 <TD> BlueMatt: poke
192 2012-09-24 12:10:41 <gavinandresen> kjj_: NACK. const bool as a function argument doesn't make sense, you shouldn't strcpy to an uninitialized local variable, and there should be just one GetDefaultRPCPort that returns whatever datatype is most natural for a port (unsigned short ?)
193 2012-09-24 12:14:26 <kjj_> yeah, I noticed that when the segfaults started. not really a C++ guy, so I wasn't sure how to do it. also, spent too much time in languages that automatially handle memory allocation
194 2012-09-24 12:14:42 <kjj_> I'm switching it to std::string, which, after some googling looks right
195 2012-09-24 12:15:17 <gavinandresen> there should be just one GetDefaultRPCPort that returns an integral type
196 2012-09-24 12:15:32 <kjj_> what's the C++ idiom to cast the ushort into a std::string for the function that requires it?
197 2012-09-24 12:15:45 <gavinandresen> which function requires a string for port?
198 2012-09-24 12:16:02 <gavinandresen> ... and are you sure there's not an overloaded version that takes an unsigned int?
199 2012-09-24 12:16:02 <kjj_> d.connect() in bitcoinrpc.cpp
200 2012-09-24 12:17:06 <gavinandresen> util.h has an itostr() function
201 2012-09-24 12:17:08 <kjj_> it is hard to figure out what d is, because it is so hard to grep for, but the function only appears to exist in one form, taking a pair of const std::string& parameters
202 2012-09-24 12:17:34 <kjj_> ok, trying it with itostr
203 2012-09-24 12:17:58 <kjj_> spent too many years in PHP where you can just casually cast however you damn well please and the system figures it out for you like 99.99% of the time
204 2012-09-24 12:19:11 <gavinandresen> you should read a couple of C++ books if you want to do much C++ programming, otherwise you'll shoot yourself in the foot repeatedly
205 2012-09-24 12:19:58 <kjj_> heh. I know. I think I have some, just haven't dusted them off in years.
206 2012-09-24 12:21:46 <kjj_> make running. protocol.h touches everything, so it'll take a while.
207 2012-09-24 12:21:49 <kjj_> https://github.com/kjj2/bitcoin/commit/c744b8c1b930dc5c6e7eb079ace5793f64647d11
208 2012-09-24 12:27:45 <jgarzik> sipa gavinandresen: I would like to record the block height at which a wallet is "born" Is there a triggering event that may be used as a proxy for wallet creation time? Maybe watch for the first time the keypool is filled?
209 2012-09-24 12:28:50 <gmaxwell> http://www.ethlife.ethz.ch/archive_articles/120924_Neuer_Globe_Bitcoin_fw/index_EN ::hangs head::
210 2012-09-24 12:28:55 <gmaxwell> jgarzik: why the wallet and why not each key?
211 2012-09-24 12:29:12 <gmaxwell> (then the wallet age is just the oldest key's age)
212 2012-09-24 12:30:02 <kjj_> wow! a postdoc discovered the 0-conf double spend!
213 2012-09-24 12:30:19 <jgarzik> gmaxwell: so to have one record "earliest block height"
214 2012-09-24 12:30:37 <jgarzik> gmaxwell: wallet scans may start there, and you do not need full blocks below that
215 2012-09-24 12:31:20 <kjj_> going to add a parameter to importprivkey to set that height?
216 2012-09-24 12:32:12 <gmaxwell> kjj_: hopefully the actual research backing that is something not stupid. Sometimes the press, even the science press, simplifies things to the point of utter stupidity.
217 2012-09-24 12:32:33 <gavinandresen> jgarzik: putting a write-once wallet-creation-time in the wallet make sense. But it also makes sense to associate times with keys; if I import a private key, it might have been created before my wallet
218 2012-09-24 12:32:37 <gmaxwell> jgarzik: great, but thats a property of the keys, not the wallet itself??? see kjj's import example.
219 2012-09-24 12:33:36 <kjj_> gmaxwell: his attack seems to require that the recipient be unable to communicate to the full network.
220 2012-09-24 12:33:51 <gavinandresen> .... and I'd make it times, not block heights, because I think you might run into subtle bugs in weird re-org scenarios
221 2012-09-24 12:34:38 <gmaxwell> Time is something you also know offline and when you're not in sync. So that helps too.
222 2012-09-24 12:41:36 <gmaxwell> kjj_: I do think we don't give quite enough heed to isolation attack concerns... though they're still pretty fringe, as mining 6 sure to be orphaned blocks is hard to make profitable...
223 2012-09-24 12:42:33 <kjj_> meh. I'm sure that is right, but for now I have no problem expecting people that are accepting more than they can afford to lose to make sure they are well connected
224 2012-09-24 12:43:22 <gmaxwell> kjj_: sure but the software provides no facility for that. If the attacker has compromised your ISP or your router (not that high a bar...) then you can appear to have many connections to diverse hosts.
225 2012-09-24 12:43:55 <kjj_> then you need something signed, and/or out of band
226 2012-09-24 12:44:22 <kjj_> for example, https://blockexplorer.com/q/getblockcount
227 2012-09-24 12:45:09 <BlueMatt> TD: hey, re: subtraction looks backwards: yea, you are right, but make sure to test that on the bitcoind comparison tool, because I thought i had the final block size count right...
228 2012-09-24 12:45:25 <TD> hrm
229 2012-09-24 12:45:26 <TD> ok
230 2012-09-24 12:45:29 <BlueMatt> TD: (re: other stuff, sorry it may take me a day or two before I really have time to respond)
231 2012-09-24 12:45:29 <gavinandresen> gmaxwell: writing code that detects a statistically-impossible-in-normal-operation drop in hash rate and warns the user that something smelly fishy would be nifty
232 2012-09-24 12:45:32 <TD> no worries
233 2012-09-24 12:45:38 <gmaxwell> kjj_: in sidebar conversations I had with sipa and forrestv an idea arose which could be useful for that... what if nodes merged mined tokens that were {addr,pubkey} pairs for observed good nodes. Then when you connect to a node it would give you the lowest hash value POW header set for their identity.
234 2012-09-24 12:45:39 <kjj_> I think I figured out why no one ever bothered setting a default RPC port for testnet
235 2012-09-24 12:45:41 <TD> i'm reviewing the code now but i'll make most of the changes myself
236 2012-09-24 12:45:50 <TD> any comments that start with M: i'll fix when I merge as they're minor
237 2012-09-24 12:45:58 <BlueMatt> ack
238 2012-09-24 12:46:30 <TD> BlueMatt: how do i use your comparison tool? are there any docs?
239 2012-09-24 12:46:31 <kjj_> if you don't specify -rpcport, the RPC server doesn't accept connections, even though it binds to the port
240 2012-09-24 12:46:35 <gmaxwell> kjj_: so the idea with that is that you'd want at least one or two peers which were authenticated by a 'sufficiently' high work token.
241 2012-09-24 12:47:19 <gmaxwell> gavinandresen: indeed.. the fact that six blocks are needed to hit the confirmed status should make it reasonably easy to avoid false positives.
242 2012-09-24 12:47:57 <TD> you can also calculate "confirmedness" in terms of work done rather than blocks
243 2012-09-24 12:48:01 <BlueMatt> TD: uhh...not really, just checkout the fullscripts branch (iirc i broke it if you dont enforce script checking), apply the included patch to bitcoind, and run bitcoind -connect=0.0.0.0 -listen
244 2012-09-24 12:48:04 <TD> that's the direction i'm planning to eventually move bcj in
245 2012-09-24 12:48:17 <BlueMatt> TD: then just running the comparison tool should work
246 2012-09-24 12:48:21 <TD> BlueMatt: ok, thanks
247 2012-09-24 12:48:24 <TD> 0.0.0.0?
248 2012-09-24 12:48:27 <TD> you mean localhost?
249 2012-09-24 12:48:29 <BlueMatt> ie dont connect out
250 2012-09-24 12:48:31 <TD> oh
251 2012-09-24 12:48:40 <BlueMatt> (well, shouldnt matter, I think I changed the magic anyway)
252 2012-09-24 12:48:52 <TD> what does a PrunedException signify?
253 2012-09-24 12:49:07 <BlueMatt> I pruned that block, if you want to go request it from the network and try that operation again
254 2012-09-24 12:49:43 <BlueMatt> re: Stored*.java: yea, I believe I threw a //TODO: in there that just says "remove me/move me to the memoryfullprunedblockstore impl, which is all it matters for"
255 2012-09-24 12:49:58 <TD> ah ha
256 2012-09-24 12:50:01 <TD> i see
257 2012-09-24 12:50:06 <BlueMatt> (to make sure we dont waste too much memory when storing in memory)
258 2012-09-24 12:50:09 <TD> ok
259 2012-09-24 12:50:11 <TD> thanks
260 2012-09-24 12:50:42 <BlueMatt> Ill probably have some time on wednesday or thursday to hack around and fix bugs
261 2012-09-24 12:51:02 <TD> for now just replying to any comments that aren't M: labelled will help
262 2012-09-24 12:51:19 <BlueMatt> (note on PrunedException: I dont think the blockchain is actually smart enough to handle it, but in theory thats what a prunedexception means)
263 2012-09-24 12:51:35 <TD> ok
264 2012-09-24 12:51:39 <BlueMatt> is there a way to inline reply to comments?
265 2012-09-24 12:51:39 <TD> BlockWasPrunedException might be clearer
266 2012-09-24 12:51:48 <TD> you can comment on the same line and that'll do it, iirc
267 2012-09-24 12:51:50 <BlueMatt> ack, if you want to refactor that
268 2012-09-24 12:51:51 <TD> google code isn't great
269 2012-09-24 12:51:53 <TD> yeah, sure
270 2012-09-24 12:53:43 <kjj_> ok, testnet=1, rpcport is not specified, server=1. p2p opens on port 18333 as expected, RPC opens on port 18332, but only on ipv6
271 2012-09-24 12:55:34 <kjj_> testnet also seems to have no fallback nodes, so nothing connects when irc=0
272 2012-09-24 12:55:46 <gmaxwell> kjj_: you sure it's only on IPv6? a v6 socket also accepts v4 connections.
273 2012-09-24 12:56:01 <gmaxwell> kjj_: correct, testnet defaults to irc enabled for a reason (while mainnet does not)
274 2012-09-24 12:56:16 <kjj_> hmm. I didn't even think my box knew about ipv6, so I was a bit shocked to see tcp6 in the netstat
275 2012-09-24 12:57:18 <kjj_> ok yeah, it is accepting connections
276 2012-09-24 12:57:39 <kjj_> but for some reason, it isn't setting the default port when making the RPC call to the running server
277 2012-09-24 12:58:49 <TD> BlueMatt: in the reorg code, when walking newBlocks in chronological order why are they being added to the block store (again)?
278 2012-09-24 12:59:56 <TD> ah right
279 2012-09-24 13:00:03 <TD> you re-arranged things so it's not been added to the store by that point
280 2012-09-24 13:02:38 <BlueMatt> TD: how do I save comments from draft to comments?
281 2012-09-24 13:03:04 <TD> on the main change screen there's a publish link
282 2012-09-24 13:03:37 <BlueMatt> ah, see it, one sec
283 2012-09-24 13:03:39 <jgarzik> hrm
284 2012-09-24 13:03:46 <jgarzik> how does CKeyPool READWRITE nVersion
285 2012-09-24 13:03:52 <jgarzik> ...when there is no nVersion in the struct?
286 2012-09-24 13:10:01 <BlueMatt> nVersion is defined as a part of the call to Serialize iirc
287 2012-09-24 13:10:03 <BlueMatt> jgarzik: ^
288 2012-09-24 13:11:34 <kjj_> hmm. ok, found the problem, but not the answer. when starting up as a RPC client, the software doesn't appear to fully process the bitcoin.conf file, so it doesn't know that it is on testnet, thus it chooses the wrong default RPC port
289 2012-09-24 13:12:15 <TD> BlueMatt: for the comparison tool, do I need to run it against prodnet/with a fresh/empty wallet or can I just use my regular user install of bitcoin for it
290 2012-09-24 13:12:58 <BlueMatt> TD: no, it has to be the custom net that the patch creates (I havent mined the blocks yet, so it requires a patch to make a lower mindiff)
291 2012-09-24 13:13:07 <TD> oh right, yes, the patch.
292 2012-09-24 13:13:08 <TD> got it
293 2012-09-24 13:16:01 <arij> hey did the september announcement happen yet?
294 2012-09-24 13:16:13 <BlueMatt> yes, bitcoin has been sold to the nsa for $1 bill
295 2012-09-24 13:16:36 <gavinandresen> kjj_: I don't believe you, the bitcoin.conf is definitely 'fully processed' when starting up as a RPC client.
296 2012-09-24 13:16:52 <gavinandresen> BlueMatt: shhh, not supposed to talk about that until tomorrow
297 2012-09-24 13:17:01 <BlueMatt> oh, sorry
298 2012-09-24 13:17:14 <arij> :(
299 2012-09-24 13:17:17 <arij> so i guess not
300 2012-09-24 13:17:27 <arij> if you are annoucing tomorrow ?
301 2012-09-24 13:17:58 <gavinandresen> arij: there are still a bunch of days left in September
302 2012-09-24 13:18:24 <arij> yea but you just said tomorrow,
303 2012-09-24 13:18:31 <arij> but yea there are 6 days left in september
304 2012-09-24 13:18:41 <gavinandresen> I also said that we're selling to the nsa for $1
305 2012-09-24 13:18:44 <arij> lol
306 2012-09-24 13:18:45 <arij> ok
307 2012-09-24 13:18:48 <arij> ill just wait
308 2012-09-24 13:19:00 <kjj_> gavinadresen: my patch sets the RPC port correctly when run as a RPC server, but returns 8332 when run as a RPC client
309 2012-09-24 13:19:37 <kjj_> the call only depends on fTestNet
310 2012-09-24 13:20:29 <gavinandresen> kjj_: then your patch has a bug. Put a breakpoint in GetDefaultRPCPort and see where it is being called from; if it is called from a global constructor then fTestNet won't have been set uyet
311 2012-09-24 13:22:44 <gavinandresen> kjj_: ah, I think I see the problem. CommandLineRPC is called from AppInit(). fTestNet is set in AppInit2()
312 2012-09-24 13:23:22 <gavinandresen> ... because if you're just a rpc client there's no need to do all the startup stuff AppInit2 does.
313 2012-09-24 13:23:57 <gavinandresen> kjj_: so to fix, call GetBoolArg("-testnet", false) instead of relying on the fTestNet flag
314 2012-09-24 13:24:37 <kjj_> but I need the actual value of the -testnet flag
315 2012-09-24 13:24:45 <kjj_> or of fTestNet
316 2012-09-24 13:25:02 <gavinandresen> GetBoolArg("-testnet") is the value of the -testnet flag.
317 2012-09-24 13:25:37 <kjj_> ahh, ok. I get it. the arg is set up, but the flag that gets set from the arg isn't yet
318 2012-09-24 13:25:53 <kjj_> wouldn't it make more sense to move the fTestNet setting up into AppInit ?
319 2012-09-24 13:26:06 <TD> BlueMatt: i assume i should find a miner tool and make it cpu mine as well?
320 2012-09-24 13:26:37 <gavinandresen> kjj_: I'd rather keep all of the parameter interactions in one place, in AppInit2
321 2012-09-24 13:27:08 <BlueMatt> TD: it sets min diff to just the first bit, so the built-in test-case miner is used (and works fine)
322 2012-09-24 13:27:22 <TD> cool
323 2012-09-24 13:27:23 <kjj_> should I change GetDefaultPort the same way?
324 2012-09-24 13:27:40 <BlueMatt> TD: (once its pretty solid, Ill go mine it and put in real nonce's...)
325 2012-09-24 13:28:22 <gavinandresen> kjj_: fewer changes is better. RPC client doesn't care about the p2p network port....
326 2012-09-24 13:29:00 <TD> BlueMatt: seems that you missed a commit somewhere, import org.apache.commons.lang.SystemUtils; doesn't work
327 2012-09-24 13:29:05 <TD> i guess there's a pom that needs updating
328 2012-09-24 13:29:12 <TD> in BlockImporter
329 2012-09-24 13:29:22 <BlueMatt> hmm...
330 2012-09-24 13:29:47 <BlueMatt> I dont think I missed a commit, but I may have imported something then forgot to add it to the pom in a commit...
331 2012-09-24 13:30:12 <TD> could be
332 2012-09-24 13:30:50 <BlueMatt> where do you see that import?
333 2012-09-24 13:30:52 <TD> seems the comparison tool doesn't work for me
334 2012-09-24 13:30:54 <BlueMatt> oh, wait
335 2012-09-24 13:31:14 <TD> it gets up to block 113 and re-orgs to 112
336 2012-09-24 13:31:17 <TD> then stops
337 2012-09-24 13:31:26 <TD> oh, no it's ok
338 2012-09-24 13:31:38 <TD> seems like it just stopped for a while for some reason
339 2012-09-24 13:31:48 <BlueMatt> there is one HUGE block in there
340 2012-09-24 13:31:55 <BlueMatt> but I thought I disabled it by default...
341 2012-09-24 13:32:22 <TD> the one with a ton of non standard transactions?
342 2012-09-24 13:32:32 <BlueMatt> yea
343 2012-09-24 13:32:44 <TD> yeah looks like it was crunching on that
344 2012-09-24 13:32:47 <BlueMatt> there is one like that that has 1 more sig (in theory) than MAX_BLOCK_SIGOPS, so it shouldnt be processing
345 2012-09-24 13:32:53 <TD> ok cool
346 2012-09-24 13:32:55 <BlueMatt> then there is one that (I thought was disabled) that has one less
347 2012-09-24 13:32:56 <TD> the tool works
348 2012-09-24 13:35:01 <TD> BlueMatt: another question .... in ChildMessage.adjustLength why is the parent.adjustLength call using 0 as the newArraySize instead of passing through the parameter?
349 2012-09-24 13:35:54 <BlueMatt> ah, thats it, addExpensiveBlocks is set in the comparison tool,but not in the regular test-cases by default
350 2012-09-24 13:36:18 <BlueMatt> TD: because you would end up adding that extra byte twice, I believe?
351 2012-09-24 13:36:54 <BlueMatt> TD: give me about 30 minutes and I nock out some of these comments (need to finish up some classwork real quick)
352 2012-09-24 13:37:00 <TD> hmm. adjustLength is incrementing the length of the child, and then you want to increment the parent size by the same amount, right
353 2012-09-24 13:38:18 <TD> BlueMatt: where is the repeated increment?
354 2012-09-24 13:38:33 <TD> the parents length has to increase by exactly the same amount as the childs, right
355 2012-09-24 13:38:44 <BlueMatt> (sorry, I wasnt looking at the code, you may be right)
356 2012-09-24 13:40:12 <BlueMatt> TD: yea, you're probably right...Ill take a look and redo that lengh prefix code stuff later this week, it smells quite broken
357 2012-09-24 13:40:25 <TD> the whole length caching thing is pretty questionable, tbh
358 2012-09-24 13:40:39 <TD> it was written by shads when he was churning out a ton of code to make bitcoinj support high performance proxy servers
359 2012-09-24 13:40:48 <BlueMatt> (too much test-driven development there...)
360 2012-09-24 13:40:51 <TD> he went pretty deep with the micro optimizations
361 2012-09-24 13:41:17 <TD> well it's ok that's why we have code review as well :)
362 2012-09-24 13:42:40 <TD> inverting the subtraction doesn't change the pass/fail of the test
363 2012-09-24 13:42:51 <TD> i suspect the calculated length is getting thrown away later, but i'll use the fixed code anyway
364 2012-09-24 13:46:40 <BlueMatt> TD: odd, because the test was failing until I added that commit...
365 2012-09-24 13:47:07 <BlueMatt> anyway...it needs further analysis (or was the test failing only something like 1/3 of the time or something due to differences in sig length?)
366 2012-09-24 13:47:16 <TD> hmm
367 2012-09-24 13:47:30 <TD> well i'm not denying the commit is required
368 2012-09-24 13:47:44 <TD> just that it appears to contain bugs that make it do the wrong thing. unfortunately they may be of a form that cancel each other out or something weird like that
369 2012-09-24 13:47:48 <TD> but yes, please do analyze further :)
370 2012-09-24 13:47:59 <BlueMatt> yea, it does look very broken...
371 2012-09-24 13:48:08 <BlueMatt> anyway, Ill redo that one entirely
372 2012-09-24 13:48:27 <kjj_> gavinandresen: that worked
373 2012-09-24 13:49:35 <TD> ok
374 2012-09-24 13:49:40 <TD> then i'll wait
375 2012-09-24 13:54:55 <BlueMatt> TD: Im marking comments that I should follow up on and change something with TODO, fyi
376 2012-09-24 13:55:17 <TD> ok
377 2012-09-24 14:08:10 <TD> something that was pointed out to me today - given we need full nodes in future, making bitcoin-qt have lots of cool graphs and bling about what it's doing would encourage people to leave it running
378 2012-09-24 14:08:16 <jgarzik> ACTION posts his evil landlord story on the off-topic Rental Investment thread, https://bitcointalk.org/index.php?topic=112320.msg1216688#msg1216688
379 2012-09-24 14:08:18 <TD> and make it explicit that by running the software you're contributing to the network
380 2012-09-24 14:08:22 <jgarzik> TD: agreed
381 2012-09-24 14:08:37 <TD> i think it's a good idea, though it could make the software seem more intimidating for regular users (temporarily)
382 2012-09-24 14:10:17 <BlueMatt> TD: absolutely! now who wants to implement it?
383 2012-09-24 14:11:29 <TD> :)
384 2012-09-24 14:11:39 <TD> just throwing it out there .... maybe diapolo or another gui hacker would find it fun
385 2012-09-24 14:12:55 <arij> what is the maximum the difficulty can increase
386 2012-09-24 14:12:59 <arij> in one period
387 2012-09-24 14:13:07 <arij> i forget how many blocks that was
388 2012-09-24 14:13:21 <epscy> 2016
389 2012-09-24 14:13:28 <arij> 2016 blocks
390 2012-09-24 14:13:41 <fiesh_> with having bitcoind/qt-bitcoin run constantly -- I found it quite annoying that it is basically impossible to link it statically, making running it chrooted much more work
391 2012-09-24 14:13:42 <arij> so what is the maximum the diff can increase ?
392 2012-09-24 14:13:56 <arij> in a 2016 block interval
393 2012-09-24 14:14:01 <arij> unlimited?
394 2012-09-24 14:14:11 <arij> or is it a maximum % ?
395 2012-09-24 14:14:26 <fiesh_> (bitcoind that is of course, without the qt)
396 2012-09-24 14:14:54 <BlueMatt> arij: there is a limit iirc, but I have no clue what it is now...
397 2012-09-24 14:14:54 <epscy> isn't one of them unbounded (increase or descrease), can't remember which though
398 2012-09-24 14:14:57 <BlueMatt> arij: its some %
399 2012-09-24 14:15:02 <arij> i see
400 2012-09-24 14:15:12 <BlueMatt> epscy: I thought both, but Im fuzzy on the details...
401 2012-09-24 14:15:15 <arij> but i need to find out
402 2012-09-24 14:15:28 <epscy> ask gmaxwell
403 2012-09-24 14:15:38 <epscy> gmaxwell: we neeeeeed you
404 2012-09-24 14:15:42 <BlueMatt> fiesh_: huh? we do the releases statically, see what we have for the release build args...
405 2012-09-24 14:15:53 <arij> we neeeeeeeeeed you
406 2012-09-24 14:15:58 <BlueMatt> fiesh_: like STATIC=1 or RELEASE=1 or something like that should work?
407 2012-09-24 14:15:59 <arij> :)
408 2012-09-24 14:16:01 <fiesh_> BlueMatt: really? I didn't realize, thanks, will take a look
409 2012-09-24 14:16:04 <BlueMatt> arij: search the wiki?
410 2012-09-24 14:16:12 <BlueMatt> arij: or search main.cpp ;)
411 2012-09-24 14:16:20 <fiesh_> BlueMatt: oh, heh, then my bad, never mind ;)
412 2012-09-24 14:16:49 <arij> no i need some one to answer it here
413 2012-09-24 14:17:10 <epscy> careful that you don't stare into statoshis code too long, because at the same time he stares back at you
414 2012-09-24 14:17:28 <BlueMatt> arij: "Im incapable of searching for the answer myself" doesnt inspire people to search for the answer for you ;)
415 2012-09-24 14:17:56 <arij> i dont need some one to search
416 2012-09-24 14:18:00 <arij> just some one who knows the answer
417 2012-09-24 14:18:03 <arij> to answer
418 2012-09-24 14:18:14 <arij> :)
419 2012-09-24 14:18:16 <arij> i can wait
420 2012-09-24 14:18:32 <epscy> the wiki needs a FAQ interface
421 2012-09-24 14:18:40 <epscy> this stuff comes up too often
422 2012-09-24 14:22:09 <JyZyXEL> how do you calculate how much a certain hash rate will increase difficulty in a certain timeframe?
423 2012-09-24 14:24:08 <devrandom> hey BlueMatt
424 2012-09-24 14:28:09 <weex> JyZyXEL: hashrates are just estimates based on difficulty and avg time to find a block
425 2012-09-24 14:28:18 <weex> so you would do it on a relative basis
426 2012-09-24 14:35:11 <TD> hey devrandom
427 2012-09-24 14:35:22 <JyZyXEL> like if 50TH/s of hashing power was added today, what would the difficulty be in a month?
428 2012-09-24 14:35:40 <JyZyXEL> that kind of calculation
429 2012-09-24 14:35:52 <BlueMatt> hey devrandom
430 2012-09-24 14:40:39 <devrandom> hey TD, congrats on 0.6
431 2012-09-24 14:41:00 <TD> thanks. it took long enough, i didn't have much coding time lately
432 2012-09-24 14:41:02 <TD> well also it was summer :-)
433 2012-09-24 14:41:16 <TD> think you'll get any time for bcj in the next few months?
434 2012-09-24 14:43:31 <helo> JyZyXEL: https://en.bitcoin.it/wiki/Difficulty
435 2012-09-24 14:45:29 <TD> ACTION -> out
436 2012-09-24 14:49:28 <JyZyXEL> oh so i can directly take my target hashrate and see what the difficulty would adjust to with that rate?
437 2012-09-24 14:53:07 <gavinandresen> Anybody know off the top of their heads what will get sent to the bitcoin process if I create a link that is: <a href="bitcoin:...address..?message=Message+With%20Spaces">
438 2012-09-24 14:53:53 <gavinandresen> Or, in other words, when browsers pass off URLs to the bitcoin: handler do they do any url decoding first?
439 2012-09-24 14:54:24 <JyZyXEL> 0xffff * 2**208
440 2012-09-24 14:54:31 <JyZyXEL> what operation is "**"
441 2012-09-24 14:54:44 <gavinandresen> JyZyXEL: exponentiation
442 2012-09-24 14:54:59 <JyZyXEL> you mean 2^208?
443 2012-09-24 14:55:03 <gavinandresen> yeah
444 2012-09-24 14:56:19 <JyZyXEL> 22012.4941572 * 2^32 / 600 = 157571570847.608471552
445 2012-09-24 15:08:19 <JyZyXEL> so for the current difficulty (28641400.507811) to double (57282801.015622) a hashrate of: 57282801.015622 * 2^32 / 600 would be needed?
446 2012-09-24 15:08:48 <JyZyXEL> that would be ~410TH/s
447 2012-09-24 15:12:24 <gmaxwell> Your difficulty figure is wrong.
448 2012-09-24 15:13:02 <gmaxwell> JyZyXEL: current difficulty is 2864140.50781097
449 2012-09-24 15:13:47 <JyZyXEL> otherwise it wasn't completely wrong?
450 2012-09-24 15:14:36 <JyZyXEL> im trying to calculate myself out of the idea of wasting 1000EUR for the asic haha :p
451 2012-09-24 15:16:16 <gmaxwell> JyZyXEL: the current difficulty has nothing to do with the difficulty after the existance of asic mining products.
452 2012-09-24 15:17:19 <JyZyXEL> i just used it as an example
453 2012-09-24 15:43:43 <jgarzik> wonder if we store bitcoind uptime (node start time) anywhere?
454 2012-09-24 15:56:08 <amiller> jgarzik, the 'stuff absolutely everything in a leveldb' approach seems to degrade around 190k for me, how far did you get?
455 2012-09-24 15:56:52 <gavinandresen> jgarzik: doesn't the OS keep track of process start time?
456 2012-09-24 15:57:09 <jgarzik> amiller: did you add in the checkpoint change?
457 2012-09-24 15:57:27 <amiller> jgarzik, yeah, even with checkpoints i didn't get past 193k or so overnight
458 2012-09-24 15:58:42 <jgarzik> gavinandresen: it does on Linux... damned if I recall the syscall to get it ATM
459 2012-09-24 15:58:55 <gavinandresen> jgarzik: quick google turns up http://linuxcommando.blogspot.com/2008/09/how-to-get-process-start-date-and-time.html
460 2012-09-24 15:59:34 <jgarzik> gavinandresen: yeah read the last line of that blog post ;p
461 2012-09-24 15:59:44 <jgarzik> gavinandresen: I doubt we want bitcoin processing "ps" output or /proc
462 2012-09-24 16:00:14 <gavinandresen> agreed. I'd vote to leave the feature out entirely, and let people who want to know read ps or /proc output....
463 2012-09-24 16:00:37 <gavinandresen> (or do you need to know the process start time for some internal reason?)
464 2012-09-24 16:08:43 <jgarzik> gavinandresen: Just updated mempool pull request to reference it... https://github.com/bitcoin/bitcoin/pull/1833
465 2012-09-24 16:09:01 <jgarzik> gavinandresen: we already query and log node start time
466 2012-09-24 16:09:11 <jgarzik> amiller: so
467 2012-09-24 16:09:27 <jgarzik> amiller: I got impatient and turned off sig checking. I was CPU-bound, not disk bound, with GDBM ;p
468 2012-09-24 16:09:40 <jgarzik> amiller: turned sig checking back on for last 2000 blocks
469 2012-09-24 16:16:11 <amiller> jgarzik, right now i'm trying out the flat file for blockdata and everything else in the leveldb
470 2012-09-24 16:17:05 <jgarzik> amiller: certainly will help. the only thing we really _need_ a database for is the tx index
471 2012-09-24 16:17:17 <jgarzik> amiller: everything else could be flat file
472 2012-09-24 17:30:36 <jgarzik_> Claimed email from SEC to various parties, RE BS&T: http://pastebin.com/3ZXYMmwr, from thread https://bitcointalk.org/index.php?topic=112404.0
473 2012-09-24 17:32:43 <Hasimir> jgarzik_, the author of the email is listed on LinkedIn as in the SEC's enforcement division
474 2012-09-24 17:32:54 <kjj_> looks legit. give me a minute to grab some popcorn
475 2012-09-24 17:33:23 <Hasimir> the IP in the headers matches the SEC's servers too
476 2012-09-24 17:33:41 <kjj_> meh. easy to fake
477 2012-09-24 17:34:05 <kjj_> not saying the emails aren't real, but slapping in two bits of public data doesn't make them real either
478 2012-09-24 17:34:58 <jgarzik_> indeed
479 2012-09-24 17:35:03 <phungus> it doesn't sound unreasonable
480 2012-09-24 17:35:13 <Hasimir> well, I guess we'll know soon enough
481 2012-09-24 17:35:13 <phungus> the SEC is charged with investigating securities law violations
482 2012-09-24 17:36:54 <jgarzik_> another thread, "Got off the phone with the Guy from the S.E.C", https://bitcointalk.org/index.php?topic=112438.0
483 2012-09-24 17:37:27 <kjj_> no wonder no one else could get through, that dude was hogging it
484 2012-09-24 17:38:45 <kjj_> ooh. the blowback might hit GLBSE too, according to the unsubstantiated rumor
485 2012-09-24 17:41:10 <_dr> what's that bit about butterfly labs supposed to be?
486 2012-09-24 17:41:16 <Hasimir> it's all very interesting
487 2012-09-24 17:41:55 <kjj_> my guess on the BFL part was summed up quite well by this comment: https://bitcointalk.org/index.php?topic=112438.msg1217173#msg1217173
488 2012-09-24 17:44:42 <kjj_> wow. today was quite exciting on As the Bitcoin Turns.
489 2012-09-24 17:47:53 <helo> the next episode should be even better
490 2012-09-24 17:57:09 <sebicas> Yes, here is a copy of the email I received today from the SEC http://pastie.org/4791945
491 2012-09-24 17:57:26 <sebicas> I think they got my email from the GPG Signature in Bitcoin OTC
492 2012-09-24 18:04:15 <jgarzik_> TD, amiller: pybond P2P+DHT network should go live "in a few days"
493 2012-09-24 18:04:37 <jgarzik_> TD: it should be applicable to any smart property tracked by a coin, not just bonds
494 2012-09-24 18:04:57 <TD> nice!
495 2012-09-24 18:05:04 <TD> looking forward to it
496 2012-09-24 18:05:06 <kjj_> no more stock exchanges then?
497 2012-09-24 18:05:11 <jeremias> hmm I keep getting "Fatal error, run database recovery"
498 2012-09-24 18:05:23 <jeremias> (is this wrong channel to ask)
499 2012-09-24 18:05:35 <jeremias> deleted everything except wallet.dat and started again
500 2012-09-24 18:05:37 <jeremias> still get it
501 2012-09-24 18:05:39 <jeremias> 0.7.0
502 2012-09-24 18:05:59 <kjj_> when you closed down your previous version, did you detach?
503 2012-09-24 18:06:08 <jeremias> hmm not sure
504 2012-09-24 18:06:12 <jeremias> probably not
505 2012-09-24 18:06:17 <jeremias> probably closed abruptly
506 2012-09-24 18:06:24 <kjj_> do you still have the old version around?
507 2012-09-24 18:06:33 <jeremias> hmm yep
508 2012-09-24 18:06:51 <kjj_> I *think* the fastest recovery will be to add detachdb=1 to your bitcoin.conf, start the old version, stop it, wait for it to end fully
509 2012-09-24 18:06:57 <kjj_> and then do the upgrade
510 2012-09-24 18:07:32 <jeremias> hmm
511 2012-09-24 18:07:40 <jeremias> get the database error with old version as well
512 2012-09-24 18:07:52 <kjj_> hmm. take a look in your db.log file
513 2012-09-24 18:08:09 <jeremias> hmm ok
514 2012-09-24 18:08:12 <jeremias> unsupported version
515 2012-09-24 18:08:13 <kjj_> and your debug.log
516 2012-09-24 18:08:25 <jeremias> ok now I'll delete the data again, then restart
517 2012-09-24 18:08:38 <kjj_> hang on, what exactly are you deleting?
518 2012-09-24 18:09:02 <jeremias> everything except wallet.dat and bitcoin.conf
519 2012-09-24 18:09:08 <kjj_> as in, are you including the log.* files in the database/ directory?
520 2012-09-24 18:09:24 <jeremias> it complains about the log files, should I delete only them?
521 2012-09-24 18:09:48 <jeremias> the problem was probably because I had erronously started very old bitcoind, the one supplied by ubuntu
522 2012-09-24 18:09:54 <jeremias> 0.3 or something
523 2012-09-24 18:09:57 <kjj_> well, if you've already nuked things, do them all
524 2012-09-24 18:10:23 <kjj_> not your wallet.dat, of course. keep that one, and make a backup copy or two
525 2012-09-24 18:11:20 <jeremias> yeah, I have backups as well, but I'll try recovering this now
526 2012-09-24 18:13:03 <jeremias> hmm still not working with any of the versions
527 2012-09-24 18:13:09 <jeremias> shit
528 2012-09-24 18:13:16 <jeremias> maybe I'll try digging the backup
529 2012-09-24 18:14:22 <kjj_> what version is your wallet from? is that from the old 0.3 version?
530 2012-09-24 18:14:33 <jeremias> I upgraded from 0.6.3
531 2012-09-24 18:14:41 <jeremias> but I think I accidentally started 0.3
532 2012-09-24 18:15:12 <kjj_> ok, yeah. toss a fresh copy of the backup in there, make sure everything else except wallet.dat and bitcoin.conf are gone, then try starting 0.7.0
533 2012-09-24 18:16:02 <jeremias> and another sad thing, no backup
534 2012-09-24 18:16:06 <jeremias> because it was dropbox
535 2012-09-24 18:16:17 <kjj_> doh!
536 2012-09-24 18:16:19 <jeremias> truecrypt + dropbox
537 2012-09-24 18:16:30 <kjj_> ok, you still have your current file though, right?
538 2012-09-24 18:16:33 <jeremias> yeah
539 2012-09-24 18:16:41 <jeremias> but bitcoind doesn't start with it
540 2012-09-24 18:16:47 <kjj_> had you set a password on it?
541 2012-09-24 18:16:52 <jeremias> no
542 2012-09-24 18:16:54 <kjj_> (encrypted your wallet)
543 2012-09-24 18:17:00 <jeremias> unencrypted on truecrypt
544 2012-09-24 18:17:11 <jeremias> my method was that I only opened it when I needed it
545 2012-09-24 18:17:13 <kjj_> ok, go get pywallet
546 2012-09-24 18:17:33 <kjj_> use pywallet to dump your keys out
547 2012-09-24 18:17:39 <jeremias> ok
548 2012-09-24 18:18:00 <kjj_> make a copy of that file, damaged or not
549 2012-09-24 18:20:01 <jeremias> seemed to output the keys without problems
550 2012-09-24 18:20:42 <kjj_> ok, now what you are going to do is double check that you have a copy of that file somewhere else, then delete everything from your bitcoin directory except for the bitcoin.conf file, start 0.7.0 and let it catch up
551 2012-09-24 18:20:52 <kjj_> then import your keys using the importprivkey RPC command
552 2012-09-24 18:21:09 <kjj_> or maybe there is a GUI way to do that last step, I don't use the GUI, so I have no idea
553 2012-09-24 18:21:25 <kjj_> importing the keys will take a long time, but hopefully you'll end up with all of your coins back
554 2012-09-24 18:21:32 <jeremias> I don't use GUI as well
555 2012-09-24 18:21:34 <jeremias> yeah...
556 2012-09-24 18:21:46 <jeremias> thanks for the help