1 2015-05-06 01:15:55 <BlueMatt> anyone ever had issues with boost 1.58?
  2 2015-05-06 02:27:52 <cfields> BlueMatt: building or runtime?
  3 2015-05-06 02:28:03 <BlueMatt> building
  4 2015-05-06 02:28:52 <cfields> BlueMatt: in rpcwallet? boost::get error ?
  5 2015-05-06 02:28:57 <BlueMatt> yup
  6 2015-05-06 02:29:08 <cfields> you need 8b08d9530b93c7a98e7387167ecd2cd5b0563bfb
  7 2015-05-06 02:29:14 <cfields> (in master)
  8 2015-05-06 02:29:15 <cfields> (in master)
  9 2015-05-06 02:29:27 <BlueMatt> yup, I was on 0.10
 10 2015-05-06 02:29:34 <BlueMatt> I replicated that myself, as well
 11 2015-05-06 04:53:52 <fanquake> ;;blocks
 12 2015-05-06 04:53:53 <gribble> 355164
 13 2015-05-06 05:33:50 <jgarzik> joshc, jonasschnelli: Let me know if there are osx build issues with the latest picocoin master branch, please.  Just included byteswap.h and that may need adjusting.
 14 2015-05-06 05:39:57 <jgarzik> huzzah - GLib library dependency removed from picocoin.  Only remaining requirement for the library is openssl.
 15 2015-05-06 05:40:12 <jgarzik> should be much easier to deploy on embedded now.
 16 2015-05-06 05:40:32 <Luke-Jr> :o
 17 2015-05-06 05:44:05 <gmaxwell> jgarzik: congrats!
 18 2015-05-06 05:44:16 <gmaxwell> what do you need from openssl?
 19 2015-05-06 05:45:12 <jgarzik> gmaxwell, the usual stuff for script and signing - sha256, ripemd, ecdsa
 20 2015-05-06 05:45:46 <jgarzik> most likely follow same path as bitcoin core
 21 2015-05-06 05:46:00 <jgarzik> libsecp256k1 + crypto import
 22 2015-05-06 05:46:07 <gmaxwell> you'll find libsecp256k1 a much more portable replacement for those things (except ripemd160 and sha1)... yea.
 23 2015-05-06 05:50:58 <chris13243> is spv pointless now that we have blockchain API's like blockcypher and insight?
 24 2015-05-06 05:52:10 <jgarzik> bitcoin is pointless now that we have coinbase ;p
 25 2015-05-06 05:52:13 <jgarzik> and paypal
 26 2015-05-06 05:52:37 <copumpkin> oh well, nice knowing y'all
 27 2015-05-06 05:52:46 <chris13243> if you wanted to build a wallet without downloading the blockchain (which is the point of SPV) wouldnt you just use a bockchain api?
 28 2015-05-06 05:54:00 <gmaxwell> chris13243: because you don't want to trust a third party who can falsify payments or conceal payments to you, or who can secretly track and report on all your activity (e.g. sell data to your competition), or-- in some cases could freeze your funds.
 29 2015-05-06 05:54:41 <gmaxwell> SPV has no risk of the first, limited risk of the second, better privacy than APIs (though still not awesome), and no risk of the last.
 30 2015-05-06 05:56:56 <chris13243> why wuld you need to trust a third party api? if they can't be trusted then why do they exist?
 31 2015-05-06 05:57:46 <gmaxwell> chris13243: perhaps now Jeff's answer to you makes more sense.
 32 2015-05-06 05:57:49 <chris13243> as long as you hold your own private key, there is no reason to need to trust the API in order to use it
 33 2015-05-06 05:57:59 <gmaxwell> They exist because they are the simpliest thing to build and use.
 34 2015-05-06 05:58:23 <gmaxwell> chris13243: thats incorrect. Control of a private key is only one of many components in Bitcoin security.
 35 2015-05-06 05:58:52 <chris13243> i see api's as making spv obsolete
 36 2015-05-06 05:59:03 <gmaxwell> You can have unique and exclusive control of your private key and still be robbed blind by falsified payments or incorrect coin values causing you to sign away all your coins to fees.
 37 2015-05-06 05:59:14 <Arnavion> Does Google's ability to view cached web pages make going to the actual web pages obsolete?
 38 2015-05-06 05:59:48 <copumpkin> chris13243: your rational behavior relies on you getting reliable information from the outside world
 39 2015-05-06 06:00:08 <jgarzik> I need to overhaul script to remove bignum stuff
 40 2015-05-06 06:00:11 <chris13243> couldnt that be solved by using two different apis an comparing the output is the same?
 41 2015-05-06 06:00:14 <copumpkin> if your interface with the bitcoin network is an API that can lie to you, you might think someone paid you when they didn't, or any number of other things
 42 2015-05-06 06:00:34 <jgarzik> I think libsecp256k1 still requires gmp or similar?  /me goes to check...
 43 2015-05-06 06:00:37 <gmaxwell> Of course, you're also subject to more benign accuracy and reliablity problems with the APIs-- many of these services have poor availablity; and have histories of returning wrong data. They can also be shut down at any time, or block your access or charge for access; and since they are closed they can't easily be repliaced-- imposing a cost on you, potentially at an unwelcome time.
 44 2015-05-06 06:00:43 <gmaxwell> jgarzik: absolutely not.
 45 2015-05-06 06:01:00 <gmaxwell> jgarzik: it's optionally used for verification-- makes verification a couple percent faster. But not required.
 46 2015-05-06 06:01:16 <copumpkin> chris13243: you can reduce risk, sure, but all the points gmaxwell makes are what makes this not a "solved problem"
 47 2015-05-06 06:01:30 <copumpkin> which is why having a nice decentralized approach is good
 48 2015-05-06 06:01:40 <copumpkin> (i.e., not "pointless")
 49 2015-05-06 06:02:21 <gmaxwell> chris13243: then two can just lie to you-- e.g. just takes another Agent Mark Force argmed with two administrative subponea. ... or even one, many services use the same DOS mitigation services which they effectively hand their SSL keys too.
 50 2015-05-06 06:02:39 <gmaxwell> and of course check two subjects you to reliablity problems from both instead of one.
 51 2015-05-06 06:05:11 <chris13243> isit hard to port an app from an api to spv?
 52 2015-05-06 06:07:39 <gmaxwell> depends on what 'app' means.
 53 2015-05-06 06:07:57 <gmaxwell> Sometimes is very hard; though the APIs are usually bitcoind like some offer functionality that cannot be accomplished without databases which are huge _e.g. hundreds of gigabytes_.. applications can virtually always be constructed to have no need of these interfaces but they're a moat that can make conversion hard.
 54 2015-05-06 06:08:47 <fanquake> jgarzik I can't compile picocoin on OS X because it's still including byteswap.h
 55 2015-05-06 06:09:26 <jgarzik> fanquake, any chance you can discover the OS byteswap macros?
 56 2015-05-06 06:09:39 <jgarzik> fanquake, all OS's have them.  Just a question of what header & name.
 57 2015-05-06 06:11:39 <fanquake> jgarzik Sure, will take a look shortly.
 58 2015-05-06 06:12:31 <jgarzik> fanquake, ok i think i found it
 59 2015-05-06 06:14:42 <jgarzik> fanquake, just pushed a fix.  let me know if that works.
 60 2015-05-06 06:14:53 <jgarzik> fanquake, include/ccoin/endian.h
 61 2015-05-06 06:15:54 <jgarzik> *poof*
 62 2015-05-06 06:22:03 <fanquake> jgarzik nice. Except apparently we don't have argp.h either
 63 2015-05-06 06:22:04 <fanquake> jgarzik nice. Except apparently we don't have argp.h either
 64 2015-05-06 06:22:16 <fanquake> Easiest fix is to brew install argp-standalone
 65 2015-05-06 06:22:29 <fanquake> Then everything compiles fine
 66 2015-05-06 06:33:02 <midnightmagic> has anyone done any key verification on the new people doing gitian builds?
 67 2015-05-06 06:33:09 <midnightmagic> "new"
 68 2015-05-06 06:33:10 <midnightmagic> "new"
 69 2015-05-06 06:33:34 <midnightmagic> centaur, erkmos, prab ?
 70 2015-05-06 06:36:46 <midnightmagic> (and ideally would act as a key introducer) ..
 71 2015-05-06 07:50:56 <wumpus> their keys are available through the key server, but besides that, no
 72 2015-05-06 08:14:10 <wumpus> midnightmagic: can you please try to combine pulls, having 7 pulls open w/ gitian sigs confuses me
 73 2015-05-06 08:14:46 <wumpus> eg https://github.com/bitcoin/gitian.sigs/pulls/midnightmagic  which one(s) to merge?
 74 2015-05-06 08:17:34 <wumpus> normally you'd just submit one pull with the assert and sig files for all your builds, sometimes two for e.g. osx signed/unsigned
 75 2015-05-06 08:51:02 <ronkrt> If I'm using bitcoin 0.8.2 beta will bitcoinj-0.12 work with it?
 76 2015-05-06 08:51:39 <sipa> yes, but i seriously suggest you upgrade
 77 2015-05-06 08:52:12 <ronkrt> What version should i use?
 78 2015-05-06 08:52:38 <sipa> 0.10.1
 79 2015-05-06 09:26:39 <ronkrt> Ok thanks
 80 2015-05-06 09:30:09 <wumpus> 0.8.2? why did you stick with such an old version?
 81 2015-05-06 09:31:57 <vertoe> Hi, I'm trying to setup gitian builds. I'm stuck with creating MacOS 10.9 SDK because I have no Mac available. Could anyone tell me how to proceed with this step "fetch and build inputs"...
 82 2015-05-06 09:32:00 <vertoe> https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-build-inputs-first-time-or-when-dependency-versions-change
 83 2015-05-06 09:34:10 <wumpus> you can still proceed, but ship the macosx steps and thus not build for macosx
 84 2015-05-06 09:34:15 <wumpus> s/ship/skip
 85 2015-05-06 09:35:27 <vertoe> ok will skip them for now, thanks
 86 2015-05-06 09:39:52 <wumpus> there is no known way to extract the necessary files from the apple download without a mac
 87 2015-05-06 09:40:39 <vertoe> ok, will ask a friend who has a mac ;-)
 88 2015-05-06 11:41:09 <jtimon> github down?
 89 2015-05-06 11:41:29 <jonasschnelli> yes
 90 2015-05-06 11:41:30 <priidu> seems so
 91 2015-05-06 11:42:12 <jonasschnelli> theres nothing to do without github. :)
 92 2015-05-06 11:43:30 <jtimon> nah, I was just waiting to see if travis was happy about my rebases, that's all
 93 2015-05-06 11:48:23 <vertoe> damn!11
 94 2015-05-06 11:55:04 <vertoe> github back
 95 2015-05-06 12:21:52 <midnightmagic> wumpus: each pullreq was individual per-branch, and per-platform. I can combine them if you prefer. Combining them in the past has led to confusion of its own, which is why I split them out.
 96 2015-05-06 12:22:34 <midnightmagic> wumpus: So..  all of them.
 97 2015-05-06 12:22:35 <midnightmagic> wumpus: So..  all of them.
 98 2015-05-06 12:27:31 <midnightmagic> wumpus: lemme rebuild the titles to make things more obvious.
 99 2015-05-06 12:29:44 <wumpus> ok, yes, was about to say that *if* you submit them separately please make it clear what is what, e.g. the title just "midnightmagic sigs 0.10.1 macosx" and such
100 2015-05-06 12:29:57 <midnightmagic> there. how's that? https://github.com/bitcoin/gitian.sigs/pulls/midnightmagic
101 2015-05-06 12:29:58 <midnightmagic> there. how's that? https://github.com/bitcoin/gitian.sigs/pulls/midnightmagic
102 2015-05-06 12:30:10 <wumpus> if you want to add a story, do it in the description
103 2015-05-06 12:30:47 <wumpus> yes, better
104 2015-05-06 12:31:13 <midnightmagic> ehh.. the LXC mismatch and the lack of key vetting, along with minor mismatches I've noticed seemed important.
105 2015-05-06 12:31:38 <wumpus> it's certainly important, don't get me wrong, but the title is just the title :)
106 2015-05-06 12:31:53 <wumpus> description is the longer memo field
107 2015-05-06 12:32:53 <midnightmagic> it's an auto-generated EOL-eating github derivation.
108 2015-05-06 12:33:06 <wumpus> the usual commit format is 1 title line (up to ~60 characters), then an empty line, then rest of the description
109 2015-05-06 12:33:19 <midnightmagic> none of them were edited. i'll make sure the lines match this more closely
110 2015-05-06 12:33:30 <wumpus> no problem this time
111 2015-05-06 12:33:38 <wumpus> I'll just merge this, just a recommendation for the future
112 2015-05-06 12:34:24 <midnightmagic> sure.
113 2015-05-06 12:36:36 <midnightmagic> the split-outs I'm doing here were, aside from clearing up past aggregated commit confusion, a specific habit to assist cherry-pick/merging, fwiw. it does, at some point, have a purpose. probably just not here.
114 2015-05-06 12:37:06 <wumpus> right
115 2015-05-06 12:39:56 <midnightmagic> wumpus: are more than one person doing osx signed bins now..?
116 2015-05-06 12:39:57 <midnightmagic> wumpus: are more than one person doing osx signed bins now..?
117 2015-05-06 12:44:58 <wumpus> btw - cherry-picking should never be an issue with the gitian sigs, as different commits should never collide
118 2015-05-06 12:44:59 <wumpus> btw - cherry-picking should never be an issue with the gitian sigs, as different commits should never collide
119 2015-05-06 12:47:03 <vertoe> is anyone familiar with gitian? I can't get it to initialize VMs https://github.com/devrandom/gitian-builder/issues/88
120 2015-05-06 12:50:17 <wumpus> midnightmagic: 7 people have built and signed the osx-signed
121 2015-05-06 12:51:21 <wumpus> vertoe: strange problem, I don't recognize it
122 2015-05-06 12:51:23 <midnightmagic> wumpus: is there a purpose to a gitian sig of an osx signed bin that I'm missing? (i.e. should I also be signing?)
123 2015-05-06 12:52:04 <wumpus> midnightmagic: well it audits the final executable that is actually distributed, so, yes
124 2015-05-06 12:52:29 <midnightmagic> wumpus: i thought signed bins were non-deterministic?
125 2015-05-06 12:52:39 <vertoe> is it recommended to run gitian on an ubuntu host?
126 2015-05-06 12:52:44 <vertoe> or is debian just fine?
127 2015-05-06 12:52:52 <wumpus> vertoe: it could be that you built the base images without USE_LXC and try to build with, or the other way around
128 2015-05-06 12:52:58 <wumpus> vertoe: shouldn't matter
129 2015-05-06 12:53:41 <wumpus> midnightmagic: the build process changed there, the signature is created and distributed out-of-band, the osx-signed build step just attaches it
130 2015-05-06 12:55:16 <midnightmagic> The split-out is a habit heldover from pipes and import scripts into other systems. Referencing a commitid in this manner can thus omit filespecs. Ehh.. like I implied, I don't care much. potential motility and yadda yadda
131 2015-05-06 12:58:37 <midnightmagic> well. how about that. we can make our own signed binaries.
132 2015-05-06 12:59:36 <s7r> What is the difference between CLTV and RCLTV?
133 2015-05-06 12:59:55 <sipa> cltv uses an absolute timestamp
134 2015-05-06 13:00:14 <sipa> rcltv a relative one (how old must a coin be before it can be spent)
135 2015-05-06 13:00:15 <sipa> rcltv a relative one (how old must a coin be before it can be spent)
136 2015-05-06 13:00:48 <s7r> and how does the absolute timestamp work?
137 2015-05-06 13:01:09 <s7r> it it calculated against block number?
138 2015-05-06 13:01:38 <sipa> or block's timestamp
139 2015-05-06 13:01:43 <sipa> read the bip
140 2015-05-06 13:02:35 <s7r> which bip is that?
141 2015-05-06 13:03:17 <sipa> 65
142 2015-05-06 13:03:27 <s7r> oh, that didn't say anything about RCLTV.
143 2015-05-06 13:03:48 <sipa> it does not
144 2015-05-06 13:03:59 <sipa> rcltv does not exist, there are just a couple of ideas
145 2015-05-06 13:04:02 <s7r> do the devs have to choose between CLTV and RCLTV or both can be implemented simultaneously
146 2015-05-06 13:04:11 <sipa> they are orthogonal
147 2015-05-06 13:10:05 <s7r> thanks sipa
148 2015-05-06 13:11:08 <s7r> rcltv has some interesting use cases that I can think of right now
149 2015-05-06 13:11:26 <s7r> do we have a link with some comparisions about RCLTV and CLTV?
150 2015-05-06 13:31:58 <jgarzik> s7r, comparisons with regards to what?
151 2015-05-06 13:32:13 <s7r> use cases, examples like BIP65 has on mediawiki
152 2015-05-06 14:53:35 <jonasschnelli> wumpus: damit. I missed the REST doc change for #5240. Now the "getutxos" looks wrong: https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md
153 2015-05-06 14:54:18 <jonasschnelli> i go over cfields trivial for this
154 2015-05-06 14:54:25 <wumpus> ok. It looked ready to merge to me
155 2015-05-06 14:54:52 <jonasschnelli> Yes. It was ready. But i forgot to use a header in the documentation. My fault.
156 2015-05-06 15:06:03 <wumpus> no problem
157 2015-05-06 15:06:17 <wumpus> I'm happy that you bother writing documentation at all :)
158 2015-05-06 15:19:27 <wumpus> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/6034 can imo be merged after squashing
159 2015-05-06 15:19:50 <jonasschnelli> okay, will squash, 5min
160 2015-05-06 15:23:49 <jonasschnelli> wumpus: 6034: squash into cfields commit
161 2015-05-06 15:24:36 <jonasschnelli> wumpus: what about merging https://github.com/bitcoin/bitcoin/pull/5958?
162 2015-05-06 15:28:06 <wumpus> jonasschnelli: huh, how did I miss that one - needs rebase though
163 2015-05-06 15:28:53 <wumpus> it looks like we have a (trivial) merge bottleneck in rpc-tests.sh, almost every pull (that adds tests) ends up changing that file :p
164 2015-05-06 15:30:00 <jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/5958 has a non-trivial merge. Will do soon.
165 2015-05-06 15:30:16 <jonasschnelli> yes. rpc-tests.sh's array is not easy to automerge.
166 2015-05-06 15:32:02 <wumpus> ok, let me know again when you did, a tests-only pull really shouldn't have to wait that long
167 2015-05-06 15:42:25 <jtimon> ping #5975 and https://github.com/jtimon/bitcoin/commit/543f5b2ba0769f9e54cb667efbf74e040ea3119d
168 2015-05-06 16:01:11 <ronkrt> what is speedy to happen when you run bitcoinjfor the first time
169 2015-05-06 16:44:51 <wallet42> any dev from coinmap.org here?
170 2015-05-06 18:00:45 <mrkent> What bitcoin.conf settings do I use to always enforce a minimum txfee of 0.0001?
171 2015-05-06 18:01:44 <mrkent> I have paytxfee set to 0.0001, but bitcoind sometimes sends with 0 fee
172 2015-05-06 18:02:12 <sipa> did you restart bitcoind after the change?
173 2015-05-06 18:03:35 <mrkent> sipa, i changed it a while back so it is highly likely to have restarted at some point
174 2015-05-06 18:04:16 <mrkent> but can't say definitively
175 2015-05-06 18:05:36 <mrkent> is this the only possible case?
176 2015-05-06 18:05:57 <sipa> yes
177 2015-05-06 18:06:08 <sipa> unless there is a bug, of course
178 2015-05-06 18:07:40 <mrkent> k
179 2015-05-06 18:11:19 <phantomcircuit> sipa, iirc there is some weirdness there with really really high priority transactions still being sent with zero fee
180 2015-05-06 18:13:05 <sipa> hmm
181 2015-05-06 18:32:39 <morcos> sipa: can i ask you a question about 6102, or really about FSTD in general
182 2015-05-06 18:32:50 <morcos> can you take a look at: https://github.com/sipa/bitcoin/compare/accuratecache...morcos:modifyFSTD?expand=1
183 2015-05-06 18:32:51 <morcos> can you take a look at: https://github.com/sipa/bitcoin/compare/accuratecache...morcos:modifyFSTD?expand=1
184 2015-05-06 18:33:19 <morcos> there are 2 things there, we found a bug in the pruning code when we tried to move the reseting of that flag, and so i want to ask your thoughts about that
185 2015-05-06 18:34:05 <morcos> but then i also thought it might make sense to move the disk space check to after we potentially pruned... it seems like we're not bothering checking diskspace for blockindex database writes anyway
186 2015-05-06 18:41:22 <gmaxwell> morcos: hm. we probably should be checking more then; leveldb behaves _really_ bad if it runs out of space.
187 2015-05-06 18:42:01 <morcos> well we check it now b/c they are flushed at the same time
188 2015-05-06 18:42:09 <morcos> but in that pull as written it wouldn't happen i guess
189 2015-05-06 18:45:38 <sipa> morcos: moving the checkdiskspace is fine
190 2015-05-06 18:46:04 <sipa> it only includes computations for the chainstate db anyway (which i should update to also be accurate)
191 2015-05-06 18:49:14 <morcos> sipa: so then we won't check at all if we're only writing block index?
192 2015-05-06 18:49:44 <sipa> morcos: well that's not actually different from now, i think
193 2015-05-06 18:50:04 <morcos> as for the fCheckForPruning move, you had worried on the original pull, about what happens if we don't actually prune and so we should clear that flag yet
194 2015-05-06 18:50:06 <sipa> morcos: what if writing utxo is perfectly accounted for, but adding the index writes makes it go over the limit
195 2015-05-06 18:50:32 <lrning> Anyone care to chime in here? http://www.reddit.com/r/Bitcoin/comments/3536sz/how_to_compile_bitcoin_core_from_source_code_on/
196 2015-05-06 18:50:47 <morcos> sipa: (at least checking at all gives you a 50MB  buffer)
197 2015-05-06 18:51:21 <sipa> morcos: we can add a static checkdiskspace check for the block index writes?
198 2015-05-06 18:51:40 <morcos> but it turns out that if we dont' actually prune, we've already recorded the fact that we've pruned in our vinfoBlockFiles, so we wouldn't find those files to unlink by checking again
199 2015-05-06 18:51:59 <morcos> (yes i think that makes sense, unless that call is too expensive)
200 2015-05-06 18:52:30 <sipa> it can't be expensive compared to the write that's going to follow anyway
201 2015-05-06 18:53:02 <morcos> so deciding not to worry about that and clearing the flag after we check makes sense to me, especially if we move this other stuff, bc it makes fialure very unlikely.  if we wanted to belt and suspenders then on startup we could delete any actual files for which vinfoBlockFile[file].nSize = 0
202 2015-05-06 18:53:19 <morcos> but i don't know thats necessary
203 2015-05-06 18:59:45 <gmaxwell> wrt pruning; should we go ahead for 0.11 and set a new flag for "we can serve the last 288 blocks from our tip"?
204 2015-05-06 19:00:24 <sipa> or even just for "we will relay new blocks"
205 2015-05-06 19:00:36 <sipa> but those together probably makes sense
206 2015-05-06 19:00:42 <morcos> i think we should just decide what we want to do about sharding
207 2015-05-06 19:01:11 <sipa> right now, a pruning node will only connect out
208 2015-05-06 19:01:20 <sipa> i think?
209 2015-05-06 19:01:36 <morcos> i need to go back and read what you were saying about an algo for that
210 2015-05-06 19:01:37 <sipa> it would accept connections, but nothing will connect to it due to not having NODE_NETWORK
211 2015-05-06 19:01:45 <morcos> but i didnt' quite understand why it was so complicated
212 2015-05-06 19:02:02 <morcos> you seemed to not like the idea of keeping a fixed proportion of the blockchain
213 2015-05-06 19:02:54 <morcos> but why is that bad?   say it's 1/256..   then maybe you keep 10/256's at first and as the block chain grows, you could drop to 9 and stay under a limit..  but like i said, i havent' thought about this as much as you
214 2015-05-06 19:04:14 <morcos> gmaxwell: missed "for 0.11", so yeah i guess solving that is too much
215 2015-05-06 19:07:45 <gmaxwell> morcos: perhaps; its a 1LOC change. (since we'd always send that bit)
216 2015-05-06 19:07:56 <gmaxwell> to just send it; I didn't even mean using it.
217 2015-05-06 19:08:30 <gmaxwell> right now the current behavior means you cna't do a pruned firewall which is kinda obnoxious.
218 2015-05-06 19:09:14 <morcos> gmaxwell: yeah i meant doing more than that was too much (the whole sharding solution)
219 2015-05-06 19:09:30 <sipa> gmaxwell: want to write a BIP?
220 2015-05-06 19:11:52 <gmaxwell> yea doing the smart stuff is too much for 0.11; but at least signaling what we can do so that future versions would be smarter would be really nice; ... I would like to go slightly beyond that so you could at least do mine+firewallet; but ....
221 2015-05-06 19:15:07 <gmaxwell> sipa: I can write one today.
222 2015-05-06 19:15:42 <sipa> what is firewallet?
223 2015-05-06 20:06:44 <petertodd> gmaxwell: I'd call it NODE_VALIDATING myself - the node will relay and fully validates, but makes no uarantees about being able to serve up archival history beyond the last 288 blocks
224 2015-05-06 20:07:21 <petertodd> gmaxwell: arguably, even "288" is maybe a number that shouldn't be defined - no guarantees at all
225 2015-05-06 20:26:02 <denisx> what was the hidden command again to revalidate a block again?
226 2015-05-06 20:28:03 <phantomcircuit> denisx, reconsiderblock
227 2015-05-06 20:28:23 <denisx> thanks