1 2015-03-01 00:02:50 <phantomcircuit> maaku, ok so i obviously hadn't thought about the incentive to reorg that deep
2 2015-03-01 00:03:08 <phantomcircuit> im 99% sure nobody would actually do it for a number of reasons but that's not good enough
3 2015-03-01 00:03:41 <phantomcircuit> horray review
4 2015-03-01 01:03:38 <sipa> phantomcircuit: the plan i had for replacing checkpoints was looking at (workbesttipontopofblock - workblock) / hashrateattip
5 2015-03-01 01:04:01 <sipa> phantomcircuit: effectively looking at equivalent days necessary to remine the blocks on top, at current speed
6 2015-03-01 01:04:13 <sipa> if that's high enough, skip
7 2015-03-01 01:14:07 <phantomcircuit> sipa, workbesttipontopofblock = work_best_top_on_top_of_block ?
8 2015-03-01 01:14:54 <SwedFTP> Has anyone seen http://lightning.network/lightning-network.pdf?
9 2015-03-01 01:16:17 <phantomcircuit> SwedFTP, #bitcoin-wizards might be better for that
10 2015-03-01 01:17:30 <SwedFTP> phantomcircuit, just got recomended to come here, and now I'll be stikcying that channel as well, thank you.
11 2015-03-01 01:17:36 <SwedFTP> stickying*
12 2015-03-01 01:19:42 <phantomcircuit> sipa, there's a few issues with that i think, the first being that you can only measure network hashrate over time
13 2015-03-01 01:20:31 <phantomcircuit> im willing to bet that using "days of current hashrate to reverse" would be very similar to a block count which is some multiple of reorg targets
14 2015-03-01 01:20:41 <phantomcircuit> hmm no it wouldn't
15 2015-03-01 01:20:43 <phantomcircuit> derp
16 2015-03-01 01:22:21 <phantomcircuit> sipa, it would however be equal to "work for tip"
17 2015-03-01 01:24:32 <phantomcircuit> sipa, as maaku pointed out it *does* change the security model and incentives
18 2015-03-01 02:30:50 <luktgf> +
19 2015-03-01 02:31:13 <luktgf> //\
20 2015-03-01 03:16:03 <phantomcircuit> sipa, hmm
21 2015-03-01 03:16:09 <phantomcircuit> is there any easy way to detect a fork
22 2015-03-01 03:16:36 <phroziac> watching block counts from different sources?
23 2015-03-01 03:17:12 <phantomcircuit> phroziac, well yes i meant with current bitcoind code
24 2015-03-01 03:17:32 <phroziac> ah
25 2015-03-01 03:44:11 <phantomcircuit> Luke-Jr, did you see maaku's comments above?
26 2015-03-01 03:44:13 <phantomcircuit> any thoughts
27 2015-03-01 03:46:17 <Luke-Jr> phantomcircuit: it's dangerous if most people are using this optimisation, but I think it makes sense as an optional feature
28 2015-03-01 03:46:32 <Luke-Jr> might help to disable it once IBD completes, so reorgs always require a complete check
29 2015-03-01 03:46:47 <phantomcircuit> hmm
30 2015-03-01 03:48:39 <phantomcircuit> Luke-Jr, ha but i changed the logic for IsInitialBlockDownload also
31 2015-03-01 03:49:04 <Luke-Jr> I don't mean IsInitialBlockDownload, just real IBD
32 2015-03-01 03:49:26 <Luke-Jr> ie, the first time we get up-to-date, from that point on never skip script checks again
33 2015-03-01 03:51:52 <phantomcircuit> Luke-Jr, how do you know which is which
34 2015-03-01 03:52:09 <phantomcircuit> i guess you could simply check scripts for all reorgs
35 2015-03-01 03:52:14 <phantomcircuit> common case that changes nothing
36 2015-03-01 03:52:39 <gmaxwell> the metric I'd proposed before was "if the block is in a chain which has height/work advantage of X over the next best chain whos headers you know about" but it's somewhat complex to implement.
37 2015-03-01 03:52:39 <Luke-Jr> phantomcircuit: throw a flag in the chainstate database?
38 2015-03-01 03:54:07 <gmaxwell> I don't want another optional off by default feature. Thats stuid.
39 2015-03-01 03:54:10 <gmaxwell> er stupid.
40 2015-03-01 03:54:21 <gmaxwell> The only pepole likely to turn it on are probably the ones who least should be running it.
41 2015-03-01 03:54:45 <Luke-Jr> ACTION wonders if it would be safe enough to have it on by default, and permanently disabled the first time it gets within X blocks from the end of the best chain
42 2015-03-01 03:56:14 <gmaxwell> certantly would be easier to implement than the advantage check; ... keep in mind, part of the reason to get rid of this crap is to avoid confusion over the security model; ideally best if the new optimization behavior doesn't create its own confusion.
43 2015-03-01 04:01:25 <phantomcircuit> well actually
44 2015-03-01 04:01:46 <phantomcircuit> i'll benchmark against running all the scripts also for comparison
45 2015-03-01 04:04:51 <phantomcircuit> oh
46 2015-03-01 04:05:30 <phantomcircuit> what about a single checkpoint which is performance only, ie if the block at that height is a mismatch then rewind and run the script checks
47 2015-03-01 04:08:06 <phantomcircuit> --security-model=reduced
48 2015-03-01 04:08:07 <phantomcircuit> heh
49 2015-03-01 04:08:10 <phantomcircuit> ACTION flees
50 2015-03-01 04:09:47 <phantomcircuit> ok so the benchmark for without checkpoints is
51 2015-03-01 04:09:49 <phantomcircuit> "forever"
52 2015-03-01 04:15:19 <phantomcircuit> gmaxwell, is there even a reasonable way to get the next best chain header?
53 2015-03-01 04:15:21 <phantomcircuit> tip
54 2015-03-01 04:16:54 <Luke-Jr> I suppose the ideal thing to do is make many passes, but obv much more complex
55 2015-03-01 04:17:28 <Luke-Jr> eg, first run you get SPV security, then it checks the basic block structure of the chain and builds the chainstate, and finally at the end it verifies all the scripts
56 2015-03-01 04:17:36 <gmaxwell> phantomcircuit: see how chaintips works.
57 2015-03-01 04:18:51 <phantomcircuit> Luke-Jr, except the scripts are saved in the utxo db so doing that might be stupid expensive
58 2015-03-01 04:19:07 <phantomcircuit> that would basically makes txindex=1 mandatory
59 2015-03-01 04:19:45 <Luke-Jr> not necessarily?
60 2015-03-01 04:20:46 <phantomcircuit> utxo real and utxo temp?
61 2015-03-01 04:20:59 <phantomcircuit> i guess utxo tip and utxo block height x
62 2015-03-01 04:21:05 <Luke-Jr> could do something like flag spent UTXOs rather than delete them from the chainstate
63 2015-03-01 04:21:07 <phantomcircuit> basically double utxo storage costs
64 2015-03-01 04:21:23 <Luke-Jr> (and delete them when you're making the 2nd pass)
65 2015-03-01 04:22:57 <gmaxwell> huh?! y'all are being goofy. there is nothing about the utxo involved there.
66 2015-03-01 04:23:01 <gmaxwell> you'd check _blocks_
67 2015-03-01 04:23:21 <Luke-Jr> gmaxwell: you need the scriptPubKey for the inputs to check the sigs
68 2015-03-01 04:24:04 <gmaxwell> ah thats what phantomcircuit meant by txindex=1. Indeed, that is annoying.
69 2015-03-01 04:24:04 <phantomcircuit> gmaxwell, getting the scriptPubKey for an arbitrary transaction requires either the utxo being setup for that block OR txindex=1
70 2015-03-01 04:24:35 <phantomcircuit> maybe removing checkpoints isn't such a good idea
71 2015-03-01 04:24:36 <phantomcircuit> :/
72 2015-03-01 04:25:04 <phantomcircuit> im not sure it can be done without changing the security model or introducing a massive performance issue
73 2015-03-01 04:25:46 <Luke-Jr> I think the hours-days sync time becomes a lot more bearable if we have SPV mode initially
74 2015-03-01 04:26:00 <Luke-Jr> so maybe the split verification isn't so importnat
75 2015-03-01 04:27:58 <gmaxwell> phantomcircuit: checkpoints already /fuck/ the security model, if they do anything at all. They only done in that there is an assumption that there will never be a reorg larg enough to matter.
76 2015-03-01 04:28:11 <gmaxwell> You can happily achieve that in other ways.
77 2015-03-01 04:28:21 <gmaxwell> You're over thinking things now.
78 2015-03-01 04:28:54 <gmaxwell> I also think it's a bit foolish to bring this up before we've switched to libsecp256k1; since making ecdsa 6x faster changes the tradeoffs.
79 2015-03-01 04:29:13 <gmaxwell> (which is why I hadn't already submitted that pull the moment 0.11 started :) )
80 2015-03-01 04:29:21 <phantomcircuit> gmaxwell, actually checkpoints are find *if* a reorg past them in handled correctly
81 2015-03-01 04:29:25 <phantomcircuit> which it's currently not
82 2015-03-01 04:29:34 <phantomcircuit> if it is then they're just a performance improvement
83 2015-03-01 04:30:24 <gmaxwell> I don't actually agree with maaku's complaint above, incidentally. Once you reorg past 100 blocks you start stealing people's coins no matter how much script validation is there.
84 2015-03-01 04:31:30 <gmaxwell> The argument argues for conservativism, absolutely. but by 8000 blocks you will have stolen at least a quarter million btc from users and invalidted tens of thousands of transactions. Whats another million BTC stolen from early blocks on top of that?
85 2015-03-01 04:32:38 <gmaxwell> such a reorg would never be accepted, even if it were constructed; users would in-mass run 'invalidateblock' rpc on the tip of the reorg and all that work would go poof.
86 2015-03-01 04:32:38 <phantomcircuit> gmaxwell, it's more difficult to actually profit from a double spend than it is to profit from taking control of utxo's
87 2015-03-01 04:32:51 <gmaxwell> phantomcircuit: I said _nothing_ about double spends.
88 2015-03-01 04:32:53 <phantomcircuit> they're certainly both above the threshold of theft
89 2015-03-01 04:33:28 <phantomcircuit> gmaxwell, oh you're referencing block rewards?
90 2015-03-01 04:33:37 <gmaxwell> simply reorging past 100 blocks steals coins out from under people even if you want to avoid it, without any double spending.
91 2015-03-01 04:33:46 <gmaxwell> Right, the coinbase outputs.
92 2015-03-01 04:34:20 <phantomcircuit> im actually not considering those in my threat model as any attacker who can reorg 8k blocks would receive the same coinbase reward from normal mining
93 2015-03-01 04:34:40 <gmaxwell> which is where all the bitcoins come from, you know. plus a substantial fraction of all coins circulating have inputs tracing to recent coinbase outputs.
94 2015-03-01 04:34:45 <phantomcircuit> they're harming their competition for sure
95 2015-03-01 04:34:49 <phantomcircuit> but dont directly benefit
96 2015-03-01 04:34:54 <phantomcircuit> so it's a bit more nuanced
97 2015-03-01 04:35:58 <gmaxwell> phantomcircuit: sure they do, they can go trade those coins and get them back, along with everyone elses coins. The important point is that the network cannot continue in that state. It's not possible to make a 'mostly benign 8000 block reorg'
98 2015-03-01 04:36:20 <gmaxwell> making a reorg that large must steal from lots of people even if you're trying to avoid it.
99 2015-03-01 04:36:54 <phantomcircuit> gmaxwell, yeah i certainly agree that an 8k reorg would be catastrophic
100 2015-03-01 04:37:16 <phantomcircuit> and actually would almost certainly make anything they could steal worthless
101 2015-03-01 04:37:17 <gmaxwell> also someone who can do that can alreay play out the full future of the inflation schedule; which has a much better payoff and no one cares to fix it.
102 2015-03-01 04:37:46 <gmaxwell> phantomcircuit: and easily fixed, 'invalidateblock' rpc and move on, it's not like its an attack you could repeat multiple times per week. :)
103 2015-03-01 04:37:48 <Luke-Jr> phantomcircuit: it may take time before people notice and value drops though - they could cash out before that
104 2015-03-01 04:37:53 <phantomcircuit> but that's a second order effect which im not 100% sure everybody understands
105 2015-03-01 04:38:12 <phantomcircuit> Luke-Jr, an 8k reorg would cause all the full nodes to enter panic mode i think
106 2015-03-01 04:38:13 <Luke-Jr> exchanges should probably shut down pending human intervention if they ever hit a 100 block reorg
107 2015-03-01 04:38:23 <kanzure> yep
108 2015-03-01 04:38:31 <Luke-Jr> phantomcircuit: I think "panic mode" is severely useless-ified these days?
109 2015-03-01 04:38:41 <gmaxwell> Luke-Jr: many things do.
110 2015-03-01 04:38:48 <kanzure> so i agree that the behavior should be a shutdown, but also, implementing hte correct behavior is important upfront
111 2015-03-01 04:38:50 <phantomcircuit> Luke-Jr, i dont know that one actually
112 2015-03-01 04:38:52 <kanzure> so that you are not scrambling when there's a disaster
113 2015-03-01 04:39:02 <kanzure> pushing all the work into the disaster response period is silly and wont work
114 2015-03-01 04:39:42 <phantomcircuit> kanzure, the correct behaviour for a large reorg is to shutdown
115 2015-03-01 04:39:43 <phantomcircuit> heh
116 2015-03-01 04:39:46 <gmaxwell> phantomcircuit: you follow the point I'm making about playing out the inflation schedule? right now anyone that could perform an 8k block reorg can collect 10 million btc free and clear without stealing from anyone.
117 2015-03-01 04:40:04 <phantomcircuit> gmaxwell, yeah you can essentially guarantee that all the remaining coins are yours without causing mass panic
118 2015-03-01 04:40:13 <phantomcircuit> by doing LOTS of 1-3 block reorgs
119 2015-03-01 04:40:40 <gmaxwell> phantomcircuit:f for a network node the right behavior is not to shut down but to keep running. Process no new transactions, and for wallets to show everything as unconfirmed, most likely.
120 2015-03-01 04:41:00 <kanzure> phantomcircuit: that will cause mass panic when all the mining pools vanish and shut down
121 2015-03-01 04:41:03 <gmaxwell> phantomcircuit: no because of timewarp you can collect them all right away with no reorgs.
122 2015-03-01 04:41:14 <kanzure> people will notice that they are not mining anymore
123 2015-03-01 04:41:25 <gmaxwell> well (no non-trivial reorgs, I guess. you could even let other people keep mining so long as they don't mess with your timestamps)
124 2015-03-01 04:42:10 <Luke-Jr> kanzure: passive miners are a problem anyway :p
125 2015-03-01 04:42:19 <kanzure> go on?
126 2015-03-01 04:42:23 <Luke-Jr> better for them to panic, than quietly mine a bad chain
127 2015-03-01 04:43:08 <skittylx> what is the last halving amount of bitcoin?
128 2015-03-01 04:44:02 <phantomcircuit> kanzure, not sure it would cause quite the panic your thinking of but yes it would be interesting
129 2015-03-01 04:44:14 <phantomcircuit> gmaxwell, you'd have to walk the chain back to pull that off right?
130 2015-03-01 04:44:56 <gmaxwell> phantomcircuit: you can do a timewarp without a reorg if you first fudge timestamps for two weeks.
131 2015-03-01 04:45:23 <gmaxwell> a time warp attack has to begin 'two weeks in the past' according to block timestamps.
132 2015-03-01 04:46:05 <gmaxwell> I've not actually tried that, the timewarp I did on testnet just started two weeks in the past (i.e. involved a reorg).
133 2015-03-01 04:46:13 <gmaxwell> But I'm pretty sure it would work.
134 2015-03-01 04:46:28 <phantomcircuit> hmm
135 2015-03-01 05:33:07 <cipher__> <<<<<<<so happy to be online right now
136 2015-03-01 05:34:21 <cipher__> gm all
137 2015-03-01 05:37:53 <maaku> gmaxwell: it's not just a finaicially-motivated reorg that concerns me, but an attack against bitcoin itself
138 2015-03-01 05:38:01 <maaku> to destroy confidence or value
139 2015-03-01 05:43:17 <maaku> also incidentally the "reorg steal the subsidy" is a temporary counterpoint that goes away as the subsidy decreases...
140 2015-03-01 05:46:20 <maaku> destroying bitcoin could be profitable if there is an approved bitcoin ETF and institutions willing to short it
141 2015-03-01 05:47:00 <maaku> basically I don't agree that the incentives here are understood well enough to approve such a change
142 2015-03-01 05:47:53 <maaku> (incedentally phantomcircuit, reorging past the last checkpoint is a hard fork change. it would be pedantic to verify the very last checkpoint hash)
143 2015-03-01 05:50:05 <phantomcircuit> maaku, sure but equally as much as adding a new checkpoint is a hard fork
144 2015-03-01 05:50:08 <phantomcircuit> ie not very
145 2015-03-01 05:50:58 <maaku> phantomcircuit: adding new checkpoints are soft-forks
146 2015-03-01 05:51:26 <phantomcircuit> maaku, not if there's a reorg that deep
147 2015-03-01 05:51:40 <phantomcircuit> hmm
148 2015-03-01 05:51:43 <phantomcircuit> i guess you're right
149 2015-03-01 05:51:53 <phantomcircuit> shrug
150 2015-03-01 05:52:07 <phantomcircuit> hard fork that's only triggered by a what? 40k block reorg
151 2015-03-01 05:52:13 <phantomcircuit> i think we can live with that
152 2015-03-01 05:54:04 <gmaxwell> maaku: I don't see how your argument follows. Any huge reorg achieves that goal equally well. Note that I was not saying subsidy, it invalidates all coinbase outputs and all their descendents.
153 2015-03-01 05:54:51 <gmaxwell> Meaning that any coins decended in any way from any coinbase output (e.g. fees) during the reorg are erased from the network, unrecoverable, to be doublespent whenever someone feels like it.
154 2015-03-01 05:55:55 <maaku> gmaxwell: I'm talking about an attack on the confidence of the system
155 2015-03-01 05:56:15 <maaku> e.g. I take on a highly leveraged naked short of the bitcoin ETF, worth many times the bitcoin market cap, and in conjuction with an unscrupulous >50% cartel do a massive reorg followed by PR blitz to shake confidence
156 2015-03-01 05:56:26 <maaku> specifically pointing out how old those old coins are stolen
157 2015-03-01 05:56:57 <maaku> would this be likely to happen? no. but right now it would be impossible
158 2015-03-01 05:57:42 <maaku> i don't like the ideas that put a price on invalidating the accounting rules of bitcoin, even if that price is very high
159 2015-03-01 05:57:44 <gmaxwell> maaku: You're incorrect.
160 2015-03-01 05:57:47 <phantomcircuit> maaku, hate to burst your bubble but nothing about this pr makes that any more of a threat than it is today
161 2015-03-01 05:58:22 <gmaxwell> maaku: The 'short on the ETF' works just as well regardless.
162 2015-03-01 05:59:40 <maaku> gmaxwell: no you move markets by shaking confidence. "someone pulled off a massive reorg which we always told you was a possibility, and we manually invalidated that block and carried on" ...
163 2015-03-01 05:59:47 <gmaxwell> (in both cases it probably does nothing because people would 'invalidateblock' and move on, but to whatever extent you can cause harm that way, being able to invalidly spend old coins is not that substantial compared to all the other harm you can do)
164 2015-03-01 06:00:14 <maaku> ... is very different from "someone stole your funds in a way we told you was impossible, but don't worry the major miners stepped in and corrected the situation."
165 2015-03-01 06:00:52 <gmaxwell> maaku: if you can reorg at that scale you can mint yourself 10 million bitcoins out of thin air, you can steal 200,000 bitcoins from other users, and you can leave a substantial fraction of all recent transactions deeply invalidated and open to free form double spending.
166 2015-03-01 06:00:52 <phantomcircuit> maaku, lol no it's not
167 2015-03-01 06:01:00 <maaku> the latter case leaves anyone except the most technical people wondering "what? i thought bitcoin was supposed to prevent that?"
168 2015-03-01 06:01:17 <gmaxwell> maaku: whats this "major miners stepped in" crap?
169 2015-03-01 06:01:55 <maaku> gmaxwell: i'm telling you how it will play out
170 2015-03-01 06:02:08 <phantomcircuit> maaku, those two scenarios are within 1% of each other for sure
171 2015-03-01 06:02:37 <gmaxwell> maaku: You're off in some weird fantasy nitch.
172 2015-03-01 06:03:30 <gmaxwell> The gap between those two things is infintesimal, both are huge reorgs, both would be fixed in practice by users invalidateblock and moving on. Both result in huge amounts of theft from users.
173 2015-03-01 06:05:32 <gmaxwell> And you're basically arguing that instead either (a) bitcoin developers should somehow be responsible for rigging the consensus, or (b) no one should be running full nodes at all anymore. Good job. You're advocating a episilon level improvement in a case where all security assumptions are out the window at the cost of pratical reducing the security model to a complete lie because everyone is dependi
174 2015-03-01 06:05:38 <gmaxwell> ng on centeralization either because they do not run their own nodes or because they depend on effective block signing in the form of software updates.
175 2015-03-01 06:07:07 <maaku> well gmaxwell, if you're checking the logs, you should see in scrollback that I suggested waiting for a fraud proof implementation and doing probabalistic validation of history
176 2015-03-01 06:07:58 <maaku> i'm arguing against the current pull request, not the entire idea of skipping some parts of validation during sync
177 2015-03-01 10:25:36 <sipa> phantomcircuit: haven't looked at the code, but you should at least look at "number of blocks on top" and not just height difference
178 2015-03-01 10:25:50 <sipa> and yes, it does change incentive structure
179 2015-03-01 13:29:50 <bit_kevin> TangPool is now support block version 3 https://bitcointalk.org/index.php?topic=972572.0
180 2015-03-01 14:38:46 <denisx> Iâm upgraded to 0.10.0 on a quad i7 with SSD and I need ca. 15min to update per one week of missing blocks
181 2015-03-01 14:38:56 <denisx> is that expected
182 2015-03-01 14:42:09 <sipa> that's around 1s per block
183 2015-03-01 14:44:41 <sipa> sounds slowish
184 2015-03-01 14:44:46 <sipa> but not by orders of magnitude
185 2015-03-01 14:52:21 <denisx> is dbcache=1000 still advisable?
186 2015-03-01 14:52:28 <sipa> yes
187 2015-03-01 14:52:31 <denisx> ok
188 2015-03-01 14:52:49 <sipa> what os?
189 2015-03-01 14:53:02 <denisx> osx
190 2015-03-01 14:53:29 <sipa> you could try to run with -debug=bench
191 2015-03-01 14:53:41 <sipa> and look at the average times
192 2015-03-01 14:53:46 <denisx> my other machines where slow too, but they use spinning rust so I thought that is ok
193 2015-03-01 14:53:47 <sipa> would be interesting to see where time is spent
194 2015-03-01 14:54:01 <sipa> though the numbers are not relying for new blocks, due to sig caching
195 2015-03-01 14:54:17 <denisx> ok, will try
196 2015-03-01 14:54:43 <denisx> can I put debug=bench in the config file?
197 2015-03-01 14:56:28 <sipa> yes
198 2015-03-01 14:58:15 <denisx> sipa: http://pastie.org/9991616
199 2015-03-01 14:58:19 <denisx> small snippet
200 2015-03-01 14:59:47 <sipa> hmm, looks pretty reasonable
201 2015-03-01 14:59:58 <denisx> ok
202 2015-03-01 15:24:01 <earlz> So what would I need to do to ensure bitcoin-core never deletes orphan block data?
203 2015-03-01 15:25:21 <sipa> define orphan block
204 2015-03-01 15:25:34 <earlz> a block that is no longer relevant
205 2015-03-01 15:25:59 <sipa> if you mean blocks not in the main chain: those are never deleted
206 2015-03-01 15:26:09 <sipa> no block that is ever stored on disk is ever deleted
207 2015-03-01 15:26:18 <earlz> ah, I figured there was some kind of cleaning that took place with them
208 2015-03-01 15:26:21 <sipa> nope
209 2015-03-01 15:26:26 <earlz> maybe I'm thinking of orphaned transactions or something
210 2015-03-01 15:26:32 <sipa> those are just kept in ram
211 2015-03-01 15:26:43 <sipa> for a limited time
212 2015-03-01 15:27:39 <earlz> IS there any database or way to get historical orphan block data? Like some third party service ro something I guess
213 2015-03-01 15:28:00 <sipa> getchainptips RPC
214 2015-03-01 15:28:17 <sipa> in bitcoin core, since 0.10
215 2015-03-01 15:28:33 <earlz> Yea, but that only works if your node has been running over a long time and actually had a chance to collect those orphans
216 2015-03-01 15:28:37 <sipa> not sure about any centralized services
217 2015-03-01 15:29:12 <earlz> just curious to do some analysis on orphans and such. Guess I just need to run a node and wait heh
218 2015-03-01 15:33:47 <skittylx> ;;blocks
219 2015-03-01 15:33:48 <gribble> 345709
220 2015-03-01 16:24:08 <earlz> So, you can of course spend 0-confirmation transactions... Where is the circular dependency (ie, vout spent in the same block as vin, vin is vout of vin, in a circle...) checking?
221 2015-03-01 16:25:10 <Luke-Jr> earlz: they can only be in the same block if they're in order
222 2015-03-01 16:25:29 <Luke-Jr> an earlier transaction in the block can't use UTXOs created later in the block
223 2015-03-01 16:25:51 <earlz> Ah... So a tx at index 10 can't reference a tx at index 20 in the same block?
224 2015-03-01 16:29:26 <mr_burdell> earlz: there's a list of orphan blocks from one of my nodes here: http://mempool.info/orphans
225 2015-03-01 16:29:52 <mr_burdell> although, I haven't checked it in a while... it's possible my script included real blocks
226 2015-03-01 16:32:50 <sipa> earlz: correct
227 2015-03-01 19:24:54 <maaku> earlz: regardless of the accounting rules, that would be impossible due to the way hash functions work
228 2015-03-01 19:35:11 <astronotusoscar> Hi everyone, I'm going to develop service, which will be integrated with bitcoin network. I expect high load. Are there an best practices how to configure bitcoind to handle high load?
229 2015-03-01 19:36:17 <sipa> maaku: how so?
230 2015-03-01 19:40:45 <maaku> sipa: circular spends?
231 2015-03-01 19:41:58 <sipa> maaku: oh, right
232 2015-03-01 19:42:11 <sipa> i forgot what the original question was about
233 2015-03-01 22:13:45 <phantomcircuit> <sipa> phantomcircuit: haven't looked at the code, but you should at least look at "number of blocks on top" and not just height difference
234 2015-03-01 22:13:52 <phantomcircuit> im not sure what you mean by that
235 2015-03-01 22:25:41 <phantomcircuit> <sipa> phantomcircuit: haven't looked at the code, but you should at least look at "number of blocks on top" and not just height difference
236 2015-03-01 22:25:44 <phantomcircuit> im not really sure what you mean by that
237 2015-03-01 22:50:36 <orion> Hi. Do I need libgmp to run bitcoin-qt?
238 2015-03-01 22:51:12 <orion> I'm struggling to determine what I should set --with-field, --with-bignum, and --with-scalar to.
239 2015-03-01 23:26:30 <sipa> phantomcircuit: i commented on the pr as well
240 2015-03-01 23:32:48 <sipa> phantomcircuit: my point is that you should be looking at how much work there is on top of a block
241 2015-03-01 23:33:04 <sipa> phantomcircuit: not how much work difference with the best known tip