1 2012-04-04 00:00:03 <luke-jr> I blocked his LPs and sent him a PM. bad idea.
2 2012-04-04 00:00:18 <luke-jr> I guess miner sw doesn't react well to forbidden LPs
3 2012-04-04 00:07:17 <phantomcircuit> luke-jr, tarpit
4 2012-04-04 00:07:21 <phantomcircuit> proceed to laugh
5 2012-04-04 00:07:25 <luke-jr> &
6 2012-04-04 00:07:46 <XMPPwocky> phantomcircuit: better, just send invalid getworks
7 2012-04-04 00:07:54 <XMPPwocky> he'll spend days debugging before he figures it out
8 2012-04-04 00:08:11 <phantomcircuit> i had to tarpit someone who was polling intersango with 5 open connections every 10 ms
9 2012-04-04 00:08:17 <luke-jr> >_<
10 2012-04-04 00:08:29 <phantomcircuit> i dont even understand how you would think that's ok
11 2012-04-04 01:05:04 <gmaxwell> sipa: what if any cases do you know still remain where a node can get stuck on a fork?
12 2012-04-04 01:05:58 <gmaxwell> Azelphur: in #bitcoin has upgraded to 0.6 after finding himself stuck on a fork on old code.. but he's staying stuck. I had him addnode me, he fetches new blocks but I don't see him try to pull the connecting chain.
13 2012-04-04 01:06:28 <gmaxwell> (he's stuck at 171819 )
14 2012-04-04 01:07:08 <gmaxwell> This is his debug log from before he was connected to me: http://paste.ubuntu.com/914011/
15 2012-04-04 01:15:26 <luke-jr> gmaxwell: did he -checkblocks?
16 2012-04-04 01:18:12 <tracton> remember when i said rg and bitvps sucks, that the servers constantly hang, and that the service is horrible? dude i was kidding. it was all a lie, sorry. i never even used bitvps. tho i'm hearing from ppl they do have some awesome vps's that kick ass. rg did ban me for no reason tho. why did he do it?
17 2012-04-04 01:18:34 <gmaxwell> Oh god, this idiot again?
18 2012-04-04 01:18:47 <gmaxwell> luke-jr: nothing in his logs indicates block corruption at all.
19 2012-04-04 01:19:16 <BlueMatt> yay static ips
20 2012-04-04 01:19:47 <luke-jr> lol
21 2012-04-04 01:54:20 <nanotube> so when does the bitcoin-qt on windows critfix alert expire? it keeps sitting in my taskbar...
22 2012-04-04 01:57:27 <Cory> Update!
23 2012-04-04 01:57:55 <BlueMatt> nanotube: when you upgrade
24 2012-04-04 01:58:08 <nanotube> BlueMatt: ah... but i'm not even on windows! :)
25 2012-04-04 01:58:18 <BlueMatt> upgrade anyway ;)
26 2012-04-04 01:58:21 <nanotube> hehe yea
27 2012-04-04 02:00:34 <luke-jr> nanotube: test 0.5.4 :D
28 2012-04-04 02:02:01 <nanotube> heh
29 2012-04-04 02:02:09 <nanotube> that's only bitcoind though innit?
30 2012-04-04 02:03:53 <luke-jr> no
31 2012-04-04 02:05:47 <nanotube> ah well... maybe. :)
32 2012-04-04 02:49:06 <Cory> Can alerts target specific OSs?
33 2012-04-04 02:50:13 <phantomcircuit> no
34 2012-04-04 02:53:29 <Cory> Has an invalid alert (not signed by the right pubkey) ever been broadcast?
35 2012-04-04 02:53:41 <BlueMatt> it cant be
36 2012-04-04 02:54:03 <BlueMatt> or...it wouldnt get past the first node
37 2012-04-04 02:55:30 <Cory> Ah, right. Makes sense.
38 2012-04-04 03:00:35 <BlueMatt> jgarzik_: sorry, /ignore me...
39 2012-04-04 03:02:32 <nameless> |BlueMatt: we do
40 2012-04-04 03:02:50 <BlueMatt> good to hear someone has sense
41 2012-04-04 03:40:21 <twobitcoins> If anyone is still looking for a copy of the bad P2SH transaction, I found it.
42 2012-04-04 03:40:44 <twobitcoins> 01000000019dc23528f5a5f376da3f3f4efd45be8c5b551abdb8093940e0b313de459a
43 2012-04-04 03:40:47 <twobitcoins> 53b00100000026255121029c7187ecea7f09146820075c3a8de5d33ffbc293b63228ea
44 2012-04-04 03:40:51 <twobitcoins> 1667c8d3796aff3f51aeffffffff0130570500000000001976a9147288ca9e213c54cb
45 2012-04-04 03:40:54 <twobitcoins> b2094f00bcf33bfbce691dbb88ac00000000
46 2012-04-04 03:43:55 <dooglus> "// BIP16 didn't become active until Apr 1 2012 (Feb 15 on testnet)"
47 2012-04-04 03:44:04 <dooglus> so it's only just started rejecting these blocks
48 2012-04-04 03:45:18 <dooglus> won't this cause a fork between different client versions?
49 2012-04-04 03:47:52 <twobitcoins> It has created a bunch of little forks, but they always resolve. New nodes create blocks that old nodes consider valid and new nodes have the majority of hashing power, so eventually new nodes have the longest chain and old nodes switch to it.
50 2012-04-04 03:49:07 <dooglus> http://blockchain.info/ tells me that deepbit is building on the invalid block - doesn't it?
51 2012-04-04 03:52:54 <bitfoo> blockchain.info shows 2 blocks at height 174232
52 2012-04-04 03:53:00 <bitfoo> and both relayed by deepbit :P
53 2012-04-04 03:53:11 <twobitcoins> It claims to have heard about the last bad block from Deepbit. Perhaps Deepbit runs an old node, but I doubt it mines using an old node.
54 2012-04-04 03:54:41 <SomeoneWeird> ask tycho?
55 2012-04-04 03:54:50 <BlueMatt> [Tycho]:
56 2012-04-04 03:56:12 <gmaxwell> Stop.!
57 2012-04-04 03:56:21 <gmaxwell> God is a @#$@## forest fire.
58 2012-04-04 03:56:30 <gmaxwell> The reports of pools on blockchain.info are unreliable. In particular the relayed by field is unreliable as an indicator of block origin and there are a great many blocks reported as relayed by deepbit which are not from deepbit.
59 2012-04-04 03:57:01 <gmaxwell> Many of the orphans produced by 1txn mining mytery have been relayed by deepbit.
60 2012-04-04 03:57:12 <gmaxwell> Deepbits actual blocks are listed on their website.
61 2012-04-04 03:59:35 <gmaxwell> dooglus: No, BIP16 doesn't cause a persistent fork. Old nodes accept the new txns happily.
62 2012-04-04 04:00:10 <dooglus> gmaxwell: so what causes this situation?
63 2012-04-04 04:01:01 <gmaxwell> It's only a one way disagreement, and a significant supermajority of hashpower (>75%) enforces the P2SH rules so that chain always overtakes and the old nodes happily reorganize onto it.
64 2012-04-04 04:01:41 <gmaxwell> dooglus: BIP16 enabled nodes will reject some transactions which old nodes see as valid (invalid P2SH transactions). Someone produced one of these transactions.
65 2012-04-04 04:01:56 <gmaxwell> (presumably intentionally though it's constructed in a way which could have been an accident)
66 2012-04-04 04:02:01 <dooglus> the 'bad P2SH tx' - was it created deliberately to mess things up? or is it a valid transaction for old clients that arises 'naturally'?
67 2012-04-04 04:02:07 <dooglus> ok
68 2012-04-04 04:02:21 <gmaxwell> It's not a kind of transaction that anyone would ever have made before...
69 2012-04-04 04:02:22 <gmaxwell> https://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2?show_adv=true
70 2012-04-04 04:03:17 <gmaxwell> Though it could have been an honest attempt at a P2SH transaction that simply didn't account for the er 'surprising' behavior of CHECKMULTISIG.
71 2012-04-04 04:03:31 <gmaxwell> But only custom code could produce it.
72 2012-04-04 04:03:51 <gmaxwell> If someone wanted to make an intentionally bad transaction the could have used a much simpler script though.
73 2012-04-04 04:08:41 <gmaxwell> twobitcoins: How'd you get a copy of it?
74 2012-04-04 04:10:56 <twobitcoins> I modified ConnectInputs to dump transactions that fail VerifySignature to debug.log and waited for someone to generate another bad block and send it to me.
75 2012-04-04 04:21:32 <gmaxwell> Ah, good call to catch it in a bad block.
76 2012-04-04 05:08:22 <[Tycho]> What ?
77 2012-04-04 05:12:19 <chk> can anyone here assist me with using gmp-proxy?
78 2012-04-04 05:14:56 <gribble> New news from bitcoinrss: Diapolo opened pull request 1032 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1032>
79 2012-04-04 05:59:30 <BTC_Bear> Don't know if anyone brought this up. I don't have windows, can you 'Clear' the urgent update message.
80 2012-04-04 06:30:44 <t7> have you guys heard of mental poker?
81 2012-04-04 06:31:36 <t7> i need a communative encryption scheme
82 2012-04-04 06:36:10 <wumpus> BTC_Bear: you'll have to put up with it until a new release for linux, sorry :)
83 2012-04-04 06:49:22 <toxicFork> has anyone made a desktop wallet app which'd store only the wallet.dat and fetch "wallet status" etc from internet ( e.g. blockexplorer ) ?
84 2012-04-04 06:49:36 <toxicFork> instead of storing blockchain
85 2012-04-04 06:51:31 <sturles> Yes.
86 2012-04-04 06:51:39 <sturles> Electrum.
87 2012-04-04 06:52:11 <toxicFork> thanks
88 2012-04-04 06:53:10 <toxicFork> looks great!
89 2012-04-04 06:54:54 <wumpus> we really need an overview of clients on bitcoin.org
90 2012-04-04 08:18:51 <sipa> gmaxwell: so you see a getblocks, you reply with invs, but no getdata follows (RE: Azelphur)?
91 2012-04-04 08:42:13 <iHerb> Hello, and please sorry for that =) Have a nice day!
92 2012-04-04 08:42:14 <iHerb> please used and saved $10 with the iHerb coupon code VAD515 or please visit my link http://iherb.com?rcode=vad515, and free Shipping on orders over $20. And FREE SAMPLE for every purchase!
93 2012-04-04 08:44:28 <Graet> sorry for spamming offtop[ic advertising, why not just dont do it?
94 2012-04-04 08:44:47 <upb> heh
95 2012-04-04 09:42:32 <wumpus> vitamin spam on freenode, we're becoming too mainstream :/
96 2012-04-04 09:43:04 <Graet> at least he could have given prices in BTC :P
97 2012-04-04 09:44:10 <lh77> :P
98 2012-04-04 09:44:17 <wumpus> hehe
99 2012-04-04 10:06:52 <denisx> what happened to blockchain?
100 2012-04-04 10:07:01 <lh77> maintanence
101 2012-04-04 10:07:05 <lh77> from 12am to 2pm
102 2012-04-04 10:07:07 <lh77> gmt
103 2012-04-04 10:08:35 <denisx> is there a city which als always GMT? ;)
104 2012-04-04 10:08:39 <denisx> is
105 2012-04-04 10:09:02 <egecko> london.
106 2012-04-04 10:09:19 <denisx> but they have summertime
107 2012-04-04 10:09:42 <sipa> afaik no place on earth ha GMT all year long
108 2012-04-04 10:09:45 <sipa> *has
109 2012-04-04 10:49:36 <rebroad> hi..... I'm looking at bitcoin-qt, and noticing that DBFlush(false) is taking over 4 minutes to run, even if the client has been running only a few seconds... does anyone have any idea what it's doing that takes so long please?
110 2012-04-04 10:50:29 <rebroad> and given that so many people are apparently having it kill -9ed, then does this mean the DBFlush could be skipped altogether?
111 2012-04-04 10:51:22 <sipa> it's cleaning the log files
112 2012-04-04 10:51:34 <sipa> not sure how much can be done about that, but 4 minutes sounds incredibly long
113 2012-04-04 10:51:44 <sipa> slow disk, and right when you were downloading blocks?
114 2012-04-04 10:52:02 <rebroad> sipa, 268451ms to be precise...
115 2012-04-04 10:52:29 <rebroad> it's when I quit (when it runs DBFlush)
116 2012-04-04 10:52:35 <sipa> yes
117 2012-04-04 10:52:54 <sipa> imho, a "Shutting dow (please don't turn off your computer)" should be shown during shutdown
118 2012-04-04 10:52:58 <sipa> in the gui
119 2012-04-04 10:53:50 <rebroad> sipa.... but if someone chooses to shutdown their OS with bitcoin running, then generally it ends up being kill -9ed I think, because it takes too long by most application standards
120 2012-04-04 10:54:23 <rebroad> (sorry, no idea why I put the four dots after your name there)
121 2012-04-04 10:55:13 <rebroad> if I edited DBFlush to simply return before the loop... I wonder, what would be the harm...?
122 2012-04-04 10:55:18 <sipa> no
123 2012-04-04 10:55:28 <sipa> but the database log files wouldn't be flushed
124 2012-04-04 10:55:40 <sipa> so you could not copy a wallet.dat file in or out, for example
125 2012-04-04 10:56:55 <rebroad> Shall I raise an issue for this? I think >4 minutes when told to shutdown is way too long... and it seems to be getting longer... whatever it's doing should be done during running, not during shutdown, IMHO
126 2012-04-04 10:57:28 <sipa> maybe the solution is only flushing the lsn's for the wallet file, and not for the transaction database
127 2012-04-04 10:57:49 <rebroad> it is the blkindex.dat flish...
128 2012-04-04 10:57:56 <sipa> yes, i know
129 2012-04-04 10:58:02 <rebroad> (or so it says)
130 2012-04-04 10:58:23 <jgarzik_> IMO a nice increment step is simply having separate db environments for wallet vs. "other stuff"
131 2012-04-04 10:58:25 <rebroad> I wasn't aware DBFlush was used for wallet.dat, debug.log doesn't seem to suggest it's used for the wallet.dat
132 2012-04-04 10:58:30 <jgarzik_> *incremental
133 2012-04-04 10:58:38 <jgarzik_> solves _many_ problems
134 2012-04-04 10:58:46 <sipa> jgarzik_: IMO the solution is not using bdb for wallets :)
135 2012-04-04 10:59:17 <jgarzik> sipa: sure, but note word "incremental" all these flush and log problems simply go away
136 2012-04-04 10:59:50 <jgarzik> sipa: you would have the same problem with sqlite or another db system, because we're simply trying to force one ACID environment for all our data
137 2012-04-04 11:00:21 <jgarzik> db usage mismatch with data
138 2012-04-04 11:00:22 <sipa> since addrman, addr.dat is always written in its entirety now; they're still using bdb, but there are easier ways if you keep everything in memory
139 2012-04-04 11:00:46 <sipa> wallets are loaded entirely into memory, and are actually only read at startup
140 2012-04-04 11:00:57 <rebroad> so, if I get DBFlush to return when it notices it's blkindex.dat, and only blkindex.dat, would that be safe to do?
141 2012-04-04 11:00:57 <sipa> the only thing that really needs a database, is the blockchain info
142 2012-04-04 11:00:59 <jgarzik> yep
143 2012-04-04 11:01:00 <sipa> bdb is fine for that
144 2012-04-04 11:01:29 <sipa> rebroad: it would be safe, yes, but you would be left with log files that are part of the database
145 2012-04-04 11:01:35 <sipa> and cannot be removed
146 2012-04-04 11:01:59 <sipa> + start-up would take longer the next time
147 2012-04-04 11:02:04 <rebroad> sipa, would more disk space be used up as a result?
148 2012-04-04 11:02:29 <sipa> depends on what you mean by that
149 2012-04-04 11:02:39 <sipa> more disk space when? on average or maximally?
150 2012-04-04 11:02:42 <rebroad> but how come the flush takes longer than the amount of time the client has been running? Sometimes I exit after running only for 30 seconds and it takes 4 minutes...
151 2012-04-04 11:03:10 <sipa> writing log files = sequential writes; flushing log files = random writes
152 2012-04-04 11:03:19 <rebroad> I would have thought the flush would take longer the more stuff that had happened..
153 2012-04-04 11:03:49 <rebroad> and sometimes the whole OS seems to hang during a flush too...
154 2012-04-04 11:03:55 <sipa> what OS?
155 2012-04-04 11:03:59 <rebroad> ubuntu
156 2012-04-04 11:04:07 <sipa> strange, no problems here
157 2012-04-04 11:04:30 <rebroad> well, i mean... disk I/O related things seem to hang/go_slow
158 2012-04-04 11:05:29 <sipa> jgarzik: what i mean is: if the only thing that really needs a db environment is the block index, there's no point in adding the extra complexity for maintaining multiple db env, if the next step is going back to only a db env for the block chain anyway
159 2012-04-04 11:05:43 <sipa> *single
160 2012-04-04 11:05:47 <rebroad> what is the advantage in having the data in blkindex.dat instead of in the database files? and why would it take longer to start up if it's not flushed at shutdown..?
161 2012-04-04 11:06:06 <sipa> i believe it will flush them on startup anyway, otherwise
162 2012-04-04 11:06:19 <sipa> log files are slow to access, but fast to write
163 2012-04-04 11:06:30 <sipa> database files are faster to access, but slower to write
164 2012-04-04 11:06:57 <sipa> so the log functions as a temporary cache for queued changes that must be written to the database still
165 2012-04-04 11:07:16 <rebroad> sipa, can it write them to the database during runtime rather than shutdown?
166 2012-04-04 11:07:28 <sipa> of course, it does so continuously
167 2012-04-04 11:07:31 <rebroad> or do something to reduce the load at shutdown?
168 2012-04-04 11:07:44 <rebroad> it'd be better at startup than shutdown, I'd have thought
169 2012-04-04 11:07:48 <sipa> it's strange that it is so *so* slow for you
170 2012-04-04 11:07:59 <sipa> which version are you running, by the way?
171 2012-04-04 11:08:15 <sipa> 0.6.0rc5 had a problem that it left way too large log files
172 2012-04-04 11:08:20 <rebroad> 0.6.0.4-beta
173 2012-04-04 11:08:24 <sipa> right
174 2012-04-04 11:08:31 <sipa> just upgrade to the latest version then, please
175 2012-04-04 11:08:40 <rebroad> ah, ok..
176 2012-04-04 11:08:43 <rebroad> thanks
177 2012-04-04 11:43:11 <Perlboy> So, computationally, how hard is it to brute force a wallet key?
178 2012-04-04 11:43:40 <rebroad> Perlboy, probably a question for #bitcoin I suspect
179 2012-04-04 11:43:59 <Perlboy> ok
180 2012-04-04 11:44:41 <MagicalTux> Perlboy: quite
181 2012-04-04 11:44:52 <Joric> 2^256
182 2012-04-04 11:45:29 <Joric> except a few special points, it was already discussed here
183 2012-04-04 11:45:58 <Perlboy> got logs?
184 2012-04-04 11:46:20 <SomeoneWeird> Joric; the hex conversion thing?
185 2012-04-04 11:46:31 <MagicalTux> 0~FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
186 2012-04-04 11:48:13 <MagicalTux> need some extra ecdsa, sha256 and ripemd160 to get the actual bitcoin address from a private addr to know if you found the right one
187 2012-04-04 11:49:00 <SomeoneWeird> luke-jr, ?
188 2012-04-04 11:49:17 <luke-jr> found out why my node reacted differently to the viral P2SH redemption
189 2012-04-04 11:49:23 <Joric> <sipa> ok, so bitcoin secret keys have 255.999999999999999999999999999999999999995 bits of entropy
190 2012-04-04 11:49:56 <Joric> ;;calc log(0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551)/log(2)
191 2012-04-04 11:49:57 <gribble> 255.999998888
192 2012-04-04 11:51:08 <SomeoneWeird> there ya go
193 2012-04-04 11:51:09 <SomeoneWeird> lol
194 2012-04-04 11:51:30 <luke-jr> it was because I was testing with 0.4.5, and left out [db9f2e01 Do not invoke anti-DoS system for invalid BIP16 transactions] for 0.4.x since it has no anti-DoS :/
195 2012-04-04 11:52:34 <SomeoneWeird> heh
196 2012-04-04 11:55:54 <sipa> Perlboy: brute-forcing a public key is 2^256; brute-forcing an address is only 2^160
197 2012-04-04 11:56:10 <sipa> Perlboy: if all you want is being able to spend funds sent to a particular address, the latter suffices
198 2012-04-04 11:56:36 <Perlboy> 2^160 * hex?
199 2012-04-04 11:58:24 <Perlboy> 1 cpu with 1 hz on 2^160 is still 4.8 with 42 zeros.
200 2012-04-04 11:58:50 <Perlboy> divide it by 12 cores (pure cpu brute)
201 2012-04-04 12:00:13 <Perlboy> lowest i could get to was 16 zeros
202 2012-04-04 12:00:29 <Perlboy> and that was assuming like 100 machines
203 2012-04-04 12:00:32 <Perlboy> ie. hard. :)
204 2012-04-04 12:00:36 <Perlboy> goodo
205 2012-04-04 12:00:45 <Perlboy> thanks </end spam>
206 2012-04-04 12:00:55 <SomeoneWeird> lol
207 2012-04-04 12:02:45 <Joric> 2^160 * hex? wtf is hex? :D
208 2012-04-04 12:03:25 <Joric> 2d^160d
209 2012-04-04 12:04:22 <SomeoneWeird> lol
210 2012-04-04 12:05:26 <forrestv> it would cost about 10^34 bitcoins to bruteforce a single address (assuming ripemd160 is about as hard as sha256)
211 2012-04-04 12:05:34 <Joric> https://bitcointools.appspot.com/?t=Sddm
212 2012-04-04 12:06:10 <helo> sipa: don't you have to have the private key to spend coin at an address?
213 2012-04-04 12:06:33 <helo> brute forcing the ripe would only give the public key wouldn't it?
214 2012-04-04 12:07:08 <forrestv> no, you'd try to find a private key whose pubkey matches the hash
215 2012-04-04 12:07:18 <forrestv> so it would give you a private key, not necessarily the original one
216 2012-04-04 12:07:31 <sipa> exactly
217 2012-04-04 12:08:12 <helo> so by "brute force an address" you mean "generate private key -> derive public key -> ripe160 to address"
218 2012-04-04 12:08:42 <SomeoneWeird> yes
219 2012-04-04 12:09:47 <luke-jr> don't forget the sha256 in there :P
220 2012-04-04 12:15:31 <gavinandresen> Joric: neat! Are you doing flood control to prevent some jerk from costing you a bunch of your appengine budget?
221 2012-04-04 12:20:56 <brokenwallet> oh shit!
222 2012-04-04 12:21:12 <brokenwallet> sipa I found the correct pass, and it wasnt the same pass that was crashing my client
223 2012-04-04 12:21:52 <brokenwallet> gmaxwell was right i think
224 2012-04-04 12:22:22 <brokenwallet> do you want my wallet to analyze why it was causing a crash on the incorrect pass?
225 2012-04-04 12:23:45 <brokenwallet> and PM me an address sipa to send you some coins for the help (even though it was my stupidness that caused the problem)
226 2012-04-04 12:24:44 <sipa> brokenwallet: whatever happens, a bad passphrase should not cause your client to crash
227 2012-04-04 12:25:20 <sipa> if you use the right passphrase, does the client just work (and able to send coins), or are you still using my patched version?
228 2012-04-04 12:26:23 <brokenwallet> i'm using the latest and i got it to work, basically i typed out every permutation that could be the password that i was using and ran through them
229 2012-04-04 12:27:01 <SomeoneWeird> lol
230 2012-04-04 12:27:21 <brokenwallet> first i ran through them with your modified client and nothing worked. Could this be due to it stripping the incorrectly decrypted keys? Meaning if i try a wrong pass then the right pass with your client would it attempt to re-read the wallet?
231 2012-04-04 12:27:22 <SomeoneWeird> ... thats one way
232 2012-04-04 12:27:58 <brokenwallet> or use the one in memory that at that point had the keys removed (at that point)
233 2012-04-04 12:28:18 <brokenwallet> let me try again to verify
234 2012-04-04 12:32:45 <brokenwallet> off topic, why does the "pay to" field allow 35 chars when it looks like bitcoin addresses are always 34?
235 2012-04-04 12:33:13 <gmaxwell> brokenwallet: congrats!
236 2012-04-04 12:35:09 <luke-jr> wumpus: ping
237 2012-04-04 12:35:52 <luke-jr> wumpus: 5a60b66 Use a messagebox to display the error when -server is provided without providing a rpc password <-- does this INTENTIONALLY change behaviour so that no-rpcpassword is fatal for Bitcoin-Qt? O.o
238 2012-04-04 12:36:14 <helo> brokenwallet: good question... as far as i know they can never be 35
239 2012-04-04 12:36:27 <gmaxwell> brokenwallet: Rather than your coins... perhaps we could have your broken backup? e.g. transfer all your coins to a new wallet, and gis us your old backup so we can reproduce? (This won't be viable if you have addresses published anywhere)
240 2012-04-04 12:36:30 <gavinandresen> multisig (BIP16) addresses on testnet can be 35.
241 2012-04-04 12:36:50 <gavinandresen> ( I don't remember if mainnet BIP16 addresses can be 35 or not)
242 2012-04-04 12:36:54 <brokenwallet> gmaxwell that is fine with me, anything to support the dev work
243 2012-04-04 12:37:20 <brokenwallet> and i use unique passes in most places including my wallet so i dont care if you know them
244 2012-04-04 12:37:44 <brokenwallet> i'm just going to re-verify everything and document it for #1024
245 2012-04-04 12:39:13 <gmaxwell> Great.
246 2012-04-04 12:39:17 <brokenwallet> gmaxwell what would be the best way to get you the wallet? email?
247 2012-04-04 12:40:34 <gmaxwell> Email would be fine. Make sure to send your funds to a totally new wallet before emailing me (Not that I'm going to steal your coins, but if email goblins get them I don't want to deal with doubts!)
248 2012-04-04 12:41:03 <Joric> gavinandresen, not really, i have no flood control atm, and i got a feeling i have to rewrite all that to js after being featured in Forbes Magazine http://www.forbes.com/sites/jonmatonis/2012/03/12/brainwallet-the-ultimate-in-mobile-money
249 2012-04-04 12:41:33 <brokenwallet> yep i have a very elementary understanding of bitcoin and how there are 100 pregenerated keys per wallet
250 2012-04-04 12:41:44 <gmaxwell> Great.
251 2012-04-04 12:44:08 <gavinandresen> Joric: if you're using django, something like this: http://django-ratelimit-backend.readthedocs.org/en/latest/ can be easy to install and will keep the jerks at bay
252 2012-04-04 12:45:03 <Joric> yeah it's all django/python
253 2012-04-04 12:46:50 <gavinandresen> Joric: code that the Faucet uses to ratelimit requests: https://gist.github.com/63bae3ff3667880719c1
254 2012-04-04 12:47:57 <Joric> gavinandresen, did you think about storing the blockchain in the big table?
255 2012-04-04 12:48:27 <Joric> it allows up to 5 gb per app atm
256 2012-04-04 12:48:41 <Joric> no sockets though :(
257 2012-04-04 12:48:48 <gavinandresen> Joric: sure, you could. But you still need a persistent bitcoind because of the no sockets....
258 2012-04-04 12:48:50 <Joric> if only there were http nodes
259 2012-04-04 12:49:42 <gavinandresen> Wouldn't be too hard to create a HTTP node that just send new blocks or transactions to registered HTTP addresses.
260 2012-04-04 12:50:01 <gavinandresen> Might even be a good business if there are people who don't want to run bitcoind's for some reason.
261 2012-04-04 12:50:41 <gavinandresen> (I doubt it'd be a good business yet, I doubt there are many people who'd be interested and willing to pay)
262 2012-04-04 13:15:22 <luke-jr> any last-minute bugfixes for stable? :P
263 2012-04-04 13:17:03 <gavinandresen> 0.6 is the stable release right now.
264 2012-04-04 13:41:40 <gribble> New news from bitcoinrss: sipa opened pull request 1033 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1033>
265 2012-04-04 13:49:04 <gavinandresen> sipa: did you consider getting rid of the CRITICAL_BLOCK macro entirely ?
266 2012-04-04 13:49:14 <gavinandresen> (and just using objects scoped in blocks)
267 2012-04-04 13:49:40 <sipa> gavinandresen: sure, but that's a larger change
268 2012-04-04 13:50:20 <gavinandresen> Larger in terms of lines of code changed... but cleaner
269 2012-04-04 13:50:28 <gavinandresen> and more in the spirit of C++