1 2013-01-30 00:16:29 <gavinandresen> andytoshi: see https://github.com/bitcoin/bitcoin/pull/1974 for a -walletnotify
2 2013-01-30 00:17:16 <gavinandresen> andytoshi: also be careful: if you accept 0-confirmation transactions you're asking for trouble???.
3 2013-01-30 00:28:34 <andytoshi> gavinandresen: good point, i'd probably want it not to tell me about transactions until they'd gotten a few confirms
4 2013-01-30 00:28:47 <andytoshi> but awesome, thanks
5 2013-01-30 00:53:56 <midnightmagic> +1 gavinandresen
6 2013-01-30 00:55:25 <jgarzik> reizuki__: [SUCCESS] Double Spend against a satoshidice loss - https://bitcointalk.org/index.php?topic=130764.msg1489288#msg1489288
7 2013-01-30 00:55:35 <jgarzik> ACTION kicks xchat autocomplete
8 2013-01-30 00:55:41 <jgarzik> [SUCCESS] Double Spend against a satoshidice loss - https://bitcointalk.org/index.php?topic=130764.msg1489288#msg1489288
9 2013-01-30 00:56:57 <reizuki__> ?
10 2013-01-30 00:57:24 <gmaxwell> reizuki__: autocomplete bug.
11 2013-01-30 01:04:00 <jgarzik> ACTION typed/pasted "Re: " at the beginning, but xchat had other ideas
12 2013-01-30 01:04:27 <jgarzik> ACTION should figure out if that can be turned off. If I want autocomplete, I'll <tab>, dammit.
13 2013-01-30 01:13:45 <asoltys> hi, i created a multisig address in my bitcoind wallet. is there an easy way to figure out which component addresses it was created from?
14 2013-01-30 01:24:57 <gavinandresen> asoltys: validateaddress will tell you
15 2013-01-30 01:28:52 <asoltys> thanks gavinandresen
16 2013-01-30 02:30:00 <gmaxwell> sipa: why doesn't bootstrap dat catting work without truncating? shouldn't the deserialziation code just find the next block?
17 2013-01-30 02:31:49 <sipa> yes, it should
18 2013-01-30 02:31:56 <sipa> meh :)
19 2013-01-30 02:33:19 <gavinandresen> FYI: I just pushed the python script I used to generate the seed nodes to contrib/seeds
20 2013-01-30 02:33:50 <gavinandresen> And??? I think we're out of issues for a 0.8 release? I'll double check in the morning, then tag when I'm more alert
21 2013-01-30 02:33:59 <BlueMatt> woooo
22 2013-01-30 02:36:32 <sipa> gavinandresen: #2224 #2228 #2203 #2202 ?
23 2013-01-30 02:36:39 <BlueMatt> awwwww
24 2013-01-30 02:37:37 <gavinandresen> 2224 pulled....
25 2013-01-30 02:38:07 <gavinandresen> 2228 : I can live with
26 2013-01-30 02:38:33 <gavinandresen> (one-time "omg I have to wait 10 or 20 minutes to start getting caught up" is not a disaster)
27 2013-01-30 02:39:02 <sipa> i'm sure we'll get tons of "omfg my client is stuck!" reports because of it
28 2013-01-30 02:39:20 <BlueMatt> what ever happened with the complaints about block latency across the network?
29 2013-01-30 02:39:27 <BlueMatt> Luke-Jr: ^
30 2013-01-30 02:39:27 <gavinandresen> sipa: you think? If we do in rc1 we could spin a rc2 that fixes it....
31 2013-01-30 02:39:33 <sipa> ok
32 2013-01-30 02:39:43 <sipa> also, the last pulltester report of 2224 was failure to build (i "think" i fixed that, but there's no new report yet)
33 2013-01-30 02:39:51 <Luke-Jr> BlueMatt: still an unaddressed problem, more or less
34 2013-01-30 02:39:56 <gavinandresen> the reindex takes so long I think very few people will notice the extra 10 minutes
35 2013-01-30 02:40:05 <BlueMatt> Luke-Jr: but its still an issue plus/minus?
36 2013-01-30 02:40:23 <sipa> i think 0.8 will improve propagation speed a lot
37 2013-01-30 02:40:27 <Luke-Jr> gavinandresen: there's a major bug in the "open block file" code, but no sane pullreq to fix it yet (shouldn't be too hard to get a minimal fix done tho)
38 2013-01-30 02:40:41 <BlueMatt> sipa: what do I need to do to transfer jenkins to doing w64-based builds?
39 2013-01-30 02:40:43 <Luke-Jr> BlueMatt: yes, fixing it is very non-trivial unfortunately
40 2013-01-30 02:40:46 <sipa> Luke-Jr: strip your existing one to the first commit, and i'm ok with it
41 2013-01-30 02:40:52 <gavinandresen> 2203 I think we can live with, but it is such a trivial change it should probably just be done.
42 2013-01-30 02:40:58 <BlueMatt> Luke-Jr: ofc not, I was just wondering as Ive heard nothing about it any time recently
43 2013-01-30 02:41:03 <Luke-Jr> sipa: I'm not, that first commit looks like I was half asleep when I wrote it, IMO
44 2013-01-30 02:41:07 <gavinandresen> Luke-Jr: is that the if-block-files-are-read-only? I am ENOCARE on that
45 2013-01-30 02:41:26 <BlueMatt> Luke-Jr: and I know it was partially blamed for p2pool's dismal luck for a while, but now p2pool seems to not have that issue thanks to some other optimizations
46 2013-01-30 02:41:31 <Luke-Jr> gavinandresen: that was what prompted me to look at it, but the bug is general
47 2013-01-30 02:41:32 <gmaxwell> BlueMatt: well, p2pool solved it on its own.
48 2013-01-30 02:41:32 <petertodd> gavinandresen: FWIW the testnet seed patch I'm working on, although I'd say leave it for >0.8 myself
49 2013-01-30 02:41:54 <gmaxwell> BlueMatt: p2pool does the stuff we talked about wrt forwarding transactions in advance and then blocks only with the trees.
50 2013-01-30 02:42:01 <BlueMatt> gmaxwell: ahhh
51 2013-01-30 02:42:24 <BlueMatt> jgarzik: what ever happened with your forray into a bitcoin backbone-ish stuff a while ago before moving on to bigger and better things?
52 2013-01-30 02:42:39 <gmaxwell> Because forrestv is an awesome one man network protocol coding machine.
53 2013-01-30 02:42:51 <BlueMatt> gmaxwell: yes
54 2013-01-30 02:43:16 <gavinandresen> sipa: 2202 is "would be nice, but not a showstopper" in my opinion-- we've never been very good at telling users what to do if their db get corrupt.
55 2013-01-30 02:43:56 <BlueMatt> FD: /me is looking more into bitcoin latency measurement/testing, partially as a research project
56 2013-01-30 02:44:05 <BlueMatt> /simulation
57 2013-01-30 02:44:28 <sipa> Luke-Jr: ok, can wait in that case
58 2013-01-30 02:45:09 <sipa> gavinandresen: 2202 is trivial if any Qt-capable person would write a yes/no question function
59 2013-01-30 02:45:56 <swhitt> can anyone help me figure out why https://blockchain.info/tx/3bf179dabbf819188f9001257234cc78b9dca909e6f5a3df15a50039c526851b hasn't been included in a block yet? 1 input, 2 outputs, 0.001 in txn fees
60 2013-01-30 02:46:18 <Luke-Jr> http://codepad.org/uLx2AI7Z feels sane to me now, but I'd not suggest merging it without someone else vetting ti
61 2013-01-30 02:46:19 <Luke-Jr> it*
62 2013-01-30 02:48:15 <sipa> Luke-Jr: rb+ doesn't create the file
63 2013-01-30 02:48:22 <sipa> if it doesn't yet exist\\
64 2013-01-30 02:48:48 <jgarzik> BlueMatt: built some backbone machines for exmulti, that's it
65 2013-01-30 02:48:50 <Luke-Jr> sigh, right??? :/
66 2013-01-30 02:49:13 <sipa> rb / wb+ looks fine to me
67 2013-01-30 02:49:16 <jgarzik> BlueMatt: backbone did not look like it had a business model behind it. more suited to non-profit, it seemed like.
68 2013-01-30 02:49:17 <BlueMatt> jgarzik: built as in?
69 2013-01-30 02:49:25 <BlueMatt> jgarzik: ahh, ok that was the issue
70 2013-01-30 02:49:37 <jgarzik> BlueMatt: 3 backbone machines actively running as public nodes under exMULTI aegis
71 2013-01-30 02:49:37 <Luke-Jr> sipa: you want to truncate it?
72 2013-01-30 02:49:43 <sipa> aargh no
73 2013-01-30 02:49:46 <jgarzik> BlueMatt: just as they have been for months
74 2013-01-30 02:49:54 <BlueMatt> jgarzik: yes, that I knew
75 2013-01-30 02:50:36 <sipa> Luke-Jr: rb / ab+, then? but that weird definition worries me
76 2013-01-30 02:50:44 <sipa> i guess the seek we do cancels that, but still
77 2013-01-30 02:52:15 <sipa> Luke-Jr: wait, it's probably mapped to O_APPEND in open(2), which is certainly not what we want
78 2013-01-30 02:52:37 <Luke-Jr> sipa: there was no sane combination IIRC
79 2013-01-30 02:53:21 <gavinandresen> BlueMatt: did you happen to put a clean-up-old-pulls cron job on the pull-tester machine? I didn't....
80 2013-01-30 02:53:37 <BlueMatt> gavinandresen: ahh, never got around to it, Ill dig it out of my .bash_history and throw it in cronrc now
81 2013-01-30 02:53:49 <gavinandresen> BlueMatt: thanks
82 2013-01-30 02:53:59 <sipa> so it needs to be readonly=>rb readwrite=>rb+,wb+
83 2013-01-30 02:54:52 <Luke-Jr> sounds about right
84 2013-01-30 02:55:41 <Luke-Jr> that makes the original code look a lot more sane
85 2013-01-30 02:55:48 <Luke-Jr> http://codepad.org/burpOmmf
86 2013-01-30 02:56:53 <sipa> jgarzik: someone reported that just that one define fixed the problem
87 2013-01-30 02:57:19 <sipa> and _LARGEFILE64_SOURCE didn't
88 2013-01-30 03:00:06 <jgarzik> sipa: _LARGEFILE64_SOURCE turns on O_LARGEFILE and guarantees 64-bit versions of various syscalls
89 2013-01-30 03:01:07 <jgarzik> sipa: adds struct stat64, fseek64, ... all 64-bit clean. So, probably not needed, as we don't use those. I'm trying to determine if it changes off_t.
90 2013-01-30 03:03:22 <sipa> jgarzik: commented on the pullreq
91 2013-01-30 03:05:28 <sipa> jgarzik: note that we don't ever need to actually do any 64-bit seek operations
92 2013-01-30 03:05:45 <sipa> it's just to support fopen opening a large file
93 2013-01-30 03:06:30 <asoltys> just playing with multisig, trying to create a transaction from a multisig address i created. anyone see what i'm doing wrong with my JSON here? http://paste.debian.net/230345/
94 2013-01-30 03:08:47 <etotheipi_> sipa: https://bitcointalk.org/index.php?topic=130764.msg1489553#msg1489553
95 2013-01-30 03:09:03 <etotheipi_> it looks like someone is leveraging malleability for double-spending
96 2013-01-30 03:09:24 <jgarzik> etotheipi_: good thread
97 2013-01-30 03:09:31 <jgarzik> etotheipi_: was just reading dooglus's post
98 2013-01-30 03:09:40 <etotheipi_> but doesn't the OP_FALSE make this tx non-standard?
99 2013-01-30 03:09:47 <etotheipi_> so again, it would pretty much need the help of a miner
100 2013-01-30 03:09:53 <jgarzik> etotheipi_: ..precisely
101 2013-01-30 03:10:00 <jgarzik> which was always the case
102 2013-01-30 03:10:20 <gmaxwell> Most of the SD double spends have been based on making a payment to SD that will get mined slowly
103 2013-01-30 03:10:38 <etotheipi_> jgarzik: it doesn't have to be ...
104 2013-01-30 03:10:41 <sipa> etotheipi_: not an OP_FALSE; it's a 0x00 byte inside the signature
105 2013-01-30 03:10:58 <jgarzik> etotheipi_: it doesn't HAVE to be, but it is the path of least resistance
106 2013-01-30 03:11:17 <etotheipi_> if 10% of the network is pissed off and doesn't take SD tx, couldn't you just figure out who those are
107 2013-01-30 03:11:30 <etotheipi_> place a bet with 90% of the network which that 10% will ignore
108 2013-01-30 03:11:44 <etotheipi_> then if you don't like it, send your conflicting tx to the other 10%
109 2013-01-30 03:12:01 <etotheipi_> obviously, not guaranteed, but definitely could get your edge... but I don't know how much of the network is split like this
110 2013-01-30 03:12:03 <gmaxwell> etotheipi_: yea thats already being done, it's mentioned in the old double spending thread.
111 2013-01-30 03:12:21 <gmaxwell> sipa: what additional pulls do you think we'll have in 0.8 before RC? I'd like to run some over night?
112 2013-01-30 03:12:48 <etotheipi_> gmaxwell: any idea how many miners have decided not to mine SD ?
113 2013-01-30 03:13:21 <gavinandresen> asoltys: the hex txids have to be in double-quotes
114 2013-01-30 03:14:59 <gavinandresen> gmaxwell: #2236 is the only pending pull that it is on my RC1 list
115 2013-01-30 03:15:05 <gmaxwell> etotheipi_: I have no idea. I know its more than one.
116 2013-01-30 03:17:28 <gavinandresen> oh, just thought of this again: should we remove the "don't use for mining/merchant apps" warning? I think yes...
117 2013-01-30 03:17:49 <BlueMatt> maybe just reword it?
118 2013-01-30 03:18:00 <BlueMatt> does it not currently say pre-release test version?
119 2013-01-30 03:18:36 <gavinandresen> yeah, but "rc1" means "we think this is good enough to be a release."
120 2013-01-30 03:18:50 <BlueMatt> rc1 or 0.8beta
121 2013-01-30 03:18:56 <BlueMatt> we think this is good enough to be a beta release
122 2013-01-30 03:19:06 <sipa> yes, i think we can remove the warning for rc1
123 2013-01-30 03:19:16 <BlueMatt> s/or/of/
124 2013-01-30 03:20:24 <sipa> gmaxwell: i'd like to see hal/cointweaks/nativealloc still in, but i don't think gavin likes that :)
125 2013-01-30 03:21:52 <sipa> jeff's flow control/netmessage would also be nice, but i haven't tested it much after seeing a segfault from it
126 2013-01-30 03:22:14 <gmaxwell> I am imagining gavin thinking about murder. :P
127 2013-01-30 03:22:31 <gavinandresen> I'm thinking about going to sleep, and then murdering y'all tomorrow....
128 2013-01-30 03:22:49 <gmaxwell> leaving out Hal means that the next upgrade when we pull it we get a free nice x% performance improvement. :)
129 2013-01-30 03:23:27 <BlueMatt> does it have parallel sigchecking currently?
130 2013-01-30 03:23:44 <gavinandresen> I'm generally unexcited about x% performance improvements when x is less than about 30. and yes, it has parallel sigchecking
131 2013-01-30 03:25:27 <sipa> gmaxwell: i found out that in recent versions of openssl they actually reverted their specialized NIST code for applicable curves in favor of the generic assembly-optimized montgomery multiplication
132 2013-01-30 03:25:52 <sipa> gmaxwell: which i think means that it's very hard to beat that without going for specialized+assembly code
133 2013-01-30 03:26:34 <gmaxwell> sipa: I wonder if that was it for performance or because the NIST code for some of the fields (the characteristic 2 ones) requires a certicom patent (at least according to certicom)?
134 2013-01-30 03:26:44 <sipa> gmaxwell: performance
135 2013-01-30 03:27:16 <gmaxwell> Interesting.
136 2013-01-30 03:27:22 <sipa> there's still the extra-specialized code for NIST224/256, which has specialized datastructures with 26 bits per uint32 and stuff
137 2013-01-30 03:27:45 <sipa> (instead of just code specialized for doing the field multiplication)
138 2013-01-30 03:28:27 <gmaxwell> I wonder if fast asm specialized ECDSA validation code is the sort of thing that could be reasonably bountied. Esp with a bounty proportional to the improvement. (like http://prize.hutter1.net/ )
139 2013-01-30 03:30:06 <Luke-Jr> gmaxwell: who's going to audit it for subtle backdoors?
140 2013-01-30 03:30:56 <petertodd> Luke-Jr: at least have two bounties...
141 2013-01-30 03:31:04 <gmaxwell> Luke-Jr: s'not like thats a new problem. Ignoring the fact that there is all kinds of crazy optimizations going into openssl doesn't make the issue go away.
142 2013-01-30 03:31:04 <sipa> Luke-Jr: you should always be able to "augment" it with code to extract the intermediate values being computed, and compare those to another ECDSA verifier
143 2013-01-30 03:31:52 <sipa> Luke-Jr: as the optimizations are about data structures and low-level mathematical operations being improved, and changing the actual high-level ECDSA algorithm
144 2013-01-30 03:32:01 <sipa> s/and/NOT/
145 2013-01-30 03:32:57 <gmaxwell> In any case, you'd put a deadzone around zero on the bounty, so the speedup has to actually be enough to spend some time reviewing it before it gets paid in any case.
146 2013-01-30 03:32:57 <petertodd> sipa: IIRC you wrote something to have Hal's signature checking run in parallel with the existing one
147 2013-01-30 03:33:25 <sipa> petertodd: correct
148 2013-01-30 03:34:06 <sipa> petertodd: which is why i trust it reasonably well now
149 2013-01-30 03:34:17 <BlueMatt> it would be nice to have a fuzzer, not just run on known-good signatures
150 2013-01-30 03:34:30 <BlueMatt> s/known-good/standardly generated
151 2013-01-30 03:34:43 <sipa> well, it's not just doing both ECDSA verifications and comparing the boolean outcoming
152 2013-01-30 03:35:01 <sipa> but comparing the intermediate values
153 2013-01-30 03:35:10 <BlueMatt> ok, but still
154 2013-01-30 03:35:11 <gmaxwell> And IIRC sipa did fuzz it.
155 2013-01-30 03:35:17 <gmaxwell> (or am I remembering another change?)
156 2013-01-30 03:35:25 <sipa> i fuzzed something
157 2013-01-30 03:35:34 <gmaxwell> maybe it was the canonical vs openssl
158 2013-01-30 03:35:39 <sipa> i think that was the canonical, indeed
159 2013-01-30 03:36:27 <petertodd> reminds me, has piuk ever offered the non-std tx data his big collection of nodes is getting? could be useful real-world fuzz material
160 2013-01-30 03:36:36 <gmaxwell> BlueMatt: not an awful idea, but unfortunately the nastiest issues would end up being really subtle and never hit by a fuzzer, things like -s%p
161 2013-01-30 03:36:46 <BlueMatt> gmaxwell: true
162 2013-01-30 03:37:28 <gmaxwell> (Generally fuzzing sucks: BUT it's non-human, and so it finds the really easy issues which are still invisible to humans)
163 2013-01-30 03:39:45 <BlueMatt> hmm...well in any case fuzzing testing intermediate values and maybe weighting towards extremes...I dunno
164 2013-01-30 03:39:51 <BlueMatt> never know
165 2013-01-30 03:41:06 <BlueMatt> anyway, before release I have 5 or 10 more block/tx tests to get added
166 2013-01-30 03:53:35 <sipa> gmaxwell: there, fuzzer added
167 2013-01-30 04:37:09 <asoltys> can I get the redeemscript for a multisigaddress in my wallet that i created with "addmultisigaddress" rather than "createmultisig"?
168 2013-01-30 04:41:54 <petertodd> asoltys: I think the only way is to get the pubkeys used to make it with validateaddress, then recreate the redeemscript with createmultisig again
169 2013-01-30 05:31:12 <asoltys> petertodd: ah ok, thanks
170 2013-01-30 05:36:20 <asoltys> yeehaw, my first multisig transaction: https://blockchain.info/tx/9d969e69b4c942cf26e07cf3d60a2a64b4e1909d6f89a2143890858b56f3263c thanks for the help folks, calling it quits for tonight
171 2013-01-30 07:07:10 <SomeoneWeird> hmm, what's the tool to bruteforce priv addresses again?
172 2013-01-30 07:18:03 <SomeoneWeird> uh, public addresses, actually
173 2013-01-30 07:19:08 <SomeoneWeird> nevermind, vanitygen
174 2013-01-30 08:00:52 <osmosis> in bitcoin-qt, in the send dialog I can enter in a greater number of bitcoins then even exists in the wallet, or a greater number of bitcoins then will ever exist even, click send, it says 'are you sure you want to send', then 'this operation needs your wallet passphrase'. I didnt go past that step. Shouldnt it just say invalid amount first?
175 2013-01-30 12:23:12 <paul0> wow, bitcoin is using more than 6gb of disk space
176 2013-01-30 12:28:26 <panzer> mine is over 8gb
177 2013-01-30 12:29:16 <epscy> mine is 6.8
178 2013-01-30 13:11:35 <helo> since the default policy in windows is to automatically hibernate after 10 minutes or idleness, will all of those machines be a consistent net loss on the network?
179 2013-01-30 13:12:03 <helo> s/or/of/
180 2013-01-30 13:15:24 <Luke-Jr> helo: presumably; but is that really a default policy?
181 2013-01-30 13:15:30 <Luke-Jr> sounds more like a battery policy
182 2013-01-30 13:18:48 <helo> that's the default behavior of my windows 8 install
183 2013-01-30 13:18:55 <helo> on a normal desktop
184 2013-01-30 13:19:09 <SomeoneWeird> yeah, its default Luke-Jr
185 2013-01-30 13:19:10 <SomeoneWeird> it's stupid
186 2013-01-30 13:19:17 <SomeoneWeird> for win8
187 2013-01-30 13:19:26 <helo> can't get my steam games installed, can't get the blockchain synched
188 2013-01-30 13:19:32 <Luke-Jr> sigh
189 2013-01-30 13:19:34 <SomeoneWeird> just disable it
190 2013-01-30 13:19:39 <SomeoneWeird> go into power settings or something
191 2013-01-30 13:19:43 <sipa> helo: so disable it?
192 2013-01-30 13:19:49 <sipa> first thing i do on a windows system
193 2013-01-30 13:19:54 <SomeoneWeird> yap
194 2013-01-30 13:20:01 <sipa> (haven't ever touched win8 though)
195 2013-01-30 13:21:57 <helo> yeah, i could do that. i'm more interested in how this will impact the network. should windows 8 installs stop in spv mode?
196 2013-01-30 13:22:39 <Luke-Jr> it might make sense to find out if Bitcoin-Qt can inhibit default-sleep during IBD at least
197 2013-01-30 13:23:21 <sipa> you mean actually hibernate while just up and running?
198 2013-01-30 13:24:58 <helo> as a power saving mechanism, it seems like a reasonable policy... i wouldn't be surprised if most desktop systems started doing the same
199 2013-01-30 13:25:25 <SomeoneWeird> sipa when it hasn't been used, yeah
200 2013-01-30 13:25:31 <Luke-Jr> SetThreadExecutionState(ES_AWAYMODE_REQUIRED | ES_CONTINUOUS | ES_SYSTEM_REQUIRED);
201 2013-01-30 13:25:34 <helo> once you start calculating the carbon footprint and total energy saved by default hibernate, i bet it's hard to argue against
202 2013-01-30 13:25:40 <Luke-Jr> http://stackoverflow.com/questions/629240/prevent-windows-from-going-into-sleep-when-my-program-is-running
203 2013-01-30 13:25:43 <sipa> not like a laptop with the lid closed or anything?
204 2013-01-30 13:25:58 <SomeoneWeird> not does it to my families desktop
205 2013-01-30 13:26:00 <helo> sipa: yeah... instead of just sleeping the monitor as with previous releases, it hibernates
206 2013-01-30 13:26:18 <SomeoneWeird> yeah
207 2013-01-30 13:26:23 <SomeoneWeird> thankgod i don't use windows
208 2013-01-30 13:34:25 <epscy> how many full nodes are running on windows?
209 2013-01-30 13:34:50 <epscy> like all the time
210 2013-01-30 13:47:32 <helo> who would be able to see the release download stats for various platforms?
211 2013-01-30 13:48:00 <helo> BlueMatt?
212 2013-01-30 13:48:22 <HM> worrying about carbon footprint for an application that must chew up cpu constantly crunching digital signitures ...
213 2013-01-30 13:50:03 <MC1984> epscy i got one
214 2013-01-30 13:51:08 <helo> HM: i was just asking about the impact on the network of win8's default-hibernate policy
215 2013-01-30 13:53:13 <epscy> it's cool that anyone can run it at home on a windows box
216 2013-01-30 13:53:23 <sipa> helo: for the binaries? just check sourceforge download page?
217 2013-01-30 13:53:44 <MC1984> another reason to start in spv mode and upgrade to full at your leisure?
218 2013-01-30 13:53:48 <epscy> but realistically, i think it the future even non mining full nodes will be on a server in a dataceter somewhere
219 2013-01-30 13:54:00 <epscy> *in the future
220 2013-01-30 13:54:12 <sipa> if the max block chain size is increased, probably
221 2013-01-30 13:54:33 <SomeoneWeird> whats spv?
222 2013-01-30 13:54:47 <sipa> lightweight mode, like what multibit does
223 2013-01-30 13:54:54 <SomeoneWeird> oh, ic
224 2013-01-30 13:54:57 <sipa> only validate block headers, but not transactions
225 2013-01-30 13:55:01 <SomeoneWeird> qt can do that now?
226 2013-01-30 13:57:32 <Luke-Jr> no
227 2013-01-30 13:57:33 <sipa> no
228 2013-01-30 13:57:51 <SomeoneWeird> bitcoind?
229 2013-01-30 13:58:09 <SomeoneWeird> no wonder i was confused lol
230 2013-01-30 13:58:19 <sipa> no
231 2013-01-30 13:58:28 <SomeoneWeird> i didn't think it could/would
232 2013-01-30 13:58:31 <helo> sipa: and the ppa
233 2013-01-30 13:58:31 <sipa> afaik multiple and bitcoin wallet for android
234 2013-01-30 13:58:39 <sipa> ppa?
235 2013-01-30 13:59:00 <sipa> s/multiple/multibit/
236 2013-01-30 13:59:01 <helo> the delivery mechanism for ubuntu users
237 2013-01-30 13:59:12 <SomeoneWeird> lol
238 2013-01-30 13:59:16 <SomeoneWeird> isnt the ppa horribly outdated
239 2013-01-30 13:59:23 <helo> no
240 2013-01-30 13:59:36 <helo> it was up to date the last time i used it
241 2013-01-30 13:59:53 <helo> i'm pretty sure it is on 0.7.2
242 2013-01-30 14:00:04 <sipa> yes, what about that?
243 2013-01-30 14:02:20 <gavinandresen> sipa: can you https://gist.github.com/4673845 to pull 2236? (add _LARGE_FILE_OFFSET to bitcoin.qt.pro file)
244 2013-01-30 14:05:57 <sipa> gavinandresen: done
245 2013-01-30 14:06:32 <gavinandresen> sipa: thanks! I'm working on 0.8 release notes...
246 2013-01-30 14:07:11 <sipa> gavinandresen: -reindex crashing when no blocks are present is worth looking into
247 2013-01-30 14:07:17 <sipa> as reported by Diapolo
248 2013-01-30 14:08:28 <gavinandresen> sipa: ok, will do. I want to get a release notes draft written first, then there are a few loose ends before tagging the tree and spinning a release
249 2013-01-30 14:08:50 <sipa> good
250 2013-01-30 14:08:55 <jgarzik> I went ahead and pulled the dir name change stuff
251 2013-01-30 14:09:07 <sipa> #2224 added some new translatable strings
252 2013-01-30 14:09:29 <sipa> so i guess a translations update is useful
253 2013-01-30 14:09:35 <gavinandresen> I think for rc1 I'll add a note about the dir name change, letting people know what to move so they don't have to reindex
254 2013-01-30 14:09:49 <gavinandresen> (letting pre-rc people know???)
255 2013-01-30 14:10:02 <sipa> right, that shouldn't go into final release release notes, but for rc's it's useful
256 2013-01-30 14:10:42 <sipa> also mention that the undo file format changed at some point, so you may see errors at startup during block validation (fixed by a -reindex)
257 2013-01-30 14:11:31 <jgarzik> it's only for pre-release hackers
258 2013-01-30 14:11:38 <sipa> sure
259 2013-01-30 14:11:41 <jgarzik> just add a note "if you ran pre-0.8, delete your public data"
260 2013-01-30 14:11:58 <jgarzik> just add a note "if you ran pre-0.8, delete your public data, we changed dir names and file formats"
261 2013-01-30 14:13:26 <sipa> perhaps it's useful (just for rcs) to have a list of all file names and directory names that have existed, so people can judge what can be deleted and what not
262 2013-01-30 14:14:33 <Luke-Jr> hmm
263 2013-01-30 14:14:56 <Luke-Jr> does bitcoind build (specifically, libleveldb.a) if you don't build Bitcoin-Qt first?
264 2013-01-30 14:15:09 <Luke-Jr> I'm getting db/builder.cc:5:24: fatal error: db/builder.h: No such file or directory
265 2013-01-30 14:15:16 <Luke-Jr> (even before the pullreq I'm working on)
266 2013-01-30 14:21:45 <jgarzik> sipa:indeed
267 2013-01-30 14:24:47 <Luke-Jr> blah, it's losing its compiler options -.-
268 2013-01-30 14:29:07 <gavinandresen> How long does the after-upgrade reindex take on a typical machine? Half an hour?
269 2013-01-30 14:30:35 <MC1984> what is a typical macine for bitcoin
270 2013-01-30 14:30:54 <MC1984> dual core at least?
271 2013-01-30 14:30:57 <Luke-Jr> gavinandresen: pretty sure the reindex I just completed took about 20 hours..
272 2013-01-30 14:31:14 <Luke-Jr> but I did have it ionice'd down
273 2013-01-30 14:38:46 <sipa> Luke-Jr: lolwut?
274 2013-01-30 14:39:58 <Luke-Jr> ok, I think #2241 is ready for review finally
275 2013-01-30 14:40:03 <sipa> gavinandresen: https://gist.github.com/4674095
276 2013-01-30 14:42:20 <gavinandresen> sipa: ACK. That's too much detail for the release notes, but good info to put in a forum thread, I think
277 2013-01-30 14:42:31 <sipa> gavinandresen: or perhaps in a docs/FILES
278 2013-01-30 14:43:04 <gavinandresen> sipa: okey dokey
279 2013-01-30 14:44:39 <Luke-Jr> gavinandresen: This is intended for 0.8, would be nice to get testing in rc1: https://github.com/bitcoin/bitcoin/pull/2241
280 2013-01-30 14:45:47 <gavinandresen> Luke-Jr: too late for 0.8.0
281 2013-01-30 14:46:02 <Luke-Jr> gavinandresen: without at least the first commit, bitcoind doesn't build for me, FWIW
282 2013-01-30 14:46:10 <gavinandresen> okey dokey
283 2013-01-30 14:46:45 <Luke-Jr> I suppose I can try to split out the other fixes from the system leveldb bit
284 2013-01-30 14:59:40 <Luke-Jr> gavinandresen: k, strictly build bugfixes moved to https://github.com/bitcoin/bitcoin/pull/2243
285 2013-01-30 14:59:47 <Luke-Jr> will remake 2241 on top of that
286 2013-01-30 14:59:50 <sipa> Luke-Jr: leveldb does += to CXXFLAGS, it shouldn't clobber things?
287 2013-01-30 15:00:01 <Luke-Jr> sipa: make's += doesn't work like that, sadly
288 2013-01-30 15:00:24 <Luke-Jr> sipa: user-provided variables overwrite makefile-provided ones after the makefile sets them up
289 2013-01-30 15:01:21 <sipa> bah
290 2013-01-30 15:02:54 <SomeoneWeird> that's stupid
291 2013-01-30 15:03:51 <sipa> Luke-Jr: will that work? CXXFLAGS is set by build_config.mk
292 2013-01-30 15:04:19 <Luke-Jr> sipa: not mine? :o
293 2013-01-30 15:05:23 <sipa> only PLATFORM_CXXFLAGS indeed, good
294 2013-01-30 15:05:58 <sipa> anyway, the xCXXFLAGS thing can be = instead of +=, no?
295 2013-01-30 15:06:29 <Luke-Jr> sipa: could be, sure
296 2013-01-30 15:07:02 <Luke-Jr> sipa: do you want me to go back and change that?
297 2013-01-30 15:07:38 <sipa> += is just slightly more confusing for a reader, as it seems to imply an existing value is being appended to
298 2013-01-30 15:08:52 <Luke-Jr> I wonder if I should do the same for LDFLAGS too, since that's also a standard var
299 2013-01-30 15:10:33 <Luke-Jr> sipa: pushed adjusted code
300 2013-01-30 15:25:43 <t7> "64GB MS Surface Pro Only Has 23GB of Free Space"
301 2013-01-30 15:25:50 <t7> wrong channel soz
302 2013-01-30 15:35:08 <gavinandresen> ???. man there are a lot of changes to wade through in 0.8 ....
303 2013-01-30 15:37:00 <TD_> only a handful of interest to end users though, no
304 2013-01-30 15:37:43 <sipa> gavinandresen: 268 non-merge commits
305 2013-01-30 15:38:08 <sipa> v0.6.0..v0.7.0 had 697 it seems :o
306 2013-01-30 15:38:38 <gavinandresen> TD_ : yeah, the time-consuming part is deciding what is release-note-worthy and what is not
307 2013-01-30 15:42:09 <gavinandresen> I'm waffling on whether or not to mention the 0-confirmation lockTime attack / fix???.
308 2013-01-30 15:42:59 <SomeoneWeird> was it fixed?
309 2013-01-30 15:43:06 <gavinandresen> yes
310 2013-01-30 15:43:11 <SomeoneWeird> then I don't see why not
311 2013-01-30 15:43:20 <gavinandresen> ??? there are still plenty of other ways to double-spend 0-conf transactions, though
312 2013-01-30 15:43:26 <TD_> indeed
313 2013-01-30 15:43:28 <SomeoneWeird> ofc
314 2013-01-30 15:43:48 <ThomasV> what was the attack?
315 2013-01-30 15:43:49 <SomeoneWeird> maybe those should be fixed :P
316 2013-01-30 15:43:56 <Luke-Jr> SomeoneWeird: the bug wasn't really in Bitcoin-Qt
317 2013-01-30 15:44:18 <TD_> apps that people are building, which use 0-confirm txns, aren't doing sufficient risk analysis
318 2013-01-30 15:44:22 <TD_> (in a few cases anyway)
319 2013-01-30 15:44:29 <TD_> satoshidice has been hit by a few double spends because of that
320 2013-01-30 15:44:33 <Luke-Jr> basically it was disabling a feature that was useless (and inaccessible), until it has a use
321 2013-01-30 15:44:38 <sipa> i'd certainly mention new/changed command-line flags: -par (if your CPU fan goes too loud, use -par=1), -dbcache (setting it higher speeds up IBD, up to a few hundred), -checklevel (modified meaning), -nocheckpoints, -reindex, -txindex (if you want getrawtransaction)
322 2013-01-30 15:44:41 <gavinandresen> mmm, some of the 0-conf attacks can be mitigated, but we'll always have the FInney attack
323 2013-01-30 15:45:11 <jgarzik> gavinandresen: mention it
324 2013-01-30 15:45:27 <jgarzik> gavinandresen: but include a big honking "0 conf is simply not secure, and we've always known that" disclaimer
325 2013-01-30 15:46:05 <TD_> gavinandresen: yes, but you can measure and handle that sort of risk
326 2013-01-30 15:46:10 <jgarzik> The more complicated answer is "know your risk profile and underlying tech 100%"
327 2013-01-30 15:46:12 <jgarzik> but few do
328 2013-01-30 15:46:17 <sipa> exactly
329 2013-01-30 15:46:20 <gavinandresen> jgarzik: that's what I decided: https://gist.github.com/4674571
330 2013-01-30 15:46:23 <TD_> the double spend i investigated against SD boiled down to "pool operator decided to deliberately exclude SD transactions to resolve a deadlock"
331 2013-01-30 15:46:33 <TD_> merchants that don't insist on using public, fixed addresses wouldn't have that issue
332 2013-01-30 15:46:45 <jgarzik> if you are sophisticated enough to understand _all_ zero conf recommendations, you are sophisticated enough to ignore $Conventional_Wisdom
333 2013-01-30 15:46:57 <jgarzik> $Conventional_Wisdom should be simple: don't do it
334 2013-01-30 15:47:00 <sipa> jgarzik: exactly
335 2013-01-30 15:47:16 <TD> the problem is, this would get internalized by end users and then Bitcoin will get a reputation as "that thing where you have to wait for 10 minutes to receive money"
336 2013-01-30 15:47:30 <TD> when many, many people are not in a position where they have to worry about Finney attacks
337 2013-01-30 15:47:45 <jgarzik> many, many people are not qualified to know if they are impacted
338 2013-01-30 15:47:49 <TD> (eg, anyone who is selling burgers/doing in person currency trades, etc)
339 2013-01-30 15:47:49 <TD> sure
340 2013-01-30 15:47:52 <TD> but we can work on that over time
341 2013-01-30 15:47:54 <jgarzik> let providers handle knowing that for them
342 2013-01-30 15:48:08 <gavinandresen> ACTION mumbles experiment, only risk time or money blah blah blah....
343 2013-01-30 15:48:10 <TD> what providers?
344 2013-01-30 15:48:14 <jgarzik> gavinandresen: +1
345 2013-01-30 15:48:45 <jgarzik> TD: the ecosystem is simply not mature enough to do as you suggest
346 2013-01-30 15:49:17 <jgarzik> TD: once people are less using the Base Layer directly, and instead using third parties to transact instantly etc. the picture changes
347 2013-01-30 15:49:39 <TD> what third parties?
348 2013-01-30 15:49:46 <TD> the entire point of bitcoin is you don't need third parties
349 2013-01-30 15:50:30 <sipa> well, i do agree with the fact that saying "don't do 0-conf transactions" implies "bitcoin: receving money takes hours", while it should be "receiving money is instant, being sure it won't get reverted takes hours"
350 2013-01-30 15:50:50 <sipa> but at the same time, very few are in a position where they can reason about the risks
351 2013-01-30 15:50:51 <TD> that's no different, from the regular users perspective.
352 2013-01-30 15:51:04 <TD> yes, that's true. but that's partly because we have such a crap website :)
353 2013-01-30 15:51:12 <gavinandresen> "patches welcome"
354 2013-01-30 15:51:17 <TD> for instance, i'll go out on a limb and say any user of the Android wallet is not at risk
355 2013-01-30 15:51:49 <TD> i'm not even sure it makes sense to show unconfirmed vs confirmed state there. that said, i still haven't finished allowing those users to spend unconfirmed change.
356 2013-01-30 15:51:52 <TD> so i guess it still matters :)
357 2013-01-30 15:52:03 <gavinandresen> sipa: re: new command-line options: ACK on dbache / par / txindex??? I think the others aren't useful enough to be release-note-worthy
358 2013-01-30 15:53:00 <sipa> gavinandresen: i think -reindex too
359 2013-01-30 15:53:14 <sipa> gavinandresen: -nocheckpoints and -checklevel are indeed more for powerusers
360 2013-01-30 15:53:52 <gavinandresen> ok, -reindex too
361 2013-01-30 15:56:19 <gavinandresen> FYI: initial upgrade reindex looks like it took over an hour on my main machine (default settings for -dbcache)
362 2013-01-30 15:57:31 <sipa> how much of that is past 210k?
363 2013-01-30 15:59:00 <Luke-Jr> can't mention txindex without reindex :P
364 2013-01-30 16:00:26 <sipa> tru
365 2013-01-30 16:02:40 <MC1984> what does checklevel do
366 2013-01-30 16:03:13 <sipa> MC1984: degree of validation that is done to the block chain database at startup
367 2013-01-30 16:03:58 <sipa> there used to be 7 levels (0-6), now there are 5 - but their meaning is very different (level 3 is now stronger than the previous level 6)
368 2013-01-30 16:03:59 <SomeoneWeird> on startup it checks every block it downloads before it saves it, right?
369 2013-01-30 16:04:20 <MC1984> oh i thought you either had checkpoints or you didnt
370 2013-01-30 16:04:38 <sipa> MC1984: checkpoints have nothing to do with it, those are just hardcoded block hashes
371 2013-01-30 16:04:49 <sipa> SomeoneWeird: 'on startup' and 'it downloads' contradict eachother
372 2013-01-30 16:05:21 <SomeoneWeird> right, when it downloads a block it validated it before saving, correct?
373 2013-01-30 16:05:31 <sipa> short answer: yes
374 2013-01-30 16:05:58 <MC1984> in light of this, is there a standard for doing benchmarks then
375 2013-01-30 16:06:07 <sipa> longer answer: validation happens in several stages, and a block is stored on disk as soon as a part of them are satisfied, but full transaction checking is only done afterwards
376 2013-01-30 16:06:27 <SomeoneWeird> ah, ic
377 2013-01-30 16:07:10 <sipa> SomeoneWeird: -checkblocks and -checklevel only control the checks done at startup (which are by definition redundant, but they protect against disk errors corrupting your database, for example)
378 2013-01-30 16:07:13 <eckey> I'm using Bitcoin-Qt 0.7.1 on OSX 10.8.2. When I 'Quit' the process, it hangs around for over 10 minutes, clocking about 5% CPU. Is this normal?
379 2013-01-30 16:07:52 <CodeShark> what's the CPU like before you quit?
380 2013-01-30 16:08:37 <eckey> don't know, I'd have to start it. I'm on my way to the Apple store to have them look at the disk
381 2013-01-30 16:09:18 <CodeShark> the disk giving you problems in other apps?
382 2013-01-30 16:09:34 <eckey> for a period during the 10 minutes, the system is completely locked
383 2013-01-30 16:09:50 <CodeShark> even aqua?
384 2013-01-30 16:09:51 <eckey> don't think so but not sure
385 2013-01-30 16:10:05 <eckey> aqua?
386 2013-01-30 16:10:12 <CodeShark> the desktop
387 2013-01-30 16:10:22 <CodeShark> if you click on other apps, it doesn't bring them into focus?
388 2013-01-30 16:10:42 <eckey> correct, all i have is the bouncing beach ball
389 2013-01-30 16:10:55 <eckey> no command-tab or clicking to other apps
390 2013-01-30 16:12:09 <CodeShark> is your block chain db synched?
391 2013-01-30 16:13:01 <eckey> when i start it it has to catch up the blocks it missed while down.
392 2013-01-30 16:13:39 <eckey> what do you mean db?
393 2013-01-30 16:13:51 <CodeShark> yes, that
394 2013-01-30 16:14:35 <eckey> this morning it had to catch up 100+ blocks because it wasn't running overnight
395 2013-01-30 16:14:48 <eckey> but it didn't have to load the entire chain
396 2013-01-30 16:14:57 <ThomasV> when a transaction is in the memory pool but never confirms, the user really gets punished. I wish there was a way to increase the fee.
397 2013-01-30 16:15:06 <ThomasV> (ie non-final transactions)
398 2013-01-30 16:15:24 <jgarzik> expire TXs from memory pool
399 2013-01-30 16:15:30 <jgarzik> if they don't make it into a block within X time
400 2013-01-30 16:15:31 <jgarzik> :)
401 2013-01-30 16:15:42 <CodeShark> let me know when you've tested the CPU pre-quit, eckey - I'm wondering why that's happening
402 2013-01-30 16:16:00 <eckey> so it's not normal?
403 2013-01-30 16:16:00 <ThomasV> jgarzik: is there a way to do that currently?
404 2013-01-30 16:16:10 <jgarzik> ThomasV: That's been my open proposal for a while, and nobody has really disagreed.. It is mainly waiting on implementation
405 2013-01-30 16:16:14 <CodeShark> it shouldn't happen, no, eckey
406 2013-01-30 16:16:15 <jgarzik> clients MUST retransmit
407 2013-01-30 16:16:19 <jgarzik> until making it into a block
408 2013-01-30 16:16:19 <sipa> jgarzik: that may help (and i'm not against it), but it's very easy to attack
409 2013-01-30 16:16:28 <sipa> so it's not a full solution
410 2013-01-30 16:16:33 <jgarzik> agreed
411 2013-01-30 16:16:57 <eckey> code: i'm on my way to the Apple store to have them look at the hardware. thanks for your help. i'll check in later.
412 2013-01-30 16:17:00 <sipa> a better one is using prio calculations together with unconfirmed parents, and add child transactions that change chance into fee
413 2013-01-30 16:17:02 <jgarzik> it's not meant as attack prevention primarily, but to make memory pool behavior more deterministic over time, as this behavior is adopted
414 2013-01-30 16:17:30 <jgarzik> eventually you will _know_ when you can cancel a transaction, to a high degree of certainty [once this behavior is adopted, as mentioned]
415 2013-01-30 16:17:32 <sipa> s/chance/change/
416 2013-01-30 16:17:42 <sipa> no, it's never _know_
417 2013-01-30 16:18:02 <ThomasV> jgarzik: how long are transactions retransmitted?
418 2013-01-30 16:18:10 <jgarzik> "to a high degree" (indicating a probabilistic answer)
419 2013-01-30 16:18:10 <sipa> ThomasV: forever
420 2013-01-30 16:18:19 <jgarzik> ThomasV: until they make it into a block
421 2013-01-30 16:18:19 <sipa> ThomasV: until they confirm
422 2013-01-30 16:18:27 <ThomasV> hmm
423 2013-01-30 16:18:43 <sipa> and that is even if there is already a conflicting transaction in the chain
424 2013-01-30 16:18:51 <sipa> (which is a bug, imho)
425 2013-01-30 16:19:42 <Luke-Jr> gavinandresen: you didn't see anything notable in Qt 4.8.4 worth upgrading to it? unless I'm reading the notes wrong, it adds support for Windows 8 (suggesting previous versions have some problem(s) on it?)
426 2013-01-30 16:21:09 <gavinandresen> no, I saw nothing in the release notes that made me think we needed to upgrade to Qt 4.8.4. And I'm not aware of any issues on Windows 8 for the subset of Qt that we use
427 2013-01-30 16:21:34 <ThomasV> sipa: if I create another tx that depends on my low priority pending tx, and the 2nd tx has a huge fee, will miners currently detect it, and will it speed up the first tx?
428 2013-01-30 16:22:32 <ThomasV> this could be a way to solve it
429 2013-01-30 16:22:56 <Luke-Jr> gavinandresen: ah, true. I guess there's a lot of Qt we don't use.
430 2013-01-30 16:23:02 <sipa> ThomasV: no, that's exactly what i'm saying
431 2013-01-30 16:23:17 <sipa> that's not done now (Luke has a pullreq to do this, though)
432 2013-01-30 16:23:22 <sipa> but it should be
433 2013-01-30 16:23:24 <ThomasV> sipa: right, got it now
434 2013-01-30 16:23:37 <sipa> gavinandresen, Luke-Jr: in the 4.8.3 release notes:
435 2013-01-30 16:23:39 <sipa> - Add OS version detection for Windows 8
436 2013-01-30 16:23:50 <sipa> so at least there is *some* support :)
437 2013-01-30 16:24:14 <Luke-Jr> ThomasV: Eligius runs with that pullreq, so in practice you could get it mined in about a day
438 2013-01-30 16:24:19 <ThomasV> sipa: so, a client could have a "speed up this tx" functino, that just does an internal transaction
439 2013-01-30 16:24:23 <gavinandresen> but what does that mean? OS version detection when building? running?
440 2013-01-30 16:24:32 <Luke-Jr> I guess if it works, it works.
441 2013-01-30 16:24:55 <ThomasV> Luke-Jr: how much of a fee do you wat ? :)
442 2013-01-30 16:25:04 <ThomasV> *want*
443 2013-01-30 16:25:57 <Luke-Jr> ThomasV: 100000 BTC
444 2013-01-30 16:26:08 <Luke-Jr> ThomasV: but it will accept the usual fee (after the parent txn is included in size)
445 2013-01-30 16:26:32 <ThomasV> that's a bit expensive given the "about a day" delay
446 2013-01-30 16:26:38 <SomeoneWeird> lmao
447 2013-01-30 16:26:43 <Luke-Jr> (it will take lower than the usual fee too, but I'm not sure exactly the details anymore)
448 2013-01-30 16:27:04 <gavinandresen> my machine is still "Reindexing blocks on disk" ??? I think we should add a new checkpoint to speed that up. And maybe tweak the default -dbcache setting ?
449 2013-01-30 16:27:55 <gavinandresen> Draft 0.8 release notes: https://gist.github.com/4674836
450 2013-01-30 16:28:05 <sipa> gavinandresen: you said a reindex took an hour for you; how much is past the 210k checkpoint?
451 2013-01-30 16:29:01 <sipa> gavinandresen: -dbcache is not a new setting (it used to be the BDB buffer size)
452 2013-01-30 16:29:03 <Luke-Jr> gavinandresen: it'd be nice to know what the -dbcache number represents
453 2013-01-30 16:29:34 <gavinandresen> sipa: reindexing took almost 2 hours (1:53)??? let me dig out the number for up-to-210K
454 2013-01-30 16:30:08 <sipa> gavinandresen: you don't have to run with the -txindex settings (just specifying it at reindex time suffices); it will complain if you do specify it and it doesn't match the setting in the index
455 2013-01-30 16:30:15 <porquilho> SomeoneWeird Oo ?!
456 2013-01-30 16:30:18 <porquilho> why are you banning me
457 2013-01-30 16:31:11 <porquilho> WHY IS this guy banning me
458 2013-01-30 16:31:36 <Luke-Jr> gavinandresen: I see you document it more lower down. Maybe a (see below for details) at the top?
459 2013-01-30 16:31:57 <gavinandresen> sipa: 1:11 (eleven!) to reindex to height=210000
460 2013-01-30 16:32:49 <Luke-Jr> gavinandresen: other than that, looks good
461 2013-01-30 16:34:08 <ThomasV> Luke-Jr: where is that pullreq, btw?
462 2013-01-30 16:35:40 <Luke-Jr> ThomasV: https://github.com/bitcoin/bitcoin/pull/1647
463 2013-01-30 16:35:59 <Luke-Jr> ThomasV: I have a 0.6.0.x-based version as well, if you want that
464 2013-01-30 16:36:02 <ThomasV> nice name :)
465 2013-01-30 16:36:15 <ThomasV> Luke-Jr: I am not mining :)
466 2013-01-30 16:37:03 <ThomasV> but we could try to convince slush to use it
467 2013-01-30 16:37:23 <gavinandresen> updated release notes: https://gist.github.com/4674836
468 2013-01-30 16:37:50 <gavinandresen> TODO list for after lunch looks like:
469 2013-01-30 16:38:05 <gavinandresen> double-check to make sure 0.7.2 fixes made it into the master branch
470 2013-01-30 16:38:20 <gavinandresen> commit release notes to doc/release-notes.txt
471 2013-01-30 16:38:35 <gavinandresen> remove the "pre-release test build, don't use it" warning
472 2013-01-30 16:38:41 <gavinandresen> bump version numbers
473 2013-01-30 16:38:51 <gavinandresen> tag tree
474 2013-01-30 16:39:51 <gavinandresen> oh, oops: add a checkpoint around block 217,000 or so
475 2013-01-30 16:40:01 <sipa> ;;bc,blocks
476 2013-01-30 16:40:02 <gribble> 218765
477 2013-01-30 16:41:05 <gavinandresen> 217777 is a nice number...
478 2013-01-30 16:41:24 <gavinandresen> afk, lunch
479 2013-01-30 16:42:06 <sipa> only 1000 blocks deep? that seems low, and by the time the next release is there, the difference in IBD time because of that will be marginal
480 2013-01-30 16:42:09 <SomeoneWeird> 213456
481 2013-01-30 16:42:14 <SomeoneWeird> just to annoy OCD'ers
482 2013-01-30 16:42:16 <SomeoneWeird> :3
483 2013-01-30 16:43:02 <gavinandresen> sipa: ok, how about 216666 ? Nice mark-of-satan there....
484 2013-01-30 16:44:06 <HM> Satoshi should have upped the block reward for prime block numbers
485 2013-01-30 16:44:19 <ThomasV> lol
486 2013-01-30 16:44:22 <SomeoneWeird> haha that would have been awesome
487 2013-01-30 16:45:02 <SomeoneWeird> gavinandresen, you have to make the next checkpoint 314159
488 2013-01-30 16:45:59 <HM> 271828 is first
489 2013-01-30 16:46:14 <sipa> was just about to say that
490 2013-01-30 16:46:19 <HM> i think that's more significant toward exponential growth
491 2013-01-30 16:46:19 <SomeoneWeird> ah, true
492 2013-01-30 16:46:40 <sipa> gavinandresen: ok, i like sticking to the "one retarget cycle deep" policy
493 2013-01-30 16:53:22 <ThomasV> I restarted my bitcoind, and my "tx taking forever" is gone.
494 2013-01-30 16:54:24 <porquilho> Someguy123
495 2013-01-30 16:54:25 <porquilho> SomeoneWeird
496 2013-01-30 16:54:26 <porquilho> SomeoneWeird
497 2013-01-30 16:54:29 <porquilho> why did you ban me ?
498 2013-01-30 16:54:36 <Someguy123> *facepalm*
499 2013-01-30 16:54:49 <Someguy123> SomeoneWeird, having a name so close to mine is annoying at times
500 2013-01-30 16:54:50 <Someguy123> =_+
501 2013-01-30 16:56:08 <porquilho> sorry Someguy123
502 2013-01-30 16:56:16 <porquilho> why did you ban me SomeoneWeird
503 2013-01-30 16:57:06 <porquilho> maybe he put me on ignore
504 2013-01-30 16:57:10 <porquilho> someone ask him
505 2013-01-30 17:01:50 <helo> porquilho: he determined that you and 'share' were the same person, and 'share' was misbehaving
506 2013-01-30 17:02:22 <helo> he, among others
507 2013-01-30 17:03:24 <gavinandresen> darn it, can't use block 216666 for a checkpoint, the block before it has a later timestamp.
508 2013-01-30 17:03:48 <SomeoneWeird> 213456 >.>
509 2013-01-30 17:04:31 <sipa> gavinandresen: let's 51% attack the chain to fix that :p
510 2013-01-30 17:04:32 <porquilho> but im not share
511 2013-01-30 17:05:00 <gavinandresen> lets see if 216111 works???. (eleven being my favorite number, y'know)
512 2013-01-30 17:05:07 <helo> porquilho: you'll have to take that up with him... i recommend /m SomeoneWeird instead of discussing in here
513 2013-01-30 17:05:07 <porquilho> helo
514 2013-01-30 17:05:18 <porquilho> he put me on ignore
515 2013-01-30 17:05:42 <porquilho> :\\
516 2013-01-30 17:06:13 <porquilho> thanks for clarifying helo
517 2013-01-30 17:06:23 <gavinandresen> 216111 works???. although 216116 is even nicer, it has a timestamp of 11:11 GMT
518 2013-01-30 17:06:24 <porquilho> i just got banned out of nothing
519 2013-01-30 17:06:39 <sipa> porquilho: where?
520 2013-01-30 17:06:43 <gavinandresen> ???. generated on january 11'th....
521 2013-01-30 17:06:47 <sipa> gavinandresen: go for it!
522 2013-01-30 17:06:49 <helo> you may have to wait until you're unbanned (maybe a couple days). i mentioned that i thought you were generally constructive.
523 2013-01-30 17:07:18 <gavinandresen> 216116 it'll be, that's just too many elevens for me to ignore.
524 2013-01-30 17:07:26 <porquilho> in #bitcoin-otc
525 2013-01-30 17:07:27 <porquilho> and
526 2013-01-30 17:07:29 <porquilho> #bitcoin
527 2013-01-30 17:07:39 <porquilho> not in here becase he doesnt have op
528 2013-01-30 17:22:37 <MC1984> RC?
529 2013-01-30 17:36:33 <gavinandresen> grumble grumble grumble???. "we" never fixed the insert-change-at-random-position bug....
530 2013-01-30 17:37:03 <ThomasV> what is that bug?
531 2013-01-30 17:37:22 <gavinandresen> ThomasV: https://bitcointalk.org/index.php?topic=128042.0
532 2013-01-30 17:38:02 <Luke-Jr> gavinandresen: I thought sipa did..
533 2013-01-30 17:38:05 <Luke-Jr> CodeShark: ping
534 2013-01-30 17:38:28 <CodeShark> Luke-Jr: ?
535 2013-01-30 17:38:44 <gavinandresen> Luke-Jr: I thought so too, but I don't see the +1 in wallet.cpp
536 2013-01-30 17:39:00 <gavinandresen> (actually, I thought I fixed it....)
537 2013-01-30 17:39:36 <SomeoneWeird> git blame time
538 2013-01-30 17:40:11 <Luke-Jr> CodeShark: PM
539 2013-01-30 17:46:21 <kuzetsa> etotheipi: oh, armory has coin control now?
540 2013-01-30 17:56:16 <sipa> i certainly didn't fix that, i thought you did, gavinandresen?
541 2013-01-30 17:56:59 <gavinandresen> ??? that'll teach me to not open an issue for something that I think I couldn't possibly forget to fix...
542 2013-01-30 17:59:05 <gavinandresen> https://github.com/bitcoin/bitcoin/pull/2246
543 2013-01-30 17:59:26 <sipa> gavinandresen: code looks correct to me
544 2013-01-30 17:59:32 <sipa> it used to be -1, and the -1 is gone?
545 2013-01-30 17:59:57 <gavinandresen> it used to be nothing
546 2013-01-30 18:00:30 <sipa> gavinandresen: i'm pretty sure it's correct
547 2013-01-30 18:00:32 <gavinandresen> (well, before spendmany it used to be an if coin-flip then swap change and non-change output)
548 2013-01-30 18:00:39 <sipa> gavinandresen: the argument to getrandint is the maximum
549 2013-01-30 18:00:53 <gavinandresen> yup. I'll pull.
550 2013-01-30 18:00:56 <sipa> no
551 2013-01-30 18:01:48 <gavinandresen> aha: https://github.com/bitcoin/bitcoin/pull/2120
552 2013-01-30 18:01:54 <gavinandresen> I poked the wrong button on github
553 2013-01-30 18:02:32 <gavinandresen> lets see if I can get it right this time....
554 2013-01-30 18:03:11 <sipa> aaah damn
555 2013-01-30 18:03:21 <sipa> the argument nMax is not the maximum
556 2013-01-30 18:03:53 <gavinandresen> right, it is [min,max)
557 2013-01-30 18:04:07 <sipa> yes, i assumed it was [0,max]
558 2013-01-30 18:04:14 <sipa> so yes, indeed, it's not fixed
559 2013-01-30 18:09:39 <petertodd_> gavinadresen: https://gist.github.com/4675807 <- minor wording change for release-notes re: txindex, I think the way it's written implies txindex is a one-shot thing
560 2013-01-30 18:11:03 <Luke-Jr> petertodd_: it is
561 2013-01-30 18:11:53 <petertodd_> oh, well never mind then... weird, I'll have to figure out why that hadn't worked for me
562 2013-01-30 18:12:10 <sipa> petertodd_: it's basically a property of the block index, so it needs to be set when the block index is created (i.e., when -reindex'ing)
563 2013-01-30 18:12:22 <sipa> if that doesn't work, it's a bug
564 2013-01-30 18:12:47 <petertodd_> alright, I'll track it down, I might have had it on a non-txindex version when I saw the behavior
565 2013-01-30 18:13:41 <sipa> _if_ -txindex=? is supplied, it must match the state of the database (and it refuses to start if there's a mismatch)
566 2013-01-30 18:13:48 <sipa> but you don't have to specify it
567 2013-01-30 18:15:03 <petertodd_> maybe that's what I did, started with txindex != 1 on a non-txindex bitcoind, anyway, I'll look into it later
568 2013-01-30 18:26:24 <BlueMatt> blockchain.info devs arent on irc, correct?
569 2013-01-30 18:42:19 <sipa> BlueMatt: i think piuk has been here, but not often
570 2013-01-30 18:43:34 <gavinandresen> wumpus : ping?
571 2013-01-30 18:58:19 <wumpus> gavinandresen: pong
572 2013-01-30 18:58:29 <Diapolo> sipa: sorry, I'm tired ^^ that pull was really one of the worst ones :D
573 2013-01-30 18:58:49 <wumpus> wow you've been really busy lately Diapolo :)
574 2013-01-30 18:59:00 <gavinandresen> wumpus: I'm looking at https://github.com/bitcoin/bitcoin/issues/2239 and working on a quick fix
575 2013-01-30 18:59:04 <Diapolo> wumpus: hey mate :)
576 2013-01-30 18:59:36 <Diapolo> gavinandresen: what about: return QDateTime::fromTime_t(pindexBest ? pindexBest->GetBlockTime() : (int64)0);
577 2013-01-30 18:59:40 <gavinandresen> wumpus: is QDateTime ClientModel::getLastBlockDate() supposed to return the time of the last block we HAVE ?
578 2013-01-30 19:00:12 <gavinandresen> Diapolo: I'm testing a patch that has it return the hard-coded timestamp of the main network genesis block
579 2013-01-30 19:00:22 <wumpus> yes gavinandresen
580 2013-01-30 19:00:24 <Diapolo> even better :)
581 2013-01-30 19:00:29 <sipa> gavinandresen: sounds correct
582 2013-01-30 19:00:39 <gavinandresen> wumpus: great. patch incoming???.
583 2013-01-30 19:00:40 <sipa> (in case of pindexBest==NULL)
584 2013-01-30 19:00:44 <Diapolo> weird that that never caused errors before until now
585 2013-01-30 19:01:03 <wumpus> either that or return your birthday or something :)
586 2013-01-30 19:01:12 <gavinandresen> sipa: re: -reindex with an empty datadir : will the IBD get kicked off when a new block is found on the network?
587 2013-01-30 19:01:27 <wumpus> but yes the genesis block makes sense
588 2013-01-30 19:01:28 <sipa> actually
589 2013-01-30 19:01:33 <gavinandresen> wumpus: ooh, 11/11/2011 ....
590 2013-01-30 19:01:44 <wumpus> :-)
591 2013-01-30 19:01:46 <sipa> i expect problems if you do a reindex with an empty datadir
592 2013-01-30 19:01:48 <Diapolo> wumpus: any thoughts on that header / cpp cleanup, pulltester seems to eat it and I would like to start a Qt5 pull after 0.8 is final
593 2013-01-30 19:02:02 <sipa> gavinandresen: needs testing, i guess, but i'm afraid it may not
594 2013-01-30 19:02:03 <gavinandresen> sipa: well, it doesn't crash, but I haven't managed to get it to download any blocks....
595 2013-01-30 19:02:16 <wumpus> Diapolo: all those cleanups can wait until 0.8 is released right, i don't see a point in rushing them in
596 2013-01-30 19:02:27 <gavinandresen> sipa: that's a bug I can live with
597 2013-01-30 19:02:34 <Diapolo> wumpus: right, just wanted to know if you hate me for it ^^
598 2013-01-30 19:02:48 <wumpus> no, I don't, I've just stopped pulling most stuff for now because of the release phase
599 2013-01-30 19:03:08 <sipa> -reindex skips the normal auto-adding of the genesis block to the database, as you want to reuse the existing one already on disk
600 2013-01-30 19:03:13 <Diapolo> gavinandresen: I observed that also, that after reindex no new blocks get downloaded ... didn't bother to look at it, thought that is caused by our normal IBD mechanics ^^
601 2013-01-30 19:03:44 <gavinandresen> sipa: ah, that explains all of the ORPHAN BLOCK messages I saw
602 2013-01-30 19:03:49 <sipa> Diapolo: it is - IBD is booted when a connection to a node is opened, and there is no IBD going on
603 2013-01-30 19:04:18 <wumpus> and after 0.8 final there's also CodeShark's multi-wallet gui code reorganization, I think it makes sense to pull that first
604 2013-01-30 19:04:26 <Diapolo> sipa: but shouldn't IBD start after reindex because the if clause for IBD should be true afterwards?
605 2013-01-30 19:04:36 <sipa> Diapolo: but there are no new connections being made
606 2013-01-30 19:04:49 <sipa> as you'll typically be fully connected by the time reindex finishes
607 2013-01-30 19:05:06 <gavinandresen> sipa: mmm???. since we're recommending -txindex -reindex to people, that bug might be a showstopper.
608 2013-01-30 19:05:07 <Diapolo> wumpus: if he is able to rebase to integrate the latest changes yes, if no I would like the header / cpp cleanup first
609 2013-01-30 19:05:19 <Diapolo> sipa: sounds right, behaves wrong ^^
610 2013-01-30 19:05:39 <sipa> gavinandresen: well, if you haven't _ever_ started the client, you can just use -txindex
611 2013-01-30 19:05:49 <sipa> but -reindex should always work, period
612 2013-01-30 19:07:24 <sipa> gavinandresen: the solution is probably to extract the genesis-init-code from main's LoadBlockIndex, and call it at the time fReindex=false is set when pindexGenesis is still NULL
613 2013-01-30 19:07:44 <Diapolo> wumpus: I still feel uncomfortable with that big code-movement in that multi wallet pull as I think it's really hard to track if no code changes were made or are missing...
614 2013-01-30 19:08:45 <wumpus> Diapolo: yes, it needs to be carefully checked
615 2013-01-30 19:09:23 <Diapolo> wumpus: it would be nice if Github could use a form of references old place -> new place to compare it
616 2013-01-30 19:10:00 <wumpus> indeed, it would be great if their diff tools were somewhat smarter and could detect things like moved / copied code
617 2013-01-30 19:10:53 <Diapolo> wumpus: while you are here, that thing gooney mentioned and I observed that our progressbar has problems with updates, when there are no new blocks coming in ... what is THE solution for this?
618 2013-01-30 19:11:27 <wumpus> delete the progress bar? :<
619 2013-01-30 19:11:47 <gavinandresen> sipa: ACK, I'll work on a pull that does that, I think we need to make -reindex on an empty data dir work
620 2013-01-30 19:12:09 <Diapolo> wumpus: it's about every GUI element there, progress bar, label and the spinning icon and it's tooltips
621 2013-01-30 19:12:09 <wumpus> the progress bar is just a rough estimate
622 2013-01-30 19:12:24 <Diapolo> wumpus: I'm not talking about the precission of the bar :)
623 2013-01-30 19:13:16 <Diapolo> update on mouseover? and perhaps also cache reindex and importing values to trigger an update if they change?
624 2013-01-30 19:13:29 <wumpus> no, it should update when something has changed
625 2013-01-30 19:13:35 <wumpus> what updates does it have problems with?
626 2013-01-30 19:13:40 <gavinandresen> I sent somebody some ideas for making the progress bar more accurate??? (associate benchmark percentages with checkpoints)
627 2013-01-30 19:14:03 <sipa> gavinandresen: headers-first mode!
628 2013-01-30 19:14:08 <Diapolo> wumpus: it doesn't catch a change in block source, when reindex finishes for example
629 2013-01-30 19:14:12 <gavinandresen> sipa: +1000
630 2013-01-30 19:14:33 <wumpus> Diapolo: install an event handler to listen for those updates and update the appropriate widget when that quantity is updated
631 2013-01-30 19:14:52 <Diapolo> gavinandresen: I guess I received that, but had no time / will to take a deeper look Gavin
632 2013-01-30 19:15:09 <wumpus> headers-first mode would be cool for a thousand reasons, but a more precise progress bar really cannot bother me :)
633 2013-01-30 19:15:14 <Diapolo> I saved your idea :) perhaps I'll just create a ticket first for discussion
634 2013-01-30 19:16:19 <sipa> gavinandresen: oh, wait, no... you don't know the number of transactions in the best chain in headers-only mode
635 2013-01-30 19:16:35 <wumpus> we don't want a more precise progress bar but an instantly usable client
636 2013-01-30 19:16:38 <sipa> and there's no way to verifiably transfer that even
637 2013-01-30 19:17:24 <sipa> wumpus: well, just turning Bitcoin-Qt into an SPV client would be fine for that :)
638 2013-01-30 19:17:38 <Diapolo> wumpus: agreed but as I said I wasn't talking about precission
639 2013-01-30 19:17:40 <gavinandresen> yes, instantly usable is the goal. I'll settle for usable-when-headers-are-downloaded (what would that be, 5 minutes?)
640 2013-01-30 19:17:59 <wumpus> yes 5 minutes is fine and instant compared to how it is now :)
641 2013-01-30 19:18:18 <wumpus> Diapolo: so there should be an event for when the block source changed?
642 2013-01-30 19:18:26 <Diapolo> sipa: if Bitcoin-Qt get's seperated I'll lose motivation ^^ core and qt belong together in my world
643 2013-01-30 19:18:38 <Diapolo> wumpus: yes I think that's the solution
644 2013-01-30 19:18:57 <Diapolo> could perhaps be in void ClientModel::updateTimer() also
645 2013-01-30 19:18:59 <sipa> Diapolo: I disagree completely :)
646 2013-01-30 19:19:11 <Diapolo> sipa: which is fine ;)
647 2013-01-30 19:19:38 <sipa> Diapolo: it could still be the same codebase or even the same binary, which starts a bitcoind in the background for full validation, transparently to the user
648 2013-01-30 19:20:02 <sipa> but there is no part of the Qt GUi that currently depends on having a fully validating node behind it, afaik
649 2013-01-30 19:20:05 <sipa> so why require it?
650 2013-01-30 19:20:09 <Diapolo> sipa: I would love to work on one project, one codebase, if that is possible fine ^^
651 2013-01-30 19:20:10 <wumpus> yeah, seperate processes would be a good idea
652 2013-01-30 19:20:26 <helo> Diapolo: so you are against a system-wide bitcoind that multiple user wallets could connect to?
653 2013-01-30 19:21:05 <wumpus> I'm not sure that's a good idea helo
654 2013-01-30 19:21:15 <sipa> gavinandresen: already working on a patch for the reindex empty dir thing
655 2013-01-30 19:21:17 <wumpus> it would be a good idea to share the chain and P2P handling though
656 2013-01-30 19:21:31 <Diapolo> helo: I'm against nothing I just said on what I would like to still work work in the future ^^
657 2013-01-30 19:21:42 <gavinandresen> sipa: cool, thanks
658 2013-01-30 19:21:48 <wumpus> but sharing the wallet handling process between users sounds like a recipe for disaster
659 2013-01-30 19:22:08 <sipa> wumpus: that's exactly the opposite of what helo says?
660 2013-01-30 19:22:12 <Diapolo> gavinandresen: I think just for finding bugs I should get my checkpoint containing a 38 :-P
661 2013-01-30 19:22:20 <helo> i recall some discussion about a system-wide bitcoind that multiple users could use
662 2013-01-30 19:22:23 <wumpus> oh sorry I misread
663 2013-01-30 19:22:37 <sipa> helo: imho, system-wide bitcoind (which may be spawned by a single user) + one or more wallet clients connecting to it (which each maintain one or more wallets, and an SPV database)
664 2013-01-30 19:23:06 <sipa> you could drop the bitcoind and have SPV-level security, without any code change
665 2013-01-30 19:23:49 <midnightmagic> ACTION cheers for jgarzik
666 2013-01-30 19:28:42 <helo> is the motivation to allow lightweight various-use-case-targeted UIs that could coexist with bitcoin-qt without adding much overhead?
667 2013-01-30 19:29:25 <helo> so bitcoin-qt can stay very focused on end-user fund management and avoid bloat
668 2013-01-30 19:38:34 <Luke-Jr> sipa: ping
669 2013-01-30 19:39:10 <Luke-Jr> sipa: ConnectBestBlock takes a CValidationState argument, but doesn't use it - instead it makes a new CValidationState on the stack and discards it?
670 2013-01-30 19:39:27 <CodeShark> I'm also in favor of the bitcoind-as-service + additional wallet clients connecting to it model
671 2013-01-30 19:40:05 <Diapolo> wumpus: I have some changes for BitcoinGUI::setNumBlocks() that displays what the client is doing, even if we have no net or no data for the progressbar :)
672 2013-01-30 19:40:07 <CodeShark> and yes, I would like to see it support greater concurrency
673 2013-01-30 19:40:18 <Luke-Jr> sipa: also, ProcessBlock uses the passed CValidationState for processing formerly-orphan blocks - which seems like a DoS vector in various ways :o
674 2013-01-30 19:40:30 <Luke-Jr> CodeShark: that's a lot of work.
675 2013-01-30 19:40:47 <CodeShark> Luke-Jr: nothing worthwhile is easy
676 2013-01-30 19:40:50 <CodeShark> :)
677 2013-01-30 19:40:53 <Luke-Jr> ???
678 2013-01-30 19:41:27 <sipa> Luke-Jr: you're right in both cases
679 2013-01-30 19:41:44 <CodeShark> for what it's worth, most of the codebase necessary is already there. getting everyone to agree on the direction...that's a bit more of a challenge :)
680 2013-01-30 19:43:27 <CodeShark> I've been a strong advocate of the idea of turning bitcoind into a streamlined service node whose main tasks are validation of network messages, relaying, and preventing DoS attacks.
681 2013-01-30 19:43:33 <CodeShark> and moving all other functionality to other processes
682 2013-01-30 19:44:14 <CodeShark> including wallets
683 2013-01-30 19:44:44 <Diapolo> CodeShark: you are calling revolution, most of my time here I got the feeling bitcoin is based on evolution ;)
684 2013-01-30 19:45:07 <CodeShark> the thing is that most of what we already have can be reused to this end
685 2013-01-30 19:45:53 <Luke-Jr> sipa: which of us writes the fix?
686 2013-01-30 19:45:58 <sipa> Luke-Jr: feel free
687 2013-01-30 19:46:44 <CodeShark> Diapolo: I'm also not suggesting it should be an immediate change
688 2013-01-30 19:47:17 <CodeShark> I would like to see the codebase evolve in a direction where such an architecture and use model would be easy to support, though
689 2013-01-30 19:48:41 <CodeShark> I can tell you from my own personal usage of bitcoind - very few of my bitcoind instances use the wallet
690 2013-01-30 19:48:57 <CodeShark> most are used to relay messages to other programs I've written
691 2013-01-30 19:49:42 <Diapolo> sipa: a bootstrap.dat with a filled blocks folder (containing up todate block files) will not erasing blocks folder, right?
692 2013-01-30 19:50:21 <CodeShark> moreover, the instances that I do run with the wallet tend to be on intranet nodes
693 2013-01-30 19:50:42 <CodeShark> or just locally on my client machine
694 2013-01-30 19:55:15 <sipa> Diapolo: stuff in blocks/* is never erased :)
695 2013-01-30 19:55:26 <sipa> (well, -reindex clears blocks/index/)
696 2013-01-30 19:55:42 <Diapolo> sipa: so I expect the imported blocks are just skipped, because they are already there?
697 2013-01-30 19:55:46 <sipa> yes
698 2013-01-30 19:55:53 <Diapolo> that's fine, thanks
699 2013-01-30 19:55:58 <CodeShark> Diapolo: perchance have you had a moment to look at pull request 2220?
700 2013-01-30 19:57:12 <Diapolo> I still feel critically hit by it, because of that fu...ing diff display on Github...
701 2013-01-30 19:57:39 <CodeShark> ?
702 2013-01-30 19:58:12 <sipa> github diff view sucks :)
703 2013-01-30 19:58:14 <Diapolo> it's time consuming to check if it's just code movement or if perhaps changes sneaked in
704 2013-01-30 19:58:27 <sipa> two-side view is so much clearer
705 2013-01-30 19:58:38 <CodeShark> yeah
706 2013-01-30 20:00:20 <CodeShark> most of the code movements are from bitcoingui.cpp to walletview.cpp
707 2013-01-30 20:01:24 <Diapolo> I think wumpus intents to take a final look after we have 0.8 out ... if you can keep your pull based on the latest Qt changes to current master for point X I'm going to take an intensive look then too
708 2013-01-30 20:01:57 <CodeShark> modifications to bitcoingui.cpp are what are most likely to make merging complicated
709 2013-01-30 20:02:12 <CodeShark> changes to other source files won't affect the merge nearly as much
710 2013-01-30 20:03:09 <CodeShark> a big part of the reason for doing the multiwallet-qt-no-core was to completely separate the GUI changes from the core changes
711 2013-01-30 20:03:40 <benkay> are there any armory/armoryx developers kicking around today?
712 2013-01-30 20:03:51 <sipa> etotheipi_: ^
713 2013-01-30 20:04:07 <Diapolo> CodeShark: I already aggreed to that, my only fear is that we are merging something that misses the latest changes, which you can tell me won't happen ;) so it's all about just looking and doing it
714 2013-01-30 20:04:21 <CodeShark> I can rebase it if it's still a concern
715 2013-01-30 20:06:10 <Diapolo> before merging a final rebase should be done, yes ... and that's all I would like to see then
716 2013-01-30 20:06:30 <CodeShark> I just did a rebase - no conflicts
717 2013-01-30 20:07:22 <CodeShark> so I think we're still good :)
718 2013-01-30 20:07:54 <CodeShark> the core changes will be a lot more difficult to merge
719 2013-01-30 20:08:23 <Diapolo> these are nothing I fear as core is mostly "in the wild" for me ^^
720 2013-01-30 20:08:32 <Diapolo> thanks btw. :)
721 2013-01-30 20:14:17 <CodeShark> np :)
722 2013-01-30 20:15:34 <sipa> ACTION is curious about what time jgarzik gets home
723 2013-01-30 20:15:54 <sturles> ACTION too
724 2013-01-30 20:16:59 <D34TH> ACTION wonders why somebody shipped him flash drives?
725 2013-01-30 20:17:07 <D34TH> :P
726 2013-01-30 20:17:16 <sipa> ?
727 2013-01-30 20:17:36 <D34TH> deal extreme ships from china
728 2013-01-30 20:17:58 <sipa> yes
729 2013-01-30 20:17:59 <BlueMatt> its only 4:15...give him time.....
730 2013-01-30 20:18:21 <BlueMatt> ACTION anticipates a major increase in P2Pool rate this evening
731 2013-01-30 20:20:42 <benkay> why's that, BlueMatt?
732 2013-01-30 20:21:04 <BlueMatt> jgarzik
733 2013-01-30 20:24:03 <benkay> jgarzik runs lots of miners? i'm lacking epic context here.
734 2013-01-30 20:24:24 <sipa> benkay: jgarzik is potentially the receiver of the first Bitcoin ASIC
735 2013-01-30 20:24:30 <benkay> !
736 2013-01-30 20:24:33 <gmaxwell> benkay: 70GH/s asic miner box arrived at jeff's today.
737 2013-01-30 20:24:34 <benkay> thanks, sipa.
738 2013-01-30 20:24:57 <sipa> gmaxwell: no, something from china arrived at jeff's today :)
739 2013-01-30 20:25:04 <sipa> (unless you know more?)
740 2013-01-30 20:25:16 <benkay> implying it may be a brick?
741 2013-01-30 20:25:45 <sipa> i don't imply anything - including that it is an ASIC :p
742 2013-01-30 20:25:49 <gmaxwell> sipa: I said 'box'. :P
743 2013-01-30 20:26:03 <benkay> oh, you ;)
744 2013-01-30 20:26:03 <gmaxwell> It's like when you buy things on ebay. "iphone 5 (box)"
745 2013-01-30 20:27:05 <porquilho> gmaxwell, SomeoneWeird
746 2013-01-30 20:27:13 <porquilho> gmaxwell, SomeoneWeird banned me from otc and bitcoin
747 2013-01-30 20:27:25 <porquilho> becase he thinks i am another person
748 2013-01-30 20:27:26 <porquilho> and he is wrong
749 2013-01-30 20:40:44 <CodeShark> http://garzikrants.blogspot.com.es/2013/01/once-upon-time-in-china-package-shipped.html