1 2016-11-14 04:55:07 0|dcousens|with P2WSH, can the scriptSig have non-push opcodes?
2 2016-11-14 04:55:20 0|dcousens|(the witness script Sig... "stack")
3 2016-11-14 04:56:05 0|dcousens|I'm looking at https://github.com/bitcoin/bitcoin/blob/e81df49644c21f835e25028ab4643aa9bf5ae8da/src/script/interpreter.cpp#L1367-L1397, and it appears that it can
4 2016-11-14 04:59:11 0|dcousens|nevermind... its treated as stack not CScript, my bad
5 2016-11-14 04:59:40 0|aj|dcousens: yeah, the first item on the stack is the program which gets converted to a CScript, but that's it... ?
6 2016-11-14 04:59:51 0|dcousens|last item*?
7 2016-11-14 05:02:28 0|sipa|last, indeed
8 2016-11-14 05:02:31 0|sipa|top of the stack
9 2016-11-14 05:25:26 0|aj|eh, i'm australian, can you blame me if i look at stacks upside down?
10 2016-11-14 05:35:45 0|bitcoin-git|[13bitcoin] 15XertroV opened pull request #9154: Add recent checkpoints to remove CPU load during sync (06master...06f/new-checkpoints) 02https://github.com/bitcoin/bitcoin/pull/9154
11 2016-11-14 05:36:34 0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9154: Add recent checkpoints to remove CPU load during sync (06master...06f/new-checkpoints) 02https://github.com/bitcoin/bitcoin/pull/9154
12 2016-11-14 06:44:22 0|bitcoin-git|[13bitcoin] 15carryforward opened pull request #9155: [trivial] update comments for tx weight (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9155
13 2016-11-14 07:46:34 0|bitcoin-git|13bitcoin/06master 14fa42e4a 15MarcoFalke: [qt] Make network disabled icon 50% opaque
14 2016-11-14 07:46:34 0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/87ab49e4fe38...924745dd6f5f
15 2016-11-14 07:46:35 0|bitcoin-git|13bitcoin/06master 14924745d 15Jonas Schnelli: Merge #9145: [qt] Make network disabled icon 50% opaque...
16 2016-11-14 07:46:44 0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9145: [qt] Make network disabled icon 50% opaque (06master...06Mf1611-qtNetworkIcon) 02https://github.com/bitcoin/bitcoin/pull/9145
17 2016-11-14 07:54:13 0|gmaxwell|Anyone know where I can go to sign this? http://imgur.com/a/iv3m6 doesn't say much but it's pretty unobjectionable.
18 2016-11-14 07:57:12 0|btcdrak|gmaxwell: no no, we're not allowed to sign that, because it's Roger Ver's attempt to snub Bitcoin Core. Looks like a more watered down version of the first leak http://pastebin.com/cgkqcWBS.
19 2016-11-14 07:58:47 0|luke-jr|gmaxwell: I emailed them a few days ago asking and got no response
20 2016-11-14 08:11:57 0|jonasschnelli|bench gives me something like: SHA256,36,0.030114054679871,0.032101750373840,0.031019667784373
21 2016-11-14 08:12:02 0|jonasschnelli|Are the time values in ms?
22 2016-11-14 08:12:20 0|jonasschnelli|And is the time value * count or per a single execution?
23 2016-11-14 08:14:26 0|gmaxwell|microseconds, IIRC. and not per count, count is already divided out.
24 2016-11-14 08:14:59 0|wumpus|count is divided out otherwise it'd be entirely pointless :) I don't know the unit hough
25 2016-11-14 08:15:48 0|wumpus|the header row should really have unit indicators [ms] [s] or such
26 2016-11-14 08:16:16 0|wumpus|appears to be seconds, looking at the code
27 2016-11-14 08:17:04 0|gmaxwell|indeed.
28 2016-11-14 08:17:48 0|gmaxwell|... 30 microseconds is absurdly slow for sha256 unless that is testing someting non-obvious.
29 2016-11-14 08:18:16 0|wumpus|doesn't it depend on how much data it is hashing per run?
30 2016-11-14 08:18:39 0|gmaxwell|er 30 milliseconds.
31 2016-11-14 08:18:46 0|gmaxwell|Yes, if it's a lot of data, indeed.
32 2016-11-14 08:18:59 0|wumpus|and yes, hashing benchmarks are best expressed in MB/s or such
33 2016-11-14 08:19:41 0|wumpus|would make sense at some point to split the bench into multiple tables, with one for hashing and CRCing algos
34 2016-11-14 08:20:18 0|gmaxwell|sometimes we care about the time to hash a minimum size piece of data: thats the sigcache case, the hashes inside the hashtree, etc.
35 2016-11-14 08:20:39 0|jonasschnelli|Then am I correct when I say for the values above it takes in avg 30ns per hash (need to lookup how mach data being hash)?
36 2016-11-14 08:20:59 0|wumpus|right, probably there should be a specific benchmark for that
37 2016-11-14 08:21:06 0|jonasschnelli|(what I'm trying to do is to compare it against ChaCha20Poly1305AEAD per byte at the end)
38 2016-11-14 08:21:38 0|wumpus|well in that case you should absolutely compare MB/s not anything else
39 2016-11-14 08:21:41 0|gmaxwell|jonasschnelli: no, it's seconds, and it's saying it takes 31 milliseconds for however much it's hashing (presumably a lot or something is broken)
40 2016-11-14 08:21:42 0|jonasschnelli|BUFFER_SIZE = 1000*1000; (for the hash test)
41 2016-11-14 08:22:43 0|jonasschnelli|31 milliseconds per 1MB, right?
42 2016-11-14 08:22:44 0|wumpus|e.g. something like I did here https://github.com/laanwj/crcbench
43 2016-11-14 08:23:01 0|jonasschnelli|wumpus: thanks..
44 2016-11-14 08:23:21 0|wumpus|jonasschnelli: yes
45 2016-11-14 08:24:29 0|wumpus|1000*1000/0.031019667784373 -> 32,237,611 bytes per second
46 2016-11-14 08:26:21 0|gmaxwell|jonasschnelli: sounds like it, yes. which is only 32.2 MB/s which sounds quite slow.
47 2016-11-14 08:26:50 0|jonasschnelli|-O0
48 2016-11-14 08:26:55 0|gmaxwell|openssl speed sha256 on my sluggish laptop says 96,185,000 bytes/s.
49 2016-11-14 08:27:00 0|gmaxwell|oh okay.
50 2016-11-14 08:27:16 0|gmaxwell|well you -O0 is "make bencmarks worthless" :P
51 2016-11-14 08:27:18 0|jonasschnelli|It's not the numbers i want to compare, just for understanding
52 2016-11-14 08:27:22 0|wumpus|why would you compare benchmarks with O0?!
53 2016-11-14 08:27:33 0|gmaxwell|s/you// :)
54 2016-11-14 08:27:42 0|jonasschnelli|I just don't wanted to configure/compile again. :-)
55 2016-11-14 08:27:53 0|jonasschnelli|Will to the benchmark on a different machine... and fix the clock, etc.
56 2016-11-14 08:28:24 0|jonasschnelli|I guess benchmark on a Mac laptop with tons of applications open doesn't really make sense.
57 2016-11-14 08:28:27 0|gmaxwell|Just don't use the results for _anything_ O0 radically changes the performance profile of different code.
58 2016-11-14 08:28:44 0|jonasschnelli|Yes. I learned that from my IBD benchmarks. :)
59 2016-11-14 08:32:12 0|gmaxwell|on the same sluggish laptop mentioned above our bench returns 0.02038276 which is about 49.06 milillion bytes/sec. So I suppose thats about what I'd expect vs OpenSSL given that we know our sha256 is slower than the faster ones using SSE2.
60 2016-11-14 08:51:20 0|jonasschnelli|SHA -O3 on Skylark: SHA256,256,0.002107024192810,0.004232339560986,0.004217050969601
61 2016-11-14 08:51:50 0|jonasschnelli|Same setup, ChaCha20Poly1305@openssh (own draft implementation): 0.00278858
62 2016-11-14 08:53:09 0|gmaxwell|hm. thats not that impressive!
63 2016-11-14 08:53:24 0|jonasschnelli|Well.. faster then I have expected.
64 2016-11-14 08:53:54 0|gmaxwell|run "openssl speed sha256" on the same hardware.
65 2016-11-14 08:54:30 0|jonasschnelli|sha256 64116.34k 140875.75k 245123.77k 296262.31k 320731.87k
66 2016-11-14 08:55:52 0|jonasschnelli|I took the ChaCha20Poly1305 from openssh: https://github.com/jonasschnelli/chacha20poly1305
67 2016-11-14 08:56:02 0|gmaxwell|okay, bitcoin's sha256 is 237.1 million bytes per second, openssl is 320.7 million bytes per second.. and the chacha is 358.6 million bytes per second. (openssl at slight disadvantage due to 8k vs 1m size, but it doesn't matter much)
68 2016-11-14 08:57:25 0|gmaxwell|okay, not so bad, encrypt+auth, about 11% faster than highly optimized sha256 alone for large blocks. IIRC the chacha/poly will have a bigger advantage for smaller messages.
69 2016-11-14 08:57:45 0|jonasschnelli|Yes. Thats true.
70 2016-11-14 08:57:57 0|gmaxwell|and better, it should wipe the floor with sha256 on arm.
71 2016-11-14 08:58:08 0|jonasschnelli|Also, i'm not sure about the constant time properties of chacha20 here: https://github.com/jonasschnelli/chacha20poly1305/blob/master/chacha.c
72 2016-11-14 09:03:01 0|gmaxwell|quick glance through shows all that to be constant time (other than the number of bytes going into it, of course) ... and the position counter carry. (odd that they did that, but it's just a counter)
73 2016-11-14 09:08:18 0|jonasschnelli|gmaxwell: I guess the implementation above is more or less from DJB itself.
74 2016-11-14 09:08:41 0|jonasschnelli|not sure if the openssh guys did modificate it, though
75 2016-11-14 09:09:44 0|gmaxwell|it looks fine to me.
76 2016-11-14 09:59:09 0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9156: Add compile and link options echo to configure (06master...062016/11/configure) 02https://github.com/bitcoin/bitcoin/pull/9156
77 2016-11-14 17:47:09 0|bitcoin-git|[13bitcoin] 15Leviathn opened pull request #9158: Removal of "free transaction" logic from codebase (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9158
78 2016-11-14 18:17:11 0|bitcoin-git|[13bitcoin] 15Leviathn closed pull request #9158: Removal of "free transaction" logic from codebase (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9158
79 2016-11-14 18:35:52 0|sdaftuar|sipa: are you planning to PR the rest of your shared-ptr-all-the-things branch soon?
80 2016-11-14 18:37:42 0|sdaftuar|i have a change to the way we manage the mempool during reorgs, which i think would make sense to rebase on to your branch, wasn't sure if i should use #9125 or some later commit in your branch
81 2016-11-14 18:37:43 0|gribble|https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa ÷ Pull Request #9125 ÷ bitcoin/bitcoin ÷ GitHub
82 2016-11-14 18:43:43 0|sipa|sdaftuar: several parts of that branch are included in #8580 now
83 2016-11-14 18:43:45 0|gribble|https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa ÷ Pull Request #8580 ÷ bitcoin/bitcoin ÷ GitHub
84 2016-11-14 18:44:10 0|sipa|there is one more commit that makes ATMT take a shared_ptr
85 2016-11-14 18:46:04 0|sdaftuar|yeah i was thinking i'd rebase on that one, as that'll help during processing of reorg'ed out transactions as well
86 2016-11-14 18:49:16 0|sipa|i could just push the one remaining patch into 8580, but it's already quite big
87 2016-11-14 18:50:21 0|sdaftuar|no problem, i can be patient (and help review!)
88 2016-11-14 18:51:15 0|sipa|i'll run a benchmark for those PRs soon
89 2016-11-14 19:01:11 0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9159: [qa] Wait for specific block announcement in p2p-compactblocks (06master...06cmpct-announce-wait) 02https://github.com/bitcoin/bitcoin/pull/9159
90 2016-11-14 19:03:21 0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9160: [trivial] Fix hungarian variable name (06master...06hungarian) 02https://github.com/bitcoin/bitcoin/pull/9160
91 2016-11-14 19:28:58 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/924745dd6f5f...b42291334651
92 2016-11-14 19:28:59 0|bitcoin-git|13bitcoin/06master 1405e57cc 15Russell Yanofsky: [qa] Fix sync_blocks timeout argument...
93 2016-11-14 19:28:59 0|bitcoin-git|13bitcoin/06master 14fd6bb70 15Russell Yanofsky: [qa] Improve sync_blocks error messages.
94 2016-11-14 19:29:00 0|bitcoin-git|13bitcoin/06master 147943b13 15Russell Yanofsky: [qa] Avoid 2 list comprehensions in sync_blocks
95 2016-11-14 19:29:08 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9136: sync_blocks cleanup (06master...06sync-clean) 02https://github.com/bitcoin/bitcoin/pull/9136
96 2016-11-14 20:26:50 0|morcos|What is the assumption for how the wallet supports txs for which some of the inputs are yours and some aren't?
97 2016-11-14 20:26:59 0|morcos|I'm asking in context of the bumpfee command.
98 2016-11-14 20:27:40 0|morcos|In particular is there a way to identify such wallet txs?
99 2016-11-14 20:40:27 0|morcos|As a crutch instead of properly supporting such txs, would people accept a wallet function IsAllFromMe(filter), that let you know if all of the inputs were from you? so you'd know if your calculation of Debits was correct
100 2016-11-14 20:41:41 0|morcos|I'd use this in bumpfee to just do nothing if not all the inputs were from you, and in listtransactions and gettransaction to not output an erroneous fee calculation
101 2016-11-14 20:55:16 0|Victorsueca|what about this:
102 2016-11-14 20:55:57 0|Victorsueca|instead of using the IsMine logic, when the bumpfee command is issued then check whether the needed private keys are available
103 2016-11-14 20:58:05 0|Victorsueca|if not available then assume the transaction was not involve the user in a way that allows him to use bumpfee
104 2016-11-14 20:58:13 0|Victorsueca|does*
105 2016-11-14 20:59:07 0|Victorsueca|sounds less resource-consuming than checking the IsMine logic
106 2016-11-14 21:03:43 0|morcos|The problem is even if you have all the keys to sign the tx, if not all the inputs are you, you can't actually calculate the proper fee.
107 2016-11-14 21:04:07 0|morcos|This is why listtransactions and gettransaction return erroneous results
108 2016-11-14 22:45:55 0|Victorsueca|what would be the appropriate way to suggest a new GUI feature?
109 2016-11-14 23:52:31 0|shinyg|Hi people, I was after a little assistance from those who know more about Bitcoin Core and those who support Wikipedia.
110 2016-11-14 23:53:16 0|shinyg|I have recently expanded the Wikipedia article for Bitcoin Core by a factor of 10. Could someone spend just a few minutes to see if there are any major ommission or errors?
111 2016-11-14 23:54:53 0|shinyg|I have almost no programming skills so I ask here because I imagine there are a few experts around, apologies if this is too off-topic
112 2016-11-14 23:56:59 0|achow101|shinyg: blockstream does not fund Bitcoin Core development at all. There are developers who work on Bitcoin Core who also have jobs at Blockstream. The people who actually partially fund development are the MIT DCI who actually pay some people to work on Core (wladimir, cory)
113 2016-11-14 23:57:40 0|shinyg|got it
114 2016-11-14 23:58:21 0|achow101|also, IIRC bitcoin.org and the bitcoin foundation are no longer related