1 2014-07-26 02:00:34 <HaltingState> sipa, in "int secp256k1_ecdsa_privkey_tweak_mul(unsigned char *seckey, const unsigned char *tweak) {"
  2 2014-07-26 02:00:38 <HaltingState> secp256k1_num_mod_mul(&sec, &sec, &factor, &secp256k1_ge_consts->order);
  3 2014-07-26 02:01:14 <HaltingState> you are checking if a 32 byte value (seckey) is greater than order of the curve, which is 33 byte int?
  4 2014-07-26 02:01:39 <sipa> the order of the curve is 32 bytes
  5 2014-07-26 02:02:53 <sipa> around 2^256 - O(2^128)
  6 2014-07-26 02:03:39 <HaltingState> a pubkey is a point on curve, so two values less than order of curve, but compresses to 33 bytes, hmm
  7 2014-07-26 02:04:09 <sipa> a _serialized_ pubkey is 32 bytes
  8 2014-07-26 02:04:21 <sipa> it has 1 byte header + 32 bytes x coordinate
  9 2014-07-26 02:04:23 <HaltingState> 32 bytes + 4
 10 2014-07-26 02:04:28 <sipa> ?
 11 2014-07-26 02:04:37 <HaltingState> isnt there a value from 0 to 3
 12 2014-07-26 02:04:41 <sipa> ?
 13 2014-07-26 02:04:52 <sipa> what are you talking about?
 14 2014-07-26 02:04:53 <HaltingState> nm, signature recovery
 15 2014-07-26 02:05:07 <HaltingState> how do you get 32 bytes for public keys?
 16 2014-07-26 02:05:14 <sipa> you don't
 17 2014-07-26 02:05:26 <sipa> the x coordinate is 32 bytes
 18 2014-07-26 02:05:32 <sipa> but that's not a full public key
 19 2014-07-26 02:06:32 <sipa> also, you started talking about private keys (which are 32 byte ints), and then switched to public key (which are pairs of 32-byte ints, serialized in compressed form to 33 bytes)
 20 2014-07-26 02:06:46 <sipa> they're different things
 21 2014-07-26 02:06:52 <sipa> the curve order is a number, not a point
 22 2014-07-26 02:07:17 <HaltingState> sorry confused; solved issue. secp256k1_ecdsa_pubkey_tweak_mul wont fail as long as the seckey and pubkey are valid
 23 2014-07-26 02:10:32 <HaltingState> the issue i was having is that seckey generation cannot fail; you are taking the base point and raising it to power of seckey. I dont think there is check there for whether seckey is larger than order of curve, but that same seckey can fail when used in function that does the order check
 24 2014-07-26 02:10:41 <HaltingState> secp256k1_ecdsa_pubkey_create does not check to see if seckey is less than order of curve
 25 2014-07-26 02:11:22 <HaltingState> so secp256k1_ecdsa_pubkey_create will succeed for seckey larger than order of curve, but will fail when used in secp256k1_ecdsa_pubkey_tweak_add
 26 2014-07-26 02:13:41 <gmaxwell> if it does, thats a bug
 27 2014-07-26 02:13:52 <HaltingState> https://github.com/bitcoin/secp256k1/blob/master/src/secp256k1.c
 28 2014-07-26 02:14:41 <HaltingState> secp256k1_ecdsa_pubkey_create does not check that seckey is less than order of curve, and so may accept valid seckey (why shouldnt it? seckey is just integer that b is raised to). where check is made for whether seckey is less than order of curve in secp256k1_ecdsa_seckey_verify
 29 2014-07-26 02:25:12 <HaltingState> sipa, should I do pull request? secp256k1_ecdsa_pubkey_create succeeds for seckeys larger than order of curve, but secp256k1_ecdsa_pubkey_tweak_add will fail if you use the same seckey because of the order check
 30 2014-07-26 03:58:40 <torokun> question
 31 2014-07-26 03:59:18 <torokun> is anyone actually working on a solution to the growth in blockchain size, and what is the priority of that to current developers?
 32 2014-07-26 04:01:57 <jgarzik> torokun, 1) yes   2) difficult question to answer, regardless of the specific topic
 33 2014-07-26 04:02:59 <torokun> so is there a branch with some aspects of that being worked on, or is it sort of in the concept phase?
 34 2014-07-26 04:04:09 <torokun> regarding priority, I have seen devs refer to prioritization of features a number of times -- just wondering where that issue fell in the spectrum of important to maybe someday...
 35 2014-07-26 04:18:53 <jgarzik> torokun, it's not one solution, it's 1000 solutions.  increasing (or reducing decrease) full node count is important, therefore anything we can do to ease pain there is useful.
 36 2014-07-26 04:22:55 <torokun> I have been thinking about ideas to ameliorate that...
 37 2014-07-26 04:24:19 <torokun> There must be a way that you could have sort of checkpoints every X blocks, at which you consolidate the picture of all unspent outputs and create a new blob of that which could be shared instead of the entire chain.
 38 2014-07-26 04:24:48 <torokun> It could be a series of blocks or a new type of binary database file.
 39 2014-07-26 04:24:50 <kazcw> and trust someone to make a checkpoint?
 40 2014-07-26 04:24:57 <torokun> no
 41 2014-07-26 04:25:15 <torokun> I think the process would have to be in the client, and you would have to have multiple clients do it and hash it.
 42 2014-07-26 04:25:36 <torokun> then they could all compare their results and sort of approve it distributedly.
 43 2014-07-26 04:25:50 <kazcw> you can't trust something just because multiple peers attest to it
 44 2014-07-26 04:25:54 <kazcw> not if you want even spv-level security
 45 2014-07-26 04:26:29 <torokun> well, it's a question of how much verification you would want in order to trust it.
 46 2014-07-26 04:26:37 <torokun> if you want it unanimous, you could do that.
 47 2014-07-26 04:26:55 <Blxjander> How about making it a client-node specific shorthand?
 48 2014-07-26 04:26:57 <torokun> then people downloading the client after that point would be able to trust it at least.
 49 2014-07-26 04:27:10 <kazcw> unanimous among your 8 peers?
 50 2014-07-26 04:27:38 <torokun> well, i'm not completely clear on how the network operates yet.
 51 2014-07-26 04:28:10 <torokun> if it were a note-specific shorthand, it wouldn't help new users by shortening the download time for them...
 52 2014-07-26 04:28:16 <torokun> "node-specific"
 53 2014-07-26 04:28:58 <Blxjander> torokun: it would be usable if multiple nodes were providing the blockchain...and provided the same "shorthand" verification strings for the same block range...
 54 2014-07-26 04:29:11 <Blxjander> that block can be skipped and downloaded later
 55 2014-07-26 04:29:17 <Blxjander> without any immediate priority
 56 2014-07-26 04:29:25 <torokun> if there were a way for each node to create the checkpoint binary and distribute its hash on the network, and for all the nodes to know when every node agreed, then they could accept it.
 57 2014-07-26 04:29:51 <kazcw> you might want to get more of a handle on how it works before thinking you have the big solutions. if we could reach consensus just by having full nodes vote, we wouldn't need PoW
 58 2014-07-26 04:30:08 <Blxjander> every what...128 blocks in the chain become a larger contiguous checkpoint marked step?
 59 2014-07-26 04:30:41 <HaltingState> sipa, w00t. ECDH is working :) passed unit test http://i.imgur.com/qgySxbr.png
 60 2014-07-26 04:31:07 <torokun> kazcw - i do intend to - just in the process of ingesting much info.  but I have no delusions of grandeur here ... hehe.
 61 2014-07-26 04:31:12 <torokun> Just thinking out loud.
 62 2014-07-26 04:35:34 <HaltingState> the blockchain size is fine; the issue is download speed
 63 2014-07-26 04:36:27 <HaltingState> people are working on patch that will download headers of blocks first and then download the bodies from multiple peers; that will speed up download time a lot. right now the client downloads one block at a time and only from on person and if the person is uploading slowly, too bad
 64 2014-07-26 04:37:00 <torokun> yes, that will be great.
 65 2014-07-26 04:37:20 <wumpus> it's even already available, please help testing: https://github.com/bitcoin/bitcoin/pull/4468
 66 2014-07-26 04:38:27 <HaltingState> 30 GB is not too much; i can torrent that in an hour. i torrent a 6 GB anime series in 10 minutes. the issue is just the slow peers and one block at a time downloads
 67 2014-07-26 04:39:22 <HaltingState> also there is no real thin client standard for bitcoin, which is another problem; otherwise i would not need to run the blockchain for apps/libraries to sign transactions and inject them into network
 68 2014-07-26 04:40:20 <torokun> Yeah............  it's not infeasable, but there's not much else out there that takes an hour to download except for whole seasons of TV shows.
 69 2014-07-26 04:40:31 <wumpus> there is a think client standard for bitcoin: SPV
 70 2014-07-26 04:40:47 <torokun> SPV is good for what it is, certainly.
 71 2014-07-26 04:40:50 <wumpus> everything based on bitcoinj uses it, as wel las all the android applications
 72 2014-07-26 04:41:00 <wumpus> and iOS I suppose
 73 2014-07-26 04:41:15 <torokun> But I'm somewhat concerned that we'll end up with over 90% spv clients.
 74 2014-07-26 04:41:30 <wumpus> the thin client problem is one that has been solved years ago
 75 2014-07-26 04:41:57 <wumpus> why would that be a problem?
 76 2014-07-26 04:42:29 <torokun> I would like running a full node to be as easy as helping to seed a torrent.
 77 2014-07-26 04:42:31 <wumpus> running full nodes is for enthousiasts, larger merchants, developers, it's not for everyone
 78 2014-07-26 04:42:43 <wumpus> SPV is meant to be for everyone
 79 2014-07-26 04:43:00 <wumpus> so it is sane for there to be lot's more SPV clients
 80 2014-07-26 04:43:06 <torokun> wumpus: that's only because it has to be at the moment, right?
 81 2014-07-26 04:43:14 <HaltingState> wumpus, is there implementation in golang?
 82 2014-07-26 04:43:27 <wumpus> torokun: well it just makes no sense to upload tons of data if you just want to make payments
 83 2014-07-26 04:43:38 <wumpus> torokun: you should see running a node and running a wallet separately
 84 2014-07-26 04:44:13 <torokun> unfortunately, then we have divorced all incentives except altruism from the running of full nodes...
 85 2014-07-26 04:44:26 <wumpus> it's only by historical accident that bitcoind/bitcoin-qt have both a wallet and node implementation built in, we're trying to fix that
 86 2014-07-26 04:44:38 <wumpus> but a lot of people already run it in disablewallet moe
 87 2014-07-26 04:44:40 <wumpus> mode*
 88 2014-07-26 04:45:18 <wumpus> HaltingState: yes btcd
 89 2014-07-26 04:45:42 <Blxjander> wumpus: so it is possible to download only the core bitcoind with blockchain only functionality?
 90 2014-07-26 04:46:06 <wumpus> Blxjander: yes, either pass --disable-wallet at build time or -disablewallet at run time
 91 2014-07-26 04:46:14 <HaltingState> btcd is full node
 92 2014-07-26 04:46:14 <wumpus> Blxjander: been possible since 0.9.0
 93 2014-07-26 04:46:44 <wumpus> HaltingState: oh, right, I don't know of any bitcoinj-like library for go
 94 2014-07-26 04:46:47 <HaltingState> https://gowalker.org/github.com/conformal/btcwallet
 95 2014-07-26 04:46:57 <wumpus> HaltingState: but should be pretty easy to build on top of that I suppose
 96 2014-07-26 04:47:10 <HaltingState> this requires a full node, but stores locally and seperates out the wallet from the node, which is nice
 97 2014-07-26 04:47:15 <torokun> well, wasn't the original idea that you wanted to verify the blockchain yourself if you were creating or receiving transactions?
 98 2014-07-26 04:47:17 <HaltingState> over the json interface
 99 2014-07-26 04:47:32 <wumpus> if you have all the message deserialization and network handling, making a SPV client isn't rocket science
100 2014-07-26 04:48:04 <wumpus> but it may exist already (it's unfortunate that everything is fragmented due to division around programming languages, though)
101 2014-07-26 04:49:11 <torokun> So what is in it for the guys running full nodes now?
102 2014-07-26 04:49:20 <Blxjander> wumpus: what is the address of the bitcoind repository?... is it the same repo as bitcoin-qt?
103 2014-07-26 04:49:48 <Blxjander> wumpus: and will I be stuck with gnu-autotools or cmake as a build system that I need to work around not having?
104 2014-07-26 04:50:02 <wumpus> torokun: the idea of running a public piece of infrastructure; same as running any P2P service, really
105 2014-07-26 04:50:26 <wumpus> Blxjander: https://github.com/bitcoin/bitcoin , and we use autotools
106 2014-07-26 04:50:48 <gmaxwell> torokun: for one, running behind a trusted full node provides SPV wallets with the best security. The SPV security model absolutely is reduced— generally fine for casual use, since so long as you wait for confirmations the primary attacks are costly ones.
107 2014-07-26 04:51:16 <Blxjander> wumpus: well I will just have to sort out the RPi I have sitting here to run the autotools from a minimal arch linux server as a functional extension of my desktop then
108 2014-07-26 04:51:32 <wumpus> Blxjander: uhm... ok
109 2014-07-26 04:52:55 <Blxjander> wumpus: I'm not running Mac/Win/Lin OS on my PPC desktop,  I have AmigaOS running on it
110 2014-07-26 04:53:19 <wumpus> Blxjander: right, good luck with that
111 2014-07-26 04:53:21 <gmaxwell> torokun: e.g. you should not generally be trusting payments you are reciving with value anywhere near the scale of the block rewards burrying them as irreversable, unless you have a known well connected full node.
112 2014-07-26 04:53:44 <torokun> gmaxwell - yes, that's true - so we will and do already see services supporting spy wallets running their own nodes.  That will give a many many to one ratio of spy clients to full nodes though...  will that be a problem at some point?
113 2014-07-26 04:54:01 <torokun> spy->spv
114 2014-07-26 04:54:16 <phantomcircuit> torokun, you dont have to verify anything to send payments
115 2014-07-26 04:54:19 <phantomcircuit> only to receive
116 2014-07-26 04:54:57 <Blxjander> torokun: eventually yeah it will be a problem
117 2014-07-26 04:55:37 <Blxjander> torokun: as anyone running the full nodes effectively becomes an authority for the spv nodes and limit the distributed content of the network with regards the number of blockchain copies
118 2014-07-26 04:55:54 <torokun> I honestly don't know - maybe, maybe not, it seems to me.
119 2014-07-26 04:56:01 <wumpus> well at least a problem with an easy solution then, just run more full nodes
120 2014-07-26 04:56:49 <gmaxwell> torokun: its potentially a problem if most of the end users are on SPV wallets AND mining is very centeralized.
121 2014-07-26 04:56:59 <wumpus> but a few full nodes can serve lots of SPV nodes
122 2014-07-26 04:57:10 <wumpus> mining centralization is a bigger issue
123 2014-07-26 04:57:27 <wumpus> it's much more difficult to spin up a mining farm than a full node
124 2014-07-26 04:57:31 <gmaxwell> Since at the limit of those trends the properties that made bitcoin intially attractive break down— e.g. miners could inflate the currency. Though there are some technical tools that could be deployed to improve that.
125 2014-07-26 04:57:48 <torokun> So to come full circle, it would be nice if there were an incentive to run full nodes, I think.  If it were as easy as using the reference client, and it were not a big chore to d/l the block chain, we'd naturally have many people running full nodes, just as torrents have lots of peers.
126 2014-07-26 04:58:45 <wumpus> torokun: well making it easier to run a full node is always welcome, but what do you think is the complicated part at this point?
127 2014-07-26 04:59:02 <gmaxwell> wumpus: yes but the proliferation of full nodes bounds the potential dishonesty of miners— with lots of full node miners dishonest options are mostly limited to censorship and outright theft by doublespending their own transactions; if SPV nodes are overwhelmingly common and no form of fraud proof is introduced, then miners get the ability to inflate and the ability to steal coins from users (e.g. inactive ones that might not complain).
128 2014-07-26 04:59:20 <gmaxwell> torokun: sure help to make the costs of running a full node lower would be welcome!
129 2014-07-26 04:59:45 <torokun> I don't think it's complicated, just takes too long to d/l the block chain, and potentially, dare I say, a lot of space for some machines.
130 2014-07-26 04:59:56 <gmaxwell> torokun: it's already as simple as starting the reference software... though there is lots of room to make it less resource intensive and useful is less time.
131 2014-07-26 05:00:12 <wumpus> torokun: the idea is that you download the sofware, install it, and start running it and you can ignore it from then on
132 2014-07-26 05:00:29 <wumpus> torokun: that it takes time to download the block chain isn't even that relevant, although speeding it up is of course still nice
133 2014-07-26 05:00:55 <gmaxwell> torokun: Well it currently requires about $1 in disk space... so, well there are huge asymptotic improvements we can make to that which are mostly implemented already, but if $1 in disk space is too much, then perhaps that user shouldn't b.e
134 2014-07-26 05:01:05 <wumpus> torokun: anyhow, if you want to do work in that direction that'd be very welcome, you could start with testing sipa's headers-only patch
135 2014-07-26 05:01:07 <gmaxwell> and as wumpus notes, if its setup well it doesn't matter how long it takes.
136 2014-07-26 05:01:54 <torokun> Would it be possible to make the reference client immediately useful by including the block chain data pre-processed in the binaries provided for download?  Then a user could start running it while it downloads and verifies the real block chain in the background over time.
137 2014-07-26 05:01:59 <wumpus> torokun: after that is in, it's would be possible to integrate bandwidth limiting/quotas
138 2014-07-26 05:02:22 <Blxjander> wumpus: well I just assigned off a 60GB partition for use as a BlockChain storage area...I think that should be a decent amount of HDD space for now at least
139 2014-07-26 05:02:57 <wumpus> torokun:  you still have to download and verify all the data before it is running, no matter how you download it
140 2014-07-26 05:03:24 <gmaxwell> torokun: thats not really helpful... There are better ways to be immediately useful. doing that would further obfscuate the security model and put the people distributing the software at increased risk of coercion.
141 2014-07-26 05:03:40 <torokun> gmaxwell - true.
142 2014-07-26 05:03:46 <gmaxwell> headers first patch gives you headers level (e.g. SPV like) validation within a minute after startup in any case.
143 2014-07-26 05:03:48 <wumpus> torokun: anyhow, as said, there isn't really a hurry in making a node 'useful'
144 2014-07-26 05:04:25 <wumpus> speed is not more important than security here
145 2014-07-26 05:05:19 <wumpus> torokun: as said, https://github.com/bitcoin/bitcoin/pull/4468 may already do what you want, see the sync times there
146 2014-07-26 05:05:50 <torokun> I will take a look at that - thanks.
147 2014-07-26 05:06:14 <jcorgan> wumpus: 100 min from scratch over GbE and .bitcoin on RAID5 :)
148 2014-07-26 05:06:30 <gmaxwell> andytosh was saying that his non-script-validating rust implementation of bitcoin sync over the network from a local node in 30 minutes, so clearly there is plenty of room for improvement.
149 2014-07-26 05:06:33 <torokun> I used to do a lot of cpp development but haven't for quite a while, and it's tough to get the time to grok significant portions of the code.
150 2014-07-26 05:06:35 <wumpus> jcorgan: from the internet or local nodes?
151 2014-07-26 05:06:39 <jcorgan> local
152 2014-07-26 05:06:47 <phantomcircuit> gmaxwell, just a thought, we might as well ship the reference client with the the headers for all the blocks under the checkpoint
153 2014-07-26 05:06:51 <gmaxwell> torokun: without the GUI bitcoind is only ~30kloc. It is not a huge program.
154 2014-07-26 05:06:54 <jcorgan> well, internet mixed in, but i'm sure it was mostly from the locals
155 2014-07-26 05:07:39 <wumpus> gmaxwell: non-validating it would be just like a file transfer, so it makes sense you can do it in 30 minutes with a fast network and disk
156 2014-07-26 05:08:05 <gmaxwell> phantomcircuit: sure, well, I'm going to propose at some point that we make an "irrelevant hardfork" to up the minimum difficulty to 2^32. (e.g. 64 bits of zeros). Packing up the grandfathered headers there would likely make sense, sipa has header compression down to about 38 bytes per header.
157 2014-07-26 05:08:09 <phantomcircuit> wumpus, uh no since you dont know the block hashes in advance
158 2014-07-26 05:08:12 <wumpus> phantomcircuit: why? downloading the headers is fast
159 2014-07-26 05:08:23 <gmaxwell> wumpus: it validates everything but scripts
160 2014-07-26 05:08:26 <phantomcircuit> wumpus, getheaders is limited to 2k for some reason
161 2014-07-26 05:08:40 <gmaxwell> wumpus: all the block header rules, spendness checks, hashes, etc.  he just hasn't written the script engine yet.
162 2014-07-26 05:09:04 <wumpus> phantomcircuit: we're trying to reduce hardcoded data like the checkpoints, not include more
163 2014-07-26 05:09:12 <gmaxwell> phantomcircuit: but really at worse that saves you only about a minute, so ::shrugs::
164 2014-07-26 05:09:28 <gmaxwell> wumpus: validated preload isn't quite the same as hardcoded data.
165 2014-07-26 05:09:41 <wumpus> gmaxwell: I still don't really like it
166 2014-07-26 05:10:23 <wumpus> for a SPV client it makes sense to hardcode that data to get up and running fast, but for a node full validation is more important than a bit of speed, we're not aiming for close to those times
167 2014-07-26 05:10:50 <gmaxwell> Full agreement, I'm not sure how best to deal with the orphan flooding attacks though— headers first increases their costs 12500 fold, but they're still a bit too cheap for comfort. Upping a minimum difficulty to 2^32 would close them off, but we need some way to handle the grandfathered blocks.
168 2014-07-26 05:14:42 <torokun> Well, you're already providing a torrent of most of the block chain.  What would be the issue with providing a package that includes the blockchain up to a certain checkpoint?
169 2014-07-26 05:15:25 <kazcw> that's basically what the torrent is
170 2014-07-26 05:15:28 <gmaxwell> torokun: the torrent gets validated, and the torrent should be compltely unnecessary (slower than a network download) with the headers first patches that we're suggesting you try out.
171 2014-07-26 05:15:45 <torokun> huh.
172 2014-07-26 05:15:54 <torokun> that's cool.
173 2014-07-26 05:16:36 <gmaxwell> (slower because when you're using it you cannot overlap importing and downloading, also some advantages from bitcoin's data already being authenticated saving some redundant hashing)
174 2014-07-26 05:18:06 <jcorgan> i've been running the headersfirst8 branch on it's own, merged into master, combined with addrindex, and with a couple other wip branches i have, with zero issues in compile or runtime that i can tell.  i haven't tried reindexing, though.
175 2014-07-26 05:19:23 <gmaxwell> reindexing is broken for a node synced initially on headers first right now
176 2014-07-26 05:19:37 <gmaxwell> because headers first will result in blocks out of order on disk and reindex can't handle it.
177 2014-07-26 05:19:55 <jcorgan> thought that was case
178 2014-07-26 05:19:57 <jcorgan> the case
179 2014-07-26 05:20:44 <gmaxwell> I haven't had time to do ~much~ testing since the first round, but I have kept a node up running in valgrind with sipa's latest version.
180 2014-07-26 05:52:49 <phantomcircuit> gmaxwell, can still validate the block headers provided
181 2014-07-26 06:07:08 <wumpus> phantomcircuit: you could add bootstrap_headers.dat functionality
182 2014-07-26 06:08:00 <wumpus> phantomcircuit: just like bootstrap.dat it'd read the file at start, except expect blocks it expects just headers
183 2014-07-26 06:08:17 <wumpus> *instead of expecting blocks
184 2014-07-26 06:09:20 <phantomcircuit> wumpus, yeah same idea
185 2014-07-26 06:10:15 <wumpus> I suspect the gain compared to headers-first from the network is minimal, but if you want to try it out why not
186 2014-07-26 06:12:23 <phantomcircuit> wumpus, it's relatively small, but the limit on getheaders is the only reason it takes 1 minute
187 2014-07-26 06:12:31 <phantomcircuit> that should really have been much much higher...
188 2014-07-26 06:12:55 <gmaxwell> phantomcircuit: meh, hardly matters, and it avoids monopolizing peers too much.
189 2014-07-26 06:13:12 <phantomcircuit> gmaxwell, headers are almost always entirely in memory
190 2014-07-26 06:13:33 <phantomcircuit> given that getdata has a *much* larger impact
191 2014-07-26 06:13:36 <phantomcircuit> it's a bit silly
192 2014-07-26 06:14:04 <wumpus> in the current implementations they are, although it's not clear they will always be
193 2014-07-26 06:14:31 <gmaxwell> due to varrious overheads they're responsible for a non-trivial amount of memory already.
194 2014-07-26 06:15:53 <phantomcircuit> wumpus, at the very least they will probably always been in the page cache
195 2014-07-26 06:16:09 <wumpus> could be...
196 2014-07-26 06:16:22 <gmaxwell> in any case, kinda optimization without a point.
197 2014-07-26 06:16:27 <wumpus> exactly
198 2014-07-26 06:16:49 <wumpus> ideally, optmization starts with profiling to find out where the problems are
199 2014-07-26 06:17:29 <gmaxwell> I could see bundling them for the anti-flooding, but thats another pinning thing which we don't like. (in particular because it helps confuse people about the security model, and waste everyone's time with misguided proposals)
200 2014-07-26 06:17:34 <phantomcircuit> for spv clients currently the bottleneck is getting headers
201 2014-07-26 06:17:39 <phantomcircuit> which is dominated by latency
202 2014-07-26 06:17:51 <gmaxwell> phantomcircuit: yes, sure, different argument for a spv client.
203 2014-07-26 06:19:04 <wumpus> phantomcircuit: spv clients already optimize for that
204 2014-07-26 06:19:23 <wumpus> phantomcircuit: for example, by hardcoding a list of block hashes, and requesting only headers from the point that the wallet was born
205 2014-07-26 06:19:39 <wumpus> or the approximate point
206 2014-07-26 06:20:15 <wumpus> the constraints for mobile SPV wallets are just very different
207 2014-07-26 14:22:11 <jgarzik> sipa, gmaxwell, cfields: ping RE https://github.com/bitcoin/bitcoin/pull/4332
208 2014-07-26 14:22:38 <jgarzik> One of bitcoin-tx goals is to provide a usable example for library-ification
209 2014-07-26 14:22:49 <sipa> jgarzik: will review this weekend
210 2014-07-26 14:26:23 <Luke-Jr> I suppose we're not far enough along that it could have its own independent repo
211 2014-07-26 14:26:43 <Luke-Jr> (library-ification)
212 2014-07-26 14:26:50 <sipa> one step at a time :)
213 2014-07-26 14:27:42 <Luke-Jr> actually… I wonder if it's possible to make it so people can just git clone dependent programs inside the BCCore root?
214 2014-07-26 14:27:48 <Luke-Jr> ie, get automake to scan subdirectories
215 2014-07-26 14:38:51 <cfields> jgarzik: pong
216 2014-07-26 14:40:19 <cfields> wumpus: ping re pull-tester stuff
217 2014-07-26 14:42:02 <cfields> sipa: thanks for getting those PRs in quickly, that helps a bunch to cut down on forked crap i have to keep up with
218 2014-07-26 14:43:39 <Luke-Jr> cfields: thoughts on scanning subdirectories for other projects?
219 2014-07-26 14:44:22 <cfields> Luke-Jr: if we're talking about the same thing, see the libsecp256k1 PR as an example