1 2012-07-31 00:25:53 <Ferroh> in other news, Zhou Tong contacts mysterious chinese millionaire, who pays back bitcoinica losses in full out of the kindess of his heart
  2 2012-07-31 00:26:10 <Ferroh> Zhou Tong stalkers subside.
  3 2012-07-31 00:26:53 <Ferroh> gmaxwell, but havent you seen the IRC logs that link phantomcircuit to zhou tong!
  4 2012-07-31 00:27:21 <gmaxwell> I'm sorry for going OT eariler.
  5 2012-07-31 00:27:27 <Ferroh> phantomcircuit is zhou tong!
  6 2012-07-31 00:27:30 <Ferroh> the moon landing was faked!
  7 2012-07-31 01:05:24 <jgarzik> MemPool.add(04552ab1db27859a), poolsz 1840
  8 2012-07-31 01:05:33 <jgarzik> heh, 1024.
  9 2012-07-31 01:05:41 <gmaxwell> probably a luke block
 10 2012-07-31 01:05:46 <jgarzik> I wonder if that's a [Tycho] block
 11 2012-07-31 01:05:58 <jgarzik> does luke create a bunch of neverseen tx's?
 12 2012-07-31 01:06:23 <jgarzik> (neverseen == in a block, but not found in memory pool)
 13 2012-07-31 01:06:58 <gmaxwell> ?P?J?????mm3????ab??n??b?U?K??]???s??L?R????????????EclipseMC: Aluminum Falcons 1?
 14 2012-07-31 01:07:35 <gmaxwell> thats the coinbase.
 15 2012-07-31 02:40:04 <klrkrzq> Hello developers!  I was hoping to have someone clarify something on the development side of bitcoin for me.  I am attempting to work with bitcoind using bitcoin-python, and can't figure out where to put the python source files after a build so that I can import the bitcoinrpc namespace for the python commands to work.  Any one out there use this?  (rocking ubuntu 12.04
 16 2012-07-31 03:36:05 <zevus> getting the same thing again, tons of log spam about getblocks
 17 2012-07-31 03:36:37 <zevus> one person from 190062, one person from 190562, one person from 189562, for hours
 18 2012-07-31 03:46:39 <zevus> one was 217.170.246.49
 19 2012-07-31 03:49:05 <zevus> 07/31/12 05:48:49 getblocks 189562 to 00000000000004c10d0a limit 500
 20 2012-07-31 03:49:06 <zevus> 07/31/12 05:48:49 getblocks 190562 to 00000000000000000000 limit 500
 21 2012-07-31 03:49:06 <zevus> 07/31/12 05:48:49 trying connection 147.229.13.218:8333 lastseen=2.5hrs
 22 2012-07-31 03:49:07 <zevus> 07/31/12 05:48:50 getblocks 190062 to 00000000000000000000 limit 500
 23 2012-07-31 03:49:08 <zevus> 07/31/12 05:48:50 getblocks 118850 to 00000000000007cf5590 limit 500
 24 2012-07-31 03:50:22 <zevus> log should show the IP requesting the blocks, that way i dont have to use tcpkill on every connection that is receiving data
 25 2012-07-31 03:53:48 <zevus> 196.215.204.76 , 4.253.62.56
 26 2012-07-31 04:13:07 <midnightmagic> jgarzik, gmaxwell: luke last I understood runs next-test which has an option -acceptnonstdtxn: it's possible those are just tx which your clients reject.
 27 2012-07-31 04:33:26 <luke-jr> midnightmagic: I didn't make the block either ;P
 28 2012-07-31 04:36:49 <midnightmagic> ah
 29 2012-07-31 10:00:04 <BlueMatt> jgarzik: got the same one (guess you could guess from the bluematt.me note in the second sentence), and yea, I was planning on responding with uhhh...no
 30 2012-07-31 10:07:07 <sipa> strange, i did not see such a mail
 31 2012-07-31 10:07:44 <sipa> gmaxwell: the entropy coders you said you guys implemented... arithmetic/range encoding ones?
 32 2012-07-31 10:10:53 <BlueMatt> interesting...the site his email is from is http://technetlaw.com/
 33 2012-07-31 10:30:53 <gmaxwell> sipa: Yes, multisymbol range coders which write out a byte at a time (which tends to be moderately faster on cpu implementations than binary arithmetic coders)
 34 2012-07-31 10:30:56 <gmaxwell> http://git.xiph.org/?p=opus.git;a=blob;f=celt/entdec.c (.h has most of the api docs)
 35 2012-07-31 10:31:00 <gmaxwell> http://git.xiph.org/?p=daala.git;a=blob;f=src/entdec.c
 36 2012-07-31 10:31:53 <gmaxwell> (the latter being the one for the video codec which lowers the coding effiency for speed reasons, also limits cdfs to 16 entries because we plan on making the searches in its decoding SIMD)
 37 2012-07-31 10:37:49 <sipa> gmaxwell: i see; i implemented an arithmetic coder once, but heavily based on code i found in ffmpeg
 38 2012-07-31 10:38:16 <sipa> it only supported binary inputs, no cdf
 39 2012-07-31 10:39:25 <sipa> i suppose it can be a lot faster if you do not need to break up a symbol with a limited number of possibilities into several binary ones
 40 2012-07-31 10:40:14 <sipa> but i'm not sure how to keep track of the probabilities then
 41 2012-07-31 10:46:46 <gmaxwell> Binary coders make varrious kinda of trivial adaptation easier, for sure. But e.g. when you _know_ the model in advance, it's not that hard to write functions to spit out probablities. For multimedia coding we have a lot of zero-mean laplace distributed variables, so there is only one parameter.
 42 2012-07-31 10:46:54 <gmaxwell> s/kinda/kinds of/
 43 2012-07-31 10:56:38 <sipa> hmm, i see
 44 2012-07-31 11:00:01 <gmaxwell> In opus all the models are static because for audio coding you seldom have enough data for useful adaptation. For daala there are functions that build cdfs on the fly based on past state.
 45 2012-07-31 12:11:56 <Lolcust> Respected gentlemen, I have a question: In a hypothetical  altchain where the "message opdrop" trick is allowed, redeeming a "to scripthash" BIP 0016 transaction would be only possible if you don't oppdrop anything into the redeeming tx (or alternatively oppdrop a certain pre-agreed pattern precisely), right ?
 46 2012-07-31 12:19:26 <sipa> Lolcust: there is nothing illegal about message opdrop (though i don't want to encourage it), except that it is nonstandard
 47 2012-07-31 12:20:03 <Lolcust> That I understand. By allowed I mean "accepted as standard by majority of miners"
 48 2012-07-31 12:20:18 <sipa> Lolcust: for the rest, the current bip16 redemption requires the txout script to be exactly OP_HASH160 [scripthash] OP_EQUAL
 49 2012-07-31 12:20:56 <sipa> so if you'd prepend an opdrop in front of it, it would no longer be considered a BIP16 redemption
 50 2012-07-31 12:21:11 <Lolcust> Awesome
 51 2012-07-31 12:21:41 <sipa> that said, in an altcoin (especially a hypothetical one) there is no reason why BIP16 would need to work exactly the same way
 52 2012-07-31 12:21:42 <Lolcust> Thanks sipa
 53 2012-07-31 12:22:12 <sipa> but if i were to design an altcoin now, its txout scripts would just be a single scripthash
 54 2012-07-31 12:46:51 <jgarzik> BlueMatt: heh, good
 55 2012-07-31 12:47:18 <jgarzik> BlueMatt: no response from the UoMD peep here, especially after I sent gmaxwell's question ("do you have permission to work on non-consenting users?")
 56 2012-07-31 12:48:24 <BlueMatt> I cant say I really want to discourage research, because learning more about the network as it functions in the real world is always good, but putting their node in dnsseed is just too far
 57 2012-07-31 12:48:32 <BlueMatt> s/research/them/
 58 2012-07-31 12:48:57 <jgarzik> yeppers
 59 2012-07-31 12:51:38 <gmaxwell> Yea, research is _excellent_. Compromising the system's behavior to expirement on non-consenting users.. not so much. :)
 60 2012-07-31 12:51:58 <sipa> well said :)
 61 2012-07-31 12:53:18 <gmaxwell> Although, to be honest, the fact that we consider this concerning suggests we've probably made the dnsseed a little too critical.
 62 2012-07-31 12:53:51 <jgarzik> gmaxwell: by "we" you mean "TD"
 63 2012-07-31 12:54:13 <gmaxwell> :) I'm pretty sure that absent TD the answer would still be _hell no_ :)
 64 2012-07-31 12:54:34 <sipa> i think it would be better if there were more (trusted?) people running seeds, but not have the client(s) query all of them
 65 2012-07-31 12:54:57 <BlueMatt> I think we should use a DHT!
 66 2012-07-31 12:55:12 <gmaxwell> BlueMatt: and then we can use a DHT to store seeds for the DHT.
 67 2012-07-31 12:55:24 <sipa> it's just DHT's all the way down!
 68 2012-07-31 12:55:27 <BlueMatt> yea!
 69 2012-07-31 12:56:14 <gmaxwell> peer rotation, better decisions on who blocks are pulled from, etc would all make this less critical.
 70 2012-07-31 12:56:20 <sipa> indeed
 71 2012-07-31 12:57:48 <Lolcust> Well, while I'm here, I don't quite get why they need their node in dns seed. If their goal is just to collect data, they could do it just fine by running several good nodes on VPSes.
 72 2012-07-31 12:58:09 <Joric> it would be nice perhaps if blockchain could be downloaded a bit faster, m-key? yeah it that would be great
 73 2012-07-31 12:59:07 <jgarzik> what gmaxwell said :)
 74 2012-07-31 12:59:18 <jgarzik> we need to rotate away from hosts provided by the seeds as soon as feasible
 75 2012-07-31 12:59:32 <BlueMatt> also, we already have a mechanism for doing that
 76 2012-07-31 13:00:10 <sipa> just rotating peers would already help a lot
 77 2012-07-31 13:00:29 <sipa> i've done some experiments with that, including some simulations
 78 2012-07-31 13:00:50 <gmaxwell> Lolcust: who knows, they may be misguided. They may be trying already but want more traffic than they're getting.
 79 2012-07-31 13:00:55 <BlueMatt> rotating in general would be really nice, but the rotate away from dnsseed-hosts should be a 50 char change, no?
 80 2012-07-31 13:01:41 <gmaxwell> BlueMatt: I don't think we should do so stupidly... to rotate away from a working host only to spend a lot of time connected to unhealthy ones isn't good.
 81 2012-07-31 13:02:01 <Lolcust> gmaxwell a VPS capable of running a BTC node can be procured for ~1-3 USD/month. They should be able to increase the amount of traffic they get by just breeding more research nodes.
 82 2012-07-31 13:02:09 <jgarzik> hum.  pynode is stuck again (due to known reasons -- lack of chain reorg support).  It's a good thing I just made IBD really fast!  ;)
 83 2012-07-31 13:02:38 <sipa> my plan was to implement (though i haven't done so already) a mechanism that after waiting some time (say a few minutes, perhaps randomized a bit) on a semaphore "lock", create a new connection anyway, and as soon as it connects, have it replace another random connection we already have
 84 2012-07-31 13:02:56 <jgarzik> makes me want to set up some special public nodes, that __don't__ do block verification, but instead rapidly distributed blocks to all connected clients
 85 2012-07-31 13:03:05 <BlueMatt> gmaxwell: agreed, I was just responding to what jgarzik said...though I do think we should rotate away from them, just maybe not with fOneShot-style right away
 86 2012-07-31 13:03:15 <gmaxwell> jgarzik: see luke's block-preview pull.
 87 2012-07-31 13:03:24 <sipa> the chances for choosing the peer to disconnect would be proportional to (time_already_connected)^(-0.8)
 88 2012-07-31 13:03:58 <sipa> with some extra weighting to decrease disconnection chances of nodes that have provided you with (many) good blocks
 89 2012-07-31 13:04:02 <gmaxwell> BlueMatt: in terms of sipa's metric we'd pre-start them with a poorer score.
 90 2012-07-31 13:05:19 <BlueMatt> well, still downloading more actively from all peers would help a lot in here anyway (dont we already put a negative bias on dnsseeds so that we start trying other nodes after the first addr set?)
 91 2012-07-31 13:05:26 <sipa> absolutely
 92 2012-07-31 13:05:47 <gmaxwell> the fact that we pin the ibd to the first peer (~always a DNS one) is unfortunate.
 93 2012-07-31 13:05:49 <sipa> dnsseeds get a 4-7 day penalty, iirc
 94 2012-07-31 13:06:04 <BlueMatt> gmaxwell: yep
 95 2012-07-31 13:08:18 <jgarzik> maybe rotate getblocks through each peer, measuring response, and slowly arriving at the best peer
 96 2012-07-31 13:08:55 <sipa> optimal peer selection for IBD is fundamentally different from peer selection for good steady-state network behavior
 97 2012-07-31 13:09:02 <sipa> imho
 98 2012-07-31 13:09:14 <jgarzik> agreed
 99 2012-07-31 13:09:16 <gmaxwell> maybe get N peers up before ibd.. then get the first N blocks one at a time? Then start fetching from the fastest?
100 2012-07-31 13:09:34 <jgarzik> sipa: hence "getblocks" rather than "getdata"
101 2012-07-31 13:09:35 <BlueMatt> just buffering blocks + sending getblocks to all reasonably-fast peers would work and be far simpler
102 2012-07-31 13:09:41 <jgarzik> if you are sending getblocks, it's IBD
103 2012-07-31 13:09:52 <jgarzik> or at least high volume sync
104 2012-07-31 13:10:03 <BlueMatt> s/getblocks/getdata/
105 2012-07-31 13:10:57 <sipa> further in the future, i expect that you'd do IBD from specialized archive nodes, and that normal network nodes simply do not provide old blocks
106 2012-07-31 13:11:03 <gmaxwell> jgarzik: for steady state network behavior great care has to be taken to prevent partitioning. E.g. if you only connect to the fastest peers... europe and north america will partition. :)
107 2012-07-31 13:11:15 <sipa> these archive nodes could just as well be http
108 2012-07-31 13:12:04 <jgarzik> wishing for a future where IBD is Somebody Else's Problem does not help for much today ;)
109 2012-07-31 13:12:09 <sipa> sure
110 2012-07-31 13:13:29 <BlueMatt> jgarzik: yep, thats why the first step of buffering blocks was already implemented
111 2012-07-31 13:31:44 <MC-Eeepc> isnt it bad to get all the blocks from one peer
112 2012-07-31 13:31:58 <MC-Eeepc> what if someone is a duck and serves a bullshit chain for fun
113 2012-07-31 13:32:11 <gmaxwell> MC-Eeepc: thats pretty much harmless.
114 2012-07-31 13:32:25 <BlueMatt> then you get bullshit for a while until you switch nodes when a new block comes out
115 2012-07-31 13:32:26 <gavinandresen> ... and expensive for the duck
116 2012-07-31 13:32:47 <MC-Eeepc> oh
117 2012-07-31 13:32:52 <gmaxwell> when the network solves another block you'll get it from a good peer, then get the missing blocks.. then see it's higher sum diff and you'll reorg.
118 2012-07-31 13:32:54 <gavinandresen> They'd have to have a bullshit chain that has valid proof-of-work
119 2012-07-31 13:33:15 <BlueMatt> or you'd just disconnect from them pretty quick
120 2012-07-31 13:33:36 <sipa> a bullshit chain with valid proof-of-work isn't hard
121 2012-07-31 13:33:57 <sipa> a bullshit chain with valid proof-of-work and more work than the real chain is :)
122 2012-07-31 13:35:14 <MC-Eeepc> ok
123 2012-07-31 13:35:41 <MC-Eeepc> well maybe it could pull blocks in a rotating fashion amongs connected peers
124 2012-07-31 13:35:47 <jgarzik> sipa: how does ultraprune handle a 1000-block reorg?  keeps last-N full blocks?
125 2012-07-31 13:35:51 <MC-Eeepc> so as not to suck gigabytes out of one guy....
126 2012-07-31 13:36:00 <BlueMatt> jgarzik: yes
127 2012-07-31 13:36:07 <BlueMatt> jgarzik: if the reorg is > N, you're screwed
128 2012-07-31 13:36:07 <sipa> jgarzik: for now it keeps all blocks, and undo info for all blocks as well
129 2012-07-31 13:36:10 <gmaxwell> jgarzik: it keeps undo logs.
130 2012-07-31 13:36:18 <jgarzik> ok
131 2012-07-31 13:36:46 <gmaxwell> BlueMatt: thats not the case with the current code... though if you want space saving it would be if you dropped undo logs past some height.
132 2012-07-31 13:37:03 <gavinandresen> disk space is cheap
133 2012-07-31 13:37:05 <BlueMatt> oh, I thought that was implemented...anyway wasnt that the plan?
134 2012-07-31 13:37:31 <jgarzik> indeed
135 2012-07-31 13:37:40 <sipa> BlueMatt: that was the original plan yes, but right now, i think the code is more interesting because of the speedup it gives :)
136 2012-07-31 13:37:49 <BlueMatt> fair enough
137 2012-07-31 13:37:52 <gmaxwell> BlueMatt: it's designed to accommodate that at least. As gavin says, disk space is cheap.. the bigger improvement is also locality.
138 2012-07-31 13:37:52 <sipa> but implementing pruning will be trivial
139 2012-07-31 13:38:41 <gmaxwell> one of the insights that I got out of ultra prune is that that txout tree commitment proposal should potentially also commit undo logs.
140 2012-07-31 13:38:48 <jgarzik> the locality is mainly needed for the indices
141 2012-07-31 13:39:01 <jgarzik> I don't see much reason to delete serialized block data
142 2012-07-31 13:39:08 <gmaxwell> jgarzik: ultraprune is 'all index'.
143 2012-07-31 13:39:29 <sipa> except for reorg, serve, and rescan, the block data itself is never used
144 2012-07-31 13:39:30 <gmaxwell> It doesn't need to use the blocks for validation.
145 2012-07-31 13:41:00 <jgarzik> that's fine -- as long as the block data stays there in blk????.dat
146 2012-07-31 13:41:50 <gmaxwell> It also breaks the block data out into many files.
147 2012-07-31 13:41:59 <sipa> right now, in a single file per block, but i'm going to change that into one file per few hundred blocks or so
148 2012-07-31 13:42:00 <jgarzik> that's silly
149 2012-07-31 13:42:40 <jgarzik> that's yucky
150 2012-07-31 13:42:43 <sipa> ?
151 2012-07-31 13:42:46 <gmaxwell> jgarzik: it lets the filesystem do its job and makes it easier to share storage between nodes.
152 2012-07-31 13:43:00 <gmaxwell> also makes running nodes without archive data easier.
153 2012-07-31 13:43:16 <sipa> the only problem with that is that you have 1/2-filesystem-block waste per block
154 2012-07-31 13:43:37 <jgarzik> have actually written a kernel filesystem, I'm skeptical
155 2012-07-31 13:43:55 <jgarzik> not sure running nodes without archive data is high on satoshi client's mission list
156 2012-07-31 13:44:03 <jgarzik> full node + client node is a full plate already
157 2012-07-31 13:44:54 <sipa> explain me what disadvantage 100 MB blk000X files has over 2 GB blk000X files?
158 2012-07-31 13:45:01 <jgarzik> it would be interesting to create a pynode mode that had no block data.  request undo data over the network, to handle reorgs.
159 2012-07-31 13:45:13 <gavinandresen> they're not compatible with existing tools that understand blk000X files
160 2012-07-31 13:45:21 <sipa> they will be
161 2012-07-31 13:45:43 <sipa> (except that there are fewer blocks per file)
162 2012-07-31 13:45:56 <jgarzik> sipa: from a filesystem perspective, probably more disk seeks.  bigger directories.  more wasted space, as you just noted.
163 2012-07-31 13:46:06 <gavinandresen> oh, you're just making the max size smaller than 2GB?  Fine, then.
164 2012-07-31 13:46:06 <jrmithdobbs> sipa: that's awesome btw, that's exactly how I planned to store the chain in the client I ended up abodoning when I got to script parser stage due to time constraints ;p
165 2012-07-31 13:46:21 <BlueMatt> jgarzik: bitcoinj implementation does that
166 2012-07-31 13:46:26 <sipa> i don't care about 2 KiB wasted space per 100 MB
167 2012-07-31 13:46:31 <jgarzik> sipa: probably well within noise range
168 2012-07-31 13:46:36 <BlueMatt> jgarzik: throw PrunedException(hash), which gets picked up and requested
169 2012-07-31 13:46:45 <sipa> and yes, directories become larger and slower, but the files in them are almost never accessed
170 2012-07-31 13:47:13 <jrmithdobbs> sipa: and you don't need to readdir() to access the contents any ways so real performance doesn't suffer
171 2012-07-31 13:47:21 <sipa> exactly
172 2012-07-31 13:48:01 <sipa> gavinandresen: i'm quite sure i can reduce storage of blocks as well, by designing a more compact serialization, but i chose not to, as that would mean breaking more compatibility, and for those for whom storage space is an issue, it already provides pruning anyway
173 2012-07-31 13:49:47 <gmaxwell> sipa: hm. How does your current layout handle getheaders load?
174 2012-07-31 13:50:26 <sipa> gmaxwell: good question, let me check
175 2012-07-31 13:50:43 <sipa> gmaxwell: served from RAM
176 2012-07-31 13:52:57 <jrmithdobbs> sipa: I'd take it a step further and build the indexes with hardlink trees instead of bdb/etc but that's a portability nightmare ;p
177 2012-07-31 13:53:22 <sipa> jrmithdobbs: the only index that ultraprune requires is a txid -> coins map
178 2012-07-31 13:53:40 <sipa> or do you mean the block index? i'm thinking about storing that just in a flat file
179 2012-07-31 13:53:50 <jrmithdobbs> sipa: I mean the block index
180 2012-07-31 13:53:52 <sipa> (though it is a small BDB file now)
181 2012-07-31 13:54:46 <jrmithdobbs> sipa: if you keep every block as a single file (I really don't see a problem with that how it's used so long as it's split up sanely, we already have a hashed value to use to build the dir structure), you can have a separate hardlink tree based on height that's just hardlinks back into the tree
182 2012-07-31 13:55:10 <sipa> meh
183 2012-07-31 13:55:12 <gmaxwell> jrmithdobbs: I'm now waiting for jgarzik to stab you.
184 2012-07-31 13:55:21 <gmaxwell> plus you want offsets.
185 2012-07-31 13:55:23 <jrmithdobbs> i abuse the crap out of my fses ok
186 2012-07-31 13:55:24 <jrmithdobbs> ;p
187 2012-07-31 13:55:54 <jrmithdobbs> (I've actually run production systems based on similar designs, it works a lot better than you'd think at first glance)
188 2012-07-31 13:56:05 <jrmithdobbs> also has benefit of letting fs cache layer do all the heavy lifting for you
189 2012-07-31 13:56:55 <gmaxwell> I'm very much a plan of 'middle' solutions. Going all the way to making the FS do all work has issues, pure blob mode has issues.. hopefully something in the middle evades the bulk of them.
190 2012-07-31 13:57:28 <jrmithdobbs> fair enough
191 2012-07-31 13:58:04 <sipa> s/plan/fan/ ?
192 2012-07-31 13:58:22 <gmaxwell> haha
193 2012-07-31 13:58:24 <gmaxwell> Good decode.
194 2012-07-31 13:59:21 <sipa> 17:55:21 < gmaxwell> plus you want offsets.   ->  sure you can encode those in device entries in the FS, or as dangling symlink data :p
195 2012-07-31 13:59:42 <gmaxwell> xattrs!
196 2012-07-31 14:00:25 <gmaxwell> if you didn't care about compatiblity you'd stick the offset tables at the front of the blockfiles.
197 2012-07-31 14:01:01 <sipa> actually, the current ultraprune code does not ever store a blockfile offset
198 2012-07-31 14:01:04 <jgarzik> single file + prealloc gets you the most optimal, including locality
199 2012-07-31 14:01:07 <jrmithdobbs> jgarzik: heh, all about options ;p
200 2012-07-31 14:18:50 <helo> does the client wait to send a transaction until it has caught up with the network?
201 2012-07-31 14:19:42 <gmaxwell> helo: no.
202 2012-07-31 14:20:13 <gmaxwell> And no reason to, generally. (though if you've been using your wallet multiple places you may have double spent yourself; but delaying won't fix that)
203 2012-07-31 14:20:58 <helo> i didn't think so, but SerajewelKS in #bitcoin is complaining that that seems to be the case
204 2012-07-31 14:21:23 <Ferroh> helo, because bitcoin-qt forces you to wait
205 2012-07-31 14:21:40 <Ferroh> helo, though technically you dont have to if you have a client that doesnt make you wait
206 2012-07-31 14:22:07 <Ferroh> helo, bitcoin-qt doesnt see that you have the bitcoins until the chain is up to date enough, so it doesn't let you spend if your balance is 0.
207 2012-07-31 14:22:53 <helo> Ferroh: in this case the blocks with the coin to send have already been seen
208 2012-07-31 14:23:18 <Ferroh> then he cant spend them
209 2012-07-31 14:23:28 <Ferroh> it doesnt wait for the last block in the chain
210 2012-07-31 14:23:32 <Ferroh> *can
211 2012-07-31 14:23:34 <Ferroh> CAN spend them
212 2012-07-31 14:23:36 <helo> right
213 2012-07-31 14:23:43 <sipa1024> what was the question?
214 2012-07-31 14:23:50 <gmaxwell> Ferroh: the conversation in #bitcoin was claiming that you couldn't spend _after_ the coins existed.
215 2012-07-31 14:23:56 <gmaxwell> Ferroh: and thats not true.
216 2012-07-31 14:24:02 <Ferroh> gmaxwell, right.
217 2012-07-31 14:24:17 <Ferroh> sipa, the question was, does the bitcoin-qt client make you wait until the chain is up to date (all the way up to date) before letting you spend
218 2012-07-31 14:24:35 <sipa> no
219 2012-07-31 14:24:41 <Ferroh> sipa: we know :)
220 2012-07-31 14:24:49 <sipa> good we agree :p
221 2012-07-31 14:30:23 <D34TH> ovh is giving away free dedi;s to twitter followers
222 2012-07-31 14:30:25 <D34TH> i just got one
223 2012-07-31 14:30:29 <D34TH> pretty legit
224 2012-07-31 14:30:50 <luke-jr> D34TH: for life? O.o
225 2012-07-31 14:31:12 <D34TH> http://www.ovh.com/bhs
226 2012-07-31 14:31:25 <D34TH> giving away 125 a day
227 2012-07-31 14:31:38 <D34TH> im on a 100 mbit port
228 2012-07-31 14:31:46 <D34TH> comes with ipv6 also
229 2012-07-31 14:31:54 <luke-jr> D34TH: my point is for how long:P
230 2012-07-31 14:31:58 <luke-jr> probably just 1 month
231 2012-07-31 14:32:00 <D34TH> idk
232 2012-07-31 14:32:23 <Dagger2> comes with _OVH's_ IPv6 implementation, mind
233 2012-07-31 14:32:52 <D34TH> luke-jr, http://www.ovh.com/us/support/termsofservice/Special_Conditions_Betatest_US.pdf
234 2012-07-31 14:33:14 <OneEyed> Dagger2: what do you mean? I've been using IPv6 on OVH for years, and it works just fine
235 2012-07-31 14:33:57 <luke-jr> D34TH: lol, so until they decide to stop
236 2012-07-31 14:34:13 <D34TH> 16 gb of ram and i3 2130
237 2012-07-31 14:34:16 <D34TH> not mad
238 2012-07-31 14:34:21 <Dagger2> OneEyed: it's on-link with no routed block, and they don't mention anywhere that your "/64" is actually a section of a /56
239 2012-07-31 14:34:26 <D34TH> 2tb storage
240 2012-07-31 14:34:42 <D34TH> Dagger2, mine says /64
241 2012-07-31 14:35:44 <Dagger2> D34TH: and you'll note that your upstream router isn't inside that /64, which is a bit impossible
242 2012-07-31 14:35:52 <luke-jr> Dagger2: all /64 is part of a /56
243 2012-07-31 14:35:53 <OneEyed> Well, it shows on the ifconfig :)
244 2012-07-31 14:36:04 <luke-jr> Dagger2: sounds pretty standard to me
245 2012-07-31 14:36:05 <OneEyed> inet6 addr: 2001:41d0:1:66b3::1/56
246 2012-07-31 14:36:28 <Dagger2> since the whole point of a router is to let you reach computers that are outside your local subnet. if the router itself is outside your local subnet, you've got a problem
247 2012-07-31 14:36:44 <D34TH> inet6 addr: 2607:5300:60:217::1/64
248 2012-07-31 14:37:54 <Dagger2> luke-jr: the standard would be to take an IP from a /64 on-link, and optionally have a /64 (/56, /48) routed to that IP
249 2012-07-31 14:38:32 <OneEyed> Dagger2: or it could be to use a link-local address to reach your router, as is sometimes done
250 2012-07-31 14:40:32 <Dagger2> OneEyed: ah, true, although that's not what OVH tell you to do. and they still give you no way to get a routed block (and if you ask their support for one, they don't understand what you're on about)
251 2012-07-31 14:40:51 <Dagger2> and they still tell you the wrong subnet size in their admin pages :/
252 2012-07-31 14:42:40 <luke-jr> &
253 2012-07-31 14:42:41 <OneEyed> Dagger2: if you need a routed block *and* are ready to jump through hoops, you can re-split your /64 and route part of it, but most stacks assume at some places that the interface is either as large as /64 or is a /128
254 2012-07-31 14:43:33 <Dagger2> OneEyed: you can't, because it's on-link. you have to bridge all your clients onto the link
255 2012-07-31 14:43:46 <luke-jr> sure you can
256 2012-07-31 14:43:52 <OneEyed> Dagger2: yes you can
257 2012-07-31 14:44:01 <Dagger2> (I suppose someone is going to say proxy-NDP at some point)
258 2012-07-31 14:44:06 <OneEyed> No
259 2012-07-31 14:44:10 <Dagger2> (that's fake bridging)
260 2012-07-31 14:45:00 <OneEyed> Oh, I see what you mean, and yes, you'd probably need to proxy ndp in fact :)
261 2012-07-31 14:45:01 <luke-jr> no, proxy NDP is basically the right way to do this. it's not bridging at all.
262 2012-07-31 14:48:14 <Dagger2> it's not the right way to do this in general (although it is what you're stuck with on OVH)
263 2012-07-31 14:49:08 <Dagger2> "this" being routed networks, such as providing IPv6 to your home network via a VPN
264 2012-07-31 14:51:34 <luke-jr> maybe.
265 2012-07-31 14:51:55 <luke-jr> but technically speaking, ISPs are required to provide end users with /48s ;)
266 2012-07-31 14:51:59 <OneEyed> Or get a provider who gives you IPv6 at home :)
267 2012-07-31 14:52:21 <OneEyed> (in France, we have Free Telecom doing that)
268 2012-07-31 14:52:26 <luke-jr> (for unenforcable definitions of "required")
269 2012-07-31 14:52:47 <OneEyed> (and Free Telecom gives you only a /64 too unfortunately)
270 2012-07-31 14:53:27 <Dagger2> VPN-to-home was just an example. substitute a VM-only network, or anything that requires a routed block of IPs
271 2012-07-31 14:53:42 <Dagger2> OVH screw you over on that front because they don't give you anything :(
272 2012-07-31 14:53:56 <epscy> /64 should be big enough for anybody
273 2012-07-31 14:54:00 <luke-jr> Dagger2: there's no reaosn that requires a routed block
274 2012-07-31 14:54:18 <luke-jr> epscy: /64 is the minimum subnet size
275 2012-07-31 14:54:32 <Dagger2> epscy: my point was that the /64 that OVH "gives you" is not actually given to you. it's on-link
276 2012-07-31 14:54:34 <luke-jr> epscy: ie, insufficient if you even want distinct wifi/LAN
277 2012-07-31 14:54:40 <luke-jr> Dagger2: on-link is still given to you
278 2012-07-31 14:54:48 <luke-jr> even if you don't like the routing protocols being used
279 2012-07-31 14:54:56 <Dagger2> epscy: for instance, let's say you go to work, plug in your laptop, and it gets the IP 10.44.55.66/8
280 2012-07-31 14:55:02 <Dagger2> epscy: does that mean your work has given you 10.0.0.0/8?
281 2012-07-31 14:55:28 <luke-jr> Dagger2: so long as you are free to add other IPs in that subnet, yes
282 2012-07-31 14:55:34 <Dagger2> epscy: what it actually means is that they've given you an IP from *their* 10.0.0.0/8
283 2012-07-31 14:55:50 <OneEyed> Dagger2: so you want to forget IPv6 autoconfiguration altogether?
284 2012-07-31 14:56:19 <OneEyed> If you're throwing in DHCP6, you might as well add NAT6 in this case and your problem is solved&
285 2012-07-31 14:56:47 <Dagger2> luke-jr: I disagree. the on-link block might be dedicated to you, but it's still your ISP's block -- after all, they're running the router for it
286 2012-07-31 14:57:29 <luke-jr> Dagger2: so is every router on the internet; you can run your own router for it too!
287 2012-07-31 14:57:51 <Dagger2> OneEyed: no. where did I suggest that?
288 2012-07-31 14:58:03 <OneEyed> Dagger2: you didn't, but I like building straw men :)
289 2012-07-31 14:59:25 <Dagger2> luke-jr: not even sure how to respond to that. most routers on the internet are not even connected to the subnet in question...
290 2012-07-31 14:59:47 <luke-jr> Dagger2: they still route it
291 2012-07-31 15:00:16 <OneEyed> luke-jr: Dagger is right in that: most of the time, you designate one entry point for your network, and the packet has this entry point MAC address as a target
292 2012-07-31 15:03:55 <Dagger2> luke-jr: what I meant by "running the router for it" is that they're running the machine that all other machines in the subnet will be using as their default router
293 2012-07-31 15:04:32 <Dagger2> obviously other routers on the internet can't be used as the default router in that subnet, because other routers on the internet aren't *in* that subnet
294 2012-07-31 15:05:53 <luke-jr> Dagger2: ISPs usually do
295 2012-07-31 15:06:10 <luke-jr> Dagger2: your VMs can use your host system for the default route instead ofc
296 2012-07-31 15:07:20 <Dagger2> luke-jr: how would the VMs get incoming packets? what path would they take?
297 2012-07-31 15:08:07 <luke-jr> client -> client ISP -> inetrouter -> & -> inetrouter -> OVH -> your network
298 2012-07-31 15:08:21 <luke-jr> client -> client ISP -> inetrouter -> & -> inetrouter -> OVH -> your host -> VM
299 2012-07-31 15:08:56 <Dagger2> see, that "OVH -> your host -> VM" won't actually happen
300 2012-07-31 15:09:02 <luke-jr> yes, it will
301 2012-07-31 15:09:14 <luke-jr> you just need to setup your host as a NDP router
302 2012-07-31 15:09:22 <Dagger2> it'll get to OVH, and then OVH will go "uh, hello VM? what's your MAC address?", and then it fails
303 2012-07-31 15:09:33 <luke-jr> no, because your router advertises the route to it
304 2012-07-31 15:10:22 <Dagger2> it doesn't advertise the route to it... if you're using proxy NDP, it pretends to have that IP, to make it look like the machine is on-link
305 2012-07-31 15:10:40 <upb> yup
306 2012-07-31 15:10:42 <luke-jr> sorry, NDP is just another routing protocol
307 2012-07-31 15:10:48 <Dagger2> the problem is that OVH's router, as a result, has to have neighbour entries for *all* your client VMs, not just "your host"
308 2012-07-31 15:10:48 <luke-jr> it just doesn't scale well
309 2012-07-31 15:11:05 <luke-jr> yes, NDP only does routing per /128
310 2012-07-31 15:11:22 <Dagger2> if you extended this logic upwards to the entire internet, you'd end up with the result that the entire internet appears to be inside a single subnet, which... would be broken
311 2012-07-31 15:11:22 <luke-jr> but that's more OVH's problem than yours
312 2012-07-31 15:11:29 <luke-jr> since they need to waste more memory on routing tablesw
313 2012-07-31 15:11:37 <luke-jr> [17:10:45] <luke-jr> it just doesn't scale well
314 2012-07-31 15:14:13 <Dagger2> well, it certainly doesn't scale to 2^64 entries, which is how many you'd need to cover the /64 OVH let you use
315 2012-07-31 15:14:21 <Dagger2> which should be a pretty big hint that it's the wrong tool for the job
316 2012-07-31 15:15:22 <luke-jr> well, like I said that's OVH's problem ;)
317 2012-07-31 15:16:17 <upb> the point is that ovh is using a hacky solution you give you ipv6
318 2012-07-31 15:16:23 <upb> why are you defending them luke-jr
319 2012-07-31 15:17:00 <luke-jr> I'm not, I'm playing devil's advocate :P
320 2012-07-31 15:17:29 <upb> why havent you come to ##re anymore btw :P
321 2012-07-31 15:17:31 <upb> hahahaha
322 2012-07-31 15:19:27 <Dagger2> I'd be a lot happier with the concept of NDP as a routing protocol if it let you insert routes to entire blocks in the upstream's routing table, preferably with a significantly longer timeout than is typically used for an NDP cache
323 2012-07-31 15:19:51 <Dagger2> as it stands, it just feels like a hack to deal with clueless upstream providers that can't handle actual routing
324 2012-07-31 16:31:06 <yellowhat> is this supposed to happen in prodnet? INFO: DNS lookup for dnsseed.bluematt.me failed. INFO: DNS lookup for seed.bitcoin.sipa.be failed.
325 2012-07-31 16:31:23 <yellowhat> usign bitcoinj
326 2012-07-31 16:31:36 <yellowhat> usign -> using
327 2012-07-31 16:34:53 <sipa> yellowhat: my dns seed was down, it's up again now
328 2012-07-31 16:35:59 <yellowhat> good to know thanks
329 2012-07-31 16:38:46 <zevus> http://nogleg.com/95.154.103.50.txt
330 2012-07-31 16:38:52 <zevus> there, it was just that one person actually
331 2012-07-31 16:39:34 <gmaxwell> thats .. one very confused node.
332 2012-07-31 16:39:57 <gmaxwell> its connectable.
333 2012-07-31 16:40:40 <zevus> i cleared my deny list from the other day & sure enough, there was all the spam again... but that was the only IP that was the same from previous
334 2012-07-31 16:41:09 <zevus> not on my addnode list, just connected randomly i guess
335 2012-07-31 16:41:44 <zevus> there's a couple hours of that actually
336 2012-07-31 16:41:47 <zevus> that's just the last few mins
337 2012-07-31 16:43:35 <zevus> well, 45 minutes
338 2012-07-31 16:43:44 <zevus> sure it would have kept on going tho
339 2012-07-31 16:43:59 <zevus> any chance of getting IP listed on getblock requests? heh
340 2012-07-31 16:48:44 <zevus> an Octopusnet Personal (VPN I guess) in russia,
341 2012-07-31 16:49:23 <gmaxwell> zevus: we intentionally do not log IPs in order to avoid making bitcoin's logfiles valuable targets for theft.
342 2012-07-31 16:57:05 <zevus> aha
343 2012-07-31 16:57:39 <gmaxwell> We're going to add some more stats per peer though, so you'd be able to see the counts incrementing though.
344 2012-07-31 16:58:13 <zevus> in peerinfo?  yah, that'd work
345 2012-07-31 17:02:44 <zevus> someone already w00tw00ting me =0
346 2012-07-31 17:04:45 <zevus> 07/31/12 19:03:51 getblocks 157476 to 000000000000054e88b6 limit 500
347 2012-07-31 17:04:45 <zevus> 07/31/12 19:03:51   getblocks stopping at limit 157975 0000000000000287eaf2
348 2012-07-31 17:04:45 <zevus> 07/31/12 19:03:56 getblocks 157498 to 000000000000055aa37f limit 500
349 2012-07-31 17:05:04 <zevus> why does it keep requesting before processing?  i mean, at least that one is moving..
350 2012-07-31 17:08:25 <gmaxwell> zevus: thats just a normal sync. It only passes a chunk at a time, then the peer processes them and needs more.
351 2012-07-31 17:08:36 <gmaxwell> That just makes sure you're not flooding it.
352 2012-07-31 17:10:14 <zevus> ah
353 2012-07-31 17:11:47 <zevus> can you tell me what the 07/31/12 19:11:14 received getdata (3 invsz)      means?  instead of just the normal received getdata for: tx  or block or w/e?
354 2012-07-31 17:12:22 <zevus> 07/31/12 19:12:10 received getdata (14 invsz)
355 2012-07-31 17:13:30 <zevus> i see some 30+ too..  my inclination is that it's some peer requesting x amt of tx?
356 2012-07-31 17:48:07 <zevus> it's doing it again, this time 18873, 189373, 182873, 171373 etc
357 2012-07-31 17:48:32 <zevus> 19:24 to 19:46 = about 40 requests for getblocks 171373 to xx
358 2012-07-31 17:48:50 <zevus> likewise for 186873 and all the other variants
359 2012-07-31 17:51:52 <MC-Eeepc> random question
360 2012-07-31 17:51:59 <MC-Eeepc> could twitter be implemented in a dht
361 2012-07-31 17:52:57 <gmaxwell> MC-Eeepc: ---> #twitter
362 2012-07-31 17:53:20 <MC-Eeepc> ??
363 2012-07-31 17:54:19 <gmaxwell> MC-Eeepc: Wrong channel.
364 2012-07-31 17:55:25 <jgarzik> 07/31/12 19:54:24 getblocks 191717 to 00000000000007e6b019 limit 500
365 2012-07-31 17:55:25 <jgarzik> 07/31/12 19:54:24   getblocks stopping at 191718 00000000000007e6b019
366 2012-07-31 17:55:26 <jgarzik> 07/31/12 19:54:24 getblocks 191717 to 00000000000007e6b019 limit 500
367 2012-07-31 17:55:28 <jgarzik> 07/31/12 19:54:24   getblocks stopping at 191718 00000000000007e6b019
368 2012-07-31 17:56:02 <MC-Eeepc> how bureaucratic
369 2012-07-31 17:56:07 <jgarzik> satoshi would yell, but I am tempted to add IP address logging for each command
370 2012-07-31 17:57:25 <gmaxwell> jgarzik: as long as it isn't on by default I don't really think it's terrible. I currently patch my nodes to log more stuff. Alternatively, bitcoin traffic isn't that high... and there is an almost working wireshark dissector.. just grab pcaps. :)
371 2012-07-31 17:58:13 <jgarzik> easier to -logips :)
372 2012-07-31 17:59:55 <gmaxwell> jgarzik: perhaps a new logging function that takes the ip as an argument, but only logs it if activated.
373 2012-07-31 18:00:17 <gmaxwell> Could also feed a circular buffer fetchable via RPC/gui.. which could have all the info.
374 2012-07-31 18:02:11 <zevus> 31.181.104.164 <---  continuously requesting 170372 to 190372, then wrapping back to 170372
375 2012-07-31 18:02:46 <gmaxwell> zevus: what version does this node claim to run?
376 2012-07-31 18:03:10 <zevus> 07/31/12 19:13:27 receive version message: version 60001, blocks=170372, us=5.9.24.81:8333, them=31.181.232.249:8333, peer=31.181.104.164:58054
377 2012-07-31 18:03:44 <gmaxwell> Interesting that this doesn't match: them=31.181.232.249:8333, peer=31.181.104.164:58054
378 2012-07-31 18:04:04 <zevus> 07/31/12 19:13:27 accepted connection 31.181.104.164:58054
379 2012-07-31 18:04:05 <zevus> 07/31/12 19:13:27 receive version message: version 60001, blocks=170372, us=5.9.24.81:8333, them=31.181.232.249:8333, peer=31.181.104.164:58054
380 2012-07-31 18:05:01 <zevus> another russian ip
381 2012-07-31 18:05:30 <gmaxwell> hm. I'd previously blocked that entire /16, wish I'd made a note as to why.
382 2012-07-31 18:05:45 <gmaxwell> It must have been doing something pretty nasty to earn that.
383 2012-07-31 18:09:48 <midnightmagic> jgarzik: Why would Satoshi yell about IP logging?
384 2012-07-31 18:15:39 <BlueMatt> anyone know off-hand if we have any non-SIGHASH_ALL in the chain?
385 2012-07-31 18:17:25 <zevus> -A INPUT -s 31.181.104.164/16 -j DROP
386 2012-07-31 18:17:30 <zevus> oh oops
387 2012-07-31 18:17:35 <zevus> 31.181.0.0, right?
388 2012-07-31 18:18:08 <zevus> fixed
389 2012-07-31 18:21:30 <zevus> id say 60% of the w00tw00t has been from chinese ip's, about 30% from russian
390 2012-07-31 18:22:30 <zevus> not like anything of value is on that server haha
391 2012-07-31 18:26:03 <zevus> spamhaus has that IP blocked
392 2012-07-31 18:26:29 <zevus> 31.181.0.0/16   that whole range also
393 2012-07-31 18:27:05 <jgarzik> gavinandresen gmaxwell sipa: any objection to P2P command "getdata" to return any known TX?  right now "getdata" will only return a requested TX if it is in mapRelay[].
394 2012-07-31 18:27:17 <jgarzik> This is essential to implementing the other part of "mempool" P2P command
395 2012-07-31 18:28:18 <BlueMatt> jgarzik: any known TX from mempool, or any known on disk too?
396 2012-07-31 18:29:06 <jgarzik> BlueMatt: I don't see any reason why not to check disk too
397 2012-07-31 18:29:17 <jgarzik> BlueMatt: but mempool is a minimum requirement
398 2012-07-31 18:30:01 <jgarzik> BlueMatt: seems like you might be informed of a TX, then request it, and wind up racing with a block that will remove the requested TX from the mempool
399 2012-07-31 18:30:07 <luke-jr> anyone have any ideas why Eligius's last two blocks would have only had 2 txns? O.o
400 2012-07-31 18:30:26 <BlueMatt> jgarzik: fair enough
401 2012-07-31 18:30:31 <gmaxwell> luke-jr: what is getmempool returning?
402 2012-07-31 18:30:48 <gmaxwell> jgarzik: can I know force you to do unbounded random seeks by requesting txn at random from you?
403 2012-07-31 18:30:52 <luke-jr> gmaxwell: looks like a bunch now
404 2012-07-31 18:31:10 <jgarzik> gmaxwell: you can do that now with old blocks
405 2012-07-31 18:31:14 <BlueMatt> gmaxwell: cant you by requesting disks (though its less expensive bw-wise)
406 2012-07-31 18:31:30 <gmaxwell> jgarzik: yes, but the seek to bw ratio isn't anywhere near so bad.
407 2012-07-31 18:31:32 <luke-jr> hrm
408 2012-07-31 18:32:30 <jgarzik> gmaxwell: <shrug>  I'm sure I could come up with just as punishing a seek pattern for blocks
409 2012-07-31 18:32:46 <jgarzik> gmaxwell: understand your point, though
410 2012-07-31 18:32:48 <gmaxwell> jgarzik: the other minor concern I have is creating a dependance on behavior that might go away.
411 2012-07-31 18:33:05 <gmaxwell> (I don't consider these thing killer but it's just a lot harder to remove functionality than add it)
412 2012-07-31 18:33:18 <jgarzik> gmaxwell: this is for SPV clients, so I dunno that it will go away
413 2012-07-31 18:33:37 <jgarzik> gmaxwell: the main thing is needing to request -recent- TX's, FWIW
414 2012-07-31 18:33:43 <gmaxwell> e.g. pruned nodes won't give completed transactions. If youe get fetches them then pruned nodes will break that.
415 2012-07-31 18:33:55 <BlueMatt> gmaxwell: could require it if NODE_NETWORK && protocol version > N
416 2012-07-31 18:34:06 <BlueMatt> ie, if you can provide full blocks, you should also provide txes from those blocks
417 2012-07-31 18:34:33 <gmaxwell> Mempool doesn't bother me at all I think.. though, I suppose it may possibly make unconfirmed transactions more immortal.
418 2012-07-31 18:34:33 <jgarzik> mempool+this behavior definitely requires a protocol bump, or nServices bit
419 2012-07-31 18:34:37 <jgarzik> no question about it
420 2012-07-31 18:34:56 <jgarzik> nServices ("I serve SPV clients") might be appropriate
421 2012-07-31 18:35:10 <BlueMatt> gmaxwell: for pruned nodes which cant provide blocks, you shouldnt set NODE_NETWORK anyway
422 2012-07-31 18:35:18 <jgarzik> indeed
423 2012-07-31 18:35:20 <gmaxwell> BlueMatt: meh. I dunno about that.  Offering to serve up historic chain isn't the same as being a random access database for them.
424 2012-07-31 18:35:45 <gmaxwell> eg. you might have the blocks but no historic transaction index... as that index will eventually be huge and you don't need it for block serving.
425 2012-07-31 18:35:46 <BlueMatt> gmaxwell: then we rename NODE_NETWORK to NODE_ARCHIVAL
426 2012-07-31 18:35:57 <BlueMatt> the point is old nodes look for that for I can get all blocks from this node
427 2012-07-31 18:36:17 <jgarzik> will SPV clients ever need to see spent TX's?
428 2012-07-31 18:36:21 <gmaxwell> I don't think there is anything we do or need to do that requires random access to the old chain.
429 2012-07-31 18:36:24 <jgarzik> not sure
430 2012-07-31 18:36:27 <jgarzik> but doubtful
431 2012-07-31 18:36:29 <BlueMatt> having a fServesRecentBlocks = NODE_NETWORK || nServices & 0x2
432 2012-07-31 18:36:33 <gmaxwell> jgarzik: I don't think so. Except e.g. for crazy contract reasons.
433 2012-07-31 18:37:06 <BlueMatt> gmaxwell: agreed, but my point is just that there is no reason to break old nodes for no reason when we should just take another nServices bit
434 2012-07-31 18:37:37 <gmaxwell> BlueMatt: Flip that around, we have no reason to offer a service that no one needs and can't depend on being available in the future.
435 2012-07-31 18:38:14 <BlueMatt> do you see a network where we never have archival nodes? or atleast dont have those as pruning becomes bigger?
436 2012-07-31 18:38:20 <gmaxwell> e.g. the spv case doesn't (currently) need spent txn. But in the future if we can't provide those we'll have to stop giving them unspent txn too which we could provide.
437 2012-07-31 18:38:34 <BlueMatt> my point is we can use NODE_NETWORK to indicate we are an archival node as that is what it currently defines
438 2012-07-31 18:38:41 <gmaxwell> BlueMatt: Having access to the blockchain is not the same has having random transaction lookup!
439 2012-07-31 18:38:59 <gmaxwell> Right now you can still be a full node network and save hundreds of megs of space by not indexing old transactions!
440 2012-07-31 18:39:20 <gmaxwell> And this, if it were tied to node_network would break that.
441 2012-07-31 18:39:40 <gavinandresen> jgarzik: no objection, although asking for lots of random transactions from disk might be a good DoS, so a limit might make sense
442 2012-07-31 18:39:58 <BlueMatt> true, either way you end up adding another nServices flag, could just add it later when its needed instead of now