1 2014-11-27 02:09:27 <op_null> is there anybody around that I could talk to about the API limitations on history?
  2 2014-11-27 02:10:09 <op_null> getting around them without being abusive to reddit's servers, ideally.
  3 2014-11-27 02:18:47 <gmaxwell> op_null: wrong channel?
  4 2014-11-27 02:19:44 <op_null> gmaxwell: damn irssi.
  5 2014-11-27 02:20:30 <op_null> gmaxwell: actually damn muscle memory. can't think "dev" without joining this channel.
  6 2014-11-27 04:32:37 <xilanma> is there any way to manually trigger block verification on a specific block?
  7 2014-11-27 04:33:02 <xilanma> without deleting the whole blockchain :P
  8 2014-11-27 04:34:29 <gmaxwell> xilanma: no. Why do you believe you need to?
  9 2014-11-27 04:35:47 <xilanma> i am writing a python function to validate blocks and failing at a specific block
 10 2014-11-27 04:35:52 <xilanma> would be helpful for debugging
 11 2014-11-27 04:36:43 <gmaxwell> xilanma: bitcoin core doesn't have the data to verify an arbritary prior block. The only way to do so is to rewind the state back to that point.
 12 2014-11-27 04:37:58 <gmaxwell> There are some debugging commands in a pull for git master to do the rewind. e.g. you could invalidate the block before it then revalidate it and it will go and connect them all again. Though on the mainnet its quite slow to do this if you're talking far back.
 13 2014-11-27 04:38:11 <xilanma> ok
 14 2014-11-27 04:38:13 <gmaxwell> xilanma: What is your block validation code for?
 15 2014-11-27 04:44:42 <xilanma> gmaxwell: just for fun
 16 2014-11-27 04:44:46 <xilanma> learning
 17 2014-11-27 04:45:04 <xilanma> is there a way to truncate the blockchain up to height / hash  X ?
 18 2014-11-27 04:45:26 <gmaxwell> you could use linearize.py to make a bootstrap file.
 19 2014-11-27 04:45:49 <xilanma> ok I will have a look :)
 20 2014-11-27 04:47:23 <BlueMatt> is there a reason our python test scripts arent "#! /usr/bin/env python2" instead of "#! /usr/bin/env python" ?
 21 2014-11-27 04:48:00 <gmaxwell> sipa: re the printblocktree stuff,  if I added an alternativenextblockhashs to getblock rpc do you think that would be reasonable?
 22 2014-11-27 04:48:27 <gmaxwell> BlueMatt: is paython2 an alias on all hosts? (even apples?)
 23 2014-11-27 04:51:09 <BlueMatt> gmaxwell: nfc, but it seems python3 is the default on many systems, so...we need something...
 24 2014-11-27 04:51:35 <BlueMatt> maybe we need to make a system-specific softlink in configure?
 25 2014-11-27 04:56:42 <gmaxwell> 'python2' works on my hosts, I just don't know if thats the norm or not.
 26 2014-11-27 04:58:18 <BlueMatt> python specifiies that python /should/ point to python2, and that both python2 and python3 should be avilable (obv given install)...but not all distros (actually really apparently only arch's python maintainers are idiots) seem to follow the python->python2 convention
 27 2014-11-27 04:58:37 <BlueMatt> really just a question of osx, I'd bet
 28 2014-11-27 04:59:35 <BlueMatt> specifically, arch decided to move everyone to python3 and pointed the symlink, then python added a pep that declared python should always point to python2, so....
 29 2014-11-27 04:59:49 <BlueMatt> anyway, I'll propose it and see if gavin's machines break
 30 2014-11-27 05:09:48 <wumpus> looks like python2 works fine on debian and ubuntu boxes
 31 2014-11-27 05:10:02 <Luke-Jr> should just fix the scripts to use Python3..
 32 2014-11-27 05:10:58 <wumpus> that does not change the problem of not knowing the name of the interpreter a bit
 33 2014-11-27 05:11:01 <BlueMatt> heyyyyyy, the irs finally got me that 2013 tax refund.....
 34 2014-11-27 05:11:03 <BlueMatt> ass holes
 35 2014-11-27 05:11:08 <wumpus> woohoo
 36 2014-11-27 05:12:07 <BlueMatt> only 10$ /more/ than I filed for????!
 37 2014-11-27 05:12:25 <BlueMatt> "We made changes to your tax return that changed the amount of your refund."
 38 2014-11-27 05:12:27 <BlueMatt> ok...then
 39 2014-11-27 05:12:54 <wumpus> Luke-Jr: well it would if the scripts work in python2 *and* 3 regardless, but that makes testing much worse as you'd have to test the tests with multiple python versions... I don't like where that's going :)
 40 2014-11-27 05:13:48 <Luke-Jr> wumpus: Python2 is obsolete ;)
 41 2014-11-27 05:15:06 <BlueMatt> Luke-Jr: HAH!
 42 2014-11-27 05:15:57 <wumpus> Luke-Jr: yes, in principle it is, but it doesn't hurt to have a bit of backwards compatibility
 43 2014-11-27 05:16:17 <Luke-Jr> wumpus: hey, you're the one who was arguing against supporting both :P
 44 2014-11-27 05:16:29 <Luke-Jr> IMO makes no sense to support Python2 but NOT python3
 45 2014-11-27 05:16:57 <wumpus> Luke-Jr: yes I usually argue againse 'lowest common denominator subsets', just choose one and go with it, but we don't really require any python3 specific features so there's no use in requiring it
 46 2014-11-27 05:17:41 <wumpus> Luke-Jr: but at a certain point in time that makes sense, sure
 47 2014-11-27 05:17:45 <BlueMatt> Luke-Jr: last I checked python2 was gonna get support for...ever pretty much, and since our scripts are already python2...might as well keep it that way
 48 2014-11-27 05:18:35 <apos> hi
 49 2014-11-27 05:18:43 <wumpus> that said, I usually write my python2 code in a way that's easy to port over to python3 when the need arises
 50 2014-11-27 05:20:54 <wumpus> hey
 51 2014-11-27 05:21:01 <tdlfbx> I just bit the bullet and dumped python2 completely.  Occasionally I get tripped up, but converting my code wasn't hard at all.
 52 2014-11-27 05:21:17 <tdlfbx> 95% is print()
 53 2014-11-27 05:21:28 <wumpus> unicode/bytes handling is the rest
 54 2014-11-27 05:22:08 <tdlfbx> A couple subtle things with iterators and some libraries (itertools) too, but that's < 1%.
 55 2014-11-27 05:22:47 <tdlfbx> Just import future and you're good.
 56 2014-11-27 05:42:51 <apos> I am new to bitcoin. can someone help me understand how bitcoin transaction is validated by a node?
 57 2014-11-27 05:43:24 <apos> does a full node check entire block chain to validate inputs of a transaction?
 58 2014-11-27 05:48:03 <wumpus> well, yes and no
 59 2014-11-27 05:48:16 <wumpus> it checks the entire block chain and keeps a running state called the utxo, the set of unspent outputs
 60 2014-11-27 05:48:24 <wumpus> it verifies new transactions against that
 61 2014-11-27 05:53:06 <wumpus> it first checks a transaction for basic validity, then it looks up the hash,vout from transaction inputs in that database, makes sure some integrity checks pass (such as not spending more than available), then verifies the combination of the input script with the output script in the txout (for each input),  and if that passes, then the transaction validates
 62 2014-11-27 06:07:28 <apos> thanks @wumpus
 63 2014-11-27 06:20:24 <gmaxwell>         "branchlen" : 4917
 64 2014-11-27 06:20:24 <gmaxwell> lol
 65 2014-11-27 06:28:12 <gmaxwell> sipa: so there is some poor interaction with getchaintips and headers first that can make the main chain look like a fork.
 66 2014-11-27 06:30:11 <gmaxwell> dunno if it's really all that important.
 67 2014-11-27 06:31:55 <wumpus> interesting
 68 2014-11-27 07:14:43 <wumpus> getchaintips works fine here, no branches longer than 1
 69 2014-11-27 07:15:01 <wumpus> so the confusion is not consistent
 70 2014-11-27 07:18:09 <gmaxwell> nah, I think it's just when headers is ahead of blocks.
 71 2014-11-27 07:18:26 <gmaxwell> e.g. my testnet node claimed the main chain was a 4917 block fork right after it started.
 72 2014-11-27 07:21:30 <wumpus> I checked only on a node that is up to date
 73 2014-11-27 08:03:56 <kefkius> Is there an example of bitcoin-tx usage for setting a register? Or barring that, how should JSON-STRING look in bash for this command: "set=NAME:JSON-STRING"?
 74 2014-11-27 08:07:55 <Luke-Jr> BlueMatt: btw, that PEP comment seems unfair: 1) Arch's python symlink predates the PEP, 2) the PEP says scripts should use python2 anyway, so we're in just as much "violation" of it prior to that PR, and 3) PEPs sometimes have bad advice
 75 2014-11-27 08:08:32 <BlueMatt> Luke-Jr: sure, sure...though the pep was in response to arch's strange choice of python symlink
 76 2014-11-27 08:08:53 <BlueMatt> which (clearly) breaks things, and arch should have reverted to the standard once there was one
 77 2014-11-27 08:09:01 <BlueMatt> (they put in effort, apparently, to not depend on it, so....)
 78 2014-11-27 08:09:01 <Luke-Jr> BlueMatt: it's not strange, Python 3 has been out for 6 years
 79 2014-11-27 08:09:19 <BlueMatt> its strange in that they're the only ones who do it
 80 2014-11-27 08:09:22 <Luke-Jr> they're not.
 81 2014-11-27 08:09:43 <BlueMatt> oh
 82 2014-11-27 08:10:27 <Luke-Jr> it's a sysadmin choice on Gentoo (I think defaulting to first-installed), and I would imagine on Debian too (since they tend to have this same kind of configuration thing)
 83 2014-11-27 08:14:54 <wumpus> debian sets up python as a symlink to python2.x by default, but I wouldn't be surprised if that could be changed through alternatives
 84 2014-11-27 08:31:49 <sipa> wumpus, gmaxwell: getchaintips returning not-yet-connected chains deriving from the active chain as 'fork' seems reasonable; i'm not sure what the solution is
 85 2014-11-27 08:31:59 <sipa> as there may effectively be more than one of those
 86 2014-11-27 08:32:52 <gmaxwell> hm funny thing about getchaintips  is say you're on a fork a bunch of blocks back, because the longest chain is invalid. you get results like
 87 2014-11-27 08:32:55 <gmaxwell>        "branchlen" : 86821
 88 2014-11-27 08:32:58 <gmaxwell>         "branchlen" : 56967
 89 2014-11-27 08:33:00 <gmaxwell>         "branchlen" : 53896
 90 2014-11-27 08:33:03 <gmaxwell>         "branchlen" : 53649
 91 2014-11-27 08:33:05 <gmaxwell>         "branchlen" : 53639
 92 2014-11-27 08:33:30 <sipa> well... we could report the whole tree rather than just the lengths :)
 93 2014-11-27 08:33:34 <gmaxwell> because all the 1 block forks on the invalid longest fork are measured in height difference relative to your current chain and not where they last branch.  Which is probably right but surprising.
 94 2014-11-27 08:34:06 <sipa> gmaxwell: on #5382 you comment that there is no way to find out about orphaned blocks... getchaintips does that, no?
 95 2014-11-27 08:34:43 <gmaxwell> sipa: I updated my comment.
 96 2014-11-27 08:34:58 <gmaxwell> I realized getchaintips did this just a bit after commenting.
 97 2014-11-27 08:35:10 <gmaxwell> (which is also why I've been screwing around with it, I'd forgotten about it.
 98 2014-11-27 08:39:11 <wumpus> yes ACK on removing printblocktree, avoids the 'oh this exists too and is broken' next time
 99 2014-11-27 08:42:07 <gmaxwell> it seems useless in any case, everything it tells you is available via rpc and it's slow enough that rpc is probably not much worse.
100 2014-11-27 08:43:23 <paveljanik> and can be used only as an cmdline argument and exits immediately.
101 2014-11-27 08:48:12 <sipa> do we want -printblock ?
102 2014-11-27 08:49:00 <gmaxwell> sipa: nope, I think that can go too.
103 2014-11-27 08:49:01 <sipa> it prints the header of a block whose hash in hex starts with a particular passed string
104 2014-11-27 08:49:04 <sipa> ack
105 2014-11-27 08:49:05 <wumpus> I suppose not
106 2014-11-27 08:49:10 <sipa> getblock is superior iirc
107 2014-11-27 08:49:14 <sipa> and faster
108 2014-11-27 08:50:40 <wumpus> if RPC can handle it there is no use in having a command line option, I suppose this stuff is for debugging database problems when the daemon refuses to start up, but it's far from useful enough for that to warrant being maintained
109 2014-11-27 08:51:01 <gmaxwell> darn bitcoin-qt merge.
110 2014-11-27 08:51:09 <wumpus> ?
111 2014-11-27 08:51:37 <gmaxwell> I was going to jokingly say we should git blame | grep Satoshi and remove anything that comes up; but the qt merge seems to have misattributed all those old lines. :P
112 2014-11-27 08:51:37 <sipa> gmaxwell: screwed up history huh?
113 2014-11-27 08:52:33 <sipa> so for getchaintips... i guess the question wrt headersfirst is: do we want it to report headers-only branches at all?
114 2014-11-27 08:52:40 <wumpus> well we could rewrite history using filter-branch *ducks*
115 2014-11-27 08:55:15 <gmaxwell> sipa: I suspect that it should probably ignore headers only anything or report them seperately like a headersonly: true on the headers only tip(s) distinct from ones we have blocks for.
116 2014-11-27 09:33:49 <damethos> quick q: what does confirmations: -1 means if I do a bitcoind getblock <hash> ?
117 2014-11-27 09:37:14 <midnightmagic> orphaned block i think
118 2014-11-27 09:38:04 <wumpus> a block that is not on the main chain
119 2014-11-27 09:40:08 <damethos> cheers
120 2014-11-27 09:45:33 <damethos> is it possible for a block to exist in a side chain forever? does that make sense? For example if a block forked the chain at a point way back in the chain and no re-org is triggered and the block just, sits there but it never becomes orphaned since no re-org is triggered
121 2014-11-27 09:46:44 <Magicking`> Since a side chain is not meant to be forever, it does not make sense I guess
122 2014-11-27 09:47:29 <sipa> damethos: that doesn't make sense
123 2014-11-27 09:47:47 <sipa> damethos: there is only ever one active chain tip
124 2014-11-27 09:48:04 <sipa> either it's your fork, and to move to another a reorg happens
125 2014-11-27 09:48:10 <sipa> or it is not your fork, and nobody cares
126 2014-11-27 09:50:03 <damethos> I understand. The reason I am asking is that i am parsing the bitcoind blk files, and i see every now and then that even though i might be at chain height 1000 , i suddenly face a block that forks the chain on some really old block height (even 500 blocks behind) and I am trying to make sense of this. The height number are just an example
127 2014-11-27 09:50:27 <damethos> *height numbers
128 2014-11-27 09:51:05 <sipa> there can be old forked branches in the blk files yes
129 2014-11-27 09:52:59 <damethos> but why are the block data in the blk file newer than block height 1001 ?
130 2014-11-27 09:53:35 <sipa> the block files are append only
131 2014-11-27 09:53:40 <sipa> they contain all blocks we ever downloaded
132 2014-11-27 09:56:30 <damethos> i see. Pain in the ass for my parser :) I now face something like this:
133 2014-11-27 09:56:34 <damethos> INFO  parser.core - Chain now is 213576 blocks high
134 2014-11-27 09:56:34 <damethos> INFO  parser.core - Ignoring deep fork at height 213072/block 00000000a2452fdb50ecc9d0e4a36833d194a2cd03259b5ce2ed1d82404903f3
135 2014-11-27 09:56:54 <damethos> which is wrong cause that block is on the main chain
136 2014-11-27 09:58:35 <sipa> why do you consider it to be a fork?
137 2014-11-27 09:58:39 <damethos> i am just trying to understand why those 500 blocks between 213072 and 213576 were appended in the files before 00000000a2452fdb50ecc9d0e4a36833d194a2cd03259b5ce2ed1d82404903f3 which belongs in the main chain
138 2014-11-27 09:59:20 <damethos> i consider a fork the block that has less total work than chain head
139 2014-11-27 09:59:38 <sipa> are you using git master?
140 2014-11-27 09:59:54 <sipa> git master downloads blocks out-of-order for higher throughput
141 2014-11-27 10:00:02 <sipa> so they end up on disk out of order too
142 2014-11-27 10:00:03 <damethos> tbh i got these blk dat files from an older bitcoind that i had running for some time now
143 2014-11-27 10:00:12 <sipa> up to 0.9.3 they were always in order
144 2014-11-27 10:00:52 <damethos> i think these blk files i have are from version 90201
145 2014-11-27 10:01:11 <sipa> oh, there can always be garbage in the files too
146 2014-11-27 10:01:25 <sipa> if the node crashes after downloading but before updating indexes or so
147 2014-11-27 10:01:38 <damethos> yeah but these are perfectly parsable blocks, they dont look garbage
148 2014-11-27 10:01:50 <damethos> or at least to me they dont
149 2014-11-27 10:01:50 <sipa> garbage will very likely look like blocks :)
150 2014-11-27 10:01:54 <damethos> heh
151 2014-11-27 10:01:58 <sipa> as the only thing written to the files is blocks
152 2014-11-27 10:02:00 <damethos> any tips how to identify them?
153 2014-11-27 10:02:39 <sipa> you can just parse them... as long as their PoW works out, you're likely fine
154 2014-11-27 10:03:06 <sipa> but be aware that the same block may appear later again
155 2014-11-27 10:03:13 <sipa> perhaps preceded by older blocks first
156 2014-11-27 10:04:20 <gmaxwell> block files are not really a good external interface. :)
157 2014-11-27 10:06:46 <damethos> i see
158 2014-11-27 10:07:05 <damethos> damn
159 2014-11-27 10:07:20 <sipa> in 0.10 there shouldn't be garbage anymore, but you do get the out-of-order blocks
160 2014-11-27 10:07:38 <damethos> how long can this out-of-order can be?
161 2014-11-27 10:07:41 <damethos> 100 blocks?
162 2014-11-27 10:07:42 <damethos> 1000?
163 2014-11-27 10:08:02 <gmaxwell> well I'd also like to be whitening the data in blocks in a future version... we still have the issue with antivirus randomly corrupting people's bitcoin installs. :(
164 2014-11-27 10:08:07 <jonasschnelli> damethos why not creating your own persistent storage by downloading the blocks over the p2p net?
165 2014-11-27 10:08:25 <gmaxwell> or running linearize.py
166 2014-11-27 10:08:30 <damethos> jonasschnelli, that was my original plan but i thought why write more code when bitcoind already does that for me
167 2014-11-27 10:08:41 <damethos> i will probably need to implement it after all
168 2014-11-27 10:09:04 <jonasschnelli> you can still use bitcoin-core for that,... but create your own persistent store backend
169 2014-11-27 10:09:18 <sipa> you can run linearize.py too, if you don't mind duplicating storage
170 2014-11-27 10:09:55 <sipa> or you can modify linearize.py to do what you want to do with the blocks
171 2014-11-27 10:09:59 <damethos> iirc linerarize uses the rpc interface and only gets the best chain blocks
172 2014-11-27 10:10:03 <damethos> i want everything
173 2014-11-27 10:10:05 <sipa> ah
174 2014-11-27 10:10:11 <damethos> orhpaned etc, i am handling the reorganizes as well
175 2014-11-27 10:10:22 <sipa> use getchaintips instead of getblockhash
176 2014-11-27 10:10:38 <sipa> that'll give you all block hashes (well, all chain tips)
177 2014-11-27 10:11:10 <damethos> ah interesting
178 2014-11-27 10:15:54 <damethos> sipa, is there a rough number on how big this out-of-order sequence can be? or is it completely random? for example is it in some small range of 0-100 blocks?
179 2014-11-27 10:16:15 <sipa> up to 1024 + reorganize depth
180 2014-11-27 10:16:58 <damethos> thats a lot
181 2014-11-27 10:17:11 <sipa> more specifically: we never download a block that is more than 1024 further ahead than the best we've validated so far
182 2014-11-27 10:17:19 <gmaxwell> also, we don't promise to not change it in the future.
183 2014-11-27 10:17:20 <damethos> ah good to know
184 2014-11-27 10:17:28 <damethos> good to know that as well gmaxwell :)
185 2014-11-27 10:17:32 <sipa> also, linearize.py handles it
186 2014-11-27 10:18:00 <damethos> sipa, handles what? the deep reorganize?
187 2014-11-27 10:18:06 <sipa> the out-of-orderness
188 2014-11-27 10:18:15 <gmaxwell> (though i don't really see us needing more than a 1024 window... but if we later find a bigger window improves things, we'd probably no hesitate in using it)
189 2014-11-27 10:20:19 <gmaxwell> s/no/not/
190 2014-11-27 10:20:25 <damethos> i will read the linearize.py and see what it does exactly for that but the first though that comes to my mind is to keep the blocks in an array and try to connect the ones that can be connected later on
191 2014-11-27 10:21:19 <damethos> i will see if my app can handle 1024 blocks reorg, i have tested with 300 and it was ok but 1024 needs more resources so i am not sure
192 2014-11-27 10:21:52 <damethos> thanks for the help guys, definitely solved my questions
193 2014-11-27 10:22:25 <gmaxwell> wumpus: 494f6e7 seems to have broke building for me on fedora.
194 2014-11-27 10:22:55 <sipa> gmaxwell: delete bitcoin-config.h, and re-run autogen
195 2014-11-27 10:24:34 <gmaxwell> indeed, that fixed it.
196 2014-11-27 10:27:24 <gmaxwell> gah, why does rest.o take so long to compile.
197 2014-11-27 10:28:19 <jonasschnelli> rest.o was also changed recently... maybe because of <boost/algorithm/string.hpp>?
198 2014-11-27 10:28:52 <jonasschnelli> s/rest.o/rest.cpp
199 2014-11-27 10:29:13 <gmaxwell> oh my terminal was hung. :-/ not doing too great tonight. :)
200 2014-11-27 10:29:48 <gmaxwell> yeech the object file for is 2.75 mbytes.
201 2014-11-27 10:29:51 <gmaxwell> :-/
202 2014-11-27 10:30:30 <sipa> so small
203 2014-11-27 10:30:52 <gmaxwell> gotta love C++ where a 211 line cpp file can result in almost three megs of object.
204 2014-11-27 10:34:32 <damethos> heh
205 2014-11-27 10:41:12 <gmaxwell> I hope the rest stuff doesn't slow us moving off json spirit.
206 2014-11-27 10:46:18 <damethos> sipa, are you sure that the linearize.py handles the out of orderness thing? this is the script we are talking about https://github.com/reddcoin-project/reddcoin/blob/master/contrib/linearize/linearize.py
207 2014-11-27 10:46:28 <sipa> no
208 2014-11-27 10:46:39 <netg> reddcoin?
209 2014-11-27 10:47:10 <sipa> this is what i'm talking about: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearize
210 2014-11-27 10:48:28 <damethos> damn you google
211 2014-11-27 10:48:42 <damethos> cheers i will read it
212 2014-11-27 10:48:50 <wumpus> I'm so close to reverting 494f6e7
213 2014-11-27 10:48:54 <sipa> the linearize version in 0.9.3 doesn't deal with out-of-orderness, but doesn't need to
214 2014-11-27 10:49:01 <sipa> wumpus: why?
215 2014-11-27 10:49:13 <wumpus> supporting broken old platforms is great, but almost everyone trips over this
216 2014-11-27 10:49:52 <wumpus> on the other hand it just exposes the issue, it doesn't cause it
217 2014-11-27 10:50:15 <paveljanik> wumpus: yes, exactly
218 2014-11-27 10:50:26 <paveljanik> and the issue is being fixed in other branch...
219 2014-11-27 10:50:32 <gmaxwell> wumpus: we have a number of other autoconf stumbling blocks in 0.10 already.
220 2014-11-27 10:50:46 <wumpus> gmaxwell: well this only affects people that regularly build master
221 2014-11-27 10:50:55 <gmaxwell> so I don't think taking another one hurts.
222 2014-11-27 10:50:59 <wumpus> gmaxwell: on the other hand, those are the people i'd rather NOT scare away :p
223 2014-11-27 10:52:31 <gmaxwell> sipa: can't say I expected this output https://0bin.zertrin.org/paste/c99234b18eb90f73d83cae1fa0465d32d63f4328#FKQ6Gk5yf5yfZYN6vXtylPuUBdInZ56G9YARXWOL5R8=
224 2014-11-27 10:52:59 <sipa> gmaxwell: interesting!
225 2014-11-27 10:53:03 <wumpus> but it's a good lesson. do not move or rename generated files unless you want to play tech support for a long time
226 2014-11-27 10:53:24 <sipa> those valid-headers are forks that got announced to you, but you already had an equivalent block
227 2014-11-27 10:59:42 <gmaxwell> oh interesting. I've had this particular node running headers first for a long time.
228 2014-11-27 12:46:33 <jonasschnelli> wumpus, sipa: coding style: do we indent switch structures? It seams to be a mix in the rest of the code. Also regarding doing blocks {}, Not indenting would mean we have two coding brackets in the same indention.
229 2014-11-27 12:46:51 <jonasschnelli> s/coding/closing
230 2014-11-27 12:50:10 <wumpus> jonasschnelli: the ground truth is clang-format (w/ src/.clang-format config) at this point
231 2014-11-27 13:00:47 <jonasschnelli> thanks. Wasn't aware of the clang-format file. Now my IDE is setup correctly.
232 2014-11-27 14:19:28 <damethos> I am going through the linearize.py and i am trying to make sense of the settings['hashlist'] which seems to load from a hashlist.txt. Who builds this list and what exactly does it contains? https://github.com/bitcoin/bitcoin/blob/master/contrib/linearize/linearize-data.py#L270
233 2014-11-27 14:20:13 <sipa> you build that list, using the other tool
234 2014-11-27 14:20:31 <sipa> (linearize-hashes.py)
235 2014-11-27 14:20:39 <damethos> ah thanks didnt notice that
236 2014-11-27 14:24:18 <damethos> i just need to merge those two operations and i assume it will work properly for me as well
237 2014-11-27 14:24:27 <damethos> better than a 1024 blocks reorg :)
238 2014-11-27 14:52:32 <wumpus> the reason that they're two separate operations is that one needs RPC access, the other only access to bitcoind's datadir
239 2014-11-27 14:54:18 <wumpus> they're independent of each other, ie you could build the hash list on another node that has the same blocks
240 2014-11-27 14:54:57 <JackH> hey did the headers first ever get build into bitcoin?
241 2014-11-27 14:55:27 <wumpus> yes it was merged a few weeks ago
242 2014-11-27 14:55:53 <Diablo-D3> is it in stable yet?
243 2014-11-27 14:55:55 <JackH> awesome! going to be 100x easier to present bitcoin-qt as a program now
244 2014-11-27 14:55:56 <damethos> wumpus, yeah got it
245 2014-11-27 14:56:06 <Diablo-D3> JackH: not yet
246 2014-11-27 14:56:11 <Diablo-D3> we still need built in upload capping
247 2014-11-27 14:56:18 <Diablo-D3> because <bitcoin> raperaperape
248 2014-11-27 14:56:23 <damethos> so, if i understand correctly, bitcoind will do a 1024 blocks reorganize if its required
249 2014-11-27 14:56:43 <JackH> alright
250 2014-11-27 14:57:02 <JackH> I assume we are not far from getting the famed snapchat either
251 2014-11-27 14:57:15 <wumpus> damethos: it will do any depth of reorganization if necessary
252 2014-11-27 14:57:33 <damethos> cheers
253 2014-11-27 14:57:35 <wumpus> damethos: you'd hope that in practice, on the mainnet, a 1024 block deep one will never happen
254 2014-11-27 14:57:49 <damethos> well, i faced a 500 blocks reorganize on testnet
255 2014-11-27 14:58:32 <damethos> i guess i have to handle this