1 2012-09-06 00:04:08 <sipa> it seems leveldb batch writes aren't fully atomic
2 2012-09-06 00:06:41 <kjj_> that's not entirely surprising
3 2012-09-06 00:07:27 <sipa> well, they are introduced in the documentation under "atomic updates"
4 2012-09-06 00:07:41 <kjj_> heh. atomic is easier to write than to do
5 2012-09-06 00:18:30 <sipa> it's very unfortunate, though
6 2012-09-06 02:21:06 <gmaxwell> I'm baffled by this:
7 2012-09-06 02:21:18 <gmaxwell> especially since this wallet hasn't been used for any crazy stunts.
8 2012-09-06 02:26:28 <jgarzik> -rw------- 1 jgarzik jgarzik 172032 Sep 6 04:21 wallet.dat
9 2012-09-06 02:26:54 <jgarzik> that's one CPU core, testnet3 wallet
10 2012-09-06 02:28:04 <gmaxwell> $ ~/bitcoin/src/bitcoind listtransactions "*" 100000 | grep txid | wc -l
11 2012-09-06 02:28:16 <gmaxwell> (most of them generations)
12 2012-09-06 02:28:50 <gmaxwell> 352 orphan
13 2012-09-06 02:29:29 <jgarzik> 129 here, for listtransactions||
14 2012-09-06 02:30:22 <jgarzik> seems like your wallet.dat should be ~8MB not ~500MB
15 2012-09-06 02:30:29 <gmaxwell> right.
16 2012-09-06 02:32:17 <gmaxwell> gah. okay nevermind. that _is_ the wallet that has a lot of crap in it.
17 2012-09-06 02:44:33 <gmaxwell> so why is it that getinfo/getbalance give different results than getbalance "*" ?
18 2012-09-06 02:46:08 <gmaxwell> and why the heck is getinfo reserving a keypool address?
19 2012-09-06 02:50:53 <jgarzik> gmaxwell: yeah the '*' stuff was always a mess
20 2012-09-06 02:51:19 <jgarzik> keypool behavior is expected too, though I don't recall why
21 2012-09-06 02:52:11 <gmaxwell> I'm remembering '*' being goofy (I know it calculates it entirely differently) but I can't remember why it gives a different result.
22 2012-09-06 02:55:44 <gmaxwell> summing listunspent gives me yet another value. But I think thats some difference in how the number of confirmations test is applied wrt immature inputs.
23 2012-09-06 02:57:16 <jgarzik> getinfo's balance ignores the accounts system
24 2012-09-06 02:59:44 <gmaxwell> and I thought '*' was also, effectively supposted to do that?
25 2012-09-06 03:05:34 <jgarzik> gmaxwell: in theory, but practice differs
26 2012-09-06 03:07:44 <jgarzik> blank account names and '*' as an account name wildcard were awful choices, too, given their usage from the shell
27 2012-09-06 06:58:41 <siefca> hi guys
28 2012-09-06 06:59:10 <siefca> Is the relaying fee implemented or it's just on the Wiki?
29 2012-09-06 06:59:26 <siefca> I'm trying to understand the statement from https://en.bitcoin.it/wiki/Transaction_fees
30 2012-09-06 06:59:31 <siefca> "Relay a transaction to other Bitcoin hosts: 0.0001 BTC"
31 2012-09-06 07:00:15 <siefca> How it's done (if it is implemented)?
32 2012-09-06 07:00:17 <Luke-Jr> siefca: the relayer doesn't get it, but yes
33 2012-09-06 07:00:28 <Luke-Jr> transactions aren't relayed by default unless that fee is met
34 2012-09-06 07:00:39 <siefca> Oh I see
35 2012-09-06 07:00:52 <siefca> So that's some kind of spam protection, a limit
36 2012-09-06 07:01:02 <siefca> Not a reward for being a proxy
37 2012-09-06 07:49:01 <amiller> what's a unit of computation
38 2012-09-06 07:49:57 <amiller> a flops? a hash? a "bit"?
39 2012-09-06 07:49:57 <coingenuity> 1cBit
40 2012-09-06 07:50:00 <amiller> i want to say a bit
41 2012-09-06 07:52:24 <Diablo-D3> amiller: you mean a hash?
42 2012-09-06 07:52:40 <Diablo-D3> or rather, mhash, no one uses any smaller prefix
43 2012-09-06 07:52:53 <Diablo-D3> mhash, ghash, thash, etc
44 2012-09-06 07:53:40 <amiller> what's the closest physical quantity it's associated with
45 2012-09-06 07:53:42 <amiller> probably a joule
46 2012-09-06 07:53:57 <Diablo-D3> joule/watt
47 2012-09-06 07:54:03 <Diablo-D3> or dollar
48 2012-09-06 07:54:34 <amiller> two people working together with a delay in between them have more of it than either of them separately
49 2012-09-06 07:54:39 <Diablo-D3> anyone who does serious financial math does calculations in both mhash/dollar and mhash/watt
50 2012-09-06 07:55:04 <Diablo-D3> if you're not getting enough mhash for your TCO then you have a problem
51 2012-09-06 07:57:38 <amiller> two women can't have a baby in 4.5 months
52 2012-09-06 07:57:51 <AEonCIpher> adoption
53 2012-09-06 07:58:52 <edcba> ok 0.5 baby in 5 monts ?
54 2012-09-06 07:58:55 <edcba> months
55 2012-09-06 08:05:18 <TD> BlueMatt: yt?
56 2012-09-06 08:07:04 <AEonCIpher> wait
57 2012-09-06 08:07:22 <AEonCIpher> are you asking for 0.5 bitcoins for a baby to be delivered in 5 months?
58 2012-09-06 08:09:01 <Varan> I'm trying too parse http://blockchain.info/tx/b57168c6b9bafe1a7a14ffdd3e4069d88e77f5ef41b931d25205b96c309526cf using https://github.com/znort987/blockparser but the last output key cannot be decomrpressed
59 2012-09-06 08:09:11 <Varan> does anyone know what is up with that output?
60 2012-09-06 08:11:47 <TD> it's just a pay-to-pubkey output
61 2012-09-06 08:11:52 <TD> instead of pay-to-address
62 2012-09-06 08:19:55 <siefca> In transactions, each input must be signed to ulock funds, is the whole transaction also signed?
63 2012-09-06 08:37:51 <_dr> siefca: the sig in the input is a signature of the transaction (well, of a hash of the tx)
64 2012-09-06 08:37:59 <_dr> siefca: I think :)
65 2012-09-06 08:43:33 <Joric> it's complicated ) it involves making a copy of the original TX, and modifying/hashing/signing input scripts
66 2012-09-06 08:43:54 <Joric> tx itself is not signed just double hashed
67 2012-09-06 08:49:38 <neofutur> just added an rss price feed tool in the bitcoin simple php tools
68 2012-09-06 08:49:42 <neofutur> example : http://p.b.gw.gd/pricefeed/bitcoin_price_feed.php discussion on https://bitcointalk.org/index.php?topic=68205.msg1164417#msg1164417
69 2012-09-06 08:49:49 <neofutur> comments welcome
70 2012-09-06 08:55:19 <Joric> siefca, or rather, it's signed several times, once for each input )
71 2012-09-06 08:55:47 <sipa> TD: it's not a pay-to-pubkey but a blockchain.info transaction message
72 2012-09-06 08:58:34 <siefca> Thx guys :)
73 2012-09-06 09:04:58 <Varan> sipa, oke ... because the blockparser tool assumed it to be a compressed pub key ... does that look similar?
74 2012-09-06 09:05:37 <Varan> do you have any info on this transaction message stuff?
75 2012-09-06 09:25:46 <TD> sipa: ?
76 2012-09-06 09:25:57 <TD> it's a string?
77 2012-09-06 09:26:02 <TD> "This is a test message."
78 2012-09-06 09:26:17 <TD> that's a stupid feature
79 2012-09-06 09:26:24 <TD> ACTION shakes his head at piuk
80 2012-09-06 09:26:36 <TD> what's wrong with a good old txid->msg database?
81 2012-09-06 09:32:45 <sipa> TD: i've already mailed him
82 2012-09-06 09:32:58 <TD> i didn't get anywhere when i mailed him about his broken qrcodes
83 2012-09-06 09:33:43 <sipa> gavin and matt complained on the forum about it, too
84 2012-09-06 09:37:56 <Varan> sipa, do you have a forum link?
85 2012-09-06 09:39:26 <Varan> http://blockexplorer.com/searchgo/b57168c6b9bafe1a7a14ffdd3e4069d88e77f5ef41b931d25205b96c309526cf blockexplorer also cannot handle it
86 2012-09-06 09:44:10 <Joric> look what he sent to me! https://blockchain.info/tx/3d29f43a3278281192943276049c15e5f0d8c7e75d4d99a4cd6693113a948f48
87 2012-09-06 09:49:14 <sipa> TD: by the way, it seems leveldb batch writes aren't entirely atomic?
88 2012-09-06 09:49:20 <TD> they aren't?
89 2012-09-06 09:49:38 <TD> i think "batch write" means the data gets appended to the log file in one go
90 2012-09-06 09:50:15 <sipa> TD: i'm not completely sure, but i've done some tests with kill -KILL'ing bitcoind while importing blocks, and every 10 tries or so, i end up with a state where the "best block" is not updated, but some of the inputs are already spent
91 2012-09-06 09:50:54 <TD> hmm. that's odd.
92 2012-09-06 09:50:55 <sipa> (and that is always done in one batch
93 2012-09-06 09:51:31 <sipa> if i use smaller batches, the problem occurs less frequently, but still
94 2012-09-06 09:53:27 <sipa> that's not a problem, however; i'm going to try writing the best block first, and at the end a "block update complete" marker, so i can recover from a partial write by using the undo data
95 2012-09-06 09:53:53 <TD> ok. it does sound bogus though
96 2012-09-06 09:54:21 <sipa> well, i may have a programming error too, of course
97 2012-09-06 09:54:41 <sipa> but i don't see how that can cause what i observe
98 2012-09-06 09:55:11 <TD> the api is pretty straightforward. hard to imagine how such a bug could occurr
99 2012-09-06 09:55:13 <TD> occur
100 2012-09-06 09:55:35 <denisx> anybody have seen this? http://pastebin.com/1j1yzQ9S
101 2012-09-06 09:56:25 <edcba> has someone paid ?
102 2012-09-06 09:56:36 <sipa> denisx: assumed to be a hoax
103 2012-09-06 09:57:43 <TD> sipa: have you tried with paranoid_checks=true?
104 2012-09-06 09:58:45 <sipa> hmm, no
105 2012-09-06 09:59:08 <sipa> should try that first
106 2012-09-06 10:00:08 <TD> http://code.google.com/p/leveldb/issues/detail?id=87
107 2012-09-06 10:00:20 <TD> you might also want to try that test
108 2012-09-06 10:01:51 <sturles> Hehe, the full release is currently leading. :-)
109 2012-09-06 10:02:18 <sipa> sturles: ?
110 2012-09-06 10:08:17 <sipa> TD: paranoid_checks doesn't seem to help
111 2012-09-06 10:09:14 <sturles> sipa: I was refering to the link from denisx.
112 2012-09-06 10:09:29 <sturles> Both addresses have received payments.
113 2012-09-06 10:10:16 <sipa> bah
114 2012-09-06 10:12:31 <TD> sipa: yeah i don't see any obvious problems with your code.
115 2012-09-06 10:13:06 <TD> looking at how leveldb is implemented, i don't see any obvious way it can be non-atomic either. writebatches are appended to the log as (simplifying) <length><records> and then applied to the memtable when the log is read back under a lock
116 2012-09-06 10:13:23 <TD> even if somehow only half a writebatch gets sent to the OS (not possible?) it should be detected
117 2012-09-06 10:14:22 <TD> it's definitely not possible that mapCoins contains a mix of coins?
118 2012-09-06 10:15:15 <sipa> hmm, i could test shutting down cleanly after a writebatch, and see if it still occurs
119 2012-09-06 10:15:35 <TD> that's a good idea
120 2012-09-06 10:16:13 <sipa> then again, recovery code that is able to go back to a known-good state may be useful for other occassions as well
121 2012-09-06 10:17:37 <TD> yes but it's still worth investigating this
122 2012-09-06 10:18:43 <sipa> indeed
123 2012-09-06 10:26:18 <TD> sipa: i can raise the matter with sanjay if you can boil down the issue to a standalone test case. leveldb writes are clearly meant to be atomic from the docs and the code
124 2012-09-06 10:26:37 <sipa> TD: good, but i'll investigate further firs
125 2012-09-06 10:26:42 <TD> thanks
126 2012-09-06 10:28:53 <denisx> how do I explain what a bitcoin address is? it is a base58 encoded public key from a public/private keypair?
127 2012-09-06 10:29:14 <kjj_> base58 encoded hash of a public key
128 2012-09-06 10:30:21 <lianj> with a version and checksum
129 2012-09-06 10:32:13 <kjj_> transactions are signed using the private key. to redeem them, the public key must be provided to verify the signature, and the hash of that public key must match the hash in the address so that we know the key pair belongs to the intended recipient
130 2012-09-06 10:34:28 <kjj_> it gets more complicated in P2SH. in P2SH, the address is the hash of the script, which hopefully includes one or more public key hashes
131 2012-09-06 10:34:52 <upb> why are the roles of public and private keys switched tho?
132 2012-09-06 10:34:56 <upb> whats the rationale
133 2012-09-06 10:35:01 <kjj_> what do you mean?
134 2012-09-06 10:35:02 <sipa> switched?
135 2012-09-06 10:35:09 <kjj_> the private keys are kept private
136 2012-09-06 10:35:28 <sipa> and the public keys are public :)
137 2012-09-06 10:35:33 <kjj_> the public keys are kept private for as long as possible too, only released when needed
138 2012-09-06 10:35:42 <upb> 'to redeem them, the public key must be provided to verify the signature'
139 2012-09-06 10:35:49 <sipa> well, yes
140 2012-09-06 10:35:58 <sipa> but primarily, the signature must be provided
141 2012-09-06 10:36:11 <upb> ahhh
142 2012-09-06 10:36:14 <upb> ok
143 2012-09-06 10:36:15 <sipa> the public key is just added as a convenience, because the verified might not yet know it
144 2012-09-06 10:36:20 <sipa> *verifier
145 2012-09-06 10:43:18 <sipa> TD: light evidence that writebatch is indeed atomic; i write the new latest block twice, once before and once after editing the transactions, and they always result in the same, yet the problem remains
146 2012-09-06 10:43:49 <sipa> the second one is even written in a separate batch, and even that one matches
147 2012-09-06 10:44:01 <sipa> so i assume a problem in my code
148 2012-09-06 10:44:01 <TD> "they always result in the same"?
149 2012-09-06 10:44:04 <TD> hm, ok
150 2012-09-06 10:44:06 <TD> good :)
151 2012-09-06 10:44:14 <kjj_> sipa: what is the problem? my scrollback doesn't go deep enough to catch up
152 2012-09-06 10:44:52 <sipa> TD: my assumption was that if a partial write occurred, the first best block would be the new one, but the second one would still be the old one
153 2012-09-06 10:47:12 <denisx> the first transaction to the hoax adress are bitvalues and says "prove it" ;)
154 2012-09-06 10:48:04 <TD> bitvalues?
155 2012-09-06 10:48:23 <kjj_> I assume ASCII after the decimal point
156 2012-09-06 10:49:54 <sipa> TD: text encoded in the txout amounts
157 2012-09-06 10:52:15 <kjj_> ugh. so many people on the forums trying to make services that assume that return to sender is possible
158 2012-09-06 10:52:50 <TD> is it possible, if people don't use shared wallets
159 2012-09-06 10:52:58 <TD> and i think that's a very basic thing that people need to get nailed into their heads
160 2012-09-06 10:53:16 <sipa> even without a shared wallet
161 2012-09-06 10:53:30 <kjj_> that is assuming a whole bunch of other stuff doesn't exist
162 2012-09-06 10:53:32 <sipa> the fact that i send coins from a particular address doesn't mean i accept payments back there
163 2012-09-06 10:53:46 <TD> it means you have the private keys
164 2012-09-06 10:53:50 <sipa> so?
165 2012-09-06 10:53:51 <kjj_> exactly. that's what needs to get drilled into peoples heads
166 2012-09-06 10:53:53 <TD> it may not be convenient for you
167 2012-09-06 10:53:59 <TD> but you can certainly re-claim the new outputs
168 2012-09-06 10:54:16 <sipa> ?agree
169 2012-09-06 10:54:19 <sipa> -?
170 2012-09-06 10:54:28 <sipa> but that doesn't mean it's the right way to do a payment
171 2012-09-06 10:56:44 <TD> sure, it's not ideal, but in practice as long as people don't share wallets it will work with todays setup
172 2012-09-06 10:56:57 <TD> in future a payment protocol is the right fix, as we all seem to have consensus on
173 2012-09-06 10:57:06 <sipa> right
174 2012-09-06 10:57:25 <sipa> i think it's just a bad thing that people build infrastructure that depends on payint back to sender addresses
175 2012-09-06 10:57:29 <sipa> *paying
176 2012-09-06 10:57:46 <sipa> but indeed; payment protocol
177 2012-09-06 11:08:48 <gmaxwell> 05:53 < TD> but you can certainly re-claim the new outputs
178 2012-09-06 11:09:07 <gmaxwell> Even that is iffy, ??? you might have just deleted that wallet.dat after emptying it.
179 2012-09-06 11:09:38 <kjj_> or my favorite, you pay a bill from dividends by directing your brokerage to send coins to an address
180 2012-09-06 11:10:01 <TD> i knew you were going to say that
181 2012-09-06 11:10:07 <gmaxwell> kjj_: sure thats the 'shared wallet' TD mentioned above.
182 2012-09-06 11:10:07 <TD> if you just emptied the wallet there's no point in deleting it
183 2012-09-06 11:10:09 <kjj_> I know, it is pretty much a shared wallet
184 2012-09-06 11:10:25 <TD> i can't think of any reason to ever delete a wallet, actually. unless you're doing software development
185 2012-09-06 11:10:52 <kjj_> I agree, there is no reason to ever delete keys that are out there
186 2012-09-06 11:11:08 <gmaxwell> TD: You say this, but I know people do it. I have dozens of the damn things and I'm currently going through what feels like a herculean effort to go gather up all their damn private keys and merge them.
187 2012-09-06 11:11:33 <kjj_> gmaxwell: infrastructure will spring up around bitcoin, lots of it will act like shared wallets. safe or not, they are here to stay
188 2012-09-06 11:11:52 <sipa> if the infrastructure had been built with a payment protocol, without the assumption that every pubkeyhash ever used by someone implies that's an address they accept payments at, there would not be any reason to keep keys and wallets around forever
189 2012-09-06 11:11:52 <TD> i'm not saying nobody does it. i'm saying they shouldn't :) and yes i know, "return to sender" only works as long as people basically don't do unexpected things that deviate too much from the core design
190 2012-09-06 11:12:03 <TD> i think it was satoshi who said "why would anyone ever delete a wallet?"
191 2012-09-06 11:12:08 <TD> and in normal usage, you never would
192 2012-09-06 11:12:23 <kjj_> gmaxwell: I agree on the wallet management. it is very easy to end up with a messy tangle of wallets
193 2012-09-06 11:12:44 <kjj_> but again, in time, utilities will spring up to manage keys.
194 2012-09-06 11:12:52 <sipa> the necessity to keep keys and wallets alive, and keep scanning every transaction in the world for things that may credit some ancient key, is a major burden
195 2012-09-06 11:13:17 <gmaxwell> TD: or when someone is forming joint-author transactions for anonymization purposes?
196 2012-09-06 11:13:59 <kjj_> I'm thinking that a utility for archiving keys would be great. rather than delete the wallet, you feed it to the tool, it sucks out the keys, dumps the rest. then, once a week or whenever, it scans the chain and sweeps anything it finds into an active address
197 2012-09-06 11:14:13 <TD> those transactions that rely on theoretical non-existent software? :)
198 2012-09-06 11:14:21 <TD> as i said, i'm not against a real solution like a payment protocol
199 2012-09-06 11:14:40 <TD> just pointing out that it's not a bad way to do returns today, if only people didn't insist on letting other people munge their wallets together with other people
200 2012-09-06 11:14:56 <gmaxwell> TD: you can make them by hand with the reference client, I've done some on testnet now with people.
201 2012-09-06 11:15:03 <gmaxwell> They're just not currently automated.
202 2012-09-06 11:16:06 <sipa> it's certainly an easy solution in the current setting
203 2012-09-06 11:18:02 <TD> ACTION gives up :)
204 2012-09-06 11:18:47 <gmaxwell> ACTION continues beating TD's horse
205 2012-09-06 11:21:02 <kjj_> you guys fighting scared off pumpkin. :(
206 2012-09-06 11:30:25 <shamoon> when building bitcoin (master), i get fatal error: miniupnpc/miniwget.h: No such file or directory
207 2012-09-06 11:30:31 <shamoon> but i already installed miniupnpc
208 2012-09-06 11:30:40 <sipa> which OS?
209 2012-09-06 11:31:01 <shamoon> ubuntu
210 2012-09-06 11:31:54 <kjj_> how did you install miniupnpc? package, or source?
211 2012-09-06 11:32:02 <shamoon> downloaded it
212 2012-09-06 11:32:02 <sipa> you need libminiupnpc-dev
213 2012-09-06 11:32:04 <shamoon> and hit make
214 2012-09-06 11:32:17 <kjj_> did you follow up with "make install" ?
215 2012-09-06 11:32:17 <sipa> you install the package
216 2012-09-06 11:32:26 <shamoon> how do i install after make install?
217 2012-09-06 11:32:50 <kjj_> sipa and I are telling you two different ways. he is saying just grab the dev package. it'll be easiest
218 2012-09-06 11:36:11 <shamoon> done
219 2012-09-06 11:36:12 <shamoon> thanks guys
220 2012-09-06 11:45:47 <sipa> TD: strange evidence: the transaction that fails to connect is always the last tx in the last block that was part of the previous batch write...
221 2012-09-06 11:45:53 <Evilmax> cresci btc, cresci! ahahahahaha
222 2012-09-06 12:13:48 <shamoon> ++: internal compiler error: Killed (program cc1plus)
223 2012-09-06 12:13:49 <shamoon> new error
224 2012-09-06 12:13:51 <shamoon> when compiling
225 2012-09-06 12:14:12 <BlueMatt> oom?
226 2012-09-06 12:14:25 <shamoon> ubuntu
227 2012-09-06 12:14:28 <shamoon> bitcoin - master
228 2012-09-06 12:14:30 <BlueMatt> out of memory?
229 2012-09-06 12:14:34 <kjj_> out of memory?
230 2012-09-06 12:14:45 <shamoon> perhaps
231 2012-09-06 12:14:51 <shamoon> how would i know if that's it?
232 2012-09-06 12:14:57 <kjj_> dmesg
233 2012-09-06 12:15:10 <sipa> how much RAM do you have?
234 2012-09-06 12:15:16 <kjj_> if you see a bunch of stuff about the oom-killer, that's what happened
235 2012-09-06 12:15:19 <shamoon> Mem: 604356k total
236 2012-09-06 12:15:40 <kjj_> no swap? yeah, that's not enough to compile bitcoin, hasn't been for a few releases now
237 2012-09-06 12:15:52 <shamoon> Swap: 0k
238 2012-09-06 12:16:07 <kjj_> set up some swap, but it'll be painful.
239 2012-09-06 12:16:17 <BlueMatt> I would have thought 0.7 with the rpc slit stuff would have helped a bit more...
240 2012-09-06 12:16:18 <shamoon> how do i set up swap?
241 2012-09-06 12:16:33 <kjj_> I got more than a day into a compile on my old 512 MB box before I drove in to the colo to add another DIMM
242 2012-09-06 12:16:37 <gmaxwell> BlueMatt: for the most part it just makes the high memory usage happen N times. :P
243 2012-09-06 12:16:55 <kjj_> shamoon: is this a normal box with a hard drive?
244 2012-09-06 12:17:06 <BlueMatt> gmaxwell: ok, so split it further (and dont #include everything this time...)
245 2012-09-06 12:17:14 <shamoon> it's an amazon AMI
246 2012-09-06 12:17:34 <gmaxwell> shamoon: you're probably best off compiling someplace else and copying it over.
247 2012-09-06 12:17:51 <shamoon> just copying bitcoind over?
248 2012-09-06 12:17:53 <gmaxwell> BlueMatt: A lot of it appears to be the template based json library.
249 2012-09-06 12:18:02 <BlueMatt> yea, amazon ec2/ami stuff is incredibly slow
250 2012-09-06 12:18:05 <BlueMatt> gmaxwell: ahhh
251 2012-09-06 12:18:08 <kjj_> I'd throw you a copy of my statically linked bitcoind, but I don't use UPNP
252 2012-09-06 12:18:35 <gmaxwell> well if you just want a binary without changes; you can use the official ones.
253 2012-09-06 12:18:39 <kjj_> then again, I'm not sure if you need that at all on amazon
254 2012-09-06 12:18:47 <shamoon> i want 0.7
255 2012-09-06 12:18:55 <BlueMatt> so grab the official rcs
256 2012-09-06 12:19:04 <shamoon> there's rc's out already?
257 2012-09-06 12:19:05 <shamoon> nice
258 2012-09-06 12:19:07 <BlueMatt> (is rc2 uploaded yet?)
259 2012-09-06 12:19:13 <gmaxwell> shamoon: sure, there are official binaries of that.
260 2012-09-06 12:19:21 <shamoon> oh sweet
261 2012-09-06 12:19:44 <gmaxwell> http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/ though the rc2 binaries aren't all up yet.
262 2012-09-06 12:20:12 <sipa> i did an rc2 build, but didn't compare checksums with anyone
263 2012-09-06 12:20:27 <BlueMatt> Im assuming wumpus' matched mine since they were pushed?
264 2012-09-06 12:20:38 <shamoon> thanks gmaxwell
265 2012-09-06 12:24:28 <sipa> TD: ok, reproduced the error with a clean shutdown; definitely a bug in my code
266 2012-09-06 12:24:53 <gmaxwell> whew.
267 2012-09-06 12:28:51 <gavinandresen> sipa : thanks for building rc2.
268 2012-09-06 12:29:04 <gavinandresen> BlueMatt : can you gitian build 0.7.0rc2 ?
269 2012-09-06 12:29:18 <BlueMatt> gavinandresen: did it last night
270 2012-09-06 12:29:30 <gavinandresen> BlueMatt: cool, output matched sipa?
271 2012-09-06 12:29:36 <BlueMatt> sipa hasnt pushed his yet afaik
272 2012-09-06 12:29:57 <sipa> now i did
273 2012-09-06 12:30:21 <gavinandresen> I uploaded osx rc2 images last night, but can't gitian build right now
274 2012-09-06 12:30:30 <gavinandresen> sipa: are you building using lxc ?
275 2012-09-06 12:30:33 <sipa> yes
276 2012-09-06 12:30:46 <gmaxwell> sipa: Did you happen to record how you got that working?
277 2012-09-06 12:30:48 <sipa> my windows build matches wumpus', but not BlueMatt's
278 2012-09-06 12:30:58 <sipa> gmaxwell: where does it fail?
279 2012-09-06 12:31:12 <sipa> i had a few problems, but those were from not following the FAQ
280 2012-09-06 12:31:18 <sipa> s/FAQ/README/
281 2012-09-06 12:31:34 <gmaxwell> sipa: Something about mounting devices, I don't know??? haven't tried for a while.
282 2012-09-06 12:31:43 <gavinandresen> I'm seeing if I can get lxc running inside a VirtualBox on my mac.... (while I wait for a new hard drive for my kvm machine)
283 2012-09-06 12:32:18 <BlueMatt> sipa: thats not what I see...
284 2012-09-06 12:32:39 <sipa> BlueMatt: how so?
285 2012-09-06 12:32:58 <BlueMatt> sipa: nevermind
286 2012-09-06 12:33:05 <BlueMatt> can I ask why anyone pushed sigs that dont match?
287 2012-09-06 12:33:25 <sipa> i push whatever i get
288 2012-09-06 12:33:51 <BlueMatt> (seems to me like no one cares about protocol for gitian stuff...)
289 2012-09-06 12:34:17 <sipa> what is the protocol for?
290 2012-09-06 12:34:27 <BlueMatt> ie dont push sigs that dont match
291 2012-09-06 12:34:30 <BlueMatt> wait for 3 sigs, etc
292 2012-09-06 12:34:32 <sipa> why not?
293 2012-09-06 12:35:05 <sipa> gmaxwell: can you try again? i may recognize some of the errors i got
294 2012-09-06 12:36:06 <BlueMatt> sipa: it breaks gverify and if there is a problem, it should be fixed, not just push stuff that doesnt match and move on...
295 2012-09-06 12:36:52 <sipa> hmm, ok; i don't use gverify really
296 2012-09-06 12:37:24 <sipa> and if everyone pushes their sigs it's much easier to see whose build deviates
297 2012-09-06 12:37:50 <gavinandresen> yes, pushing non-matching sigs seems like the right thing to do. Fixing problems then pusing AGAIN also seems like the right thing to do
298 2012-09-06 12:37:57 <sipa> if you push first, and wumpus and me get the same hashes that differ from yours, we'll both think we have a problem
299 2012-09-06 12:38:59 <sipa> gavinandresen: let me know how lxc works out
300 2012-09-06 12:39:00 <BlueMatt> ok, so apparently my build (which .bash_history indicates was built with the correct tag) used an old copy of src to build...
301 2012-09-06 12:39:03 <gavinandresen> Seems to me correct protocol is: push what you got. If there's a mismatch, fix it, then push again with a commit message that explains what caused the mismatch.
302 2012-09-06 12:40:19 <BlueMatt> Jun 20 18:12:14 <BlueMatt>\tsipa: please dont push sigs to gitian.sigs if they dont match, it freaks gverify out
303 2012-09-06 12:40:26 <BlueMatt> knew that existed somewhere
304 2012-09-06 12:41:32 <BlueMatt> yea...building with -c bitcoin=0.7.0rc2 built 0.7.0rc1....
305 2012-09-06 12:42:05 <sipa> BlueMatt: i use a script that just dumps the correct source tree into gitian, and uses that
306 2012-09-06 12:42:33 <sipa> oh.. maybe you need -c bitcoin=*v*0.7.0rc2 ?
307 2012-09-06 12:42:40 <BlueMatt> hmm? no
308 2012-09-06 12:43:13 <sipa> that is the tagname, no?
309 2012-09-06 12:43:39 <BlueMatt> yea, but devrandom broke git reset in 74652f1881c662a0343ed37635bc3ad09bc55d2d
310 2012-09-06 12:44:08 <BlueMatt> git checkout -q #{remote["commit"]} && git reset -q --hard to just git reset -q --hard && git clean -q -f -d
311 2012-09-06 12:44:27 <sipa> i'm sure he likes pull requests :)
312 2012-09-06 12:47:28 <gavinandresen> what package is vmbuilder in ?
313 2012-09-06 12:47:42 <BlueMatt> python-vbuilder or something like that iirc
314 2012-09-06 12:47:50 <BlueMatt> (just type vmbuilder in bash and it should tell you)
315 2012-09-06 12:47:53 <sipa> python-vm-builder
316 2012-09-06 12:48:06 <sipa> TD, gmaxwell: ok, bug found and fixed; i can't easily break things by kill -KILL'ing during loadblocks
317 2012-09-06 12:48:09 <gavinandresen> thanks. I'll submit a pull against the gitian-builder/README.md about that....
318 2012-09-06 12:48:22 <TD> yay
319 2012-09-06 12:50:35 <sipa> gmaxwell's idea of a log-structure blockdev to check consistency at arbitrary points in time during a sync would be nice as a test, though
320 2012-09-06 13:00:33 <BlueMatt> sipa/gavinandresen: my point is less dont push your sigs if they seem wrong, my point is... before pushing check your sigs, and compare them to whats already there...if there is a problem diff it and actually look for the issue instead of pushing and not doing anything about it
321 2012-09-06 13:02:15 <gavinandresen> I agree with the "look for the issue" bit. There should be a "troubleshooting.txt" file in gitian.sigs that tells us non-gitian-experts how to do that.
322 2012-09-06 13:02:51 <BlueMatt> diff .../bitcoin-build.assert .../bitcoin-build.assert | grep -v deb | grep -v "^< $"
323 2012-09-06 13:04:04 <gavinandresen> what does that second grep do?
324 2012-09-06 13:04:12 <BlueMatt> get rid of annoying blank lines
325 2012-09-06 13:04:45 <BlueMatt> may need a grep -v "^> $" too, but thats just the command I used a minute ago
326 2012-09-06 13:05:21 <gavinandresen> So a difference is found (I assume...) ... then what?
327 2012-09-06 13:05:35 <BlueMatt> look at the file, if its a binary, do more digging
328 2012-09-06 13:05:36 <gavinandresen> (and don't tell me, put it in a troubleshooting.txt and commit it)
329 2012-09-06 13:05:46 <BlueMatt> ...
330 2012-09-06 13:06:29 <BlueMatt> aside from if its a *.h/cpp, which it just was, the answer would be "do more digging"
331 2012-09-06 13:06:32 <sipa> 1) verify the source is actually identical
332 2012-09-06 13:06:52 <sipa> 2) check whether there are maybe installed packages whose version differs
333 2012-09-06 13:06:55 <gavinandresen> make sure you've got the lastest gitian-builder
334 2012-09-06 13:07:10 <gavinandresen> (ooh, last-est, I kinda like that)
335 2012-09-06 13:07:20 <sipa> last-est?
336 2012-09-06 13:07:25 <sipa> ah!
337 2012-09-06 13:07:26 <gavinandresen> instead of latest
338 2012-09-06 13:07:52 <sipa> the autocorrect function in my visual cortex didn't even emit a warning about that!
339 2012-09-06 13:08:02 <Eliel> :D
340 2012-09-06 13:08:05 <sipa> (read: i missed it)
341 2012-09-06 13:08:24 <BlueMatt> that may be the most convoluted way to say I missed it ive ever seen
342 2012-09-06 13:08:41 <sipa> ACTION will try to be more convoluted next time
343 2012-09-06 13:08:54 <kjj_> BlueMatt: you don't read bash.org, do you?
344 2012-09-06 13:09:02 <BlueMatt> kjj_: ok...point taken
345 2012-09-06 13:10:03 <sipa> BlueMatt: when I was a student, we did this play called 'revue', in which the characters were parodies of the professors... one typical type of joke was giving them very long lines to say something trivial
346 2012-09-06 13:10:18 <BlueMatt> heh
347 2012-09-06 13:12:00 <sipa> like "in addition, we also can't entirely exclude the possibility that there is a chance for ..." instead of "that's possible"
348 2012-09-06 13:12:12 <BlueMatt> yep
349 2012-09-06 13:13:23 <gavinandresen> all right, one make-base-vm done, one to go...
350 2012-09-06 13:13:27 <Diablo-D3> sipa: heh
351 2012-09-06 13:24:12 <TD> tx propagation seems like at least 30 seconds at the moment :(
352 2012-09-06 13:24:23 <TD> at least for a tx i just sent to go from my laptop to my server node (ie two random nodes)
353 2012-09-06 13:25:38 <MC-Eeepc> thats not good
354 2012-09-06 13:26:46 <TD> gavinandresen: how long do you anticipate turnaround time on 0.8 might be?
355 2012-09-06 13:26:48 <MC-Eeepc> not good at all
356 2012-09-06 13:27:05 <MC-Eeepc> perhaps something to do with a dearth of connectable nodes?
357 2012-09-06 13:27:35 <BlueMatt> MC-Eeepc: no, actually, that would probably help (depending on a number of factors)
358 2012-09-06 13:28:34 <MC-Eeepc> how? more connections = less hops to everywhere
359 2012-09-06 13:28:50 <gavinandresen> TD: I dunno... I'd like it to be quicker than the 0.6-0.7 turnaround
360 2012-09-06 13:28:54 <kjj_> I was thinking of making a high speed relay node. little or no checking, just accept connections and pass messages around
361 2012-09-06 13:29:15 <BlueMatt> MC-Eeepc: depending on a number of factors, yes
362 2012-09-06 13:29:15 <gmaxwell> kjj_: Your node will rapidly be blacklisted by all the other nodes.
363 2012-09-06 13:29:29 <kjj_> yeah, that's why I haven't actually done it yet
364 2012-09-06 13:29:35 <BlueMatt> kjj_: you cant relay if you dont check
365 2012-09-06 13:29:44 <gavinandresen> you can, but you shouldn't
366 2012-09-06 13:29:56 <BlueMatt> well, you can do anything, but protocol says no
367 2012-09-06 13:30:20 <gmaxwell> TD: Whatever component of that delay is due to slow validation on spinning disk nodes should be greatly improved by ultraprune decreasing the working-set size.
368 2012-09-06 13:30:35 <gavinandresen> I was thinking about probabilistic checking/relaying this morning....
369 2012-09-06 13:30:51 <BlueMatt> ehhh...bitcoin backbone
370 2012-09-06 13:30:58 <BlueMatt> payment protocols
371 2012-09-06 13:31:05 <BlueMatt> etc, etc
372 2012-09-06 13:31:14 <gavinandresen> ... a rule like "If I've heard about this transaction from lots of my peers, then increase the chance of relaying without checking" might work nicely.
373 2012-09-06 13:31:22 <BlueMatt> why?
374 2012-09-06 13:31:45 <gmaxwell> 'meh'. I mean it might, but I don't think we really need it.
375 2012-09-06 13:31:51 <kjj_> gavinandresen: the problem is that by the time you hear about it from lots of your peers, the less useful it is for you to pass it on
376 2012-09-06 13:31:52 <gavinandresen> no, we don't need it yet
377 2012-09-06 13:32:16 <BlueMatt> I'd argue we dont need it at all if we fix issues like lack of payment protocols
378 2012-09-06 13:32:21 <gmaxwell> I am a bit fond of luke's 'preview' relaying; where you peer explicitly tells you that they didn't check it.
379 2012-09-06 13:32:25 <TD> kjj_: that doesn't help at all. it'd just add latency.
380 2012-09-06 13:32:28 <gavinandresen> kjj_ : if all the peers are doing probabilistic checking, then you get lots of checking at first then less and less....
381 2012-09-06 13:32:37 <gavinandresen> (as it relays across the network)
382 2012-09-06 13:32:38 <BlueMatt> gmaxwell: bitcoin backbone
383 2012-09-06 13:32:52 <TD> i think the ultraprune stuff would likely help
384 2012-09-06 13:33:03 <TD> and just generally offloading signature checking to other cpus
385 2012-09-06 13:33:06 <gmaxwell> TD: I'll eat my hat if it doesn't. :)
386 2012-09-06 13:33:22 <gavinandresen> sure, there are plenty of optimizations to be done first
387 2012-09-06 13:33:32 <BlueMatt> TD: what like threaded sig checking...someone implemented that...oh...
388 2012-09-06 13:33:40 <gmaxwell> Also, node rotation will help, especially if peer performance is included in the decision of what peers get kept.
389 2012-09-06 13:34:01 <gmaxwell> Right now we very likely have nodes that are horribly slow with 124 peers... while there are superfast nodes with just 20 peers.
390 2012-09-06 13:36:57 <TD> it would be useful if a node could push back and say "i'm going to drop you but try peer X"
391 2012-09-06 13:37:06 <TD> and then peers would announce their current load in their addr broadcasts, maybe
392 2012-09-06 13:37:11 <TD> so it can help to load balance the network more evenly
393 2012-09-06 13:40:16 <gmaxwell> At least announcing 'overloaded' might be helpful. It's important to avoid making it possible for an attacker to make their peers much more attractive.
394 2012-09-06 13:40:21 <TD> i'm seeing a ton of transactions in my log with insufficient fees
395 2012-09-06 13:41:00 <gmaxwell> TD: a couple days ago someone was trying some nanopenny flooding dos attack, might be back now.
396 2012-09-06 13:42:09 <TD> it's annoying that the log message doesn't tell you what the txid is of the tx with insufficient fees
397 2012-09-06 13:42:13 <TD> (afaict)
398 2012-09-06 13:48:25 <jgarzik> indeed
399 2012-09-06 13:48:56 <jgarzik> ACTION was thinking the other day that should really log the txid
400 2012-09-06 13:49:18 <jgarzik> as well as the fees -we- think it should have included
401 2012-09-06 13:49:22 <gmaxwell> I suspect we want an in-memory circular buffer for detailed logging (avoiding privacy and space issues)
402 2012-09-06 13:52:11 <jgarzik> we log problem txids for other error situations, so it seems reasonable in the main debug.log here
403 2012-09-06 13:52:48 <jgarzik> problem transactions are the sort of information we should prefer to log
404 2012-09-06 13:53:14 <jgarzik> network anomaly detection
405 2012-09-06 14:05:48 <TD> even at hundreds of blocks per second syncing an entire chain is a drag
406 2012-09-06 14:06:05 <sipa> BlueMatt: did you actually implement parallel signature checking within one block/transaction?
407 2012-09-06 14:08:45 <jgarzik> TD: I think downloading blk*.dat + reindexing will be nicer
408 2012-09-06 14:08:57 <TD> i'm syncing an SPV wallet actually
409 2012-09-06 14:09:01 <jgarzik> TD: sipa mentioned working on a reindexing solution
410 2012-09-06 14:09:04 <jgarzik> ah
411 2012-09-06 14:09:10 <TD> it's still annoyingly slow. because i have keys in the wallet that don't have an associated creation time
412 2012-09-06 14:09:12 <TD> ACTION grumbles
413 2012-09-06 14:10:26 <jgarzik> that's an interesting observation... I could see how knowing ctime would help
414 2012-09-06 14:15:27 <TD> it uses getheaders to scan up to the earliest key creation time faster
415 2012-09-06 14:15:42 <TD> but obv if you have imported any keys without specifying a creation time, it has to start from scratch
416 2012-09-06 14:22:35 <BlueMatt> sipa: it was only per-block, but abstracting it to txes as well would have been pretty easy (throwing tx processing in a callback would have taken 10 seconds)
417 2012-09-06 14:22:52 <gavinandresen> jgarzik: in-memory circular buffer is a great idea, along with an RPC command to dump it....
418 2012-09-06 14:26:20 <gavinandresen> sipa: is it normal to get WARNING: kvm not loaded, this will probably not work out ... when doing a gbuild with USE_LXC=1 ?
419 2012-09-06 14:26:44 <sipa> i suppose i didn't get the warning, as i did have kvm loaded
420 2012-09-06 14:26:51 <sipa> so i can't comment
421 2012-09-06 14:26:54 <gavinandresen> ok
422 2012-09-06 14:27:16 <sipa> MC-Eeepc: new ultraprune+leveldb build ready
423 2012-09-06 14:27:56 <TD> gitian seems extremely complicated for what it does. is the VM really necessary?
424 2012-09-06 14:28:13 <sipa> TD: if you use LXC, no
425 2012-09-06 14:28:38 <MC-Eeepc> sipa changelog?
426 2012-09-06 14:30:53 <MC-Eeepc> its pretty well faster than normal bitcoin up to about 150k then starts choking for me
427 2012-09-06 14:37:55 <sipa> MC-Eeepc: mostly a fix that should make it more robust when crashing (or disk unplugging)
428 2012-09-06 14:38:04 <sipa> MC-Eeepc: also, maybe try using -dbcache=150
429 2012-09-06 14:38:30 <MC-Eeepc> what does that do
430 2012-09-06 14:40:21 <BlueMatt> devrandom: manuall pull-request: my master branch on github (the website wont update...)
431 2012-09-06 14:40:43 <BlueMatt> (for gitian-builder)
432 2012-09-06 14:42:55 <sipa> MC-Eeepc: use a larger memory cache for the coin db
433 2012-09-06 14:43:04 <sipa> so it doesn't need to read from disk
434 2012-09-06 14:44:07 <MC-Eeepc> link?
435 2012-09-06 14:44:32 <sipa> MC-Eeepc: https://bitcoin.sipa.be/builds/ultraprune
436 2012-09-06 14:44:54 <sipa> oh, http, not https
437 2012-09-06 14:45:43 <MC-Eeepc> oki
438 2012-09-06 14:48:02 <Joric> i only can open http not https
439 2012-09-06 14:48:08 <sipa> yes, same
440 2012-09-06 14:48:26 <sipa> i probably never configured an https server
441 2012-09-06 14:48:51 <t7> i have done IIS with https ... :(
442 2012-09-06 14:49:01 <BlueMatt> t7: oh gawd...
443 2012-09-06 14:49:21 <t7> it was at work, not out of choice
444 2012-09-06 14:49:38 <BlueMatt> have to configure IIS -> I would quit
445 2012-09-06 14:49:44 <Joric> hope github pages will get https support i'd even buy a cert... it's rather dangerous to host sites there for now
446 2012-09-06 14:50:04 <BlueMatt> iirc its possible, but you have to use some weird alternate url
447 2012-09-06 14:51:15 <gmaxwell> Joric: IMHO the danger of it has very little to do with it supporting https or not. For all you know even the janitor at github would have access to the server holding those customer supplied certs. Security is more than a URL. :P
448 2012-09-06 14:53:13 <t7> if its got that little padlock in the browser then its unhackable
449 2012-09-06 14:53:34 <sipa> haha
450 2012-09-06 14:53:37 <BlueMatt> hehe
451 2012-09-06 14:53:48 <graingert> hoho
452 2012-09-06 14:54:59 <gmaxwell> (If anything, not using HTTPS means we avoid overstating the security of the site)
453 2012-09-06 14:55:08 <t7> but i thought all the major cert authorities were giving keys to FBI etc?
454 2012-09-06 14:55:36 <graingert> are downloads still served off of freenode?
455 2012-09-06 14:55:43 <t7> i dont know why i think that. Maybe i read it somewhere
456 2012-09-06 14:55:45 <graingert> http://bitcoin.org/ is down?
457 2012-09-06 14:55:52 <gmaxwell> t7: they don't have to; every major government (and quite a few not so major ones) has their own browser-trusted CA.
458 2012-09-06 14:55:56 <BlueMatt> graingert: yea, ddc me and Ill send you "the official binaries"
459 2012-09-06 14:56:04 <gmaxwell> graingert: freenode? 0_o
460 2012-09-06 14:56:05 <graingert> BlueMatt: y down?
461 2012-09-06 14:56:07 <BlueMatt> always remember: the Chinese post office has a ca in your system....
462 2012-09-06 14:56:18 <graingert> sorry
463 2012-09-06 14:56:23 <graingert> I meant urm
464 2012-09-06 14:56:31 <graingert> github crap edition
465 2012-09-06 14:56:32 <t7> gmaxwell: does that mean they can snoop on me?
466 2012-09-06 14:56:39 <graingert> *sourceforge
467 2012-09-06 14:56:49 <t7> github slow edition
468 2012-09-06 14:57:14 <t7> bitbucket looks really cool i need to check it out one day
469 2012-09-06 14:58:14 <Joric> sipa, your ultraprune isn't going to prune my blockchain right away, is it? how to run it?
470 2012-09-06 14:58:20 <graingert> gmaxwell: download packages on github are super nice: https://github.com/downloads/bitcoin/bitcoin/testnet3.zip
471 2012-09-06 14:59:36 <gavinandresen> Yay! LXC-inside-VirtualBox gitian build worked!
472 2012-09-06 14:59:49 <MC-Eeepc> theres a question about this here in the UK right now
473 2012-09-06 15:00:02 <MC-Eeepc> the govt wants to store everything for 12 months
474 2012-09-06 15:00:05 <gmaxwell> t7: it means they can engage in active mitm attacks, same as they could do if your own CA was trecherous.
475 2012-09-06 15:00:22 <MC-Eeepc> the question is are they going to "compell" CAs to make certs for them for gmail and stuff
476 2012-09-06 15:00:42 <gmaxwell> sipa: perhaps ultraprune needs to be renamed.
477 2012-09-06 15:01:00 <t7> if i got the cert from the site themselves, then im safe, right? you never give a private key to the CA?
478 2012-09-06 15:01:51 <t7> MC-Eeepc: im gonna max out my bandwidth from random.org
479 2012-09-06 15:01:58 <t7> fucking government
480 2012-09-06 15:02:28 <gmaxwell> t7: right. At least until someone copies the private key off the server and then decrypts the traffic they logged from you months ago.
481 2012-09-06 15:02:38 <gmaxwell> (Almost no one uses the DHE ciphersuites with SSL)
482 2012-09-06 15:02:40 <MC-Eeepc> yeh the tories were dead against it when labour was in and it was called IMP
483 2012-09-06 15:02:45 <BlueMatt> gmaxwell: except google
484 2012-09-06 15:02:55 <MC-Eeepc> now tories are in and hey suprise, its called CCDP and theyre all for it
485 2012-09-06 15:03:25 <t7> i guess this is about money rather than actually wanting to monitor comms
486 2012-09-06 15:03:38 <MC-Eeepc> points to shady actors in the security establishment making thier desires known to whatever govt gets in
487 2012-09-06 15:03:42 <t7> same contractor has MPs in his pockets
488 2012-09-06 15:03:45 <MC-Eeepc> IE people we cannot vote out
489 2012-09-06 15:04:02 <gavinandresen> graingert: github https:// redirects to non-SSL http://cloud.github.com/....
490 2012-09-06 15:04:42 <MC-Eeepc> its about money to the DPI box contractors who have made a killing in the middle east and asia, and are now looking to open up a domestic market
491 2012-09-06 15:05:15 <graingert> gavinandresen: well that's dangerous
492 2012-09-06 15:05:23 <graingert> gavinandresen: I still get bluebar
493 2012-09-06 15:05:47 <graingert> *greenbar
494 2012-09-06 15:07:00 <gavinandresen> graingert: github should fix their redirects, I think. They're using Amazon's cloudfront, which does support https. I think.
495 2012-09-06 15:07:04 <kjj_> the sooner the insane SSL PKI/CA model dies, the better.
496 2012-09-06 15:07:33 <BlueMatt> kjj_: go write a 15th anti-ca standard to help the process along ;)
497 2012-09-06 15:07:46 <BlueMatt> (xkcd #927)
498 2012-09-06 15:09:08 <graingert> it's all about namecoinsec
499 2012-09-06 15:09:11 <MC-Eeepc> trustcoin?
500 2012-09-06 15:11:56 <TD> no block for 40 minutes? :( poolsize 2735
501 2012-09-06 15:12:30 <TD> Joric: no it does not free up any disk space, indeed
502 2012-09-06 15:12:39 <TD> Joric: or not much anyway. leveldb is more efficient on-disk than bdb, it seems
503 2012-09-06 15:15:07 <TD> it looks like the network is now constantly falling behind
504 2012-09-06 15:15:13 <Joric> seems it created blktree/blocks/coins subdirectories must be it
505 2012-09-06 15:15:14 <TD> blocks are only including a few hundred transactions
506 2012-09-06 15:15:22 <TD> but the mempool routinely contains thousands
507 2012-09-06 15:17:12 <MC-Eeepc> thats sounds bad
508 2012-09-06 15:17:25 <gmaxwell> meh, depends on what the transactions are.
509 2012-09-06 15:21:50 <TD> ok, that block just cleared 1000
510 2012-09-06 15:21:53 <TD> but the pool still has 2000 in it :(
511 2012-09-06 15:22:22 <MC-Eeepc> why cant they all go in
512 2012-09-06 15:23:08 <MC-Eeepc> oh wait each miner mines what it wants
513 2012-09-06 15:23:12 <TD> yes
514 2012-09-06 15:23:20 <MC-Eeepc> as long as its under the hash target
515 2012-09-06 15:23:22 <TD> i guess most pools by now have artificially limited block size
516 2012-09-06 15:23:36 <TD> unless the issue is the limited free-tx space
517 2012-09-06 15:23:47 <TD> i don't recall the exact rules for tx inclusion, gavin tweaked them for 0.7 anyway
518 2012-09-06 15:24:05 <BlueMatt> we need a bitcoin-backbone
519 2012-09-06 15:24:05 <MC-Eeepc> when propagation times are 30 seconds, isnt there an incentive to leep your blocks small so that you win a race
520 2012-09-06 15:24:14 <BlueMatt> MC-Eeepc: yes
521 2012-09-06 15:24:48 <MC-Eeepc> if bitcoin backbone is what i think it is you can stuff it
522 2012-09-06 15:24:50 <TD> 30 seconds for a _single transaction_
523 2012-09-06 15:24:52 <TD> it's larger for blocks
524 2012-09-06 15:24:56 <TD> which is why pools are throttling the block size
525 2012-09-06 15:24:59 <TD> so they win races ....
526 2012-09-06 15:25:16 <BlueMatt> MC-Eeepc: then you dont understand the purpose
527 2012-09-06 15:25:24 <TD> lol
528 2012-09-06 15:25:28 <TD> the backbone makes technical sense
529 2012-09-06 15:25:58 <MC-Eeepc> why does the entire winning block have to be passed around, why not just transmit what txns make the block that everyone already has in the mempool
530 2012-09-06 15:26:08 <BlueMatt> Ive seen too many people say "but it ruins the p2p nature of bitcoin!!!111one"
531 2012-09-06 15:26:28 <BlueMatt> MC-Eeepc: Ive got a branch for that...if you want to finish it
532 2012-09-06 15:26:39 <kjj_> MC-Eeepc: not everyone has the same transactions. there isn't "a mempool", each node has a potentially different pool
533 2012-09-06 15:26:43 <TD> BlueMatt: what needs to be finished?
534 2012-09-06 15:26:53 <BlueMatt> TD: its horribly non dos-resistant
535 2012-09-06 15:27:00 <TD> how so?
536 2012-09-06 15:27:21 <BlueMatt> TD: Ive been thinking Ill probably rip out the block as v<tx hash> stuff and deal with that later so the bloom stuff can get in quicker
537 2012-09-06 15:27:36 <TD> or leave the code in but just disabled, with a comment explaining why?
538 2012-09-06 15:27:51 <MC-Eeepc> well if a node cant make the block because he lacks txns, just request the full thing from one that can
539 2012-09-06 15:27:52 <BlueMatt> TD: it doesnt take into account nodes sending you blocks and not giving you the txes, etc, etc
540 2012-09-06 15:28:00 <TD> MC-Eeepc: the issue isn't bandwidth at the moment, it's the disk IO, that's why sipa has been working on it
541 2012-09-06 15:28:05 <MC-Eeepc> even then it should help
542 2012-09-06 15:28:05 <sipa> gmaxwell: yes; how about "turbo_edition" ?
543 2012-09-06 15:28:06 <TD> BlueMatt: oh, i see.
544 2012-09-06 15:28:12 <BlueMatt> TD: but I was gonna go back and fix the block downloading stuff big-time while I was at it, so...I got distracted
545 2012-09-06 15:28:23 <TD> MC-Eeepc: that's what matts work does. it's a good idea and already thought of
546 2012-09-06 15:28:25 <BlueMatt> (deuplicate block requests, etc)
547 2012-09-06 15:28:37 <MC-Eeepc> goddammnit i will never have an original idea
548 2012-09-06 15:28:40 <TD> :)
549 2012-09-06 15:28:42 <TD> no you will
550 2012-09-06 15:28:47 <BlueMatt> MC-Eeepc: welcome to the club ;)
551 2012-09-06 15:28:59 <TD> you're getting very close to the cutting edge ;)
552 2012-09-06 15:29:16 <BlueMatt> ACTION doesnt think he's ever had an original idea when it came to bitcoin...
553 2012-09-06 15:29:26 <MC-Eeepc> bro i barely know how this shit works anyway and ive been here 2 years
554 2012-09-06 15:29:47 <TD> ideas are cheap. implementations are expensive.
555 2012-09-06 15:30:08 <MC-Eeepc> what is this backbone then
556 2012-09-06 15:30:20 <TD> ACTION -> home
557 2012-09-06 15:30:35 <BlueMatt> MC-Eeepc: it is what you are thinking, but its only there to help propagation times and ensure stability for big miners/merchants
558 2012-09-06 15:30:49 <BlueMatt> they will still be a part of the p2p network, and that will still exist as an important part of bitcoin
559 2012-09-06 15:31:26 <MC-Eeepc> im not enthralled
560 2012-09-06 15:32:02 <MC-Eeepc> then you have a bitcoi that will turn to shit if said backbone disappers
561 2012-09-06 15:32:19 <BlueMatt> nope, thats why the p2p network still exists
562 2012-09-06 15:32:22 <MC-Eeepc> then you have a group of actors with more influence then anyone else
563 2012-09-06 15:32:28 <BlueMatt> think of it as simply short-circuiting the p2p network to increase propagation times ie making it easy for miners to get direct connections to each other
564 2012-09-06 15:32:54 <MC-Eeepc> if huge miners want to directly peer thats thier business
565 2012-09-06 15:32:56 <BlueMatt> I work under the assumption that the backbone would have public-facing nodes (providing they dont get too much ddos) for p2pool/etc miners
566 2012-09-06 15:33:02 <MC-Eeepc> whats that got to do with devs
567 2012-09-06 15:33:29 <BlueMatt> not much, but it would be nice if someone with no/little vested interest ran it (ie a dev)
568 2012-09-06 15:33:39 <BlueMatt> (and someone who had a ton of bitcoin experience)
569 2012-09-06 15:33:39 <gmaxwell> MC-Eeepc: well apparently the pools are too convinced that their competition is going to DDOS them or whatever, and so they're not actually able to cooperate it seems.
570 2012-09-06 15:33:52 <gmaxwell> But otherwise it doesn't; it's just another thing that can exist in the ecosystem.
571 2012-09-06 15:34:08 <MC-Eeepc> ok
572 2012-09-06 15:34:30 <MC-Eeepc> matt made it sound like devs getting involved in network topology
573 2012-09-06 15:35:01 <BlueMatt> its just us encouraging more direct connection between large actors
574 2012-09-06 15:35:10 <BlueMatt> s/us/anyone/
575 2012-09-06 15:35:17 <MC-Eeepc> it sunds like something they could do already with addnode etc, except for the whle game theory shit
576 2012-09-06 15:35:56 <BlueMatt> thats why devs make a "backbone" to encourage it
577 2012-09-06 15:36:07 <BlueMatt> also, a backbone means it is possible for p2pool miners to get in on it
578 2012-09-06 15:36:17 <BlueMatt> otherwise they would be locked out of such direct peering agreements
579 2012-09-06 15:36:51 <MC-Eeepc> i just dont like it
580 2012-09-06 15:37:02 <gmaxwell> Don't like what?
581 2012-09-06 15:37:06 <MC-Eeepc> pools are not meant to be around forever
582 2012-09-06 15:37:19 <gmaxwell> They're not 'meant' to be around at all.
583 2012-09-06 15:37:32 <gmaxwell> But good luck with that!
584 2012-09-06 15:37:34 <BlueMatt> MC-Eeepc: great, so the backbone would connect p2pool miners more directly then
585 2012-09-06 15:37:52 <BlueMatt> MC-Eeepc: it would also connect in large merchants who are concerned about being cut off the network
586 2012-09-06 15:38:20 <gmaxwell> BlueMatt: I think I missed why you're talking about this?
587 2012-09-06 15:38:41 <BlueMatt> the propagation times came up again
588 2012-09-06 15:38:46 <MC-Eeepc> if you can work out a way for this backbone to set itself up automatically based on node quality/bandwidth/whatever then fine
589 2012-09-06 15:38:54 <MC-Eeepc> if someoone has the keys, fuck that shit
590 2012-09-06 15:39:01 <BlueMatt> (and, as always, I bitched and moaned that we should do stuff like a backbone to see if we need other further fixes first)
591 2012-09-06 15:39:38 <gmaxwell> MC-Eeepc: I think bluematt has managed to confuse you. 'has the keys' makes no sense in the context of what bluematt is talking about.
592 2012-09-06 15:39:58 <gmaxwell> MC-Eeepc: he's talking about some people setting up some well maintained nodes, and prodding major sites to add node them. Thats pretty much it.
593 2012-09-06 15:40:26 <MC-Eeepc> yeah, how is tht the business of devs?
594 2012-09-06 15:40:44 <BlueMatt> its not, its the business of "someone"
595 2012-09-06 15:40:46 <gmaxwell> (And doing so should make the average bitcoin propagation time lower because it will improve connectivity)
596 2012-09-06 15:40:48 <sipa> BlueMatt: are you talking about jgarzik's backbone?
597 2012-09-06 15:41:02 <BlueMatt> sipa: or a backbone, but jgarzik is the furthest along on the planning afaik
598 2012-09-06 15:41:41 <gmaxwell> MC-Eeepc: its the business of whomever wants to work on it; preferably someone who's avoided other conflicts of interest, however.
599 2012-09-06 15:41:47 <BlueMatt> MC-Eeepc: specifically, its the business of someone with little/no vested interest in a particular pool/merchant/etc and who knows a lot about bitcoin...
600 2012-09-06 15:42:06 <BlueMatt> MC-Eeepc: as it turns out, that description matches many of the devs pretty closely
601 2012-09-06 15:42:24 <MC-Eeepc> so you would pay no thought to perhaps getting some holepunching in there to improve interconnectedness in general, and whatver other net wide optimisations to keep the prop time down, like the mempool block build thing
602 2012-09-06 15:42:43 <BlueMatt> whole punching wouldn't help
603 2012-09-06 15:42:48 <BlueMatt> again, we have plenty of listening nodes now
604 2012-09-06 15:43:10 <sipa> ACTION punches BlueMatt wholly
605 2012-09-06 15:43:20 <BlueMatt> sorry...
606 2012-09-06 15:43:23 <sipa> :p
607 2012-09-06 15:44:04 <Joric> most routers don't support hole punching nowadays, fucking iptables - port restricted nat
608 2012-09-06 15:44:11 <gmaxwell> MC-Eeepc: can you please refrain from instantly resorting to the accusatory tone? _We're constantly discussing techical performance improvements in here, you must know this if you're reading at all_
609 2012-09-06 15:44:43 <gmaxwell> MC-Eeepc: Fortunately multiple things can happen at once.
610 2012-09-06 15:44:57 <BlueMatt> (and if we did whole punching, the level of complaints over anonymity would be /HUGE/)
611 2012-09-06 15:45:13 <MC-Eeepc> sorry
612 2012-09-06 15:45:20 <gmaxwell> Well we _do_ do a kind of hole punching, thats what UPNP does.
613 2012-09-06 15:45:37 <BlueMatt> well, I was thinking udp/tcp hole punching
614 2012-09-06 15:45:44 <MC-Eeepc> but i dont know if some of you guys realise what you hold in your hands sometimes
615 2012-09-06 15:45:53 <BlueMatt> in the more traditional sense of udp hole punching (which is also somewhat possible with tcp)
616 2012-09-06 15:46:00 <MC-Eeepc> just saying, direct peering etc is what got us the present global money system
617 2012-09-06 15:46:06 <gmaxwell> And yea, I don't think I've seen evidence that we need more listening nodes at the moment. There is a large base of broken/delayed listening nodes.
618 2012-09-06 15:46:43 <gmaxwell> and I wish we knew why.
619 2012-09-06 15:47:15 <BlueMatt> ACTION constantly wishes we could add a nice little "send details about my system back to bitcoin.org" feature in bitcoin-qt/bitcoind...
620 2012-09-06 15:47:27 <BlueMatt> (obv we cant, before someone yells at me...)
621 2012-09-06 15:47:33 <MC-Eeepc> bittorrent makes a bloody good job of the hole punching stuff, to the point where no one bothers forwarding ports and it makes no difference
622 2012-09-06 15:47:52 <MC-Eeepc> it was worse at it than FTP to begin with
623 2012-09-06 15:48:08 <BlueMatt> its hard to be worse than ftp when it comes to port forwarding/hole punching...
624 2012-09-06 15:48:24 <gmaxwell> gavinandresen: You got that press contact under control?
625 2012-09-06 15:48:39 <MC-Eeepc> the first torrent client i treid demanded an open port for every single torrent
626 2012-09-06 15:49:47 <gavinandresen> gmaxwell: happily, she's already reported everthing I told her (I didn't tell her anything beyond "something interesting will happen")
627 2012-09-06 15:50:14 <MC-Eeepc> i jsut kind of wonder if bitcoin could be globally managing its connetions in a more intelligent way
628 2012-09-06 15:50:22 <MC-Eeepc> than pretty much random
629 2012-09-06 15:50:29 <gavinandresen> no, impossible, it is perfect as it is right now.
630 2012-09-06 15:50:59 <Joric> tested udp punchthrough in my game - 2/3 players weren't be able to connect with each other, mostly iphone users then ppl behind iptables
631 2012-09-06 15:51:11 <gavinandresen> I keep saying I want to see a bitcoin fork that uses a completely different network protocol to pop up (and interconnect)
632 2012-09-06 15:51:34 <gmaxwell> MC-Eeepc: you puzzle me. :P You freak out because BlueMatt mentions some people running stable nodes; and then you go on to propose that there should be some kind of global master control of the overall topology. :P
633 2012-09-06 15:51:49 <MC-Eeepc> nothing of the sort
634 2012-09-06 15:52:09 <gmaxwell> gavinandresen: I have a node connected over RS232 at home now, using basically the raw transactions API.
635 2012-09-06 15:52:34 <MC-Eeepc> some sort of algorithm in each client which selects good nodes out of the thousands it may try, and keeps them around
636 2012-09-06 15:52:35 <gmaxwell> I guess I should publish the shim programs for that.
637 2012-09-06 15:52:36 <gavinandresen> gmaxwell: cool. Now you just need to run RS232 wires to all the major exchanges and miners....
638 2012-09-06 15:52:55 <gmaxwell> gavinandresen: "I know! we could use bluetooth!"
639 2012-09-06 15:53:03 <sipa> ACTION proposes RFC 1149 links
640 2012-09-06 15:53:10 <MC-Eeepc> perhaps when added up, this effect would automatically create a backbone out of whats already out there
641 2012-09-06 15:53:15 <gavinandresen> 1149 is pigeons? Good idea!
642 2012-09-06 15:53:24 <MC-Eeepc> centralisation in a comletely decentralisd and uncontrollable way
643 2012-09-06 15:53:29 <MC-Eeepc> and people are still free to addnode and shit
644 2012-09-06 15:53:48 <sipa> so, how is that different from what we have?
645 2012-09-06 15:54:12 <MC-Eeepc> i dont know, nodes are random right now right?
646 2012-09-06 15:54:20 <sipa> not really random
647 2012-09-06 15:54:34 <sipa> i mean: yes, really random, but far from uniformly random
648 2012-09-06 15:54:56 <BlueMatt> MC-Eeepc: ok...that may beat it
649 2012-09-06 15:55:09 <gmaxwell> Weird looking node in the seeds list: 46.166.138.142:9901 100.00% 100.00% 100.00% 88.69% 39.86% 3883 60002 "/Satoshi:0.6.3/"
650 2012-09-06 15:55:15 <MC-Eeepc> BlueMatt ??
651 2012-09-06 15:55:35 <gmaxwell> 188.165.73.246:9901 100.00% 100.00% 100.00% 88.62% 39.77% 3888 60002 "/Satoshi:0.6.3/"
652 2012-09-06 15:56:03 <BlueMatt> MC-Eeepc: the torrent/ftp comparison
653 2012-09-06 15:56:04 <sipa> MC-Eeepc: in other words: if you use an algorithm that deterministically maximizes optimal connectivity, i think your network becomes a lot more prone to sybil/dos attacks
654 2012-09-06 15:56:05 <gmaxwell> sipa: hey, I bet those are PPCOIN nodes. I sure hope your seeder filters by height now.
655 2012-09-06 15:56:16 <BlueMatt> gmaxwell: how is that weird?
656 2012-09-06 15:56:17 <sipa> gmaxwell: no
657 2012-09-06 15:56:26 <sipa> 0.6.3 is 60001 no, not 60002?
658 2012-09-06 15:56:42 <gmaxwell> sipa: erk. well I guess the port number keeps them harmless for us.
659 2012-09-06 15:57:03 <gmaxwell> BlueMatt: height 3883 and proto 60002 + Satoshi:0.6.3
660 2012-09-06 15:57:08 <sipa> ACTION food
661 2012-09-06 15:57:26 <MC-Eeepc> sipa probably, but the same would be true for a backbone created of the will of men, and not algorithmicly right?
662 2012-09-06 15:57:32 <BlueMatt> gmaxwell: ok...yea, a bit odd
663 2012-09-06 15:58:03 <gmaxwell> MC-Eeepc: You should probably forget bluematt mentioned that. It's not something that would exist instead of the normal p2p network.
664 2012-09-06 15:58:30 <gmaxwell> and yes, any such thing would be astonishingly vulnerable to some kinds of attacks... but only in isolation.
665 2012-09-06 15:58:41 <BlueMatt> gmaxwell: maybe just a weird commit that we never released as a release?
666 2012-09-06 15:59:09 <gmaxwell> BlueMatt: there are 83 such nodes.
667 2012-09-06 15:59:29 <MC-Eeepc> what about in the future when the backbone is the only way to actually get stuff done, and you can try the general network but good luck mining/running a business on that
668 2012-09-06 15:59:31 <BlueMatt> gmaxwell: ok...yea, thats pretty strange...
669 2012-09-06 15:59:54 <MC-Eeepc> would that not replace the p2p net de facto, for those that actually want to do anything
670 2012-09-06 15:59:56 <gmaxwell> MC-Eeepc: what about in the future when diabolical aliens insert their mind control probes into your head????? WHAT THEN?
671 2012-09-06 16:00:19 <MC-Eeepc> thats jsut sily :<
672 2012-09-06 16:00:32 <ThomasV> that's not future. maybe past
673 2012-09-06 16:00:49 <gmaxwell> BlueMatt: it's ppcoin.
674 2012-09-06 16:01:19 <BlueMatt> its...wtf?
675 2012-09-06 16:01:28 <gmaxwell> genuses didn't change their magic. Or their version string.
676 2012-09-06 16:01:35 <BlueMatt> ahh...wow
677 2012-09-06 16:02:02 <MC-Eeepc> sipa was this meant to be faster with dbcache 150 or something?
678 2012-09-06 16:02:12 <gmaxwell> MC-Eeepc: that was the guess.
679 2012-09-06 16:03:51 <gmaxwell> I wonder if nodes should stop listening or at least stop announcing if their best block is more than N days old.
680 2012-09-06 16:05:34 <jgarzik> stop announcing
681 2012-09-06 16:06:38 <MC-Eeepc> is there any way to watch the logfile live
682 2012-09-06 16:06:47 <gavinandresen> gmaxwell: 83 ppcoin nodes? that's about 10x more than I would've predicted
683 2012-09-06 16:06:54 <D34TH> tail -f ~/.bitcoin/debug.log
684 2012-09-06 16:07:08 <MC-Eeepc> on windows
685 2012-09-06 16:07:26 <gmaxwell> gavinandresen: I wish we could get that many testnet nodes. :P
686 2012-09-06 16:07:33 <D34TH> do you have msys?
687 2012-09-06 16:07:47 <MC-Eeepc> whats that
688 2012-09-06 16:08:21 <D34TH> MC-Eeepc, http://www.mingw.org/wiki/MSYS
689 2012-09-06 16:28:08 <sipa> MC-Eeepc: indeed
690 2012-09-06 16:30:45 <leotreasure_> does bitcoin still connect to other clients via irc?
691 2012-09-06 16:32:29 <gmaxwell> leotreasure_: Not unless users manually enable it. It never really 'connected to [...] via irc' it just used IRC channel activity to find online nodes which it connected to out of band.
692 2012-09-06 16:33:28 <gmaxwell> leotreasure_: any reason you ask?
693 2012-09-06 16:33:47 <leotreasure_> i'm giving a talk on Bitcoin next week
694 2012-09-06 16:34:05 <leotreasure_> wanted to find out a bit more about the technical workings
695 2012-09-06 16:34:27 <leotreasure_> what is the default method of connecting currently?
696 2012-09-06 16:34:50 <sipa> it connects to peers it knows
697 2012-09-06 16:34:54 <BlueMatt> it is, and always has been, to connect to nodes you've previously heard of/connected to
698 2012-09-06 16:34:57 <jgarzik> leotreasure_: you plumb your local database of known peers
699 2012-09-06 16:35:06 <jgarzik> leotreasure_: and exchange peers with other connected peers
700 2012-09-06 16:35:32 <sipa> and it gets them from DNS seeding, from -addnode if specified, from peer exchange, and ultimately (if all else fails) from a hardcoded list
701 2012-09-06 16:36:01 <leotreasure_> i think i read somewhere that addnode was omitted in the upcoming 0.7.0 version or was that just for ipv6?
702 2012-09-06 16:37:12 <gmaxwell> I have no idea what you were reading.
703 2012-09-06 16:37:28 <BlueMatt> hes thinking of the addnode control via rpc
704 2012-09-06 16:38:11 <BlueMatt> addnode has been in for a while, controlling the list of addnode entries via rpc...hasnt
705 2012-09-06 16:38:34 <leotreasure_> ok nm probably not too important for general overview talk
706 2012-09-06 16:39:10 <leotreasure_> what's the network protocol that bitcoin communicates over please?
707 2012-09-06 16:39:29 <leotreasure_> or is it bitcoin per se?
708 2012-09-06 16:39:43 <BlueMatt> ip/tcp/bitcoin
709 2012-09-06 16:39:54 <jgarzik> leotreasure_: -addnode existed pre-0.7, and continues to work in 0.7+
710 2012-09-06 16:40:07 <jgarzik> leotreasure_: an addnode RPC has been proposed, but not merged. it is likely to be merged..
711 2012-09-06 16:40:28 <leotreasure_> thanks guys
712 2012-09-06 16:45:36 <gmaxwell> OH!!!!
713 2012-09-06 16:45:47 <gmaxwell> thats why he was talking about.
714 2012-09-06 16:46:05 <BlueMatt> bit of lag time there...
715 2012-09-06 16:52:06 <gmaxwell> bitcoind listunspent 1 9999999 | grep 'scriptPubKey' | sort | uniq -c | sort -n produces some fun output.
716 2012-09-06 16:52:24 <gmaxwell> apparently I have some txouts with hundreds uses.
717 2012-09-06 17:49:47 <BlueMatt> ;;later tell TD in case you are interested, I went ahead and pulled out the block-as-v<tx hash> stuff and pull requested the rest of the bloom stuff (https://github.com/bitcoin/bitcoin/pull/1795)
718 2012-09-06 17:49:47 <gribble> The operation succeeded.
719 2012-09-06 18:00:15 <gavinandresen> 0.7.0rc2 binaries up on sourceforge...
720 2012-09-06 18:08:15 <BlueMatt> gavinandresen: missing linux?
721 2012-09-06 18:09:03 <gavinandresen> BlueMatt: thanks, uploading now....
722 2012-09-06 18:23:51 <Luke-Jr> gmaxwell: ping
723 2012-09-06 18:24:36 <gmaxwell> Luke-Jr: pong
724 2012-09-06 18:24:43 <Luke-Jr> 3595b18 Don't force IRC off if not listening, do force it off if IPv4 is off. <-- first part is a bug fix or not?
725 2012-09-06 18:25:42 <gmaxwell> Luke-Jr: it's a bugfix but not generally an important one. (Its somewhat more important for testnet3, as irc is the only bootstrapping method)
726 2012-09-06 18:27:02 <Evilmax> Rumors say the price of bitcoins will rise beyond $ 12: then buy, buy!
727 2012-09-06 18:27:07 <Evilmax> :)
728 2012-09-06 18:28:11 <gavinandresen> Evilmax: 11 is my favorite number.
729 2012-09-06 18:28:45 <Evilmax> 11.3
730 2012-09-06 18:28:47 <Evilmax> better
731 2012-09-06 18:28:53 <Luke-Jr> + " -timeout=<n> " + _("Specify connection timeout in milliseconds (default: 5000))") + "\\n" +
732 2012-09-06 18:28:56 <gavinandresen> 11.11 would be better.
733 2012-09-06 18:29:03 <Evilmax> 11.3 eur!
734 2012-09-06 18:29:05 <Evilmax> i mean
735 2012-09-06 18:29:05 <Luke-Jr> ^ anyone care to fix the double parenthesis? doesn't seem worth a pullreq
736 2012-09-06 18:29:24 <gavinandresen> Luke-Jr: sure
737 2012-09-06 18:37:11 <kjj_> what's wrong with the double parenthesis? they are nested
738 2012-09-06 18:38:55 <BlueMatt> theres a double in the string
739 2012-09-06 18:39:15 <BlueMatt> (open 1, close 3; if you count those not in the string)
740 2012-09-06 18:39:20 <BlueMatt> s/1/2/
741 2012-09-06 18:39:56 <kjj_> ahh, I see it now. I was moving the initial (" into "( as I read it
742 2012-09-06 18:40:17 <BlueMatt> (as did I)
743 2012-09-06 18:43:17 <Luke-Jr> gavinandresen: was there a reason the build version was bumped for rc2?
744 2012-09-06 18:44:12 <gavinandresen> because that's the way we do it? new code == new build version ....
745 2012-09-06 18:44:19 <Luke-Jr> hasn't been in the past, but ok
746 2012-09-06 18:44:33 <Luke-Jr> (before, it only seemed to happen when there was a security fix in between)
747 2012-09-06 18:45:12 <gavinandresen> before I probably just forgot to bump
748 2012-09-06 18:45:53 <gavinandresen> there will be no bump going from rc2 to final (assuming rc2 IS final), just a new git tag and new binaries.
749 2012-09-06 18:46:28 <Luke-Jr> i c
750 2012-09-06 19:02:15 <gavinandresen> wow, that was quick: http://edition.cnn.com/2012/09/06/politics/romney-tax-threat/index.html
751 2012-09-06 19:03:02 <Luke-Jr> is there any actual evidence of that version being true yet? <.<
752 2012-09-06 19:03:19 <gavinandresen> I don't think so, smells like a hoax to me
753 2012-09-06 19:04:16 <gmaxwell> Yea, it doesn't make any sense in any case.
754 2012-09-06 19:04:59 <snapattack> hey folks - I want to use the blockchain (the latest solved hash) as a source of entropy in my web application. Is `bitcoind getmemorypool` the only way to obtain the hash without relying on thirdparty services like BBE and blockchina.info?
755 2012-09-06 19:05:40 <gmaxwell> snapattack: you want getblockhash most likely.
756 2012-09-06 19:06:03 <gavinandresen> snapattack: you want bitcoind getblockhash `bitcoind getblockcount` I think. Or is it getblocknumber....
757 2012-09-06 19:06:12 <gmaxwell> snapattack: though, using the lastest block hash as a sorce of 'entropy' is probably a bad idea.
758 2012-09-06 19:07:28 <gmaxwell> (because the party producing the block has as much control of the value as they want to buy)
759 2012-09-06 19:09:05 <snapattack> yeah but nobody ever knows what the hash is until it is registered in the blockchain
760 2012-09-06 19:09:09 <snapattack> let me explain my situtation
761 2012-09-06 19:09:44 <Luke-Jr> snapattack: sure we do.
762 2012-09-06 19:10:20 <snapattack> If you knew, you'd win every block
763 2012-09-06 19:10:27 <Luke-Jr> cool, how do I play?
764 2012-09-06 19:10:43 <Luke-Jr> win/win sounds good to me
765 2012-09-06 19:11:46 <snapattack> again, let me explain: An online lottery is created and users can enrol. When a user enrols they are given an index. When the lottery closes an index must be chosen. This index is the winner of the lottery. A system where the server decides the index is untrustworthy because they could simply change the outcome. However, If a promised protocol is followed to obtain the solved hash exactly 2 hours from the lottery close and
766 2012-09-06 19:12:04 <snapattack> entropy source, users are free to verify that it was a legit lottery and that the server did not rig it
767 2012-09-06 19:12:18 <gmaxwell> thats a cruddy protocol, here is one which is simpler and more secure.
768 2012-09-06 19:12:26 <Luke-Jr> aww, I don't know that far in advance :<
769 2012-09-06 19:12:48 <jrmithdobbs> ya, the last hashed block isn't entropy at all
770 2012-09-06 19:13:04 <jrmithdobbs> it's always going to be <target so easy to precompute
771 2012-09-06 19:13:32 <gmaxwell> The server picks a large random value (e.g. 128 bits), R. The server then tells all the users H(R) where H is some secure cryptographic hash function. The user(s) provides their own random value R2. Later the server announces R, everyone computes H(R||R2)=X and X tells you who the winner is.
772 2012-09-06 19:14:21 <jrmithdobbs> R2[0...n-1] but ya
773 2012-09-06 19:14:42 <gmaxwell> jrmithdobbs: well yes, if there are multiple users.
774 2012-09-06 19:15:08 <jrmithdobbs> gmaxwell: ya, i'm just in a pissy/nitpicky mood ;p
775 2012-09-06 19:15:27 <snapattack> I don't want users to have to submit random values, thats a pain in the ass for enrolment, why is the blockchain method cruddy?
776 2012-09-06 19:16:06 <Joric> it's not very user friendly ) http://img802.imageshack.us/img802/4180/30768852.png
777 2012-09-06 19:16:33 <gmaxwell> With what you proposed luke or other big pool operator could win big. They'd entroll a bunch of sockpuppets in your lottery, such that they were half the players. Then they could impose an additional restriction on blocks that they solve so that the hash results in them being the winner.
778 2012-09-06 19:16:53 <gmaxwell> Joric: thats your own weird design failure making it unfriendly.