1 2014-10-12 01:26:30 <aburan28> what does BIP22,BIP23 do to address the centralized mining pool issue?
  2 2014-10-12 01:27:26 <jgarzik> aburan28, Enhances ability for end-line miners (computing service providers) to audit the mining pools ("real" miners)
  3 2014-10-12 01:28:33 <aburan28> ah I see
  4 2014-10-12 01:41:08 <Luke-Jr> aburan28: when more completely implemented, it will also enable end miners to take the pooling, and merge in their own transaction selection
  5 2014-10-12 01:53:29 <phantomcircuit> Luke-Jr, correct me if im wrong, but isn't that going to be computationally expensive for the pool?
  6 2014-10-12 01:53:41 <Luke-Jr> phantomcircuit: why would it be?
  7 2014-10-12 01:53:57 <Luke-Jr> you have to calculate the merkle root for the extranonce anyway
  8 2014-10-12 01:54:02 <phantomcircuit> have to validate that the transactions included by the miners are actually valid
  9 2014-10-12 01:54:06 <Luke-Jr> no
 10 2014-10-12 01:54:09 <Luke-Jr> don't have to
 11 2014-10-12 01:54:20 <Luke-Jr> they can already block withhold if they want to be malicious
 12 2014-10-12 01:54:30 <phantomcircuit> right im not thinking malicious
 13 2014-10-12 01:54:32 <Luke-Jr> you just need to be sure they're not playing two different pools
 14 2014-10-12 01:54:33 <phantomcircuit> just incompetent
 15 2014-10-12 01:54:52 <Luke-Jr> phantomcircuit: randomly verify transactions, you'll identify incompetence eventually
 16 2014-10-12 01:56:10 <phantomcircuit> Luke-Jr, right i guess that would be sufficient
 17 2014-10-12 02:09:49 <BlueMatt> sipa: how does headers-first interact with pruning again? if it prunes undo data past where you need a reorg, does it have proper logic to redownload that?
 18 2014-10-12 02:10:10 <BlueMatt> ;;later tell sipa how does headers-first interact with pruning again? if it prunes undo data past where you need a reorg, does it have proper logic to redownload that?
 19 2014-10-12 02:10:10 <gribble> The operation succeeded.
 20 2014-10-12 02:13:37 <Luke-Jr> BlueMatt: does it prune? i thought that was a future PR
 21 2014-10-12 02:21:25 <phantomcircuit> oh make check is formatted now
 22 2014-10-12 02:21:27 <phantomcircuit> neat
 23 2014-10-12 02:41:42 <BlueMatt> Luke-Jr: mmm, ok
 24 2014-10-12 02:44:42 <Luke-Jr> BlueMatt: you'd probably know better than me
 25 2014-10-12 02:52:37 <BlueMatt> Luke-Jr: I havent reviewed that pull before, I was just reading it through
 26 2014-10-12 03:18:15 <rodarmor> This is peripheral to bitcoin development proper, so apologies if this isn’t the right place to post, but I’m hoping to get feedback on the idea: https://github.com/casey/beacontx
 27 2014-10-12 03:23:12 <justanotheruser> rodarmor: you have to justify that this needs to be in the blockchain
 28 2014-10-12 03:23:39 <justanotheruser> the blockchain is for distributed consesus. You have trusted authority using a trustless system.
 29 2014-10-12 03:25:12 <Luke-Jr> rodarmor: just extend the peer-to-peer protocol..
 30 2014-10-12 03:25:19 <Luke-Jr> what justanotheruser said, no need for a blockchain
 31 2014-10-12 03:25:50 <rodarmor> It uses the bitcoin blockchain, and the OP_RETURN opcode to simply embed a hash to the payload, so space use is minimal. Miners may choose to deprioritize these transactions, but they would be likely to encourage bitcoin adoption, so it would seem to be in their own interest to allow them.
 32 2014-10-12 03:26:17 <Luke-Jr> rodarmor: but there's no purpose to that
 33 2014-10-12 03:26:17 <tom99> what are those distributed companies called? DACs?
 34 2014-10-12 03:26:19 <tom99> this reminds me of that
 35 2014-10-12 03:26:23 <rodarmor> Also, by using the bitcoin blockchain itself, merchants are able to send a strong signal that they are not only WILLING to accept bitcoin transactions, but ABLE to.
 36 2014-10-12 03:27:18 <rodarmor> I personally have been hesitant to try to pay with bitcoin because I didn’t want to get some random employee that had no idea what bitcoin was. This sends a timely signal that bitcoin CAN be accepted by a business, in a way that something that did not use the blockchain could not.
 37 2014-10-12 03:27:54 <justanotheruser> rodarmor: the "bitcoin accepted here" stickers also do that
 38 2014-10-12 03:28:16 <Luke-Jr> rodarmor: that makes no sense at all
 39 2014-10-12 03:28:52 <devthedev> Do all merchants who use Square's terminal have the ability to accept Bitcoin?
 40 2014-10-12 03:28:55 <rodarmor> Luke-Jr: Why? It happens a lot that the owner of a business decides to accept bitcoin without properly training the employees.
 41 2014-10-12 03:29:20 <Luke-Jr> rodarmor: and?
 42 2014-10-12 03:30:27 <rodarmor> Luke-Jr: Sorry, I was responding to the comment that a bitcoin sticker indicates that a business is set up properly to accept transactiosn. What where you referring to when you said “that makes no sense at all"?
 43 2014-10-12 03:31:02 <Luke-Jr> rodarmor: your apparently claim that throwing a hash in the blockchain is going to somehow change that
 44 2014-10-12 03:33:09 <rodarmor> Luke-Jr: Yes, I actually do. If beacons are timely, in that old beacons are deprioritized by end-user search providers, then a beacon, which is a bitcoin transaction, would seem to provide a good signal that the originator had a functioning wallet connected to the network. Especially if the convention is that beacons themselves are meant to indicate that bitcoin is accepted, it would be counter-productive for a merchant who is
 45 2014-10-12 03:33:09 <rodarmor> set up to properly process bitcoin transactions to send one.
 46 2014-10-12 03:33:35 <Luke-Jr> rodarmor: still no need for a blockchain
 47 2014-10-12 03:35:49 <_W_> rodarmor: furthermore, it in no way stops a business from having untrained employees
 48 2014-10-12 03:35:56 <rodarmor> The bitcoin blockchain is by definition accessible to the target customer base, it provides an anti-spam mechanism which is extremely valuable for this application, and the application uses OP_RETURN, and so is as good a citizen as possible.
 49 2014-10-12 03:36:21 <rodarmor> _W_: I agree, it is not an iron clad guarantee, but a useful heuristic.
 50 2014-10-12 03:37:18 <rodarmor> If blockchain bloat or transaction volume is an issue, then transactions could be referenced by a level of indiraction. A hash to a list of hashes could be stored in the block chain, to be retrieved by some known mechanism.
 51 2014-10-12 03:37:19 <_W_> I don't think it's even that
 52 2014-10-12 03:39:16 <rodarmor> _W_: Really? I respectfully disagree. If beacons that are more than 24 hours are considered to be “stale”, then a beacon sent in the last 24 hours would seem to be a good signal. It indicates that it is likely that someone at the business has a functioning device which is connected to the network, and that they had bitcoin to pay the transaction fee. This would seem to me to be an excellent signal.
 53 2014-10-12 03:40:25 <Luke-Jr> rodarmor: what purpose is there to storing it in the blockchain? i see none
 54 2014-10-12 03:42:43 <rodarmor> Luke-Jr: It provides a known discovery method, there is an anti-spam mechanism, and it provides the heuristic the originator is set up to receive transactions. What other storage mechanism would acheive that?
 55 2014-10-12 03:43:10 <kyuupichan> With commit 69aa Gavin bumped protocol version from 70001 to 70002 with no comment other than "bump protocol version".  What was the motivation and what is the difference between the two protocol versions please?
 56 2014-10-12 03:43:13 <Luke-Jr> rodarmor: you're talking about temporary messages. it doesn't need storage.
 57 2014-10-12 03:43:41 <Luke-Jr> rodarmor: furthermore, the blockchain is not a storage system, it is a consensus system
 58 2014-10-12 03:44:51 <rodarmor> Luke-Jr: While that may be true, I think it is likely that miners would consent to mine transactions which are likely to be beneficial to the adoption of the currency, so while it might not be a “pure” use of the system, it is likely to be a positive one.
 59 2014-10-12 03:45:06 <Luke-Jr> rodarmor: no, it is useless
 60 2014-10-12 03:45:22 <Luke-Jr> rodarmor: just broadcast the messages over the p2p network like alerts
 61 2014-10-12 03:45:31 <Luke-Jr> or like the ancient Bitcoin market system
 62 2014-10-12 03:45:35 <rodarmor> What about spam and timestamping?
 63 2014-10-12 03:47:39 <Luke-Jr> rodarmor: same as transaction relaying
 64 2014-10-12 03:47:56 <Luke-Jr> these don't need timestamps
 65 2014-10-12 03:48:08 <Luke-Jr> at least not cryptographically provable ones
 66 2014-10-12 03:48:41 <rodarmor> Luke-Jr: I would disagree. Almost all goods and services are provided during a given duration. Having a timestamp is useful. Having a cryptographically provable one is a bonus.
 67 2014-10-12 03:49:10 <BlueMatt> bitcoin timestamps are very far from cryptographically provable, to be pedantic
 68 2014-10-12 03:49:38 <rodarmor> BlueMatt: Right, but they are definitely more than adaquate for this purpose.
 69 2014-10-12 03:49:56 <Luke-Jr> rodarmor: nonsense, you're talking about high precision timestamps
 70 2014-10-12 03:50:11 <Luke-Jr> bitcoin's block timestamps are only remotely adequate for low precision
 71 2014-10-12 03:50:34 <rodarmor> Luke-Jr: What precision do block timestamps have?
 72 2014-10-12 03:51:02 <Luke-Jr> rodarmor: +/- 3 hours on average
 73 2014-10-12 03:51:12 <Luke-Jr> actually, more like 4 hours
 74 2014-10-12 03:52:09 <rodarmor> Luke-Jr: If beacon payloads contain their own expiration time, then low precision is okay. Simply proof of having been published some time in the past is sufficient.
 75 2014-10-12 03:52:57 <Luke-Jr> sigh
 76 2014-10-12 03:54:47 <Luke-Jr> fine, do it. and we'll ask everyone to not use it. and everyone will ignore us. and we end up with yet another system built on top of bitcoin poorly.
 77 2014-10-12 03:55:07 <christophe> This sounds like the kind of thing that works just fine in a centralized fashion.
 78 2014-10-12 03:55:31 <rodarmor> christophe: What about censorship?
 79 2014-10-12 03:56:15 <christophe> If merchants accepting bitcoin have to worry about censorship, they'll also have to worry about advertising they accept bitcoin in the first place, no?
 80 2014-10-12 03:56:27 <Mutsumi> Luke-Jr, then is there a reference for something done 'right?'
 81 2014-10-12 03:56:29 <christophe> What's your threat model?
 82 2014-10-12 03:57:01 <Luke-Jr> rodarmor: Bitcoin is not censorship-resistent anyway.
 83 2014-10-12 03:57:21 <christophe> Mutsumi: putting the height in the coinbase would be at the other extreme: very useful (for the network itself), no extra space taken.
 84 2014-10-12 03:57:29 <Luke-Jr> Mutsumi: as I suggested to him earlier, the alert system and the old Bitcoin market would be decent references for conceptd
 85 2014-10-12 03:57:48 <rodarmor> christophe: The threat model is that bitcoin is legal, but, for example, explicit but legal adult services are discouraged on popular review sites to appeas morals. Or that bitcoin is legal, but other things aren’t.
 86 2014-10-12 03:58:31 <christophe> I think you have a solution looking for a problem, as they say.
 87 2014-10-12 03:59:05 <rodarmor> Luke-Jr: I’m would definitely rather not introduce something that isn’t beneficial for the bitcoin ecosystem in general. So lets’s assume that indirect lists of hashes are used to avoid transaction and storage bloat.
 88 2014-10-12 03:59:09 <Luke-Jr> rodarmor: this sounds more like you want a censorship-resistent network.
 89 2014-10-12 03:59:24 <rodarmor> Luke-Jr: What’s an alternate mechanism for spam control?
 90 2014-10-12 03:59:47 <Luke-Jr> rodarmor: hashcash?
 91 2014-10-12 04:00:00 <christophe> Why do you need spam control anyway (beyond avoiding DOS attacks)?
 92 2014-10-12 04:00:26 <christophe> A simple flood-fill ephemeral storage network would work fine.
 93 2014-10-12 04:00:28 <rodarmor> christophe: Just because anything that allows for advertising goods and services is a natural target for spam.
 94 2014-10-12 04:00:38 <rodarmor> Luke-Jr: That is actually not a bad idea. How does the hash-cash difficulty target adjust?
 95 2014-10-12 04:01:05 <rodarmor> Luke-Jr: Computers will become more or less powerful, so we need some kind of mechanism for setting the difficulty.
 96 2014-10-12 04:01:20 <christophe> But it's not advertising goods and services directly, it just provides the ability to associate a business name/address with (actually accepts bitcoin).
 97 2014-10-12 04:01:47 <christophe> No humans actually looking at any of the entries.
 98 2014-10-12 04:02:36 <Luke-Jr> a better question is how you prove the location actually exists and accepts bitcoin
 99 2014-10-12 04:02:58 <rodarmor> christophe: business, name, address, and description. Entries are retrieved by end-users from third-party search providers. All data is stored by hash, so end-users can verify the content of the listings for themselves. Third-party search providers compete to provide the best service, and probably spider each other for all the payloads.
100 2014-10-12 04:03:06 <rodarmor> Luke-Jr: You don’t. Heuristic only, but a good one.
101 2014-10-12 04:03:43 <rodarmor> Luke-Jr: As long as it is counter-productive to make up a fake location or one that doesn’t actually accept bitcoin, everyone is incentivized to get the desired outcome.
102 2014-10-12 04:03:58 <christophe> Dedupping can easily be the problem of the search provider. Also doesn't really fix the censorship problem.
103 2014-10-12 04:04:53 <Luke-Jr> filling a map with phony information is a form of censorship
104 2014-10-12 04:05:00 <rodarmor> christophe: Yes, it does. Because the origin hashes are stored in a decentralized universally accessible fashion, anyone can run a search provider and have access to all the data. I could probably write a google app engine app that provides a good user experience with a limited amount of resources.
105 2014-10-12 04:05:35 <rodarmor> Luke-Jr: This is true, but it would be an expensive attack, as users increase the minimum tx fee to show up in searches and legit merchents up their beacon tx fees.
106 2014-10-12 04:05:37 <christophe> How do I, search provider XYZ, prove I'm not censoring stuff out before sending you the results?
107 2014-10-12 04:06:20 <rodarmor> christophe: Beacuse all the data is user accessible, users can run their own search engines entirely locally, based on open source code.
108 2014-10-12 04:06:37 <rodarmor> christophe: Same trust model for the bitcoin core.
109 2014-10-12 04:06:50 <Luke-Jr> rodarmor: so it also expels the smaller businesses in preference for big business
110 2014-10-12 04:08:12 <rodarmor> Luke-Jr: Well, I suppose that’s how advertising in general works. Big business can buy bigger soap boxes. However individual search providers could also provide the ability to down-vote individual beacons, and thus de-proritize spammy listings that drown out good ones.
111 2014-10-12 04:08:35 <Luke-Jr> lol
112 2014-10-12 04:08:51 <Luke-Jr> aka censorship
113 2014-10-12 04:09:36 <rodarmor> Luke-Jr: Censorship by a non-privilaged third party that competes for users by curating publically accessible data to provide a good user experience may be censorship, but it doesn’t keep me up at night.
114 2014-10-12 04:10:19 <Luke-Jr> rodarmor: sounds like you can just make an open source web platform
115 2014-10-12 04:10:37 <Luke-Jr> or phone app
116 2014-10-12 04:11:06 <Luke-Jr> doesn't need the bitcoin infrastructure at all
117 2014-10-12 04:12:43 <rodarmor> Luke-Jr: So I can see how hashcash might be used to deprioritize spam, and I understand that one might question the usefuless of the i-really-accept-bitcoin heuristic, but what about decentralized storage and discovery?
118 2014-10-12 04:12:56 <rodarmor> Luke-Jr: Actually, I can kind of see how it might work. It
119 2014-10-12 04:13:24 <rodarmor> ’s like a hash-cash difficulty prioritized mempool that anyone can connect to.
120 2014-10-12 04:13:32 <kanzure> there are already other implementations of local search nodes
121 2014-10-12 04:13:36 <Luke-Jr> rodarmor: Bitcoin doesn't do decentralised storage, so you'll have to find something that does
122 2014-10-12 04:13:48 <kanzure> that too
123 2014-10-12 04:14:26 <rodarmor> Luke-Jr: Leaving aside intellectual purity for a moment, and assuming that it used a list-of-hashes design, would there be a negative impact on the bitcoin ecosystem?
124 2014-10-12 04:14:40 <kanzure> leaving aside all reason?
125 2014-10-12 04:15:01 <rodarmor> kanzure: just some reason
126 2014-10-12 04:15:17 <rodarmor> And please feel free to tell me to drop it, I certainly don’t want to waste anyone’s time.
127 2014-10-12 04:15:24 <Luke-Jr> rodarmor: Bitcoin doesn't do decentralised storage.
128 2014-10-12 04:16:04 <rodarmor> Luke-Jr: I understand that it might not be the direct intent of bitcoin to do decentralized storage, but it does “do” it, for some definition of decentralized storage.
129 2014-10-12 04:16:16 <kanzure> yes if you weaken your definitions anything can be anything
130 2014-10-12 04:16:25 <kanzure> but that's neither surprising or useful
131 2014-10-12 04:17:44 <rodarmor> kanzure: This is true. And you don’t think the bitcoin-merchant heuristic, while imperfect, might be of practical usfulness?
132 2014-10-12 04:19:16 <rodarmor> kanzure: I’m kind of seeing how a priotizied ephemeral mempool might work, so it might be a better implementation for practical reasons.
133 2014-10-12 04:20:50 <rodarmor> kanzure: Even if messages are ephemeral, then they can contain hashes of other messages, which establishes what might be a rough kind of ordering. Unlike the bitcoin block-chain there is no descent from a common ancestor, but perhaps that isn’t importantt for this application.
134 2014-10-12 04:21:10 <kanzure> i'm not going to design your application for you.
135 2014-10-12 04:22:09 <rodarmor> kanzure: I’m making a friendly request for comment on an alternative to an original suggestion that you didn’t approve of :–)
136 2014-10-12 04:22:45 <kanzure> where did i express disapproval. i intended to, but if you look, i didn't.
137 2014-10-12 04:23:20 <rodarmor> kanzure: That’s true, I apologize.
138 2014-10-12 04:30:57 <rodarmor> Anyways, it’s my bedtime. Thank you very much for the well reasoned argument!
139 2014-10-12 04:31:42 <rodarmor> (I updated the readme on github with a note at the top, so hopefully nobody implements something stupid while I’m asleep, but you never know these days.)
140 2014-10-12 04:53:56 <sipa> BlueMatt: merging pruning and headersfirst will be nontrivial
141 2014-10-12 04:56:08 <Luke-Jr> sipa: oh, if it's already non-trivial can I go ahead and push to merge proposals first? :P
142 2014-10-12 05:00:34 <johnnygoode_> I'm having a bit of trouble getting started on bitcoinj. Can I get a helping hand?
143 2014-10-12 05:21:10 <Luke-Jr> hm
144 2014-10-12 05:21:42 <Luke-Jr> I wonder if we ought to be noticing equal-height forked chains, and giving their transactions similar treatment as reorg'd ones, before the reorg
145 2014-10-12 05:22:11 <Luke-Jr> (equal-work really)
146 2014-10-12 05:26:29 <phantomcircuit> Luke-Jr, yes but that would be difficult and requires changes to the p2p protocol
147 2014-10-12 05:26:43 <sipa> huh
148 2014-10-12 05:26:49 <sipa> he just means in the wallet, i presume
149 2014-10-12 05:27:33 <Luke-Jr> sipa: no
150 2014-10-12 05:27:52 <Luke-Jr> sipa: right now, when we reorg, we take the transactions being removed from the now-dead blocks and put them in the mempool ignoring (some) policy
151 2014-10-12 05:28:02 <Luke-Jr> we should treat forked chains similarly IMO
152 2014-10-12 05:28:35 <earlz> So, what does the "true" second argument to `getblock` actually do?
153 2014-10-12 05:28:45 <sipa> earlz: decode the block or something
154 2014-10-12 05:28:53 <Luke-Jr> earlz: contrast it with false
155 2014-10-12 05:29:38 <earlz> On some older altcoins, I see it gives a full summary of the block including the equivalent of `getrawtransaction ..  1` of each tx in the block... but I don't see that on bitcoin itself, at least not the newest version
156 2014-10-12 05:29:56 <earlz> weird..
157 2014-10-12 05:30:00 <earlz> it's true by default
158 2014-10-12 05:30:07 <earlz> altcoins are weird I guess
159 2014-10-12 05:30:20 <sipa> read the documentation :)
160 2014-10-12 05:30:52 <earlz> so there is no equivalent to the altcoin behavior then? It's be really nice to get all info about all transactions in a block in one call
161 2014-10-12 05:30:53 <gwillen> Luke-Jr: the goal being to reduce the chance to double-spend against them by trying to keep the two branches in sync?
162 2014-10-12 05:31:12 <sipa> earlz: use batched json-rpc :)
163 2014-10-12 05:31:14 <Luke-Jr> gwillen: right
164 2014-10-12 05:31:20 <gwillen> 
ACTION nods

165 2014-10-12 05:31:35 <earlz> ugh... I need to get an API that actually supports batching
166 2014-10-12 05:31:49 <sipa> bitcoind does since ages
167 2014-10-12 05:32:10 <earlz> well I mean my client api
168 2014-10-12 05:32:26 <earlz> Currently using a huge hackjob of an api for C#
169 2014-10-12 05:34:04 <earlz> terrible http://sourceforge.net/p/bitnet/code/HEAD/tree/trunk/
170 2014-10-12 05:35:31 <earlz> probably have to mostly writ eit custom to do proper batching
171 2014-10-12 05:35:52 <sipa> you're better off spending that time on an RPC that just returns all transactions :p
172 2014-10-12 05:36:08 <phantomcircuit> sipa, you cant do that
173 2014-10-12 05:36:17 <sipa> phantomcircuit: for 1 block
174 2014-10-12 05:36:20 <phantomcircuit> oh
175 2014-10-12 05:36:24 <phantomcircuit> yeah i did that before
176 2014-10-12 05:36:30 <sipa> but if you really need to process all transactions, you should use the p2p protocol
177 2014-10-12 05:36:45 <earlz> I still petition for a `getblockbynumber` rpc call, even if orphans make it confusing
178 2014-10-12 05:36:55 <phantomcircuit> sipa, but then you cant leverage the bitcoin core script template matcher
179 2014-10-12 05:55:51 <lechuga_> earlz: getblockhash+getblock
180 2014-10-12 06:06:36 <earlz> lechuga_: less calls though :(
181 2014-10-12 06:07:07 <earlz> There's no way to even batch that shit away
182 2014-10-12 06:56:09 <wumpus> earlz: there is in phase 1 batch all the getblockhash calls, in batch 2 batch all the getblock calls, or get the blocks directly as linearize.py does
183 2014-10-12 06:56:50 <wumpus> earlz: see https://github.com/bitcoin/bitcoin/blob/master/contrib/linearize/linearize-hashes.py
184 2014-10-12 07:13:16 <phantomcircuit> earlz, write yourself a getblockhashes rpc call
185 2014-10-12 07:13:21 <phantomcircuit> you will save a bunch of time
186 2014-10-12 07:18:57 <Luke-Jr> phantomcircuit: or just batch it
187 2014-10-12 07:22:48 <wumpus> what would the advantage of a getblockhashes be over RPC batching?!
188 2014-10-12 07:23:46 <earlz> yea I'm curious about that too
189 2014-10-12 07:24:34 <earlz> I think getblockbynumber and then combining that with batching would be really awesome, but failing that, the two step hash then data batching wumpus described sounds decent
190 2014-10-12 07:24:52 <phantomcircuit> wumpus, it's about 100x faster
191 2014-10-12 07:24:56 <phantomcircuit> no really
192 2014-10-12 07:24:57 <phantomcircuit> :/
193 2014-10-12 07:25:09 <earlz> If you query the RPC interface using json-rpc 2.0 is there any difference on the daemon?
194 2014-10-12 07:25:19 <earlz> does it even diffentiate between 1.0 and 2.0?
195 2014-10-12 07:25:26 <wumpus> phantomcircuit: I already got a 30x speedup from separate getblockhash RPC calls to RPC batching
196 2014-10-12 07:25:34 <earlz> Only reason I could think it to be faster is locking
197 2014-10-12 07:25:35 <wumpus> phantomcircuit: it's fast enough
198 2014-10-12 07:25:52 <earlz> if getblockhash requires a lock
199 2014-10-12 07:26:38 <wumpus> here: https://github.com/bitcoin/bitcoin/pull/5050
200 2014-10-12 07:26:40 <earlz> My block explorer is havign to deal with ancient altcoins as well. Anyone know off hand when batching was added to the daemon?
201 2014-10-12 07:26:46 <phantomcircuit> wumpus, the more important one is modifying getblock to return the decoded transactions also
202 2014-10-12 07:26:47 <wumpus> gets all the hashes in 10 seconds
203 2014-10-12 07:26:56 <phantomcircuit> the getrawtransaction calls take forevah
204 2014-10-12 07:27:20 <earlz> that they do
205 2014-10-12 07:27:44 <wumpus> best to get the raw blocks and parse them yourself, it's pretty easy
206 2014-10-12 07:28:06 <earlz> that's why I wish you could in-place expand the block data to include transaction data
207 2014-10-12 07:28:14 <wumpus> that *explodes* the amount of data going through RPC
208 2014-10-12 07:28:25 <earlz> ugh parsing adds a whole other layer of complexity
209 2014-10-12 07:28:25 <phantomcircuit> wumpus, easier to leverage the rpc stuff for script template matching
210 2014-10-12 07:29:07 <wumpus> phantomcircuit: I've found python-bitcoinlib to be great for doing that locally
211 2014-10-12 07:29:08 <earlz> How many libraries are capable of fully parsing scripts? Most of the ones I know of can only parse the most common opcodes
212 2014-10-12 07:30:51 <wizardofozzie> Earlz; you'll need to customize
213 2014-10-12 07:31:43 <wizardofozzie> Use Python 2.7 with bitcointools that Gavin made and tailor it with a few extras.
214 2014-10-12 07:33:55 <phantomcircuit> wumpus, shrug
215 2014-10-12 07:34:09 <phantomcircuit> i agree in principle, but i just find the rpc call to be easier
216 2014-10-12 07:34:13 <phantomcircuit> and i have patience
217 2014-10-12 07:34:23 <phantomcircuit> (and 10 bitcoind instances to load balance over...)
218 2014-10-12 08:02:19 <wumpus> earlz: python-bitcoinlib can do it all
219 2014-10-12 08:02:56 <wumpus> https://github.com/petertodd/python-bitcoinlib
220 2014-10-12 08:03:06 <earlz> language barrier of not wanting to use python though :/
221 2014-10-12 08:10:07 <wumpus> that's just stubbornness :)
222 2014-10-12 08:12:41 <Luke-Jr> sanity* <.<
223 2014-10-12 12:31:38 <jgarzik> "Right now a complete sync for me with headers first takes one hour to get to height 295k (*) which is as far as bootstrap.dat goes. You can easily spend that much time on just the download."
224 2014-10-12 12:31:47 <jgarzik> gmaxwell, ITYM checkpoint, not bootstrap
225 2014-10-12 12:31:55 <jgarzik> current bootstrap goes to 317k
226 2014-10-12 14:15:07 <michagogo> 
ACTION pokes jgarzik

227 2014-10-12 14:15:19 <jgarzik> michagogo, ?
228 2014-10-12 14:15:37 <michagogo> 17:14:19 <michagogo> Any idea if there's a way to seed a torrent from a compressed file?
229 2014-10-12 14:16:17 <jgarzik> michagogo, You mean, send out uncompressed data, yet store as compressed data?  Interesting idea, but haven't heard of anyone doing that.
230 2014-10-12 14:16:30 <michagogo> jgarzik: that's exactly what I mean
231 2014-10-12 14:16:50 <jgarzik> of course, I'm into looped into the latest from the bittorrent scene
232 2014-10-12 14:17:36 <michagogo> (running a main and test nodes, plus seeding bootstrap, on something like 50-60GB of storage, so I'm bumping up against the limit frequently)
233 2014-10-12 14:21:59 <Emcy> its obviously doable
234 2014-10-12 14:22:02 <wumpus> bittorrent requires random access within a file, so at least in the naive striaightforward way it wouldn't work - you could maybe serve the torrent from a compressed file system?
235 2014-10-12 14:22:09 <Emcy> dont know if anyone is doing though
236 2014-10-12 14:23:00 <wumpus> (squashfs, for example)
237 2014-10-12 14:23:30 <Emcy> bootstrap torrent seems dead anyway
238 2014-10-12 14:23:38 <michagogo> wumpus: why wouldn't it work? Is it impossible to seek within a compressed file?
239 2014-10-12 14:24:30 <wumpus> michagogo: just very inefficient in  the general case
240 2014-10-12 14:24:58 <DanMAbraham> michagogo!
241 2014-10-12 14:24:59 <DanMAbraham> :p
242 2014-10-12 14:25:01 <DanMAbraham> I LIKE YOUR NAME
243 2014-10-12 14:25:09 <michagogo> DanMAbraham: uhm.
244 2014-10-12 14:25:12 <michagogo> thanks, I guess?
245 2014-10-12 14:25:52 <DanMAbraham> 
ACTION is moarr

246 2014-10-12 14:25:55 <Emcy> s-senpai noticed you michagogo
247 2014-10-12 14:25:58 <DanMAbraham> moarrr
248 2014-10-12 14:26:06 <michagogo> Emcy: uh, what?
249 2014-10-12 14:26:10 <michagogo> DanMAbraham: ah, hi
250 2014-10-12 14:26:25 <Emcy> lol
251 2014-10-12 14:27:25 <moarrr> looks like 4 channels banned me
252 2014-10-12 14:27:35 <michagogo> moarrr: ban evasion is bad
253 2014-10-12 14:27:40 <michagogo> Emcy: seriously, wth?
254 2014-10-12 14:27:42 <moarrr> #vim #dogecoin #mysql ##linux
255 2014-10-12 14:27:52 <moarrr> michagogo: haha, evasion? i cant even change my nick
256 2014-10-12 14:27:55 <moarrr> i didnt try and evade anything
257 2014-10-12 14:28:01 <moarrr> but yeh, those channels are idiots
258 2014-10-12 14:28:05 <moarrr> i think dogecoin is bullshit too