1 2016-04-12 00:27:14	0|Chris_Stewart_5|instagibbs: Do you think it could be used to implement some sort of waiting mechanism in a while loop eventually? I get that looping is currently disabled but if it is brought back an OP_NOP could be useful
  2 2016-04-12 00:28:24	0|gmaxwell|no.
  3 2016-04-12 00:29:34	0|gmaxwell|Chris_Stewart_5: nops were _never_ a 'waiting' mechenism, they were explicitly added for forward extensibility.
  4 2016-04-12 00:30:50	0|Chris_Stewart_5|gmaxwell: Back to my original question then, why is OP_NOP treated differently than the other OP_NOPs, specifically why is allowed by the DISCOURAGE_UPGRADABLE_NOPS flag?
  5 2016-04-12 01:41:41	0|gmaxwell|Chris_Stewart_5: because there were already people creating them in the network.
  6 2016-04-12 05:19:42	0|Guest2012|d
  7 2016-04-12 06:25:21	0|GitHub99|[13bitcoin] 15rustyrussell opened pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (06master...06bip9-status-as-object) 02https://github.com/bitcoin/bitcoin/pull/7863
  8 2016-04-12 10:08:50	0|jonasschnelli|hmm...
  9 2016-04-12 10:09:19	0|jonasschnelli|sync_mempool() in the RPC tests does actually check the order of the transaction in the mempool
 10 2016-04-12 10:09:59	0|jonasschnelli|replacing with RBF seems to result in different orders in the mempools.
 11 2016-04-12 10:11:18	0|jonasschnelli|And sync_mempool only proceeds if the mempool set is _identical_
 12 2016-04-12 10:18:46	0|gmaxwell|A test for bitcoin core slavishly enforcing exact behavior? It couldn't be!
 13 2016-04-12 10:22:20	0|jonasschnelli|gmaxwell is right (as always). My debugging is wrong (as always).
 14 2016-04-12 10:23:34	0|sipa|those sync_* functions in the test could probably just be replaced with a ping RPC and then observing getpeerinfo until the pong returns
 15 2016-04-12 10:54:22	0|sipa|lmdb?
 16 2016-04-12 10:54:31	0|jonasschnelli|Sync from random peers in 2h and 20'.
 17 2016-04-12 10:55:08	0|jonasschnelli|Lmdb will follow now... this is just the basepoint to compare after
 18 2016-04-12 10:55:14	0|sipa|ok
 19 2016-04-12 10:55:31	0|sipa|sync from a random peer is very variable though
 20 2016-04-12 10:55:32	0|jonasschnelli|2h20' is standard --disable-debug
 21 2016-04-12 10:56:05	0|jonasschnelli|sipa: Yes. I know,... i might connect to another node in the same net for performance benchmark...
 22 2016-04-12 10:58:58	0|gmaxwell|hm. that sounds like something wrong.
 23 2016-04-12 10:59:27	0|gmaxwell|since I have numbers substantially higher on very fast hosts with gbe between them. :)
 24 2016-04-12 11:00:35	0|sipa|jonasschnelli: this test was not done over the daylight savings time switchover, right? :)
 25 2016-04-12 11:01:03	0|jonasschnelli|no. Its just a brand new server.
 26 2016-04-12 11:01:22	0|jonasschnelli|Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz
 27 2016-04-12 11:01:29	0|jonasschnelli|64GB Ram and 1gb/s SSD
 28 2016-04-12 11:01:41	0|jonasschnelli|though, RAID 1
 29 2016-04-12 11:01:51	0|sipa|how high is dbcache?
 30 2016-04-12 11:02:03	0|jonasschnelli|./src/bitcoind --dbcache=8000 --maxmempoolsize=1000
 31 2016-04-12 11:02:16	0|sipa|the disk won't matter in that case :)
 32 2016-04-12 11:02:32	0|jonasschnelli|Yes. Thats true.. maybe the log writing. :)
 33 2016-04-12 11:02:37	0|jonasschnelli|(because its so fast)
 34 2016-04-12 11:03:35	0|jonasschnelli|And the server is totally quite ("nothing" runs on it besides bitcoind)
 35 2016-04-12 11:04:24	0|sipa|quiet?
 36 2016-04-12 11:05:04	0|jonasschnelli|quite in terms of running applications
 37 2016-04-12 11:16:47	0|gmaxwell|ah 3.6GHz. okay then that translates to my best number assuming we're bottlenecked on a single core.
 38 2016-04-12 11:22:38	0|sipa|we really need better parallellism for validation across blocks...
 39 2016-04-12 11:26:41	0|gmaxwell|(I have a benchmark time with big dbcache on the 24-core 2.4GHz host of about 3.5hr as of two days ago)
 40 2016-04-12 11:26:53	0|gmaxwell|no real difference in speed local vs network.
 41 2016-04-12 11:27:10	0|sipa|gmaxwell: on a 24-core machine, have you benchmarked whether higher or lower -par works better?
 42 2016-04-12 11:28:22	0|gmaxwell|doubt it matters much. I think when you wrote that code I was benchmarking it on 32 way host and found that it didn't improve after 8 or so, and you capped the code out at .. uh 16?  With libsecp256k1 that effect it likely worse.
 43 2016-04-12 11:43:06	0|GitHub165|[13bitcoin] 15RyanKung opened pull request #7864: Qa: some code style reflected for pep8 (06master...06dev/rk) 02https://github.com/bitcoin/bitcoin/pull/7864
 44 2016-04-12 11:43:15	0|ryankung|...
 45 2016-04-12 11:43:42	0|jonasschnelli|lmdb, 10% progress in 20mins. Will probably be a little bit slower...
 46 2016-04-12 11:43:43	0|ryankung|I just reflected the python testcase code into pep8 code style.
 47 2016-04-12 11:43:44	0|ryankung|some
 48 2016-04-12 11:45:55	0|GitHub74|[13bitcoin] 15jonasschnelli opened pull request #7865: [RPC] Add bumpfee command. (06master...062016/04/rbf_combined) 02https://github.com/bitcoin/bitcoin/pull/7865
 49 2016-04-12 11:46:52	0|GitHub182|[13bitcoin] 15jonasschnelli closed pull request #7159: [RPC] Add RBF opt-in possibilities to rawtx functions (06master...062015/12/rpc_rbf) 02https://github.com/bitcoin/bitcoin/pull/7159
 50 2016-04-12 11:47:02	0|GitHub179|[13bitcoin] 15jonasschnelli closed pull request #7824: Add uncontroversial RBF base features (06master...062016/04/rbf_uncontroversial) 02https://github.com/bitcoin/bitcoin/pull/7824
 51 2016-04-12 12:01:22	0|GitHub47|[13bitcoin] 15RyanKung closed pull request #7864: Qa: some code style reflected for pep8 (06master...06dev/rk) 02https://github.com/bitcoin/bitcoin/pull/7864
 52 2016-04-12 12:11:52	0|jonasschnelli|ryankung: thanks for the work! Once the python3 pr is merge, you should reopen you PR
 53 2016-04-12 12:14:17	0|ryankung|ok :)
 54 2016-04-12 13:36:59	0|electrumuser|Hi, quick confirmation, does the scriptSig contain the sigtype after the signature?, I mean, I have transactions being rejected because signature is too short, I've been comparing the raw tx from two wallets spending the same input, and I noticed that signatures get appended a 01 byte, I can't find documentation about it. But I suspect it might be SIGHASH_ALL, am I correct?
 55 2016-04-12 13:38:17	0|sipa|that's corrrect
 56 2016-04-12 13:38:20	0|sipa|-r
 57 2016-04-12 13:39:24	0|electrumuser|Thank you very much sipa.
 58 2016-04-12 13:49:50	0|cjcj_|'
 59 2016-04-12 13:51:43	0|GitHub119|13bitcoin/06master 14bf477bc 15Jorge Timón: Trivial: Globals: Explicitly pass const CChainParams& to ProcessMessage()
 60 2016-04-12 13:51:43	0|GitHub119|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/934f2b5e7693...514993554c37
 61 2016-04-12 13:51:44	0|GitHub119|13bitcoin/06master 145149935 15Pieter Wuille: Merge #7828: Trivial: Globals: Explicitly pass const CChainParams& to ProcessMessage()...
 62 2016-04-12 13:51:51	0|GitHub176|[13bitcoin] 15sipa closed pull request #7828: Trivial: Globals: Explicitly pass const CChainParams& to ProcessMessage() (06master...060.12.99-chainparams-trivial) 02https://github.com/bitcoin/bitcoin/pull/7828
 63 2016-04-12 16:02:58	0|jonasschnelli|lmdb seems a lot slower (at least on the machine I'm benching)
 64 2016-04-12 16:03:47	0|jonasschnelli|6.5h for 76% IBD
 65 2016-04-12 16:06:33	0|sipa|against random peers?
 66 2016-04-12 16:06:48	0|sipa|or from local network
 67 2016-04-12 16:07:37	0|sipa|with dbcache=8000 the database used should have nearly 0 effect
 68 2016-04-12 16:14:25	0|jonasschnelli|sipa: random peers, dbcache=9000
 69 2016-04-12 16:14:42	0|jonasschnelli|(I made it higher than the 8GB lmdb fix-size)
 70 2016-04-12 16:15:18	0|jonasschnelli|Block download speed looks not after the bottleneck...
 71 2016-04-12 16:15:25	0|jonasschnelli|CPU is running at 645.3%
 72 2016-04-12 16:16:55	0|sipa|maybe it was earlier on
 73 2016-04-12 16:17:22	0|sipa|if you're syncing from random peers, i'd at least want to see an average over a few dozen runs to draw conclusions
 74 2016-04-12 16:18:09	0|sipa|you're including a totally uncontrollable variable into your test setuo by doing so
 75 2016-04-12 16:18:52	0|jonasschnelli|sipa: Yes. Agreed. My idea was to do a reindex once its done to exclude the variable of download
 76 2016-04-12 16:19:21	0|jonasschnelli|Also when I download from one of my other nodes,... the other node does also run stuff in background.. gitian, etc.
 77 2016-04-12 16:20:30	0|sipa|reindex is a better benchmark yes, but with dbcache=8000, i doubt you'll see much difference :)
 78 2016-04-12 16:21:59	0|jonasschnelli|sipa: I'll give you the prove...
 79 2016-04-12 16:22:37	0|sipa|ok :)
 80 2016-04-12 21:18:08	0|paveljanik|http://eprint.iacr.org/2016/367
 81 2016-04-12 22:02:35	0|Chris_Stewart_5|Where does bitcoin core mark the script invalid if there are too many script opts in a OP_IF branch that is not executed
 82 2016-04-12 22:02:51	0|Chris_Stewart_5|I'm looking at this right now, but I don't see how that would mark a script invalid if the ops are not executed
 83 2016-04-12 22:02:53	0|Chris_Stewart_5|https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L269-L271
 84 2016-04-12 22:05:41	0|Chris_Stewart_5|unless OP_IF operators are run through the interpreter even if the stack top is not true..
 85 2016-04-12 22:15:44	0|sipa|why would they not?
 86 2016-04-12 22:16:49	0|sipa|how would the interpreter even know what the operators are, without going through them
 87 2016-04-12 22:17:07	0|sipa|like, how would it find the endif?
 88 2016-04-12 22:18:04	0|Chris_Stewart_5|Most PLs don't execute code inside of OP_IF branches, isn't it simply discarded? Why would this be different?
 89 2016-04-12 22:18:31	0|sipa|conceptually, sure
 90 2016-04-12 22:18:44	0|sipa|but if you write and if branch in a program, it's still compiled
 91 2016-04-12 22:18:52	0|sipa|the result is still part of the program
 92 2016-04-12 22:18:55	0|Chris_Stewart_5|Why not delete all operators until OP_ELSE
 93 2016-04-12 22:18:56	0|sipa|it's not gone
 94 2016-04-12 22:19:08	0|sipa|how can you 'delete' them without going through them?
 95 2016-04-12 22:19:12	0|Chris_Stewart_5|or OP_ENDIF if there is no OP_ELSE
 96 2016-04-12 22:19:23	0|sipa|how will you find where the OP_ENDIF is?
 97 2016-04-12 22:19:31	0|Chris_Stewart_5|Search the list for it?
 98 2016-04-12 22:19:47	0|sipa|there is no more efficient way to do that than to just iterate through the operators :)
 99 2016-04-12 22:19:50	0|Chris_Stewart_5|Am I confusing implementation of the language with the language itself?
100 2016-04-12 22:20:06	0|sipa|no, we're only talking about the implementation of the interpreter
101 2016-04-12 22:20:31	0|Chris_Stewart_5|what does vfExec stand for in english?
102 2016-04-12 22:20:43	0|Chris_Stewart_5|or what does it represent in the interpreter
103 2016-04-12 22:20:43	0|sipa|vector of booleans named Exec
104 2016-04-12 22:21:03	0|sipa|and there is one entry in that vector for each IF you're inside
105 2016-04-12 22:21:32	0|Chris_Stewart_5|sipa: Also what if the control structure of the program is encoded as a binary tree
106 2016-04-12 22:21:49	0|sipa|well it isn't
107 2016-04-12 22:21:53	0|sipa|it's a byte array
108 2016-04-12 22:22:10	0|Chris_Stewart_5|You can ignore the OP_IF branch by simply making the right branch (assumedly the OP_ELSE branch) the new root tree
109 2016-04-12 22:22:33	0|sipa|but the program is not represented as branches
110 2016-04-12 22:22:38	0|sipa|it's just a vector of bytes
111 2016-04-12 22:23:29	0|Chris_Stewart_5|is this one of those things that is too risky to change for fear of unintended consensus changes?
112 2016-04-12 22:23:35	0|sipa|hell yes
113 2016-04-12 22:23:40	0|Chris_Stewart_5|gotcha.
114 2016-04-12 22:24:43	0|Chris_Stewart_5|So if I'm understanding this correctly, vfExec is just a vector of bools indicating if an OP_IF has matched it's OP_ENDIF?
115 2016-04-12 22:25:20	0|sipa|no, it's a vector of booleans saying whether you're in the executed side of the branch
116 2016-04-12 22:25:55	0|Chris_Stewart_5|ok. Thanks
117 2016-04-12 22:28:33	0|sipa|fun fact: you can create an ifthen .... else .... else .... else .... endif branch in bitcoin script