< 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
< gmaxwell>
no.
< gmaxwell>
Chris_Stewart_5: nops were _never_ a 'waiting' mechenism, they were explicitly added for forward extensibility.
< 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?
< gmaxwell>
Chris_Stewart_5: because there were already people creating them in the network.
< Guest2012>
d
< GitHub99>
[bitcoin] rustyrussell opened pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (master...bip9-status-as-object) https://github.com/bitcoin/bitcoin/pull/7863
< jonasschnelli>
hmm...
< jonasschnelli>
sync_mempool() in the RPC tests does actually check the order of the transaction in the mempool
< jonasschnelli>
replacing with RBF seems to result in different orders in the mempools.
< jonasschnelli>
And sync_mempool only proceeds if the mempool set is _identical_
< gmaxwell>
A test for bitcoin core slavishly enforcing exact behavior? It couldn't be!
< jonasschnelli>
gmaxwell is right (as always). My debugging is wrong (as always).
< sipa>
those sync_* functions in the test could probably just be replaced with a ping RPC and then observing getpeerinfo until the pong returns
< * jonasschnelli>
made a new personal sync record
< sipa>
lmdb?
< jonasschnelli>
Sync from random peers in 2h and 20'.
< jonasschnelli>
Lmdb will follow now... this is just the basepoint to compare after
< sipa>
ok
< sipa>
sync from a random peer is very variable though
< jonasschnelli>
2h20' is standard --disable-debug
< jonasschnelli>
sipa: Yes. I know,... i might connect to another node in the same net for performance benchmark...
< gmaxwell>
hm. that sounds like something wrong.
< gmaxwell>
since I have numbers substantially higher on very fast hosts with gbe between them. :)
< sipa>
jonasschnelli: this test was not done over the daylight savings time switchover, right? :)
< jonasschnelli>
no. Its just a brand new server.
< jonasschnelli>
Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz
< jonasschnelli>
Yes. Thats true.. maybe the log writing. :)
< jonasschnelli>
(because its so fast)
< jonasschnelli>
And the server is totally quite ("nothing" runs on it besides bitcoind)
< sipa>
quiet?
< jonasschnelli>
quite in terms of running applications
< gmaxwell>
ah 3.6GHz. okay then that translates to my best number assuming we're bottlenecked on a single core.
< sipa>
we really need better parallellism for validation across blocks...
< 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)
< gmaxwell>
no real difference in speed local vs network.
< sipa>
gmaxwell: on a 24-core machine, have you benchmarked whether higher or lower -par works better?
< 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.
< jonasschnelli>
ryankung: thanks for the work! Once the python3 pr is merge, you should reopen you PR
< ryankung>
ok :)
< 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?