1 2012-11-16 00:00:33 <phantomcircuit> ok well first step
 2 2012-11-16 00:00:40 <phantomcircuit> reverse the banned and maxconnections check
 3 2012-11-16 00:00:42 <phantomcircuit> heh
 4 2012-11-16 00:04:10 <sipa> interesting: even with signature caching, ~ 1/2 of the time spent in CreateNewBlock is script validation
 5 2012-11-16 00:06:03 <Luke-Jr> sipa: like the validity check, or is it doing verification when it builds the block too?
 6 2012-11-16 00:06:26 <sipa> Luke-Jr: it does verification in both cases in current HEAD
 7 2012-11-16 00:06:39 <Luke-Jr> ugly :<
 8 2012-11-16 00:06:47 <sipa> at least one is redundant, but imho both are
 9 2012-11-16 00:07:18 <sipa> i added some benchmarking code, and disabled script verification during creation (but not during validation):
10 2012-11-16 00:07:19 <Luke-Jr> sipa: I feel safer as a miner with the final check, though I suppose it's less important when BIP 23 proposals are merged
11 2012-11-16 00:07:41 <Luke-Jr> which I just rebased and addressed your/gavin's suggestions
12 2012-11-16 00:08:03 <sipa> CreateNewBlock(): 0.004052s creation time, 0.006538s check time
13 2012-11-16 00:08:17 <Luke-Jr> otoh, miners which don't mess with the block contents might skip proposing
14 2012-11-16 00:08:33 <sipa> for a 79kB block with 224 transactions
15 2012-11-16 00:11:07 <phantomcircuit> Sleep(10);
16 2012-11-16 00:11:10 <phantomcircuit> that's ms right
17 2012-11-16 00:11:20 <sipa> yes
18 2012-11-16 00:11:29 <sipa> very clear code
19 2012-11-16 00:11:38 <sipa> sleep(10): 10s; Sleep(10): 10ms
20 2012-11-16 00:11:43 <phantomcircuit> that's actually a long time
21 2012-11-16 00:11:54 <sipa> you have no patience
22 2012-11-16 00:12:03 <phantomcircuit> hehe
23 2012-11-16 00:12:48 <sipa> Luke-Jr: there is no way a transaction with a wrong script can enter the memory pool
24 2012-11-16 00:13:14 <sipa> Luke-Jr: there are cases where the mempool contains conflicting transactions, but that is checked in any way during block construction
25 2012-11-16 00:13:30 <sipa> the fact that its scripts are valid is a static boolean property of the transaction
26 2012-11-16 00:14:34 <Luke-Jr> sipa: perhaps.
27 2012-11-16 00:14:47 <Luke-Jr> sipa: but on the off-chance my memory flips a bit, I'd rather not lose $500 for it :P
28 2012-11-16 00:14:52 <sipa> ha
29 2012-11-16 00:14:55 <phantomcircuit> how does a blockchain re-org effect the memory pool?
30 2012-11-16 00:16:04 <sipa> phantomcircuit: disconnected transactions get considered for entering the mempool; reconnected transactions are removed
31 2012-11-16 00:18:51 <sipa> Luke-Jr: calculate the chance fora bitflip times the loss, and calculate how much the extra latency of createnewblock costs you in increased stale rates :)
32 2012-11-16 00:19:23 <sipa> 788 tx:
33 2012-11-16 00:19:26 <sipa> CreateNewBlock(): 0.012756s creation time, 0.055265s check time
34 2012-11-16 00:23:01 <phantomcircuit> 0-50k in 52 seconds
35 2012-11-16 00:24:47 <Luke-Jr> sipa: I don't wait on CreateNewBlock for block changes.
36 2012-11-16 00:25:01 <phantomcircuit> sipa, i believe reducing the sleep time from 10ms to 1ms will have a measurable impact over low latency connections
37 2012-11-16 00:25:14 <phantomcircuit> ie it wont matter for most people but for some people it will
38 2012-11-16 00:26:25 <sipa> Luke-Jr: ok, calculate the loss in *fees* because of the increased latency of CreateNewBlock, vs the cost*chance of a bitflip in the wrong place
39 2012-11-16 00:26:32 <sipa> Luke-Jr: i think it's still worth it :p
40 2012-11-16 00:26:45 <Luke-Jr> what fees?
41 2012-11-16 00:26:56 <gmaxwell> exactly.
42 2012-11-16 00:27:00 <phantomcircuit> actually my singular test showed a 7% speed up with 1ms sleep over a <1ms latency network
43 2012-11-16 00:27:30 <sipa> gmaxwell: exactly what?
44 2012-11-16 00:28:06 <stamit> exactly = giving you positive pats to think of him as a friend
45 2012-11-16 00:28:23 <gmaxwell> ah, you're arguing for not checking. meh.
46 2012-11-16 00:28:54 <Luke-Jr> sipa: anyhow, like I said, no argument from me when proposals are supported
47 2012-11-16 00:28:58 <phantomcircuit> is there already a map of the ip a node is connected with so i dont have to count multiple connections?
48 2012-11-16 00:29:00 <Luke-Jr> then you get the best of both
49 2012-11-16 00:29:02 <gmaxwell> sipa: that latency of GBT can be hidden by mining an empty block for the first call after a new block.
50 2012-11-16 00:29:33 <gmaxwell> sipa: all you lose is fees with very low odds and fees are currently non-existant.
51 2012-11-16 00:29:33 <sipa> gmaxwell: resulting in less fees
52 2012-11-16 00:30:11 <gmaxwell> You're probably right that a straight expected value analysis favors not checking.
53 2012-11-16 00:30:28 <gmaxwell> Though good thing we don't apply it generally, as there would be no rule enforcement. :P
54 2012-11-16 00:30:36 <phantomcircuit> he's technically right
55 2012-11-16 00:30:37 <sipa> haha
56 2012-11-16 00:30:40 <Eliel> well, ideally, you shouldn't have any transactions to put in the block right after one is found :P
57 2012-11-16 00:30:40 <phantomcircuit> the best kind of right
58 2012-11-16 00:30:44 <Luke-Jr> sipa: FWIW, I added the block check because we started to change the block assembly code.
59 2012-11-16 00:30:53 <Luke-Jr> sipa: the main idea is to avoid any new bugs from losing $
60 2012-11-16 00:31:16 <gmaxwell> The only time it really matters if GBT is fast is right after a new block on the network, any other time being slow and checking is prudent.
61 2012-11-16 00:31:18 <Luke-Jr> and that code is still in flux
62 2012-11-16 00:32:17 <sipa> Luke-Jr: assuming all transactions in the block come from the memory pool, I don't see how the crappiest block assembly code could result in an invalid block being accepted by a script-check-skipping validation step
63 2012-11-16 00:32:35 <gmaxwell> sipa: e.g. hit the maximum size and drop something.
64 2012-11-16 00:32:43 <gmaxwell> then you could end up with a failed dependency.
65 2012-11-16 00:32:48 <Luke-Jr> sipa: for example, putting a dependent transaction before one it depends on
66 2012-11-16 00:33:02 <sipa> Luke-Jr, gmaxwell: both your examples would be caught