1 2014-10-02 00:00:11 <dabura667> Almost exactly 7 hours ago was when I was talking about it
2 2014-10-02 00:40:52 <BlueMatt> sipa: ping
3 2014-10-02 00:41:30 <BlueMatt> ;;later tell sipa change the path to use the commithash 6324804b54262cd16d0d1d6bdbede5b809934723 and the filename to use pull-tests-d5b6d16.jar and try it again
4 2014-10-02 00:41:30 <gribble> The operation succeeded.
5 2014-10-02 00:43:08 <sipa> gribble: ok you can tell me now
6 2014-10-02 01:08:25 <cfields> sipa: pretty sure this is what he meant: http://pastebin.com/raw.php?i=RqMp0H0j
7 2014-10-02 01:14:32 <cfields> BlueMatt: erm.. https://github.com/TheBlueMatt/bitcoinj/commit/d5b6d1618adf8a96fe569c14dbcb2691298debca
8 2014-10-02 01:14:53 <cfields> BlueMatt: i suspect there's more to that?
9 2014-10-02 01:15:28 <BlueMatt> lol, yes, there is something missing there
10 2014-10-02 01:16:38 <sipa> BlueMatt: should i try with that hash?
11 2014-10-02 01:17:19 <BlueMatt> 1 sec
12 2014-10-02 01:17:50 <BlueMatt> use commithash 2d76ce92d68e6746988adde731318605a70e252c and file hash b55a98828b17060e327c5dabe5e4631898f422c0cba07c46170930a9eaf5e7c0 and filename pull-tests-5caed78.jar
13 2014-10-02 01:17:52 <sipa> BlueMatt: can you create a PR or commit somewhere?
14 2014-10-02 01:17:54 <BlueMatt> sipa: ^
15 2014-10-02 01:17:54 <sipa> ok
16 2014-10-02 01:18:18 <BlueMatt> I figured it'd be easier for you (see the pastebin above)
17 2014-10-02 01:18:22 <BlueMatt> but I can if you wish
18 2014-10-02 01:18:31 <sipa> nothing is easier than git merge :)
19 2014-10-02 01:18:41 <sipa> but on it now
20 2014-10-02 01:19:03 <BlueMatt> also, I didnt remember the filename so I was gonna make you go look it up instead of doing it myself :p
21 2014-10-02 01:19:42 <sipa> pushed
22 2014-10-02 01:23:34 <sipa> what is the filename derived from?
23 2014-10-02 01:23:55 <BlueMatt> commithash of bitcoinj
24 2014-10-02 01:24:08 <sipa> ah, got it
25 2014-10-02 01:24:18 <sipa> while 2d76 is the commithash of test-scripts
26 2014-10-02 01:25:57 <BlueMatt> yes
27 2014-10-02 01:43:31 <sipa> BlueMatt: GREEEEEN
28 2014-10-02 01:44:38 <BlueMatt> NICE
29 2014-10-02 01:47:05 <sipa> can you PR the comparison tool upgrade
30 2014-10-02 01:56:51 <sipa> BlueMatt: nevermind, #5027
31 2014-10-02 02:00:29 <BlueMatt> sipa: oops, missed it, sorry
32 2014-10-02 02:00:39 <BlueMatt> sipa: I was figuring you'd just leave it as a part of headers first
33 2014-10-02 02:00:43 <BlueMatt> but, whatever
34 2014-10-02 02:01:18 <poutine> dabura667, whats up
35 2014-10-02 02:25:11 <dabura667> Poutine: my mobile IRC client is not letting me copy my log...
36 2014-10-02 02:25:45 <dabura667> It was 9 and a half hours ago
37 2014-10-02 02:25:56 <dabura667> Gah this dumb app.
38 2014-10-02 02:27:47 <poutine> well it's no longer in my scroll buffer
39 2014-10-02 02:32:38 <gmaxwell> sipa: what was the issue with the comparison tool null pointer exception earlier today?
40 2014-10-02 02:33:16 <sipa> gmaxwell: ask BlueMatt
41 2014-10-02 02:34:33 <gmaxwell> bluematt: what was the issue with the comparison tool null pointer exception earlier today?
42 2014-10-02 02:38:45 <prettymuchbryce> What would it mean if a node responds to my tx with "reject??????2??????d?tx@non-canonical" ?
43 2014-10-02 03:09:53 <cfields> gmaxwell: https://github.com/TheBlueMatt/bitcoinj/commit/5caed78dad5abe1b5793ba831124e036b2d37e39
44 2014-10-02 03:11:10 <cfields> gmaxwell: looks like the comparison tool could get a getheaders before it had finished setting up its chain internally
45 2014-10-02 03:11:22 <cfields> sipa: congrats :)
46 2014-10-02 03:16:45 <dabura667> poutine: let me see if I can get it copied...
47 2014-10-02 03:22:58 <Luke-Jr> ACTION wonders what cfields is congrating sipa for
48 2014-10-02 03:23:18 <cfields> Luke-Jr: headers-first finally went green
49 2014-10-02 03:23:37 <Luke-Jr> aha
50 2014-10-02 03:57:39 <dabura667> https://www.irccloud.com/pastebin/gzJ4H5ff
51 2014-10-02 03:58:23 <dabura667> poutine: I was able to copy some of it
52 2014-10-02 04:54:33 <poutine> dabura667, Ok, I'm reading your paste. What's the txid/vout of the unspent txout?
53 2014-10-02 04:55:02 <poutine> http://tbtc.blockr.io/api/v1/tx/raw/027737bf6dc90185563efcd64fe8e20060bde89da0a82e969ef068e611bcee44 <- is this the tx you're trying to spend?
54 2014-10-02 04:55:06 <poutine> txout
55 2014-10-02 04:57:13 <poutine> I'm guessing 027737bf6dc90185563efcd64fe8e20060bde89da0a82e969ef068e611bcee44:0
56 2014-10-02 04:58:42 <poutine> dabura667, Your specified unsigned tx: 010000000144eebc11e668f09e962ea8a09de8bd6000e2e84fd6fc3e568501c96dbf3777020000000017a91457e821b8513ea3bb05e74eacf2fa7022d39172e887ffffffff01a0c44a00000000001976a91454162f4fefc07dd0a01336d278b77552eea0d09488ac0000000001000000 has script operations in the scriptSig. This part is wrong
57 2014-10-02 05:10:34 <dabura667> poutine: that's unsigned + for signing.
58 2014-10-02 05:11:15 <dabura667> So that's the data I double sha256 in order to calculate the sig
59 2014-10-02 05:11:42 <dabura667> Which is also why te hashtype is on there.
60 2014-10-02 05:12:29 <dabura667> Aren't you supposed to include the entire scriptpubkey of the refered vout of the previous transaction when signing?
61 2014-10-02 05:14:47 <dabura667> Oooooh!
62 2014-10-02 05:15:34 <dabura667> p2sh you need to insert the serialized redeemscript and not the scriptpubkey of the previous tx
63 2014-10-02 05:15:39 <dabura667> I get it now
64 2014-10-02 05:15:45 <dabura667> Awesome!
65 2014-10-02 05:16:58 <phantomcircuit> wat
66 2014-10-02 05:17:20 <BlueMatt> ;;seen wumpus
67 2014-10-02 05:17:20 <gribble> wumpus was last seen in #bitcoin-dev 9 hours, 9 minutes, and 23 seconds ago: <wumpus> right, the mempool is never allowed to conflict with the block chain
68 2014-10-02 06:22:30 <wumpus> BlueMatt: hey
69 2014-10-02 06:23:48 <sipa> morning wumpus
70 2014-10-02 06:23:58 <BlueMatt> wumpus: morning
71 2014-10-02 06:24:17 <BlueMatt> (I was just gonna see if you were on and ask for a closure of https://github.com/bitcoin/bitcoin/issues/4907, but it was more of a "hey, if he's here"...)
72 2014-10-02 06:25:44 <wumpus> morning
73 2014-10-02 06:25:49 <wumpus> ok, closed :)
74 2014-10-02 06:26:16 <sipa> RIP pulltester
75 2014-10-02 06:26:23 <BlueMatt> good riddance
76 2014-10-02 06:26:50 <wumpus> I liked pulltester, although it was one spammy bastard
77 2014-10-02 06:26:54 <wumpus> :)
78 2014-10-02 06:27:02 <BlueMatt> it was also broken for most of its life
79 2014-10-02 06:28:09 <wumpus> I'm not sure if it was broken most of its life, but yeah it was broken often; let's hope Travis does better there
80 2014-10-02 06:28:43 <wumpus> the stability up until now seems promising
81 2014-10-02 06:29:08 <BlueMatt> it has a maintainer, so its rather guaranteed to be better than something hacked together and then never maintained
82 2014-10-02 06:29:25 <wumpus> good point
83 2014-10-02 06:29:47 <Luke-Jr> dunno, I've found Travis to be klunky at best
84 2014-10-02 06:29:57 <Luke-Jr> not that I have any better alternatives to recommend
85 2014-10-02 06:41:54 <wumpus> klunky? you mean the interface?
86 2014-10-02 06:43:24 <wumpus> it took me a bit of getting used to, to have to click an extra time to get to the specific log, but then again there is so much log output now that having it all in one log would be inconvenient too :)
87 2014-10-02 06:49:51 <Luke-Jr> wumpus: I mean requiring a .travis.yml file for even the most basic/standard C project
88 2014-10-02 06:50:02 <Luke-Jr> ie, configure, make, make check
89 2014-10-02 06:50:27 <Luke-Jr> and the hacks to manually specify every variation you want
90 2014-10-02 06:50:55 <Luke-Jr> it'd be nice to not have to spend hours setting it up :p
91 2014-10-02 06:51:03 <wumpus> IIRC they can run without a .travis.yml, but I'm not sure what they do in that case. I know because I had accidentally activated that for bitcoin/bitcoin initially, and it flagged every pull with a red cross
92 2014-10-02 06:51:14 <Luke-Jr> it assumes Ruby if there's no .travis.yml
93 2014-10-02 06:51:18 <wumpus> oh :(
94 2014-10-02 06:51:30 <Luke-Jr> the end result is quite pretty though https://travis-ci.org/luke-jr/bfgminer :D
95 2014-10-02 06:52:29 <wumpus> that's a lot of variations
96 2014-10-02 06:53:17 <Luke-Jr> I'd like to have more (MinGW32, OpenWrt, Linux32, etc), but making Travis do those is .. too painful
97 2014-10-02 06:54:09 <wumpus> I suppose you'd have to build all the depenencies to like we do
98 2014-10-02 06:54:25 <Luke-Jr> right
99 2014-10-02 08:30:51 <wumpus> ugh... I broke the build
100 2014-10-02 08:31:25 <Luke-Jr> :o
101 2014-10-02 08:31:28 <wumpus> #4845 was not failing the travis tests, but now is after merge
102 2014-10-02 08:32:01 <wumpus> reverting...
103 2014-10-02 08:32:40 <wumpus> (seems to fail the recently added windows tests)
104 2014-10-02 09:29:38 <wumpus> ok - tests on master are green again https://travis-ci.org/bitcoin/bitcoin/builds/36848299 -- now trying to figure out what exactly went wrong
105 2014-10-02 09:30:54 <sipa> wumpus: my guess: a &vec[size]
106 2014-10-02 09:31:14 <sipa> which we only started testing recently
107 2014-10-02 09:31:24 <wumpus> sipa: I'd expect different errors in that case
108 2014-10-02 09:31:47 <wumpus> at least some assertion failure
109 2014-10-02 09:31:52 <wumpus> what we get is test/miner_tests.cpp(82): error in "CreateNewBlock_validity": check ProcessBlock(state, __null, pblock) failed
110 2014-10-02 09:32:43 <wumpus> and this seems to be windows specific
111 2014-10-02 09:37:31 <sipa> ok
112 2014-10-02 10:45:15 <wumpus> reproduced again in pull #4845, https://travis-ci.org/bitcoin/bitcoin/builds/36851727 , going to try locally now
113 2014-10-02 10:45:44 <wumpus> luckily depends makes it easy to set up a win32 cross build (without gitian)
114 2014-10-02 12:52:57 <michagogo> hmm
115 2014-10-02 12:53:40 <michagogo> Seeing lots of ERROR: CheckBlock() : size limits failed
116 2014-10-02 12:54:49 <michagogo> Several hundred of those alternated with ProcessBlock complaining about CheckBlock failing in one second
117 2014-10-02 12:54:55 <michagogo> Then it stops
118 2014-10-02 12:55:25 <michagogo> (this is running 0.9.3 in a Windows 10 VM, syncing with -connect from my local 0.9.3 node)
119 2014-10-02 12:57:24 <michagogo> In fact, looks like 128 pairs
120 2014-10-02 12:57:58 <michagogo> 2 minutes later: Peer 192.168.56.1 is stalling block download, disconnecting
121 2014-10-02 12:58:10 <michagogo> Then it promptly reconnects
122 2014-10-02 12:59:11 <michagogo> And 257 more of those pairs o_O
123 2014-10-02 13:00:54 <michagogo> Actually, that 257 was two events
124 2014-10-02 13:01:00 <michagogo> It's 128 each time
125 2014-10-02 13:01:08 <michagogo> Same thing after restarting the node o_O
126 2014-10-02 13:07:13 <michagogo> http://pastebin.com/rLBKCkmJ
127 2014-10-02 13:07:13 <michagogo> Okay, wtf
128 2014-10-02 13:07:22 <michagogo> That's the log running with -debug
129 2014-10-02 13:08:04 <michagogo> 2014-10-02 13:03:27 ERROR: CheckBlock() : size limits failed
130 2014-10-02 13:08:04 <michagogo> 2014-10-02 13:03:27 ERROR: ProcessBlock() : CheckBlock FAILED
131 2014-10-02 13:08:04 <michagogo> 2014-10-02 13:03:27 received: block (81 bytes)
132 2014-10-02 13:08:04 <michagogo> 2014-10-02 13:03:27 received block a5856447bc814f3ca660cdcc53894a2cfc2a6e9758c735c64a18299149136cde
133 2014-10-02 13:08:06 <michagogo> Huh?!?
134 2014-10-02 13:08:41 <michagogo> ACTION tries restarting the node on his computer
135 2014-10-02 13:11:24 <michagogo> Still happened
136 2014-10-02 13:11:58 <michagogo> But then reconnecting the VM to the internet and restarting without -connect, it's syncing mornally
137 2014-10-02 13:12:00 <michagogo> normally
138 2014-10-02 13:12:18 <michagogo> ACTION is very confused
139 2014-10-02 13:18:55 <michagogo> ...and after syncing a bunch, reconnecting, same thing
140 2014-10-02 13:18:58 <michagogo> ACTION fires up wireshark
141 2014-10-02 13:37:21 <michagogo> Okay, wtf
142 2014-10-02 13:37:28 <michagogo> It's sending a block of all zeroes
143 2014-10-02 13:37:30 <michagogo> https://www.cloudshark.org/captures/41a33afb7864
144 2014-10-02 13:38:23 <michagogo> Except for the version number
145 2014-10-02 13:45:59 <wumpus> michagogo: sounds like the sending node has a corrupted block chain
146 2014-10-02 13:46:07 <michagogo> Hm.
147 2014-10-02 13:46:29 <michagogo> Would a getblock on one of those blocks expose the issue?
148 2014-10-02 13:47:27 <wumpus> yes - if you know the original block hash, and getblock that, and get a block whose hash is different, you can be sure there is corruption
149 2014-10-02 13:47:40 <wumpus> but for example a5856447bc814f3ca660cdcc53894a2cfc2a6e9758c735c64a18299149136cde is useless
150 2014-10-02 13:50:14 <michagogo> Aha
151 2014-10-02 13:50:35 <michagogo> 16:50:10
152 2014-10-02 13:50:35 <michagogo> Can't read block from disk (code -32603)
153 2014-10-02 13:50:35 <michagogo> getblock 000000000015b9edb280336ef2e1e6a20191ee8a0a72f5c896bd551c5fa6e9b0
154 2014-10-02 13:50:38 <michagogo> Dammit.
155 2014-10-02 13:51:15 <wumpus> that's interesting - so RPC gives an error, but P2P sends a zeroed out block
156 2014-10-02 13:51:24 <michagogo> ...so it just returns all zeroes except for version 2?
157 2014-10-02 13:51:51 <michagogo> Weird.
158 2014-10-02 13:52:02 <michagogo> I wonder what caused this..
159 2014-10-02 13:52:30 <wumpus> indeed; is the blkXXXX file missing?
160 2014-10-02 13:52:56 <michagogo> How do I find out which one it should be in?
161 2014-10-02 13:53:15 <wumpus> I don't know, maybe add some debuggig around the 'Can't read block from disk' message
162 2014-10-02 13:53:34 <michagogo> Doesn't look like it's missing
163 2014-10-02 13:53:52 <michagogo> There are 174 files, named blk#####.dat from 0 through 173
164 2014-10-02 13:54:41 <michagogo> None of the blk*.dat files have been modified since some time in 2013
165 2014-10-02 13:54:59 <michagogo> At least, none of the first hundred or so
166 2014-10-02 13:55:07 <wumpus> you don't have anything in your debug.log?
167 2014-10-02 13:55:15 <michagogo> And that block is height 83850
168 2014-10-02 13:55:20 <michagogo> Oh, of course
169 2014-10-02 13:55:21 <wumpus> ReadBlockFromDisk *does* log a more detailed error
170 2014-10-02 13:55:24 <michagogo> oops
171 2014-10-02 13:55:31 <michagogo> ACTION checks
172 2014-10-02 13:55:39 <michagogo> Not sure how I missed that -_-
173 2014-10-02 13:56:01 <michagogo> 2014-10-02 13:55:55 ERROR: ReadBlockFromDisk : Deserialize or I/O error - CAutoFile::read : end of file
174 2014-10-02 13:57:04 <wumpus> that doesn't sound good
175 2014-10-02 13:57:18 <wumpus> any stop requests or other I/O errors in dmesg?
176 2014-10-02 13:57:27 <michagogo> Does Windows have a dmesg?
177 2014-10-02 13:57:31 <wumpus> oh, no clue
178 2014-10-02 13:57:42 <michagogo> ACTION checks Event Viewer
179 2014-10-02 14:00:21 <michagogo> Don't see anything
180 2014-10-02 14:01:58 <michagogo> ACTION has no idea
181 2014-10-02 14:02:30 <michagogo> So... reindex?
182 2014-10-02 14:04:04 <michagogo> wumpus: am I right in thinking a reindex would fix it?
183 2014-10-02 14:04:21 <wumpus> yes
184 2014-10-02 14:04:38 <wumpus> assuming no other corruption happens
185 2014-10-02 14:07:57 <michagogo> Whoa
186 2014-10-02 14:08:01 <michagogo> tons of 2014-10-02 14:07:54 ProcessBlock: ORPHAN BLOCK 0, prev=000000000000021705635a2180267faa002180a2424f674e423f95fbf5f7c5ad
187 2014-10-02 14:08:07 <michagogo> (with different prevs each time)
188 2014-10-02 14:08:58 <wumpus> that's expected, from the position of the corruption on it will be unable to connect the blocks
189 2014-10-02 14:09:02 <michagogo> ah
190 2014-10-02 14:09:44 <wumpus> if it happens that quickly you can just as well delete your blockchain files and start over
191 2014-10-02 14:10:01 <michagogo> wumpus: it was around the 60k mark
192 2014-10-02 14:14:28 <hearn> ugh, is someone messing with testnet?
193 2014-10-02 14:14:48 <hearn> if so please stop mining empty blocks
194 2014-10-02 14:18:38 <wumpus> michagogo: probably the same file with block 83850 in it...
195 2014-10-02 14:22:03 <michagogo> Grr, I guess I'll just reload from bootstrap
196 2014-10-02 14:22:36 <michagogo> Does -loadblock leave the file untouched, btw?
197 2014-10-02 14:22:48 <earlz> So, other than RPC username/password, is there anything to prevent drive-by XSS attacks on the wallet?
198 2014-10-02 14:23:17 <michagogo> (I don't want to move or rename it because I'm seeding it)
199 2014-10-02 14:23:23 <earlz> (ie, user loading a page in their browser that makes requests to 127.0.0.1... it's send-only due to cross-domain restrictions, but that's enough to send your coins somewhere
200 2014-10-02 14:24:25 <iwilcox> Isn't same-origin policy meant to apply to requests?
201 2014-10-02 14:25:04 <earlz> Nothing stops you from constructing a page with <form action="http://127.0.0.1:1234">
202 2014-10-02 14:25:35 <iwilcox> Except the browser won't be trying to talk JSON-RPC to the target
203 2014-10-02 14:26:09 <earlz> isn't it all over HTTP though? I wonder if it's possible to construct valid JSON-RPC calls from the browser
204 2014-10-02 14:26:18 <earlz> I imagine it probably is
205 2014-10-02 14:33:19 <michagogo> erm
206 2014-10-02 14:33:22 <michagogo> jgarzik: ping
207 2014-10-02 14:33:40 <michagogo> I'm trying to make a partial bootstrap.dat
208 2014-10-02 14:35:24 <michagogo> Am I misreading, or does the script fail if the genesis block isn't part of the blocks you requested?
209 2014-10-02 14:42:23 <wumpus> michagogo: yes
210 2014-10-02 14:42:39 <michagogo> Why? O_o
211 2014-10-02 14:42:41 <wumpus> loadblock doesn't touch anything, only the automatic bootstrap renames
212 2014-10-02 14:42:47 <michagogo> oh, that
213 2014-10-02 14:42:53 <michagogo> right, that's what I thought
214 2014-10-02 15:03:56 <wumpus> not sure it makes sense to make a partial bootstrap
215 2014-10-02 15:06:06 <wumpus> at least not if your goal is to skip 83000 blocks, those first blocks are processed in seconds
216 2014-10-02 15:08:58 <michagogo> wumpus: nah
217 2014-10-02 15:09:12 <michagogo> max_height=323508
218 2014-10-02 15:09:12 <michagogo> min_height=313000
219 2014-10-02 15:54:09 <jgarzik> michagogo, pong
220 2014-10-02 15:56:31 <michagogo> jgarzik: 17:33:42 <michagogo> I'm trying to make a partial bootstrap.dat
221 2014-10-02 15:56:32 <michagogo> 17:35:26 <michagogo> Am I misreading, or does the script fail if the genesis block isn't part of the blocks you requested?
222 2014-10-02 15:56:41 <michagogo> And I checked, turns out it does
223 2014-10-02 15:56:47 <michagogo> and by
224 2014-10-02 15:56:57 <michagogo> and by "fail" I mean "abort"
225 2014-10-02 15:57:03 <michagogo> Why does it do that?!?
226 2014-10-02 15:57:23 <michagogo> (I replaced the hash it checks for with the first hash that I wanted)
227 2014-10-02 15:58:00 <michagogo> jgarzik: In other words, you left in the min_height option, but made it not work
228 2014-10-02 16:01:07 <jgarzik> michagogo, typically an import requires that it start at block 0, so the script does not bother to create anything else
229 2014-10-02 16:01:30 <jgarzik> michagogo, perhaps with the new drop-in-and-reindex scheme, that changes the picture
230 2014-10-02 16:01:33 <michagogo> jgarzik: The script should me, IMHO, useful for more than just an import from 0
231 2014-10-02 16:01:41 <michagogo> should be*
232 2014-10-02 16:01:55 <michagogo> Right, maybe for drop-in-and-reindex it makes sense this way
233 2014-10-02 16:02:03 <michagogo> But the previous script was useful for more than this
234 2014-10-02 16:02:34 <michagogo> For example, generating a partial bootstrap, like I'm trying to do -- min_height=317001
235 2014-10-02 16:02:52 <michagogo> It was also able to update a file
236 2014-10-02 16:02:57 <jgarzik> michagogo, if you make a modification, I'll ACK it
237 2014-10-02 16:03:36 <michagogo> ACTION doesn't think he knows python well enough to do that
238 2014-10-02 16:04:16 <michagogo> I mean, I don't really know python at all... my tiny tweak to the previous version to allow appending and partial files was trial-and-error and guesswork :P
239 2014-10-02 16:47:36 <chichov> how come gettransaction <hash> gives me an error after I started the daemon with "-txindex -reindex" and waited until he was done?
240 2014-10-02 16:48:25 <Happzz> are nodes uniquely identified?
241 2014-10-02 16:48:38 <timothy> ip address : port? :P
242 2014-10-02 16:48:54 <Happzz> other than that.
243 2014-10-02 16:49:23 <chichov> my bad, had to use "getrawtransaction" with the hash
244 2014-10-02 17:13:00 <cfields> wumpus: you happen to be around to test a quick bdb fix?
245 2014-10-02 17:13:21 <cfields> i can't reproduce here, haven't moved to trusty yet
246 2014-10-02 17:13:33 <timothy> so new bdb have some problem?
247 2014-10-02 17:13:49 <cfields> no, it's just a little compile issue
248 2014-10-02 17:13:55 <timothy> ACTION is using 5.3.28
249 2014-10-02 17:14:07 <timothy> oh to compile old bdb on new compiler
250 2014-10-02 17:14:08 <timothy> ok
251 2014-10-02 17:14:25 <cfields> yes, exactly
252 2014-10-02 17:14:37 <timothy> well I'm on archlinux, so last compiler, last glibc, etc :)
253 2014-10-02 17:14:43 <timothy> if you need help
254 2014-10-02 17:15:13 <michagogo> chichov: gettransaction is wallet-onl
255 2014-10-02 17:15:14 <michagogo> y
256 2014-10-02 17:36:39 <chichov> is there any smart/efficient way to search for a transaction with a specific spent transaction output?
257 2014-10-02 17:37:30 <chichov> somewhat similar to following the chain at blockchain.info, where you can follow the path some money has went over transactions
258 2014-10-02 17:39:20 <sipa> chichov: build an index for it
259 2014-10-02 17:39:25 <sipa> bitcoind doesn't have that
260 2014-10-02 17:39:47 <sipa> you can look up by crediting txid, not by spending txid
261 2014-10-02 17:39:53 <chichov> sipa: I mean it's easy to go back once you've built the txindex, but forward is a different story
262 2014-10-02 17:40:05 <sipa> yes
263 2014-10-02 17:40:23 <chichov> alright, thanks for the suggestion
264 2014-10-02 17:40:32 <chichov> you think blockchain.info runs something like that?
265 2014-10-02 17:40:32 <sipa> i didn't suggest anything :)
266 2014-10-02 17:40:36 <sipa> yes
267 2014-10-02 17:40:56 <sipa> want efficient lookups for some query: build an index for it
268 2014-10-02 17:41:00 <sipa> that's true for everything
269 2014-10-02 17:54:36 <wumpus> cfields: sure
270 2014-10-02 17:54:56 <cfields> wumpus: good thing you replied late, my first fix was way off :)
271 2014-10-02 17:55:08 <wumpus> hehe okay
272 2014-10-02 17:55:14 <cfields> wumpus: see https://github.com/bitcoin/bitcoin/pull/5034
273 2014-10-02 17:58:47 <wumpus> cfields: it compiles!
274 2014-10-02 17:59:03 <cfields> ok, great.
275 2014-10-02 17:59:18 <cfields> thanks for reporting. someone else reported that a while back and i completely forgot about it
276 2014-10-02 17:59:59 <wumpus> yes I vaguely remember, wasn't that the guy trying to build in windows with mingw?
277 2014-10-02 18:00:48 <cfields> iirc he was considering it
278 2014-10-02 18:03:59 <cfields> wumpus: uh oh..
279 2014-10-02 18:04:06 <cfields> wumpus: https://travis-ci.org/bitcoin/bitcoin/jobs/36894037
280 2014-10-02 18:05:36 <gavinandresen> sipa: IsCompressedOrUncompressedPubKey() : ACK.
281 2014-10-02 18:06:43 <chichov> what's more or less the average block size?
282 2014-10-02 18:08:14 <michagogo> chichov: depends
283 2014-10-02 18:08:17 <michagogo> average all time?
284 2014-10-02 18:08:20 <michagogo> Or average recently?
285 2014-10-02 18:08:24 <chichov> average recently
286 2014-10-02 18:12:56 <wumpus> cfields: I don't get it
287 2014-10-02 18:13:14 <wumpus> cfields: what is failing there?
288 2014-10-02 18:13:30 <cfields> wumpus: not sure what happened yet, waiting on the merged version to see if the same thing happens
289 2014-10-02 18:16:50 <sipa> gavinandresen: done
290 2014-10-02 18:17:24 <cfields> wumpus: https://travis-ci.org/bitcoin/bitcoin/builds/36895505 built fine..
291 2014-10-02 18:17:34 <cfields> new bug in comparison-tool, i guess?
292 2014-10-02 18:18:10 <sipa> what's the bug?
293 2014-10-02 18:18:14 <michagogo> chichov: how recently? I can calculate it if you want
294 2014-10-02 18:18:36 <chichov> michagogo: oh nevermind, I got the right numbers now
295 2014-10-02 18:18:56 <cfields> bad: https://s3.amazonaws.com/archive.travis-ci.org/jobs/36894037/log.txt
296 2014-10-02 18:18:59 <cfields> good: https://api.travis-ci.org/jobs/36895512/log.txt?deansi=true
297 2014-10-02 18:19:09 <cfields> exact same build
298 2014-10-02 18:19:28 <BlueMatt> looks like comparisontool fail :(
299 2014-10-02 18:19:31 <BlueMatt> fuck
300 2014-10-02 18:19:36 <cfields> Blocks which should/should not have been accepted but weren't/were: 9
301 2014-10-02 18:23:33 <BlueMatt> cfields: hmm, not sure I can debug this much without a full debug.log :(
302 2014-10-02 18:24:07 <wumpus> can't we make travis push debug.log to a pastebin? *ducks*
303 2014-10-02 18:25:58 <cfields> heh
304 2014-10-02 18:26:19 <cfields> well, temporarily... we can just have it cat the whole log
305 2014-10-02 18:26:19 <wumpus> I'm sure the operators would hate us for pushing such large files, but at least there is no security issue in that case as you get a random URI every time
306 2014-10-02 18:26:38 <cfields> if it's too big, the build will fail, but it's already failed anyway...
307 2014-10-02 18:27:22 <wumpus> won't it fail without output in that case?
308 2014-10-02 18:27:27 <cfields> wumpus: that's equally hackish, but just as reasonable if it's temporary, imo
309 2014-10-02 18:27:37 <cfields> wumpus: iirc it fails and just cuts off at the limit
310 2014-10-02 18:27:40 <sipa> we can gzip + base64 encode it first :p
311 2014-10-02 18:29:23 <cfields> we can do either of those, and i'll start on an uploader for bitcoincore.org
312 2014-10-02 18:29:54 <cfields> no matter how we do it we expose ourselves to some kind of DOS, though we can limit it to be only a dev annoyance at worst, i think
313 2014-10-02 18:30:05 <cfields> (uploading to our own server, that is)
314 2014-10-02 18:34:28 <cfields> BlueMatt: how about just aborting at the first invalidBlocks ?
315 2014-10-02 18:34:54 <BlueMatt> yes, probably should do that too
316 2014-10-02 18:35:02 <chichov> sipa: is it possible to use getreceivedbyaddress for any address (after some configuration)?
317 2014-10-02 18:35:02 <sipa> cfields: what's the problem?
318 2014-10-02 18:35:27 <sipa> chichov: no, it's a wallet RPC
319 2014-10-02 18:35:44 <sipa> with watch-only you can make any address part of your wallet, though
320 2014-10-02 18:36:04 <chichov> watch-only?
321 2014-10-02 18:36:43 <wumpus> cfields: well if we host our own on bitcoincore.org I'd be afraid of people using it to upload arbitrary files
322 2014-10-02 18:36:48 <cfields> sipa: just trying to figure out how to help debug the comparison tool
323 2014-10-02 18:37:22 <BlueMatt> re: this bug: no rush, I think I know the problem
324 2014-10-02 18:37:25 <wumpus> cfields: unless we can restrict uploads to from travis only, then we can be reasonably sure no one will do that :)
325 2014-10-02 18:37:30 <cfields> wumpus: right, that's the concern. We could limit most of it by clamping the ip-range to travis's, but ofc that's not foolproof
326 2014-10-02 18:37:36 <BlueMatt> I'll cut off the tester after the first fail + a few blocks, so no rush on these things
327 2014-10-02 18:37:56 <wumpus> cfields: well if you make it too much bother, people won't do it
328 2014-10-02 18:38:32 <cfields> wumpus: indeed. I think we can effectively make it so that someone would have to PR a change in order to get a file pushed to the server
329 2014-10-02 18:38:47 <wumpus> cfields: much easier ways of hosting dox then :)
330 2014-10-02 18:38:51 <cfields> in that case, we'd be vulnerable, but we'd also see it happen and have a nice log of it :)
331 2014-10-02 18:39:07 <wumpus> like ehh, pastebin!
332 2014-10-02 18:39:13 <wumpus> ight
333 2014-10-02 18:39:16 <wumpus> +r
334 2014-10-02 18:39:19 <cfields> heh
335 2014-10-02 18:39:38 <cfields> wumpus: well i'm thinking mainly in terms of uploading build results, so binaries
336 2014-10-02 18:39:50 <cfields> since this would work the exact same way
337 2014-10-02 18:40:43 <cfields> but sure, it could be limited to debug logs at first, and see how that goes
338 2014-10-02 18:41:48 <cfields> BlueMatt: great, thanks
339 2014-10-02 18:44:05 <cfields> BlueMatt: while you're at it, could you give it a time limit for the "bitcoind still hasn't requested block..." case?
340 2014-10-02 18:44:15 <BlueMatt> cfields: yes
341 2014-10-02 18:44:23 <cfields> unless that's changed, we end up waiting forever there, so it stalls for 50min 'til travis kills it
342 2014-10-02 18:44:41 <BlueMatt> yea, pulltester used to have explicit timeouts of much shorter
343 2014-10-02 18:44:41 <cfields> thanks :)
344 2014-10-02 18:44:46 <BlueMatt> we might consider adding those ourselves too
345 2014-10-02 18:47:26 <cfields> i'd rather add as few arbitrary limits as possible. what takes 1min for a full test locally could take 10 on travis. But if we know that we've certainly failed a particular test after a few sec of waiting, it makes sense to scope the timeout there instead
346 2014-10-02 19:04:56 <Akima> "Bitcoin protocol ensures that bitcoins are not sent to address which does not exist" source: https://localbitcoins.com/faq#reverse_transaction
347 2014-10-02 19:05:00 <Akima> Is that true?
348 2014-10-02 19:05:31 <Akima> I thought you could generate a wallet offline and that would give you a functioning address that you can use to receive funds.
349 2014-10-02 19:06:18 <sipa> it's false
350 2014-10-02 19:07:30 <sipa> i think they are referring to the fact tha tbitcoin addresses have built-in checksum, so you can't just send to any arbitrary string of digits that looks like an address
351 2014-10-02 19:07:38 <sipa> but 'doesn' t exist' is confusing wording
352 2014-10-02 19:07:53 <dhill> all valid addresses exist :)
353 2014-10-02 19:08:15 <sipa> all valid addresses exist
354 2014-10-02 19:08:23 <sipa> no invalid ones exist
355 2014-10-02 19:08:48 <sipa> ACTION is a proud member of tautolgy club
356 2014-10-02 19:09:05 <Akima> sipa: ah, that makes sense. Thanks.
357 2014-10-02 19:28:42 <wumpus> please don't start translating error messages in core, it's a terrible idea, translators have it difficult enough as-is
358 2014-10-02 19:31:55 <sipa> "start" ?
359 2014-10-02 19:32:02 <wumpus> I still have a stack of messages with things I need to explain and/or fix up for translators so they can make a sensible thing of it
360 2014-10-02 19:32:30 <wumpus> yes, start - IIRC it's now limited to wallet-related messages and command-line arguments
361 2014-10-02 19:34:17 <wumpus> oh and initialization messages/errors, seemingly
362 2014-10-02 19:34:40 <wumpus> which makes sense as they're shown in the splash screen
363 2014-10-02 19:36:20 <wumpus> but translating block rejection messages, for example, would be a waste
364 2014-10-02 19:37:06 <sipa> all State.Abort() calls are translated currently
365 2014-10-02 19:37:18 <sipa> i'm just following existing practice in headersfirst
366 2014-10-02 19:37:25 <wumpus> UGH
367 2014-10-02 19:38:00 <jgarzik> wumpus, +1
368 2014-10-02 19:38:03 <jgarzik> agreed
369 2014-10-02 19:38:07 <sipa> i have no problem with changing that
370 2014-10-02 19:38:13 <wumpus> yes, let's change it immediately
371 2014-10-02 19:38:20 <wumpus> for some reason that escaped me
372 2014-10-02 19:39:21 <sipa> and AbortNode()
373 2014-10-02 19:39:38 <wumpus> AbortNode may make some sense
374 2014-10-02 19:39:58 <wumpus> ie, "Disk space is low!" is a message that is shown in the UI before exiting
375 2014-10-02 19:41:33 <wumpus> oh... I understand now, state.Abort calls AbortNode() with that message, so it is shown
376 2014-10-02 19:41:35 <wumpus> sneaky
377 2014-10-02 19:42:23 <wumpus> not sure this is the best way to do it, but at least we're not translating messages that only end up on RPC or logging
378 2014-10-02 19:42:54 <ajweiss> where can i find the most recent version of headers first?
379 2014-10-02 19:43:12 <gmaxwell> yea, I as trying to be maximally polite and not just say "fuck no!!" to that discussion.
380 2014-10-02 19:43:49 <sipa> gmaxwell: ?
381 2014-10-02 19:44:09 <sipa> ajweiss: in the pull request (#4468)
382 2014-10-02 19:44:58 <ajweiss> ok cool i was looking at the right thing
383 2014-10-02 19:47:50 <wumpus> gmaxwell: would probably be better to show some generic message about an internal error and have people check the debug log for details, but at least I now understand how it came to be that way that Abort() are translated
384 2014-10-02 19:48:01 <gmaxwell> sipa: jtimon asking about internationalizing block error messages.
385 2014-10-02 19:52:55 <wumpus> so, instead, the user will get a "Failed to write block index" "Ok" dialog.. hehe.. maybe it could be translated to "cow falling over but not dying" in some languages, like mozilla's crash
386 2014-10-02 20:23:28 <wumpus> https://github.com/bitcoin/bitcoin/pull/5036
387 2014-10-02 21:31:13 <BlueMatt> ;;later tell gavinandresen (and wumpus too) random thought, we could move the money that we're spending on the dev server into travis to get faster builds?
388 2014-10-02 21:31:13 <gribble> The operation succeeded.
389 2014-10-02 21:31:21 <BlueMatt> cfields: (would those builds actually be faster?)
390 2014-10-02 21:32:06 <cfields> BlueMatt: we're already getting cached builds from them
391 2014-10-02 21:32:34 <cfields> BlueMatt: we could bump up the builder count, though
392 2014-10-02 21:33:03 <BlueMatt> that was my question, yea
393 2014-10-02 21:33:11 <BlueMatt> maybe its worth throwing a tiny bit of money
394 2014-10-02 21:34:49 <cfields> i think it might be reasonable to bump up the count after a while. I wanted to give it some time to see how much we actually clog it up
395 2014-10-02 21:35:22 <cfields> i'd like to add some other builders (clang mainly, with fsanitize stuff switched on), but i think that'd slow us down too much atm
396 2014-10-02 21:37:29 <BlueMatt> and the wine tests
397 2014-10-02 21:37:38 <BlueMatt> and the full-reorg tests on one test
398 2014-10-02 21:37:40 <cfields> those are on now
399 2014-10-02 21:37:43 <BlueMatt> (after they work again, ofc)
400 2014-10-02 21:37:44 <cfields> (wine)
401 2014-10-02 21:37:47 <BlueMatt> ahh, nice
402 2014-10-02 21:37:56 <BlueMatt> was 'bout to say...I know those tests are failing
403 2014-10-02 21:39:28 <cfields> ah, i wasn't sure if you were planning to make em work for the future or not
404 2014-10-02 23:24:08 <BlueMatt> cfields, wumpus: ack troll to fix the broken tests: https://github.com/bitcoin/bitcoin/pull/5035