1 2012-11-13 00:04:55 <MC-Eeepc> it really uses md5?
  2 2012-11-13 01:13:10 <Diablo-D3> you know
  3 2012-11-13 01:13:16 <Diablo-D3> I think this month is DiabloMiner's birthday
  4 2012-11-13 01:14:25 <Diablo-D3> Date:   Sat Nov 6 11:16:17 2010 -0400
  5 2012-11-13 01:38:27 <forrestv> happy birthday, first miner i used
  6 2012-11-13 01:39:01 <Diablo-D3> I really should hurry up working on Seaking so I can port DM to it
  7 2012-11-13 01:39:09 <Diablo-D3> and then I can add fpga and asic support
  8 2012-11-13 02:19:49 <InabaEMC> Hey Slush.. does the Stratum protocol require an update every 1 minute or 2?  I'm trying to get Stratum working on EMC but having some troubles.
  9 2012-11-13 02:35:38 <phantomcircuit> so why is leveldb so much faster than bdb?
 10 2012-11-13 02:35:45 <phantomcircuit> because this is really *much* faster
 11 2012-11-13 02:36:29 <Diablo-D3> because bdb was never meant for this kind of shit
 12 2012-11-13 02:41:52 <ThomasV> how much faster is it?
 13 2012-11-13 02:44:06 <Luke-Jr> lol
 14 2012-11-13 02:44:30 <jgarzik> phantomcircuit: it's more usage pattern than raw muscle
 15 2012-11-13 02:44:42 <jgarzik> phantomcircuit: plus leveldb is not strictly ACID
 16 2012-11-13 02:46:31 <gmaxwell> phantomcircuit: either leveldb or ultraprune alone got much of the performance benefit; though combined it's faster.  (ultraprune because it reduced the database working size substantially, and leveldb because it isn't slow)
 17 2012-11-13 02:48:11 <phantomcircuit> jgarzik, heh well durability isn't really important except for private keys
 18 2012-11-13 02:48:12 <gmaxwell> Garr244 are you attempting to fuzz test someone's bot?
 19 2012-11-13 02:48:13 <jgarzik> leveldb "isn't slow" in the same way IDE drives "aren't slow"... they relax flushing semantics :)
 20 2012-11-13 02:48:40 <phantomcircuit> the on disk information is really effectively a cache for the network
 21 2012-11-13 02:48:58 <gmaxwell> jgarzik: meh, we used transactions in bdb that didn't depend on instant flushing.
 22 2012-11-13 02:51:03 <Luke-Jr> gmaxwell: but bdb still demanded it from the OS
 23 2012-11-13 02:53:27 <Garr244> gmaxwell, nah just variants of my name under my account -- someone was using "gar255" on -otc
 24 2012-11-13 02:53:32 <Garr244> sorry for the spam :P
 25 2012-11-13 03:16:15 <MC-Eeepc> http://timekoin.org/images/documents/timekoin.pdf
 26 2012-11-13 03:16:32 <MC-Eeepc> is that the guy who got raided by he fedz for the romny thing
 27 2012-11-13 03:27:51 <jgarzik> gmaxwell: BDB does far more than just flushing.  OS-aligned blocks, separate log files, a lot of little details that are critical for big iron database servers.  Tries to protect against app and OS crashes both.
 28 2012-11-13 03:28:08 <jgarzik> leveldb just ignores a lot of those details, and since we use it as a cache of public data, that's just fine.
 29 2012-11-13 03:29:09 <jgarzik> Google's leveldb and bitcoin's leveldb use are similar:  avoid the need for "recovery", rather than building a recoverable database
 30 2012-11-13 03:30:08 <jgarzik> detecting a failure is sufficient
 31 2012-11-13 04:07:17 <robbak> Here's a problem I have building bitcoin: src/db.h clashes with the BDB's C include /usr/local/include/db48/db.h, whick is in the same dir as the c++ db_cxx.h.
 32 2012-11-13 04:08:15 <robbak> I'm working around this by patching transactiondesc.cpp to #include "walletdb.h", which pulls in the correct db.h as a side effect.
 33 2012-11-13 04:09:20 <robbak> How should this be fixed permanently and properly? The proper fix I can see is renaming src/db.h so it doesn't clash.
 34 2012-11-13 04:09:25 <robbak> I'd like some comments.
 35 2012-11-13 04:14:07 <Luke-Jr> robbak: it doesn't clash for anyone else
 36 2012-11-13 04:14:14 <Luke-Jr> are you using the included build makefiles?
 37 2012-11-13 04:18:20 <Luke-Jr> can someone reopen #1813 finally? -.-
 38 2012-11-13 04:31:20 <robbak> Yes. qmake for the gui, src/makefile.unix for the daemon, with -L/usr/local/lib/db48/ added to cxxflags
 39 2012-11-13 04:32:03 <robbak> Either other OSes list ../ before included cxxflags, or other OSes instll the C include to a different folder.
 40 2012-11-13 04:33:02 <robbak> I currently have a tree building with a renamed db.h
 41 2012-11-13 04:53:16 <Luke-Jr> BlueMatt: plan to rebase addnoderpc? :/
 42 2012-11-13 04:53:59 <Luke-Jr> robbak: try using BDB_INCLUDE_PATH=/usr/local/lib/db48/
 43 2012-11-13 05:00:53 <Luke-Jr> whew, looks like I have 11 branches to fix/rebase :|
 44 2012-11-13 05:35:51 <robbak> Luke-Jr: is that BDB_INCLUDE_DIR an argument to add to qmake, gmake or is it an environment variable to set?
 45 2012-11-13 05:36:10 <Luke-Jr> the first two
 46 2012-11-13 06:47:22 <robbak> Right, I have it going into both CXXFLAGS and INCLUDEPATH for qmake. That's changed, and it builds and runs without the patch. Bargain! thanks.
 47 2012-11-13 06:48:46 <Luke-Jr> wow, I post a few "rebase needed" comments and everything pops alive
 48 2012-11-13 06:48:47 <Luke-Jr> XD
 49 2012-11-13 07:11:04 <phantomcircuit> im trying to bootstrap something but i cant figure out the format of addr.dat
 50 2012-11-13 07:11:22 <phantomcircuit> anybody got some python code that just extracts all the known peers?
 51 2012-11-13 07:11:35 <sipa> addr.dat or peers.dat ?
 52 2012-11-13 07:11:40 <phantomcircuit> uh
 53 2012-11-13 07:11:54 <phantomcircuit> peers.dat
 54 2012-11-13 07:12:10 <sipa> the latter is just a serialized CAddrMan
 55 2012-11-13 07:12:12 <phantomcircuit> i assume that's more sane
 56 2012-11-13 07:12:21 <phantomcircuit> oh
 57 2012-11-13 07:12:22 <phantomcircuit> so
 58 2012-11-13 07:12:24 <phantomcircuit> sort of
 59 2012-11-13 07:12:25 <phantomcircuit> lol
 60 2012-11-13 07:13:03 <phantomcircuit> i could strip out some of my old python code to crawl the network for peers...
 61 2012-11-13 07:14:55 <weex> phantomcircuit: relevant? http://xkcd.com/416/
 62 2012-11-13 07:15:40 <phantomcircuit> weex, possibly
 63 2012-11-13 07:15:52 <phantomcircuit> ctrl+c would definitely work in this case
 64 2012-11-13 07:15:54 <phantomcircuit> i think
 65 2012-11-13 07:16:07 <weex> always nice to have a kill switch
 66 2012-11-13 07:17:46 <phantomcircuit> sometimes you just gotta let it happen
 67 2012-11-13 07:44:30 <MC1984> ???A hunter-gatherer who did not correctly conceive a solution to providing food or shelter probably died, along with his or her progeny, whereas a modern Wall Street executive that made a similar conceptual mistake would receive a substantial bonus and be a more attractive mate,??? Professor Crabtree says.
 68 2012-11-13 07:44:37 <MC1984> BURN
 69 2012-11-13 07:44:45 <MC1984> he is so fuckin right though
 70 2012-11-13 07:45:10 <MC1984> the specied is screwed
 71 2012-11-13 08:00:55 <sipa> watch 'idiocracy'
 72 2012-11-13 08:14:27 <MC1984> yeah i have
 73 2012-11-13 08:14:35 <MC1984> also huxley was right, not orwell
 74 2012-11-13 09:38:34 <xenland> great cheese
 75 2012-11-13 12:29:33 <yellowhat> is there another blockchain.info like database with timestamps on transactions, not just on blocks?
 76 2012-11-13 12:38:41 <cjd> It's the man with the yellow hat :D
 77 2012-11-13 12:45:03 <sipa> bitcoind? :p
 78 2012-11-13 12:47:08 <yellowhat> sipa, i mean a webservice.
 79 2012-11-13 12:48:45 <yellowhat> sipa, the local bitcoind will only store the timestamp correctly, if it is online while the tx is made, right?
 80 2012-11-13 13:02:58 <sipa> yellowhat: yes, and only for wallet transactions
 81 2012-11-13 13:06:25 <yellowhat> is this still correct and in effect? "nodes reject any block timestamp that is greater than 2 hours from the current network time. Block timestamps that are earlier than the median time of the past 11 blocks are also rejected. This validation puts upper and lower bounds on the acceptable range of block timestamps."
 82 2012-11-13 13:07:12 <gmaxwell> yellowhat: it's a protocol rule and can't be changed without risking non-convergence. So yes, it's 'still' correct.
 83 2012-11-13 13:07:25 <yellowhat> thanks.
 84 2012-11-13 13:08:06 <gmaxwell> well, almost correct. The timestamp must be later than the median of the last 11. Equal to is not acceptable.
 85 2012-11-13 13:08:59 <yellowhat> if you are interested why i am asking so much about time: hackathon project we did in 1 day: https://github.com/bitcoinaustria/bitnotar presentation: http://goo.gl/vBwkY i would welcome criticism.
 86 2012-11-13 13:18:43 <sipa> > median(last_11) is a block validity rule
 87 2012-11-13 13:18:59 <sipa> < now+2h is somewhat more fuzzy
 88 2012-11-13 13:19:38 <kjj_> well, it is still a rule.  but under that rule, a block can become valid if you wait a while
 89 2012-11-13 13:22:42 <gmaxwell> kjj_: right, and clocks aren't exactly in sync... so there is some uncertanty around it.
 90 2012-11-13 13:26:23 <kjj_> for many applications, getting to the same day is good enough
 91 2012-11-13 13:27:00 <cjd> yellowhat: I like your thinking, it would be nice though to use a 0btc transfer with a fee so that ultraprune can remove it and then we won't get in trouble with gmaxwell ;)
 92 2012-11-13 13:29:03 <sipa> does it use 0btc outputs?
 93 2012-11-13 13:29:12 <kjj_> without reading the source, it looks like this is just burning transactions to the pubkey that matches the hash of the file?
 94 2012-11-13 13:29:31 <cjd> the presentation shows non 0 output in a picture but 0 is obviously preferable
 95 2012-11-13 13:29:41 <cjd> yeap
 96 2012-11-13 13:29:53 <sipa> 0 btc outputs are non-standard
 97 2012-11-13 13:30:02 <cjd> that's too bad
 98 2012-11-13 13:30:12 <sipa> why?
 99 2012-11-13 13:30:15 <gmaxwell> cjd: uh, where are you getting the idea that zero value outputs are a good thing?
100 2012-11-13 13:30:26 <sipa> there's no reason why anyone would ever spend a 0 btc output
101 2012-11-13 13:30:32 <sipa> so they'd just linger forever
102 2012-11-13 13:30:56 <cjd> Because sometimes you want to prove that you had a certain hash at a certain time and you're not transferring btc to someone
103 2012-11-13 13:30:56 <gmaxwell> cjd: with zero value outputs the size of the utxo set is unbounded and there is no incentive to clean them up at all, they only cost you...
104 2012-11-13 13:31:18 <gmaxwell> cjd: there are ways to do that that add _no_ data to the blockchain.
105 2012-11-13 13:32:04 <cjd> oh? without messing around with merged mining schenanigans and namecoin?
106 2012-11-13 13:32:04 <gmaxwell> (e.g. see https://github.com/goblin/chronobit )
107 2012-11-13 13:32:41 <sipa> it uses the same merkle-tree-root-committed-in-coinbase technique as merged mining
108 2012-11-13 13:32:51 <sipa> but there's no second chain or anything, just data
109 2012-11-13 13:34:36 <helo> so anyone can add arbitrary data to p2pool's coinbase?
110 2012-11-13 13:34:40 <amiller> is there a non-standard p2pool
111 2012-11-13 13:35:15 <amiller> if you have to basically bribe a miner to include it in the coinbase anyway...
112 2012-11-13 13:36:08 <gmaxwell> ::sigh::
113 2012-11-13 13:36:14 <gmaxwell> why must you all be stupid? :P
114 2012-11-13 13:36:50 <gmaxwell> helo: no, you can add hash roots to the shares you produce, which are tracable along the sharechain to any future block p2pool produces.
115 2012-11-13 13:37:14 <UukGoblin> cjd, there are several options of improving chronobit to make it into a separate timestamping network, I just don't have time to do it
116 2012-11-13 13:37:53 <helo> ahh
117 2012-11-13 13:37:57 <UukGoblin> so that people who want to timestamp something just send it to other p2pool-mining peers, and check back later to get the proof
118 2012-11-13 13:37:58 <cjd> this is interesting
119 2012-11-13 13:37:59 <gmaxwell> Not to mention that time commitments don't need to add any data.
120 2012-11-13 13:38:00 <amiller> yellowhat, how do you derive a public key from the hash of a document
121 2012-11-13 13:38:13 <amiller> do you really derive a public keypair?
122 2012-11-13 13:38:40 <cjd> amiller: just take the first 160 bits of the sha256 is the easy way
123 2012-11-13 13:38:42 <amiller> or do you just insert 20 bytes that looks like a public key but is actually the hash of a document
124 2012-11-13 13:38:47 <cjd> I didn't do it but I'm guessing
125 2012-11-13 13:38:55 <cjd> mhm
126 2012-11-13 13:38:58 <kjj_> doh!
127 2012-11-13 13:39:01 <amiller> it would be good if you can indicate that the transaction is not spendable
128 2012-11-13 13:39:20 <amiller> because otherwise you are _undetectably_ deflating the money supply
129 2012-11-13 13:39:48 <UukGoblin> there doesn't seem to be a lot of interest around timestamping though, even I can't find the time to use my software ;-)
130 2012-11-13 13:40:08 <sipa> there is a lot of interest in using the blockchain a communication medium though :(
131 2012-11-13 13:40:19 <kjj_> when I made my notary service, I had the thing gather a batch of documents, record their hashes in a block of text, hash the text, create the pubkey for the hash, spend to it, wait for a block, send that transaction back to me, and only then publish the text
132 2012-11-13 13:40:26 <amiller> sipa, money is speech, eh
133 2012-11-13 13:40:33 <UukGoblin> lol
134 2012-11-13 13:40:54 <cjd> UukGoblin: what kind of size are these proofs?
135 2012-11-13 13:41:03 <cjd> how big are we talking?
136 2012-11-13 13:41:09 <UukGoblin> cjd, several to few hundred kB
137 2012-11-13 13:41:21 <cjd> ouch
138 2012-11-13 13:41:32 <amiller> what's ouch about that
139 2012-11-13 13:41:34 <gmaxwell> cjd: Can you name a _single_ application for which this is problematic?
140 2012-11-13 13:41:35 <UukGoblin> cjd, but there's lots of room for improvement
141 2012-11-13 13:41:49 <cjd> anything using udp
142 2012-11-13 13:42:11 <gmaxwell> ...
143 2012-11-13 13:42:40 <cjd> I'm kind of talking out my ass at the moment because I have no idea how p2pool hashes old entries into the new one's coinbase
144 2012-11-13 13:42:54 <gmaxwell> cjd: thats isn't an application. If you need to transmit something over UDP you need to provide your own reliablity layer in any case or it's all bets off.
145 2012-11-13 13:43:04 <amiller> kjj, link? i'm still trying to figure out if you're talking about putting no-op data in the scriptpubkey or if you're actually deriving a key with committed data or something
146 2012-11-13 13:43:19 <UukGoblin> just keep in mind that p2pool keeps a share chain, much like a blockchain
147 2012-11-13 13:43:27 <cjd> ok
148 2012-11-13 13:43:35 <kjj_> amiller: I haven't published it, and I haven't made the service public
149 2012-11-13 13:44:02 <kjj_> I'm actually making a full key from the hash of the list of hashes, sending coins to it, sending the coins back to my real wallet
150 2012-11-13 13:44:05 <sipa> i suppose we'll need some code to detect unspendable txout templates, and automatically prune those
151 2012-11-13 13:44:06 <UukGoblin> there are splits and stales on it, just like in the real block chain
152 2012-11-13 13:44:22 <sipa> kjj_: why......?
153 2012-11-13 13:44:25 <cjd> prune ones with 0 output :)
154 2012-11-13 13:44:32 <sipa> cjd: no, you can't
155 2012-11-13 13:44:34 <amiller> kjj_, so you publish the private key after the coins are already spent?
156 2012-11-13 13:44:48 <kjj_> amiller: yes
157 2012-11-13 13:44:48 <sipa> cjd: because that means every attempt to spend one of those output becomes illegal
158 2012-11-13 13:44:52 <amiller> kjj_, that's excellent
159 2012-11-13 13:44:57 <amiller> that's basically the same as the guy fawkes algorithm
160 2012-11-13 13:45:03 <amiller> what's awesome is that doing signatures this way does not even require ECDSA
161 2012-11-13 13:45:15 <UukGoblin> sipa, and is there anything wrong with it being illegal?
162 2012-11-13 13:45:22 <UukGoblin> (or is it just that current rules make it legal?)
163 2012-11-13 13:45:25 <kjj_> sipa: there wasn't a notary service when I started it.  I never finished for two reasons
164 2012-11-13 13:45:28 <sipa> UukGoblin: yes, hard fork the second someone tries it
165 2012-11-13 13:45:37 <sipa> UukGoblin: because right now it is legal
166 2012-11-13 13:45:44 <UukGoblin> right
167 2012-11-13 13:46:13 <amiller> kjj_, one side effect of that is it potentially makes double spends appealing at a certain amount.
168 2012-11-13 13:46:29 <cjd> hmm
169 2012-11-13 13:46:41 <sipa> if we'd make it illegal to spend 0-value amounts... well, that'd be nice in a way, but perhaps there are uses of 0-outputs that don't like this
170 2012-11-13 13:46:42 <amiller> suppose someone makes a transaction with 10,000 btc then sepnds it back to themselves
171 2012-11-13 13:46:47 <amiller> then publishes the private key
172 2012-11-13 13:46:49 <cjd> perhaps allow spending of transactions which have been pruned as long as the amount added is 0?
173 2012-11-13 13:47:07 <sipa> cjd: how do you know what the amount is, if they are pruned?
174 2012-11-13 13:47:29 <cjd> if everything else adds up and there are some extranious inputs, assume they are zero
175 2012-11-13 13:47:31 <UukGoblin> you'd store the transactions yourself to have a proof that they were included
176 2012-11-13 13:47:40 <UukGoblin> (transactions + merkle branch)
177 2012-11-13 13:47:42 <sipa> cjd: that means you can't derive the fee amount anymore
178 2012-11-13 13:47:43 <kjj_> amiller: very small amounts
179 2012-11-13 13:47:44 <UukGoblin> just like a chronobit proof
180 2012-11-13 13:47:51 <cjd> oh yuck
181 2012-11-13 13:47:53 <cjd> indeed :(
182 2012-11-13 13:48:02 <amiller> kjj_, yeah
183 2012-11-13 13:48:08 <sipa> cjd: and even worse, that would require a hard fork in any case, as you're making something legal that was illegal
184 2012-11-13 13:48:25 <cjd> oh it's illegal to add a 0 value input?
185 2012-11-13 13:48:30 <sipa> no
186 2012-11-13 13:48:43 <sipa> but you're making it legal to spend an non-existing 0-value output
187 2012-11-13 13:48:50 <cjd> ahh indeed
188 2012-11-13 13:48:59 <kjj_> amiller: basically, I charged a nominal minimum fee, but people could pay more.  when a threshold was reached either in money collected or time waited, it would create the signing block
189 2012-11-13 13:49:21 <sipa> the cleanest solution imho (if people *really* need to add data in transaction that doesn't need to hit the UTXO set) is making spending 0-value outputs illegal
190 2012-11-13 13:49:34 <UukGoblin> kjj_, have you seen chronobit? any thoughts?
191 2012-11-13 13:49:37 <cjd> yeah, for me (my opinion is just that), spending 0 value inputs has no usefulness
192 2012-11-13 13:49:38 <sipa> but then again, i think people don't need that at all
193 2012-11-13 13:49:43 <UukGoblin> (there's #chronobit, too)
194 2012-11-13 13:49:58 <sipa> and i don't like the sign that it's fine to use the blockchain for communication
195 2012-11-13 13:50:01 <kjj_> UukGoblin: I'm aware of it, yeah.  that's one of the two reasons why I never finished
196 2012-11-13 13:50:08 <gmaxwell> sipa: why not just use pushes in script sigs?
197 2012-11-13 13:50:14 <sipa> gmaxwell: yeah
198 2012-11-13 13:50:23 <sipa> right
199 2012-11-13 13:51:15 <cjd> I think that it's a good idea to pave a road for people who want this use case (putting myself asside for a moment) because if we say "no this is evil don't" then people will hack something together and it will be bad.
200 2012-11-13 13:51:21 <kjj_> the other reason was that I got nervous about accepting files for upload to be hashed and deleted
201 2012-11-13 13:51:31 <UukGoblin> kjj_, fair enough
202 2012-11-13 13:51:42 <yellowhat> amiller: the document is the private key. so you can spend it, let it prune if you decide so in the future. this is the current implementation in the prototype
203 2012-11-13 13:52:01 <amiller> yellowhat, so you have to reveal the plaintext in order to spend the btc?
204 2012-11-13 13:52:17 <sipa> cjd: i think we need to give them a way to communicate metadata to transactions that is easier than using the blockchain :)
205 2012-11-13 13:52:29 <sipa> cjd: instead of making it hard to use the blockchain as communication medium
206 2012-11-13 13:52:41 <UukGoblin> yes!
207 2012-11-13 13:53:01 <gmaxwell> sipa: Doing both is more powerful than either alone. :)
208 2012-11-13 13:53:28 <UukGoblin> I was also thinking of making the proof file format into an RFC of some sort
209 2012-11-13 13:53:32 <cjd> hrm, the problem is that the chain is a beautiful awesome notary service and it doesn't require effort and you pay for it's services using good ol bitcoin.
210 2012-11-13 13:53:44 <sipa> gmaxwell: right, but just doing the first will result in people that keep asking "how do i find the sender address of a transaction? yes i know it doesn't reqlly exist, but i need it anyway!"
211 2012-11-13 13:53:48 <gmaxwell> In any case, the committment stuff is not transaction metadata a commitment should result in no txn at all.
212 2012-11-13 13:54:06 <UukGoblin> cause it's pretty generic, can be used with other things like coin burning too
213 2012-11-13 13:55:05 <yellowhat> amiller, not really. you just have to  use the document hash as a private key. that hash stays secret. except if you prove the documents existance, then anyone reading the proof (for example a judge) can spend the btc
214 2012-11-13 13:55:07 <gmaxwell> cjd: thats crap though.  Done correctly notary service has a proper price of ~0 because it has O(1) scaling... You don't need to add any data to the chain.
215 2012-11-13 13:55:43 <gmaxwell> cjd: schemes which add data to the chain are rubbish because they externalize their cost and there is no mechenism for paying the true victims of it (all future users of Bitcoin forever in time).
216 2012-11-13 13:55:45 <amiller> hmm... anyone reading the proof can spend the btc
217 2012-11-13 13:55:59 <cjd> depending on how large a proof you're comfortable with, yes
218 2012-11-13 13:56:32 <sipa> cjd: done on top of bitcoin directly the proof has size 32*log2(num_commitments) bytes
219 2012-11-13 13:56:34 <UukGoblin> cjd, much of the proof can be distributed if done properly
220 2012-11-13 13:56:40 <gmaxwell> cjd: adding data to the blockchain doesn't make the proofs any smaller, generally.
221 2012-11-13 13:56:49 <UukGoblin> your own private data of the proof will be below 1kB I imagine
222 2012-11-13 13:57:13 <sipa> with a billion data entries committed, you need not even a kilobyte
223 2012-11-13 13:57:39 <gmaxwell> cjd: it may just move some fraction of the data to be replicated forever on hundreds of thousands of computers for all time, which was what I meant about externalizing the cost.
224 2012-11-13 13:57:57 <UukGoblin> cjd, currently, the proof is large because it stores all p2pool shares in the chain between the timestamp and when p2pool finds a bitcoin block
225 2012-11-13 13:58:15 <UukGoblin> this is all publicly-known data (it's just that p2pool forgets it after 24h because it's useless to it)
226 2012-11-13 13:58:22 <cjd> UukGoblin: is there any other way? when I say proof I mean proof given only the header chain
227 2012-11-13 13:58:23 <gmaxwell> cjd: e.g. not only does it make people who are uninterested in your committments pay for them, but it increases the sum-cost _enormously_ in the process.
228 2012-11-13 13:58:33 <UukGoblin> and that data can be stored for all users as a side-chain
229 2012-11-13 13:59:03 <cjd> you can shuffle it around here or there but you still need to have that data
230 2012-11-13 13:59:06 <gmaxwell> UukGoblin: uh. thats not a good idea.
231 2012-11-13 13:59:30 <sipa> well it can be stored in a side-chain for users who consider it valuable to have such a chain
232 2012-11-13 13:59:42 <sipa> but i doubt you'll find many rational users who think that
233 2012-11-13 13:59:47 <gmaxwell> What sipa says.
234 2012-11-13 13:59:54 <UukGoblin> cjd, yes there is, and that's to make shares into a tree rather than store a list of them
235 2012-11-13 14:00:08 <cjd> yeap
236 2012-11-13 14:00:20 <cjd> but that's a patch against p2pool :/
237 2012-11-13 14:00:27 <cjd> an ugly one too
238 2012-11-13 14:00:29 <UukGoblin> that's not a big deal
239 2012-11-13 14:00:31 <yellowhat> cronobit looks interesting, too. i will look into it to see if it fits this use case. i have to be AFK now for 2-3 hours taking care of the children
240 2012-11-13 14:00:41 <gmaxwell> That, however, sounds like a fine one to me. Just get forrest to include a set secondary commitments in the shares for N-back shares.
241 2012-11-13 14:00:45 <gmaxwell> Like a skiplist.
242 2012-11-13 14:00:56 <UukGoblin> sipa, you'll store it just to be able to remember your proofs. You can then choose to donate some bandwidth to provide your stored data to other users of the notary service.
243 2012-11-13 14:01:34 <UukGoblin> yellowhat, appreciated. If you have any queries, catch me here on in #chronobit
244 2012-11-13 14:01:37 <gmaxwell> UukGoblin: You'd just store your own proofs. Thats much more efficient.. exactly as many copies as there are people interested in a particular proof.
245 2012-11-13 14:02:22 <cjd> if you have a hashtree and that tree roots in a tx output, as far as I can tell you're somewhere around 2k for the proof all the way back to the header chain for 8192 entries per tx..
246 2012-11-13 14:03:37 <UukGoblin> gmaxwell, that's more or less what I meant
247 2012-11-13 14:05:22 <gmaxwell> cjd: huh? log2(8192) is 13. You're on the order of 420 bytes.
248 2012-11-13 14:06:54 <cjd> yeap, and then the tx which is around 250 IIRC and then the hash branch linking the tx back to the header
249 2012-11-13 14:07:30 <UukGoblin> cjd, the data you want to timestamp will often be much larger than a few kb though, and you have to store that too
250 2012-11-13 14:07:48 <UukGoblin> I don't see why a few kB would ever be problematic
251 2012-11-13 14:09:15 <gmaxwell> cjd: you still don't get to 2kB doing that.
252 2012-11-13 14:09:48 <cjd> maybe I messed up on my math, anyway if I run under then that's good because the hashtree can be taller
253 2012-11-13 14:10:19 <sipa> cjd: a proof for data in a merkle tree rooted in the coinbase is data+32*log2(entries_committed)+size_coinbase_tx+32*log2(num_transactions_in_block)
254 2012-11-13 14:10:36 <sipa> and that's enough to link it to the block chain headers
255 2012-11-13 14:10:57 <cjd> wish I ran a huge mining pool, then I could have coinbase access :)
256 2012-11-13 14:11:44 <gmaxwell> cjd: you can run p2pool and thus have coinbase access to the blocks you produce and the shares they commit.
257 2012-11-13 14:12:27 <cjd> yeah, <2k becomes the hard part... I suppose I could buy near-root coinbase access from one of the pool ops
258 2012-11-13 14:13:15 <gmaxwell> Where are you getting this 2k figure from?
259 2012-11-13 14:13:28 <cjd> the absurd thing is the number of transactions from everyone buying notary service would far outweigh the once a day or once a week fake tx
260 2012-11-13 14:13:39 <cjd> I figure 2 udp packets is about my limit
261 2012-11-13 14:18:22 <amiller> i think there should be a guy-fawkes style pubkey system
262 2012-11-13 14:18:30 <amiller> you could eliminate ECDSA for the typical payment case
263 2012-11-13 14:19:11 <amiller> guy fawkes is a one-time signature algorithm that relies on timestamping messages
264 2012-11-13 14:19:56 <cjd> a thing that has long interested me about bitcoin is that the protocol and chain system itself will withstand a break of ecdsa
265 2012-11-13 14:19:59 <cjd> that's impressive
266 2012-11-13 14:20:50 <amiller> the typical payment case is when you only need a single signature because you created a fresh address for a single event
267 2012-11-13 14:20:53 <gmaxwell> cjd: limit for _what_?
268 2012-11-13 14:21:45 <UukGoblin> cjd, but not a break of SHA256 ;-]
269 2012-11-13 14:22:01 <amiller> on one hand a break of sha256 is highly unlikely
270 2012-11-13 14:22:03 <cjd> to be able to give very small pieces of data to very low power devices fast
271 2012-11-13 14:22:20 <amiller> on the other hand, the whole thing is like a macabre celebration of how close we come to busting lesser-difficulty hashes
272 2012-11-13 14:22:26 <UukGoblin> amiller, a resonable break might be unlikely, but it's certain that collisions exist
273 2012-11-13 14:23:09 <amiller> UukGoblin, the blockchain places the heads of partially-preimaged hashes up on stakes :p
274 2012-11-13 14:23:21 <cjd> actually even if sha256 become weak and miners were able to near hash 0, it would be reasonable to add another hash to the back of that and continue to raise the difficulty above the current maximum, this would require the miners to upgrade of course
275 2012-11-13 14:23:41 <cjd> but anyway this is silly conjecture
276 2012-11-13 14:23:45 <sipa> that's a hard fork in any case
277 2012-11-13 14:23:57 <sipa> which is no easier than just changing the hashing algorithm
278 2012-11-13 14:24:07 <UukGoblin> triple des comes to mind
279 2012-11-13 14:24:25 <sipa> i vote quad-rot13
280 2012-11-13 14:24:29 <cjd> :D
281 2012-11-13 14:24:43 <UukGoblin> nod
282 2012-11-13 14:25:25 <amiller> guy fawkes hash-based signatures would require a scriptpubkey that can span across two transactions
283 2012-11-13 14:27:47 <amiller> hm
284 2012-11-13 14:27:57 <amiller> or it would just require an opcode that can consume proofs-of-timestamp
285 2012-11-13 14:33:46 <UukGoblin> what's a guy fawkes signature?
286 2012-11-13 14:39:09 <amiller> okay lets run through this
287 2012-11-13 14:39:27 <amiller> i'm a merchant i'm about to accept a payment from you, so i create a secret 2^k just a random string
288 2012-11-13 14:39:37 <amiller> then i take the hash of this string
289 2012-11-13 14:39:57 <amiller> the hash of this string is my address, which i give to you
290 2012-11-13 14:40:07 <amiller> lets do Y = H(X) where X is my private key and Y is the address
291 2012-11-13 14:40:22 <amiller> by X is my private key i mean the same random 2^k string from the first part
292 2012-11-13 14:40:55 <amiller> you pay me by creating a 1btc transaction output that says "whoever can prove he knows the preimage of Y may claim this btc"
293 2012-11-13 14:41:06 <gmaxwell> Then I, as a miner, run code that automatically rebinds any pay to preimage transactions to one paying to me... PROFIT.
294 2012-11-13 14:41:20 <amiller> hold your horses
295 2012-11-13 14:41:27 <amiller> now to claim my payment i must do two phases
296 2012-11-13 14:41:54 <gmaxwell> (and yes, this kind of scheme can be made more secure, but not in the bitcoin system as it is today; see the MAVE crazy stuff)
297 2012-11-13 14:42:10 <amiller> first i must somehow timestamp in the blockchain a message that says "I know the preimage of Y and i want to transfer the payment to my stable wallet P"
298 2012-11-13 14:43:16 <amiller> right so i do that either by getting this put in a coinbase or i can do it myself in a transaction if i pay for it
299 2012-11-13 14:44:00 <slush> etotheipi_: ping?
300 2012-11-13 14:44:23 <UukGoblin> amiller, remember there's nothing stopping the miner from creating an earlier timestamp of his preimages
301 2012-11-13 14:44:32 <amiller> finally, I make a transaction says "The preimage of Y is X and in the blockchain you can see that the key should now be associated with  PK "
302 2012-11-13 14:44:47 <amiller> it's not done by timestamp
303 2012-11-13 14:44:49 <amiller> it's done by 'work'
304 2012-11-13 14:45:02 <amiller> or blockheight if you like
305 2012-11-13 14:45:23 <amiller> i don't reveal the preimage X until i'm certain my commitment is timestamped deep in the chain
306 2012-11-13 14:50:04 <amiller> so all this requires is an opcode that's strong enough for all these timestamp methods we just talked about
307 2012-11-13 14:50:27 <amiller> if you want to be able to prove that a commitment was made before some block, then maybe you could prove it to a miner
308 2012-11-13 14:55:23 <UukGoblin> amiller, and what's the purpose?
309 2012-11-13 14:56:41 <amiller> ECDSA is slow, this involves a single hash (well, as many hashes are are needed to do that timestamp proof)
310 2012-11-13 14:57:27 <UukGoblin> oh... heh
311 2012-11-13 14:58:07 <UukGoblin> but if I'm reading it right, it requires lots of waiting for your commitment to be timestamped?
312 2012-11-13 14:58:27 <UukGoblin> making it, arguably, slower?
313 2012-11-13 14:58:52 <amiller> it's slower but costs less
314 2012-11-13 14:59:01 <amiller> it's easier on the miners although it transfers some burden to the client
315 2012-11-13 14:59:32 <amiller> easier on the miners = less tx fee required, eventually
316 2012-11-13 15:00:07 <UukGoblin> btw, need a fee-avoidance mechanism
317 2012-11-13 15:00:21 <amiller> i don't follow
318 2012-11-13 15:01:57 <UukGoblin> like, when I have lots of inputs to a large txn
319 2012-11-13 15:02:17 <UukGoblin> I'd like some mechanism that'll re-arrange these inputs using many small transactions
320 2012-11-13 15:02:23 <UukGoblin> so that I don't have to pay any fees
321 2012-11-13 15:02:40 <UukGoblin> and I need that to prove that the current fee mechanism is meh ;-]
322 2012-11-13 15:03:55 <cjd> I would think the way to avoid fees is to keep btc in lots of small amounts rather than globing it together so you don't have to make change and that way the "velocity" of your btc is low
323 2012-11-13 15:04:39 <cjd> but then the miners could detect what you're up to and start orphaning your transactions unless you pay even more
324 2012-11-13 15:08:57 <amiller> that's an interesting point, that sometimes you don't have to make change if you have exactly the right amount
325 2012-11-13 15:10:18 <cjd> well if you only make a tiny bit of change, then only a tiny bit of btc has high velocity
326 2012-11-13 15:10:23 <amiller> but keeping btc in small amounts is expensive for exactly the same reason that lots of small outputs is expensive - the miners are burdened by a large number of utxos
327 2012-11-13 15:14:32 <UukGoblin> well you should keep your BTC in roughly the same chunks that you intend on spending them
328 2012-11-13 15:14:46 <UukGoblin> so to be flexible, you'd have both small and large outputs
329 2012-11-13 15:14:58 <UukGoblin> but it'll never be perfect, hence the need of a wallet rebalancing app
330 2012-11-13 15:15:26 <gmaxwell> "orphaning your transactions" what the @#$@ does that mean?
331 2012-11-13 15:16:58 <UukGoblin> I guess he meant "not including your transactions"
332 2012-11-13 15:19:06 <denisx> is there already a macbuild with ultraprune?
333 2012-11-13 15:20:19 <kjj_> UukGoblin: I run p2pool.  I call the scripts I'm writing to clean up my wallet my "dust collector"
334 2012-11-13 15:21:00 <UukGoblin> ah, that's another use case, to insta-clean your wallet by including your own free cheap transactions in the blocks you mine
335 2012-11-13 15:21:17 <UukGoblin> kjj_, fun. Will you make the scripts public?
336 2012-11-13 15:21:31 <UukGoblin> s/free cheap/free/
337 2012-11-13 15:22:01 <amiller> that's pretty cool kjj_
338 2012-11-13 15:23:20 <kjj_> my problem is that I write ugly, nasty dirty scripts, full of garbage and past experiments.
339 2012-11-13 15:23:53 <kjj_> and then I get lost when I try to clean them up for publication
340 2012-11-13 15:23:53 <UukGoblin> kjj_, I know what you mean
341 2012-11-13 15:24:12 <sipa> denisx: no idea - ask gavin :)
342 2012-11-13 15:24:21 <UukGoblin> kjj_, do you use git?
343 2012-11-13 15:24:40 <kjj_> nope
344 2012-11-13 15:25:02 <kjj_> I've been forced to start learning it to contribute my trivial little patches to the client
345 2012-11-13 15:25:16 <kjj_> but I almost always end up in here begging for git help
346 2012-11-13 15:25:45 <UukGoblin> kjj_, that's one of the reasons I guess. I used to write messy scripts as well, but since I started using version control systems, I just delete the rubbish and let the VCS remember my older versions in case I need to go back to them
347 2012-11-13 15:26:21 <UukGoblin> I no longer have a need to comment out code
348 2012-11-13 15:26:22 <amiller> git's just a blockchain with a command line anyway
349 2012-11-13 15:26:38 <UukGoblin> huh.
350 2012-11-13 15:26:48 <sipa> amiller: awesome tweet by the way "Back to the future is basically a movie about a git rebase"
351 2012-11-13 15:26:52 <kjj_> meh.  my mind is still file based.
352 2012-11-13 15:27:02 <amiller> :p
353 2012-11-13 15:27:40 <amiller> sipa, also: the flux capacitor is a 51% attack
354 2012-11-13 15:27:53 <kjj_> I'm not a fan of OO either, so you have that...
355 2012-11-13 15:27:57 <kjj_> gotta run, back later
356 2012-11-13 15:28:24 <sipa> amiller: so all the world together drives at 175 mph, and with 88 mph you have a majority? :p
357 2012-11-13 15:31:22 <gavinandresen> denisx: no mac build with ultraprune yet.
358 2012-11-13 15:32:46 <denisx> I think the mac would get the most out of ultraprune since it still has this 100% cpu bug
359 2012-11-13 15:33:03 <sipa> huh?
360 2012-11-13 15:33:21 <gavinandresen> denisx: really?  I haven't noticed 100% CPU usage on latest release
361 2012-11-13 15:33:44 <denisx> I need ca. 30min to catch one week of blocks
362 2012-11-13 15:33:44 <sipa> denisx: you know that 100% cpu usage (if it's doing real work, at least) is intended?
363 2012-11-13 15:34:11 <sipa> on what kind of cpu?
364 2012-11-13 15:34:19 <denisx> quad i7
365 2012-11-13 15:34:33 <sipa> ok, should be about 10x as much
366 2012-11-13 15:34:47 <sipa> but ultraprune will hardly affect cpu usage, normally
367 2012-11-13 15:37:33 <sipa> denisx: ever tried to find out where it was spending cpu?
368 2012-11-13 15:37:54 <denisx> it happens only while catching the blocks
369 2012-11-13 15:38:20 <sipa> so it's basically just much slower than expected, but that's all?
370 2012-11-13 15:38:39 <denisx> yes
371 2012-11-13 15:38:48 <denisx> and exactly at 100% cpu
372 2012-11-13 15:38:50 <sipa> gavinandresen: how fast is block sync for you?
373 2012-11-13 15:38:56 <sipa> denisx: well that's expected if it's slow
374 2012-11-13 15:39:31 <gmaxwell> It should be getting 100% cpu usage at the end... if it's not either you are waiting on the network or something is wrong.
375 2012-11-13 15:39:54 <sipa> still, i get several blocks/s on my CPU
376 2012-11-13 15:40:00 <denisx> since it was wrong before I think the bug is still there
377 2012-11-13 15:40:28 <sipa> denisx: the earlier '100% cpu' bug was just a thread in a spinlock
378 2012-11-13 15:40:42 <gavinandresen> sipa: my bitcoin development environment is still in pieces on the floor, so I haven't been running ultraprune
379 2012-11-13 15:40:47 <sipa> it has nothing to do with the fact that obviously when doing a cpu intensive task, you'll see maxed out cpu usage
380 2012-11-13 15:40:59 <sipa> gavinandresen: head, i mean
381 2012-11-13 15:41:01 <denisx> gavinandresen: you should, I heard its nice! ;)
382 2012-11-13 15:41:26 <sipa> gavinandresen: eh, i mean 0.7.1 or whatever came before it
383 2012-11-13 15:41:45 <gavinandresen> sipa: Oh, 0.7.1 is SLOW....
384 2012-11-13 15:41:45 <sipa> gavinandresen: what rate of blocks/s do you see at the end of the chain
385 2012-11-13 15:41:56 <sipa> on osx
386 2012-11-13 15:42:01 <gavinandresen> (takes like half an hour to catch up on a week's worth of blocks :-)
387 2012-11-13 15:42:40 <sipa> ok, so you see the same as denisx
388 2012-11-13 15:42:48 <gavinandresen> yup.
389 2012-11-13 15:42:55 <sipa> that's unexpectedly slow
390 2012-11-13 15:43:31 <jgarzik> could depart from tradition, and do a 0.8-alpha test release, with big flashing warning stickers and "0.8 is not done yet" labels on it
391 2012-11-13 15:44:17 <sipa> jgarzik: as soon as auto-migration is implemented, i'd like to see some "technology preview release, not for mining/merchants" release
392 2012-11-13 15:44:24 <sipa> well, s/release/binaries/
393 2012-11-13 15:44:32 <jgarzik> ACK
394 2012-11-13 15:45:00 <BlueMatt> Luke-Jr: Ill rebase addnoderpc if there is some consensus on design/more interest
395 2012-11-13 15:45:18 <BlueMatt> also...not today, need to wait for plane time tomorrow/friday
396 2012-11-13 15:45:20 <gavinandresen> sipa: part of putting my development environment back together is making it easier for me to compile 64-bit, latest SDK versus 32-bit, maximum-compatibility, to see if there is any performance difference
397 2012-11-13 15:45:46 <sipa> oh, right, could it be that signature verification is significantly slower on 32-bit?
398 2012-11-13 15:45:56 <gavinandresen> could be....
399 2012-11-13 15:46:09 <sipa> or the 32-bit openssl is less optimized
400 2012-11-13 15:47:28 <sipa> gmaxwell, jgarzik, gavinandresen: how do you see auto-migration by the way? there are three options basically: a) move block files to new names + -reindex    b) -loadblock old block files + delete    c) -loadblock old block files + keep
401 2012-11-13 15:47:59 <sipa> a) is certainly fastest and the only way that doesn't need 4GB of temporary extra disk storage
402 2012-11-13 15:48:06 <gavinandresen> I say a)
403 2012-11-13 15:48:15 <gavinandresen> Common case will be users upgrade and never look back.
404 2012-11-13 15:48:16 <sipa> but b) is the only way that allows easy switching back to old versions
405 2012-11-13 15:48:23 <sipa> eh, c
406 2012-11-13 15:48:38 <sipa> b) has the advantage over a) of defragmenting block files
407 2012-11-13 15:49:09 <gavinandresen> meh on fragmented block files.  ultraprune will hardly every read them anyway
408 2012-11-13 15:49:26 <sipa> true
409 2012-11-13 15:49:37 <gmaxwell> I am unhappy about the idea that nodes will be setup differently based on how they were started.
410 2012-11-13 15:50:01 <gavinandresen> We'll have less customer support from "I ran out of disk space, what do I do" if we move files
411 2012-11-13 15:50:01 <gmaxwell> If we went the (a) route I think we would be better off sticking with 2gib blockfiles across the board.
412 2012-11-13 15:50:21 <sipa> a) also means you get 2 +- 2GB .blk*.dat files, and 128 MB files after that
413 2012-11-13 15:50:34 <gmaxwell> gavinandresen: We wouldn't any non-move option would need to check space first. And a user with <4gb free is going to have problems soon in any case.
414 2012-11-13 15:51:37 <gavinandresen> What happens if my blk0001.dat file is a symlink?
415 2012-11-13 15:51:46 <gavinandresen> (in the move case....)
416 2012-11-13 15:51:46 <jgarzik> sipa: we discussed this remember?
417 2012-11-13 15:51:50 <jgarzik> GUI: move and delete
418 2012-11-13 15:51:58 <jgarzik> GUI: import and delete
419 2012-11-13 15:52:01 <jgarzik> bitcoind: import and keep
420 2012-11-13 15:52:10 <gmaxwell> I'd rather have B / C in a choice in the gui, with a check for free space. (and just refuse to run if <4gb free)
421 2012-11-13 15:52:14 <jgarzik> no need to move, as block files are in new directories
422 2012-11-13 15:52:28 <jgarzik> either delete, or not
423 2012-11-13 15:52:46 <sipa> jgarzik: i know, but with less participants in the discussion
424 2012-11-13 15:53:12 <gavinandresen> why spend time coding a GUI choice?  This is a one-time, one-release thing, hardly seems worth it
425 2012-11-13 15:53:27 <sipa> afk
426 2012-11-13 15:53:31 <jgarzik> I think there is value in keeping old block files around, for bitcoind users
427 2012-11-13 15:53:38 <jgarzik> new users will never see old block files
428 2012-11-13 15:53:41 <jgarzik> just import
429 2012-11-13 15:53:53 <gmaxwell> gavinandresen: because there is the "can you downgrade" angle vs "wastes 4gb disk space"
430 2012-11-13 15:53:59 <jgarzik> bitcoind users are more likely to bounce between versions
431 2012-11-13 15:54:12 <jgarzik> downgrade, etc.
432 2012-11-13 15:54:24 <gavinandresen> but the number of users who bounce between versions is pretty darn small.  I think.
433 2012-11-13 15:55:21 <gavinandresen> I just want to minimize work, and if you're bouncing between versions then cp -r the datadir before you upgrade....
434 2012-11-13 15:55:24 <cjd> when faced with the choice of breaking noobs and breaking experienced people, break the experienced people because they're all running wacky distros with experimental kernel modules anyway so stuff breaking is normal
435 2012-11-13 15:55:25 <gmaxwell> gavinandresen: "0.x didn't work for me! I want to go back to the working one" isn't that uncommon though.
436 2012-11-13 15:55:56 <gavinandresen> gmaxwell: fine.  You can import from the moved blk*.dat files.
437 2012-11-13 15:56:10 <gavinandresen> (if you don't want to re-dl the chain)
438 2012-11-13 15:56:30 <jgarzik> indeed
439 2012-11-13 15:56:33 <gmaxwell> gavinandresen: yea, in like .. 24 hours.
440 2012-11-13 15:56:37 <jgarzik> ESPECIALLY for such a major change
441 2012-11-13 15:56:46 <jgarzik> that's why I think this release, there is more value than most, in keeping the old files
442 2012-11-13 15:57:03 <gavinandresen> jgarzik: if the answer is 'move', then the old files ARE kept.
443 2012-11-13 15:57:14 <gavinandresen> (they're just moved to a different directory)
444 2012-11-13 15:57:29 <gmaxwell> gavinandresen: that has no value except avoiding issues on systems that are almost out of disk space.
445 2012-11-13 15:57:47 <jgarzik> gavinandresen: /me was agreeing with gmaxwell's "0.x didn't work for me! I want to go back to the working one"
446 2012-11-13 15:57:53 <gmaxwell> And has the cost of making the blockchain look very different on hosts that were born ultraprune vs upgraded.
447 2012-11-13 15:58:22 <cjd> copy and delete after a few days, maybe with a little warning message? ok I'll shutup now since I'm not going to write the patch..
448 2012-11-13 16:01:56 <gmaxwell> Ignoring what happens with the files themselves ... I have mixed feelings on reindex vs loadblock. Reindex is more complicated and more likely to run into issues. OTOH, we'd like to get those fixed.  OTOOH finding them as part of users upgrade process is a pretty bad way to go about it.
449 2012-11-13 17:13:23 <jgarzik> gmaxwell: reindex should be using loadblock logic...
450 2012-11-13 17:13:50 <sipa> it is
451 2012-11-13 17:14:27 <sipa> i haven't seen any issues with reindexing lately
452 2012-11-13 17:17:57 <sipa> but still, it is more vulnerable, as any data written to the block files is likely to break the reindex process
453 2012-11-13 17:18:20 <sipa> sure, that shouldn't happen at all
454 2012-11-13 17:18:43 <gmaxwell> Right, I'm not currently aware of any issues but it absolutely is more fragile.
455 2012-11-13 17:18:54 <sipa> indeed
456 2012-11-13 17:23:40 <gavinandresen> so... what's the consensus for upgrading/downgrading?  I don't feel strongly, I just prefer to default to "do what is fastest/least-likely-to-cause-trouble for the greatest number of people"
457 2012-11-13 17:24:46 <sipa> all 3 methods seem to have advantages and disadvantages :)
458 2012-11-13 17:24:51 <sipa> i don't really care
459 2012-11-13 17:26:01 <sipa> i think that cases for which reindex fails, will not be able to loadblock everything either
460 2012-11-13 17:26:28 <gavinandresen> sipa: then implement the easiest one quick, before we spend more time arguing
461 2012-11-13 17:27:31 <sipa> the problem is really just gui code, the logic itself is trivial in any case
462 2012-11-13 17:28:23 <gavinandresen> gui can just be an at-startup "upgrading block database" splashscreen thingie, can't it ?
463 2012-11-13 17:28:25 <gmaxwell> sipa: well, I worry about people terminating the reindex at random times... though the last version of the reindex seems more robust against that.
464 2012-11-13 17:29:03 <sipa> gmaxwell: it stores in the block db 'i am reindexing', and if you restart in between it restarts
465 2012-11-13 17:29:15 <gavinandresen> I'm pretty strongly against asking users what to do.  GUI rule is "don't ask users questions that 98% of them will not know how to answer"
466 2012-11-13 17:29:24 <sipa> and it always skips parts of the block files that arr already known
467 2012-11-13 17:29:31 <sipa> arrrr
468 2012-11-13 17:29:49 <gavinandresen> is it talk like a pirate day again already?  cool!
469 2012-11-13 17:30:26 <sipa> yeah, every prime-numbered tuesday!
470 2012-11-13 17:30:30 <sipa> or something
471 2012-11-13 17:31:18 <midnightmagic> muaahaha soon a good chunk of miners will have hashing clusters stronger than the jaguar supercomputer..  lol
472 2012-11-13 17:31:22 <gmaxwell> gavinandresen: there is no right answer to the "be able to downgrade" or "don't waste a bunch of space". Picking one is unfortunate, if we go that route I suspect we should pick don't waste better long term consequences.
473 2012-11-13 17:31:28 <midnightmagic> (as it was prior to the upgrade)
474 2012-11-13 17:31:43 <gmaxwell> midnightmagic: it has gpus now! though ... nvidia. :P
475 2012-11-13 17:32:11 <midnightmagic> gmaxwell: Yes, @ 17pf or so. They're saying they have 280,000 nvidia gpu, which doesn't make any sense to me.
476 2012-11-13 17:32:12 <sipa> also, in particular for a "demo release", ability to downgrade is quite important
477 2012-11-13 17:32:31 <midnightmagic> gmaxwell: I don't suppose you know who Michael Wolfe is do you?
478 2012-11-13 17:32:46 <midnightmagic> from PGI.
479 2012-11-13 17:33:14 <gmaxwell> No.
480 2012-11-13 17:33:15 <sipa> pretty good... integrity?
481 2012-11-13 17:33:27 <gmaxwell> portland compiler group.
482 2012-11-13 17:33:33 <midnightmagic> portland group incorporated. they wrote one of the OpenACC compilers.
483 2012-11-13 17:34:05 <gmaxwell> sipa: also we don't want people to want to demo to not get the loadblock/reindex advantage.
484 2012-11-13 17:56:04 <sipa> gmaxwell: hmm?
485 2012-11-13 18:05:21 <gmaxwell> sipa: if they install to a seperate data dir to avoid an inability to downgrade then they'll end up doing an IBD from the network, which isn't exactly a great expirence.
486 2012-11-13 18:06:52 <Luke-Jr> BlueMatt: it looked to me like there was general agreement to merge it as-is for 0.7, but it wasn't rebased in time&
487 2012-11-13 18:11:27 <sipa> gmaxwell: right, of course
488 2012-11-13 18:18:32 <BlueMatt> Luke-Jr: no, it was rebased at that time, but it was largely bikeshed'd for 0.7, I may have time to rebase it on the plane tomorrow or friday
489 2012-11-13 19:20:48 <cjd> if they have a weird system and the new version crashes for some odd reason
490 2012-11-13 19:33:41 <sipa> helo: from git head, or from a release?
491 2012-11-13 19:35:19 <D34TH> i am the weird system king
492 2012-11-13 19:39:29 <sipa> D34TH: on a scale of -2.1 to 1.7, how weird is your system?
493 2012-11-13 19:40:14 <D34TH> its roughly 0xDD
494 2012-11-13 19:55:21 <kjj_> D34TH, weird, or just old?
495 2012-11-13 19:58:21 <D34TH> kjj_, weird
496 2012-11-13 19:58:55 <cjd> so how bout those big endian patches? ;)
497 2012-11-13 19:58:57 <kjj_> like Slackware weird, or QNX weird?
498 2012-11-13 19:59:24 <D34TH> like ppc ubuntu with 64 mb ram weird
499 2012-11-13 19:59:32 <D34TH> old mac g3
500 2012-11-13 19:59:34 <D34TH> lol
501 2012-11-13 19:59:45 <kjj_> ahh.
502 2012-11-13 19:59:48 <D34TH> i set it up next to my rack
503 2012-11-13 20:00:07 <D34TH> it makes the entire circut its plugged into have a floating ground somehow
504 2012-11-13 20:00:22 <kjj_> erm, pretty sure physics doesn't work that way
505 2012-11-13 20:00:29 <D34TH> i cant explain it
506 2012-11-13 20:00:32 <cjd> it shunts power to ground? /o\\
507 2012-11-13 20:00:37 <kjj_> I hope you are cross compiling for that box
508 2012-11-13 20:00:46 <D34TH> no
509 2012-11-13 20:00:49 <D34TH> i dont even use it
510 2012-11-13 20:00:51 <D34TH> its unplugged
511 2012-11-13 20:01:06 <cjd> if it's putting voltage to ground, that's a good thing
512 2012-11-13 20:01:06 <kjj_> oh, so like my Vax then
513 2012-11-13 20:01:12 <D34TH> i'd sell it but shipping would be more than its worth
514 2012-11-13 20:04:11 <sipa> cjd: i don't think anyone managed to let the satoshi code run on BE hw
515 2012-11-13 20:05:09 <cjd> yeah, trying to port it would be enormously painful AFAICT
516 2012-11-13 20:05:21 <kjj_> hey, speaking of endian...  I've always wondered how we get the right hashes
517 2012-11-13 20:06:40 <kjj_> as in, the padding in the midstate appears to be in machine-specific format
518 2012-11-13 20:07:33 <sipa> cjd: i don't think so
519 2012-11-13 20:08:00 <sipa> cjd: i figure it's just direct memory copying in a few places, though they may be well hidden
520 2012-11-13 20:08:23 <sipa> just don't think many people spent efford on it
521 2012-11-13 20:08:57 <cjd> yeah, a lot of it is just the serialization and one could write a filter for that
522 2012-11-13 20:09:07 <sipa> indeed
523 2012-11-13 20:09:19 <cjd> but then there's the sneeky stuff inside of the script and whatnot
524 2012-11-13 20:09:32 <sipa> not sure
525 2012-11-13 20:09:57 <cjd> I made my app all endian independent and now I'm not sure if it was worth all the effort, it seems that little has basicly won the war...
526 2012-11-13 20:10:23 <cjd> except like a fool, I byteswap everything before putting it on the wire
527 2012-11-13 20:14:53 <sipa> ha
528 2012-11-13 20:15:32 <Luke-Jr> sipa: "direct memory copying" is machine-specific :P
529 2012-11-13 20:15:46 <sipa> Luke-Jr: of course
530 2012-11-13 20:16:46 <D34TH> but i wanna copy luke's hashes from his pool and submit them from my client before he sends his
531 2012-11-13 20:25:56 <Luke-Jr> D34TH: sure, GBT makes that possible
532 2012-11-13 20:26:19 <D34TH> but will i get the coins instead of you
533 2012-11-13 20:26:27 <Luke-Jr> no
534 2012-11-13 20:27:37 <D34TH> how does it keep track?
535 2012-11-13 20:27:43 <Luke-Jr> &
536 2012-11-13 20:27:51 <Luke-Jr> hashes encode the payouts&
537 2012-11-13 20:28:31 <D34TH> so, its possible to get payout address of finder?
538 2012-11-13 20:28:40 <helo> (sipa: from a release)
539 2012-11-13 20:28:40 <sipa> sure
540 2012-11-13 20:29:00 <sipa> D34TH: just look at the outputs of the coinbase transaction of a block
541 2012-11-13 20:29:24 <D34TH> berb, starting food combustion
542 2012-11-13 20:53:06 <xIsalty> dammit d34th wheres my coffee
543 2012-11-13 20:54:53 <D34TH> i only make coffee from 04:00-09:00 and 20:00-22:00 ET
544 2012-11-13 20:55:32 <sipa> so many zeroes and colons
545 2012-11-13 20:55:33 <xIsalty> or on those long nights building releases
546 2012-11-13 20:55:41 <sipa> i almost parsed your line as an ipv6 address
547 2012-11-13 20:56:04 <D34TH> lol
548 2012-11-13 20:56:20 <xIsalty> lol
549 2012-11-13 20:57:10 <jgarzik> olo
550 2012-11-13 20:57:37 <sipa> i assume you use RFC 2324 then?
551 2012-11-13 20:59:05 <D34TH> i find if you can combine RFC 2324 with RFC 2549 you can get a really nice smooth brew, with quick delivery.
552 2012-11-13 20:59:53 <sipa> D34TH: i fear collisions...
553 2012-11-13 21:00:16 <D34TH> i fear poop in my coffee, but we roll with the punches
554 2012-11-13 21:02:42 <phantomcircuit> sigh fat fingered ctrl+w for a second
555 2012-11-13 21:02:51 <phantomcircuit> closed a bunch of irc channels
556 2012-11-13 21:03:54 <D34TH> im sorry for your loss
557 2012-11-13 21:05:51 <sipa> may they forever remain silent
558 2012-11-13 21:19:22 <phantomcircuit> sipa, they probably will
559 2012-11-13 21:19:26 <phantomcircuit> THEYRE GONE FOREVER
560 2012-11-13 21:19:32 <phantomcircuit> because i cant tell which ones they were
561 2012-11-13 21:19:34 <phantomcircuit> lol
562 2012-11-13 21:23:42 <denisx> sipa: I am trying to build head on freebsd, but I get errors with leveldb.cpp:33: error: 'NewMemEnv' is not a member of 'leveldb'
563 2012-11-13 21:24:00 <topace> hmmm im having a problem with   bitcoind move  command just hanging
564 2012-11-13 21:24:05 <denisx> I'm using leveldb from the ports, do I need to build it differently?
565 2012-11-13 21:24:15 <helo> leveldb is included with the source
566 2012-11-13 21:24:25 <topace> i see a forum post about the same thing (marked as solved) but there really isnt a valid solution in that thread
567 2012-11-13 21:24:30 <helo> it's been "forked"
568 2012-11-13 21:25:16 <topace> anyone know how to fix the problem? or know what it might be?
569 2012-11-13 21:26:41 <xenland> ew move?
570 2012-11-13 21:27:07 <denisx> topace: maybe it still has to do?
571 2012-11-13 21:27:55 <xenland> I never understood move really, its like Bitcoin is saying "Locally these bitcoins belong to this account, but networkly they belong to this one"
572 2012-11-13 21:29:46 <topace> move just moves things internally between the accounts
573 2012-11-13 21:29:50 <topace> in the local wallet
574 2012-11-13 21:30:00 <topace> shoudlnt be a network operation at all
575 2012-11-13 21:30:25 <sipa> xenland: you mistake accounts for addresses
576 2012-11-13 21:30:39 <sipa> xenland: accounts are purely local and have nothing to do with coins on the network
577 2012-11-13 21:30:55 <sipa> they're just balances that get incremented when coins arrive to an associated address
578 2012-11-13 21:31:17 <xenland> Thats what i said its local and nothing changes "really"
579 2012-11-13 21:31:25 <xenland> Whats the beneifit of doing it?
580 2012-11-13 21:31:26 <topace> sipa: exactly, so why on earth would somethign as simple as an internal move between accounts cause the whole ThreadRPCServer to deadlock?
581 2012-11-13 21:31:43 <sipa> topace: good question...
582 2012-11-13 21:31:43 <topace> xenland: useful for writing apps that interface with the wallet
583 2012-11-13 21:32:04 <topace> xenland: eg. to track user deposits
584 2012-11-13 21:32:11 <sipa> xenland: the fact that you say "locally these bitcoins belong to this account" is a misunderstanding; bitcoins do not belong to an account *at all*
585 2012-11-13 21:32:26 <sipa> xenland: it's just a balance, a single number, it can even be negative
586 2012-11-13 21:32:27 <xenland> Why move it at all then? why not keep it in their deposit address?
587 2012-11-13 21:32:37 <xenland> sipa: okay
588 2012-11-13 21:33:01 <sipa> xenland: if you implement an e-wallet, you can use it to track users' balances, for example
589 2012-11-13 21:33:09 <xenland> Ah
590 2012-11-13 21:33:12 <topace> what i do, is give the user a deposit address, assigned to their account, then when a user balance is >0 (meaning they sent some coins to any one of their addresses), i move the entire balance out of their account into a general "pool" account, and credit the database records accordingly
591 2012-11-13 21:33:55 <topace> its a good way to check "did a user deposit some coins to the web-wallet/web-application
592 2012-11-13 21:34:06 <topace> .. when it works :)
593 2012-11-13 21:34:41 <topace> if move completely hangs, and prevents all other RPC calls, it makes the web-wallet/web-application die pretty fast :(
594 2012-11-13 21:34:55 <xenland> I suppose. I personally just use a DB its more predictable and handles errors well.
595 2012-11-13 21:35:23 <topace> xenland: but you have to interface with the bitcoind to see if coins come in :p
596 2012-11-13 21:35:56 <xenland> topace: Atleast i don't need to use commands that hang on me and that don't really make sense at all to have if you can use a database to save your data
597 2012-11-13 21:36:06 <xenland> :P
598 2012-11-13 21:36:22 <topace> xenland: how would you check for a depsoit?
599 2012-11-13 21:36:55 <xenland> getbalance(address) or do what i do which is ....(one sec)
600 2012-11-13 21:38:12 <xenland> Give out deposit address, make a cronjob that will periodically query bitcoin for getreceivedbyaddress(), subtract the known difference from getrecievedbyaddress() from the current saved mysql data and you'll get how much Bitcoins was funded to the account
601 2012-11-13 21:38:27 <xenland> from that point on you update the customers account balance
602 2012-11-13 21:38:43 <xenland> and then i also make a log file that logs all actions to the database that has to do with finaincials that are all checksumed to prevent tampering
603 2012-11-13 21:38:46 <topace> that assumes you know which address you want to check
604 2012-11-13 21:38:50 <sipa> topace: since what version does move cause a hang?
605 2012-11-13 21:38:54 <topace> what if a user has hundreds of associated addresses
606 2012-11-13 21:38:58 <topace> sipa: 0.7.1
607 2012-11-13 21:39:22 <xenland> topace: the cronjob scanns all addresses and updates where needed, you don't need to know anything
608 2012-11-13 21:39:25 <topace> it _has_ been working fine withn 0.7.1 for other moves
609 2012-11-13 21:39:46 <xenland> topace: just look out for the finished product of this project: https://github.com/Xenland/Bitcoin-Financial-Web-Development-Kit--BFWDK-
610 2012-11-13 21:39:57 <xenland> and You'll see what i mean, it should be finished in the next week
611 2012-11-13 21:39:58 <topace> xenland: crontab that does getreceivedbyaddress() for thousands and thsouands of addresses every few minutes? sounds like aa recipe for scalability disaster
612 2012-11-13 21:40:15 <xenland> The cron tab does ALL addresses
613 2012-11-13 21:40:16 <sipa> topace: i have an idea about what may cause the hang; can you build from source?
614 2012-11-13 21:40:38 <xenland> updates all address information
615 2012-11-13 21:40:49 <xenland> in one run to save CPU cycles
616 2012-11-13 21:41:00 <topace> sipa: not on this server, its a live-wallet for 3 other web-apps im already using it for...
617 2012-11-13 21:41:02 <xenland> all you have to do is just "Query" balance
618 2012-11-13 21:41:10 <xenland> from db
619 2012-11-13 21:41:18 <xenland> but thats my opnion i see you have your own :) we are human
620 2012-11-13 21:41:39 <xenland> Decentralization FOR THE COLONY! lol
621 2012-11-13 21:42:01 <sipa> topace: i can build a binary if you trust me, but no guarantees this fixes it, or doesn't send your coins to mars
622 2012-11-13 21:42:09 <topace> indeed.. i've done some profiling on my live web-wallets, and getreceivedbyaddress COULD take anywhere up to 10 seconds to return an answer.
623 2012-11-13 21:42:24 <topace> so doign that on thsounands of addresses every few minutes simply is not practical
624 2012-11-13 21:43:31 <xenland> Then if you are worry about scaling you shouldn't be using Bitcoin directly at all but i guess thats why you use the "move" command, makes sense now, just not the way i would do it, what happens if someone or a programmer "mislabels" an account... how do you recover? i think about things like that
625 2012-11-13 21:43:43 <topace> sipa: i _can_ build, just worried about breaking my other stuff....
626 2012-11-13 21:44:00 <topace> how do i get exactly bv 0.7.1 from git?
627 2012-11-13 21:44:10 <sipa> git checkout v0.7.1
628 2012-11-13 21:45:47 <topace> k.. got a patch/debug line to add?
629 2012-11-13 21:46:08 <xenland> What good is scalability if you can't recover your customers accounts? :P crap i gotta go now I'll never know the answer
630 2012-11-13 21:46:23 <D34TH> xenland: irc on phone?
631 2012-11-13 21:46:29 <topace> i dont know what yo unmean "recover" accounts
632 2012-11-13 21:46:32 <topace> all the data is still there
633 2012-11-13 21:48:16 <sipa> topace: soon, testing myself
634 2012-11-13 21:49:14 <amiller> what would happen if the difficulty wasn't about zeros but was actually about partial collision with the previous block
635 2012-11-13 21:49:36 <sipa> amiller: would work, afaict
636 2012-11-13 21:49:49 <gmaxwell> amiller: would work, but it would make e.g. DOS prevention somewhat harder.
637 2012-11-13 21:49:53 <amiller> "the first d digits of this block will be equal to the last d digits of the previous block whish is 0x234214
638 2012-11-13 21:49:54 <amiller> "
639 2012-11-13 21:50:19 <sipa> any variable-difficulty constraint on the hash of a block is fine
640 2012-11-13 21:50:23 <amiller> it wouldn't make dos any harder if the commitment were unambiguous like that
641 2012-11-13 21:50:45 <gmaxwell> amiller: it means you have to have the other blocks to do a sniff test, thats all I'm saying.
642 2012-11-13 21:50:58 <gmaxwell> oh which is.. e.g. providing it with it. I suppose.
643 2012-11-13 21:51:19 <sipa> right, it means PoW can't be validated before connecting a block header to the tree
644 2012-11-13 21:51:34 <sipa> which isn't a disaster
645 2012-11-13 21:51:40 <amiller> it's not any different than now
646 2012-11-13 21:51:51 <amiller> i mean it's not any harder than now, i think what you just described isn't a problem sipa
647 2012-11-13 21:52:16 <sipa> it's not a problem for the theoretical security model, no
648 2012-11-13 21:52:17 <amiller> if the format is unambiguous, it's not any harder to parse the message and determine what the collision target should be
649 2012-11-13 21:52:29 <amiller> since you'd have to hash it anyway
650 2012-11-13 21:52:42 <gmaxwell> sipa: even pratically if you always provide the target with it, it would be fine.
651 2012-11-13 21:52:56 <gmaxwell> And actually the prev is in the header, duh. So there you go.
652 2012-11-13 21:53:08 <sipa> Uh.
653 2012-11-13 21:53:38 <sipa> topace: https://github.com/sipa/bitcoin/commits/fixmove
654 2012-11-13 21:53:49 <sipa> it's based directly on top of v0.7.1
655 2012-11-13 21:53:50 <gmaxwell> (and, uh, if it wasn't in the header you'd have a theoretical security problem)
656 2012-11-13 21:54:22 <sipa> Yeah, as I said: uh.
657 2012-11-13 21:54:27 <sipa> :)
658 2012-11-13 21:54:34 <sipa> (read: forget what i said)
659 2012-11-13 21:55:01 <gmaxwell> (because without the header committing to its precise target it becomes advantageous to try to concurrently fork at all points)
660 2012-11-13 21:56:23 <sipa> topace: please let me know if this fixes it
661 2012-11-13 21:56:41 <sipa> i've seen too many reports about move locking up already for it to be a coincidence
662 2012-11-13 21:57:18 <topace> sipa: sorry you'll have to help me with git? (im a svn guy) how do i merge that patch?
663 2012-11-13 21:59:02 <sipa> topace: git remote add sipa http://github.com/sipa/bitcoin.git
664 2012-11-13 21:59:05 <sipa> topace: get fetch sipa
665 2012-11-13 21:59:10 <sipa> topace: git checkout fixmove
666 2012-11-13 21:59:16 <sipa> topace: <build>
667 2012-11-13 22:04:32 <topace> k building (sorry takes a while on the VM)
668 2012-11-13 22:11:45 <topace> wow long time to compile... its a tiny vm that just runs my wallet :p
669 2012-11-13 22:11:50 <topace> not made for development
670 2012-11-13 22:12:09 <sipa> where did the binary it was running come from?
671 2012-11-13 22:13:56 <topace> bitcoin.org's pre-compiled linux-binary
672 2012-11-13 22:18:50 <cjd> what's the status of txn_count ? something that might well be used in the future or a pretty safe bet that it will remain dead?
673 2012-11-13 22:19:24 <sipa> txn_count?
674 2012-11-13 22:19:41 <cjd> the 1 byte field in the header which is always 0
675 2012-11-13 22:19:59 <sipa> eh?
676 2012-11-13 22:20:18 <sipa> oh, i see your confusion
677 2012-11-13 22:20:33 <sipa> that field is to specify the number of transactions
678 2012-11-13 22:20:48 <sipa> in full blocks, it contains the number of transactions that follow
679 2012-11-13 22:20:58 <sipa> but if you only send a block header, it's always 0
680 2012-11-13 22:21:04 <sipa> (since no transaction follow)
681 2012-11-13 22:21:06 <cjd> ahh
682 2012-11-13 22:21:18 <cjd> is it stored on disk?
683 2012-11-13 22:21:21 <sipa> yes
684 2012-11-13 22:21:44 <cjd> because the header has a beautiful 16 byte alignment but it's off by one when you add that uint8
685 2012-11-13 22:21:53 <sipa> it's not a uint8
686 2012-11-13 22:21:55 <sipa> it's a varint
687 2012-11-13 22:22:06 <cjd> oh ok, makes sense
688 2012-11-13 22:22:30 <sipa> but it's always the singly byte 0 when submitting a header
689 2012-11-13 22:23:04 <cjd> I can't really see the reason for storing the tx count, you get a tx and either it hashes into the header or it doesn't, right?
690 2012-11-13 22:23:22 <sipa> it's not part of the header
691 2012-11-13 22:23:34 <sipa> so it's not hashed either
692 2012-11-13 22:23:54 <sipa> it just always follows the header so the parser knows how many transactions to parse
693 2012-11-13 22:24:18 <sipa> block headers are 80 bytes
694 2012-11-13 22:24:25 <cjd> oh ok so it's more for deserialization of the block structure on the wire
695 2012-11-13 22:25:35 <phantomcircuit> huh my bitcoin-alt code cant generate a valid version message anymore
696 2012-11-13 22:25:41 <phantomcircuit> what changed?
697 2012-11-13 22:25:43 <topace> sipa: okay done compiling, just waiting for it to startup
698 2012-11-13 22:26:42 <sipa> phantomcircuit: since when?
699 2012-11-13 22:27:23 <sipa> phantomcircuit: which version does it claim?
700 2012-11-13 22:27:26 <topace> topace@www1:~$ ./bitcoind move sess_lkgsj1v0kep40fad5c8pcg6862 main_pool 2 0
701 2012-11-13 22:27:27 <topace> true
702 2012-11-13 22:27:36 <topace> looks liek that fixed it!
703 2012-11-13 22:27:38 <phantomcircuit> sipa, some bullshit version
704 2012-11-13 22:27:44 <phantomcircuit> i like like 3000 or something dumb
705 2012-11-13 22:27:44 <sipa> phantomcircuit: no answer
706 2012-11-13 22:27:51 <phantomcircuit> i think*
707 2012-11-13 22:28:04 <topace> sipa: thank you so much! lets make sure that gets into 0.7.2 !!
708 2012-11-13 22:28:22 <phantomcircuit> actually i'll just copy/pasta from wireshark
709 2012-11-13 22:28:23 <phantomcircuit> that'll do
710 2012-11-13 22:28:48 <sipa> phantomcircuit: as of february 20, 2012, the earlier support protocol version is 209
711 2012-11-13 22:29:13 <cjd> phantomcircuit: here (pm)
712 2012-11-13 22:29:18 <sipa> topace: well we're already pretty far into doing 0.8.0
713 2012-11-13 22:29:27 <sipa> topace: but perhaps this warrants a 0.7.1.1 or so
714 2012-11-13 22:29:44 <Luke-Jr> sipa: ?
715 2012-11-13 22:29:44 <topace> well, whichever :)
716 2012-11-13 22:29:45 <phantomcircuit> cjd, hehe i have one :)
717 2012-11-13 22:29:51 <cjd> long as you don't mind your code telling bitcoind it's cjdns ;)
718 2012-11-13 22:29:51 <topace> ill update the forum thread too, thanks
719 2012-11-13 22:29:57 <Luke-Jr> I have a few commits on top of 0.7.1 right now, but nothing I seen that's major?
720 2012-11-13 22:30:11 <sipa> Luke-Jr: move causes the rpc thread to lockup
721 2012-11-13 22:30:29 <sipa> Luke-Jr: since CWallet::IncOrderPosNext()
722 2012-11-13 22:30:49 <sipa> it creates a second CWalletDB object, while another is holding the db lock
723 2012-11-13 22:31:02 <Luke-Jr> sipa: is this fixed in master? O.o
724 2012-11-13 22:31:05 <sipa> Luke-Jr: no
725 2012-11-13 22:31:09 <Luke-Jr> ah, that's why I missed it
726 2012-11-13 22:31:25 <sipa> Luke-Jr: i just wrote the fix an hour ago, and it seems to fix the problem for topace
727 2012-11-13 22:31:40 <Luke-Jr> well, when it's in master I'll be sure to merge it into 0.7.x :
728 2012-11-13 22:32:31 <topace> Luke-Jr:  just confirmed it fixed it now :) at least for me
729 2012-11-13 22:32:50 <topace> code looks safe to merge too, from what i know :p (not much, lol)
730 2012-11-13 22:33:49 <sipa> Luke-Jr: #2009
731 2012-11-13 22:39:38 <D34TH> sipa: #2012 the last pull req
732 2012-11-13 22:39:58 <D34TH> the mayans say that it will break our coins
733 2012-11-13 22:40:27 <sipa> D34TH: the last pull req is #2147483647 :p
734 2012-11-13 22:41:12 <D34TH> sipa: why not #18446744073709551615
735 2012-11-13 22:41:13 <cjd> why does everything have to be in little endian all the time?!
736 2012-11-13 22:41:35 <sipa> cjd: no offence, but human digit order is big endian
737 2012-11-13 22:41:57 <sipa> D34TH: that'd take too long :D
738 2012-11-13 22:42:25 <cjd> 18:39 < sipa> D34TH: the last pull req is #2147483647 :p <-- when I see I number like this I immedietly think "oh great I forgot to byte swap it"
739 2012-11-13 22:42:49 <sipa> cjd: nope, that's just 0x7FFFFFFF
740 2012-11-13 22:43:07 <D34TH> why not 0xFFFFFFFF
741 2012-11-13 22:43:23 <sipa> D34TH: that'd take too long :D
742 2012-11-13 22:43:28 <D34TH> lool
743 2012-11-13 22:44:28 <D34TH> 0x07D4
744 2012-11-13 23:08:57 <jgarzik> phantomcircuit: steal code from https://github.com/jgarzik/pynode/tree/master/bitcoin
745 2012-11-13 23:09:01 <jgarzik> phantomcircuit: it's a python bitcoin lib
746 2012-11-13 23:09:33 <jgarzik> phantomcircuit: Very modular; easy to ignore parts you don't care about
747 2012-11-13 23:24:04 <phantomcircuit> jgarzik, yeah i dont really need all that
748 2012-11-13 23:24:43 <jgarzik> phantomcircuit: luckily it is "easy to ignore parts you don't care about"
749 2012-11-13 23:26:38 <phantomcircuit> no i mean the version construction
750 2012-11-13 23:26:43 <phantomcircuit> i only need a static string
751 2012-11-13 23:26:44 <phantomcircuit> lol
752 2012-11-13 23:35:00 <etotheipi_> is there a reason my debug.log file for Bitcoin-Qt is 2.7 GB?
753 2012-11-13 23:35:25 <sipa> do you use -debug ?
754 2012-11-13 23:35:37 <etotheipi_> no
755 2012-11-13 23:35:38 <D34TH> do you ever delete it
756 2012-11-13 23:35:39 <D34TH> ever
757 2012-11-13 23:35:51 <etotheipi_> no, I never delete it
758 2012-11-13 23:35:55 <etotheipi_> I never look at it
759 2012-11-13 23:36:08 <etotheipi_> this is the first time in months I've gone to look at it
760 2012-11-13 23:36:22 <sipa> how long has it been running?
761 2012-11-13 23:36:33 <etotheipi_> I start it and stop it pretty frequently
762 2012-11-13 23:36:49 <sipa> i believe it truncates it at startup if it's too large
763 2012-11-13 23:36:52 <etotheipi_> (testing Armory's capability to handle disconnects, etc)
764 2012-11-13 23:37:07 <etotheipi_> hmmmm
765 2012-11-13 23:37:20 <etotheipi_> I wonder if Armory is somehow inducing enormous log files
766 2012-11-13 23:37:36 <D34TH> i'd say rename it
767 2012-11-13 23:37:39 <D34TH> and start testing
768 2012-11-13 23:37:47 <sipa> just delete it
769 2012-11-13 23:37:55 <D34TH> or that
770 2012-11-13 23:38:08 <sipa> if at startup, the log file is over 10M, only the last 2M are kept
771 2012-11-13 23:38:10 <etotheipi_> hold on, I just closed Bitcoin-Qt and restarting to see if it truncates it
772 2012-11-13 23:38:49 <D34TH> etotheipi_, what version are you running
773 2012-11-13 23:39:09 <sipa> also, it may be interesting to see what kind of messages occur frequently in it
774 2012-11-13 23:39:17 <etotheipi_> what is "getblocks -1 to 00000000000000000000 limit 500" ?
775 2012-11-13 23:39:32 <sipa> a node requesting block headers
776 2012-11-13 23:39:45 <sipa> in particular, one of the "anti blockchain stuck" hacks
777 2012-11-13 23:39:55 <etotheipi_> unfortunately, I see no timestamps anywhere in the log file... that would be useful
778 2012-11-13 23:40:02 <sipa> -logtimestamps
779 2012-11-13 23:40:11 <etotheipi_> oh :)
780 2012-11-13 23:40:16 <D34TH> a new launch option for me to add
781 2012-11-13 23:40:19 <D34TH> sigh
782 2012-11-13 23:40:21 <sipa> undocumented feature
783 2012-11-13 23:40:35 <etotheipi_> okay, so that didn't truncate it
784 2012-11-13 23:40:44 <sipa> that's very strange
785 2012-11-13 23:41:18 <etotheipi_> and it took forever to restart... so maybe it was trying to do something with it
786 2012-11-13 23:42:15 <gmaxwell> Are you sure you don't have debug=1 in your bitcoin.conf?
787 2012-11-13 23:42:17 <etotheipi_> is there any message I can look for with*out* logtimestamps?
788 2012-11-13 23:42:34 <sipa> ?