< dcousens> with P2WSH, can the scriptSig have non-push opcodes?
< dcousens> (the witness script Sig... "stack")
< dcousens> nevermind... its treated as stack not CScript, my bad
< aj> dcousens: yeah, the first item on the stack is the program which gets converted to a CScript, but that's it... ?
< dcousens> last item*?
< sipa> last, indeed
< sipa> top of the stack
< aj> eh, i'm australian, can you blame me if i look at stacks upside down?
< bitcoin-git> [bitcoin] XertroV opened pull request #9154: Add recent checkpoints to remove CPU load during sync (master...f/new-checkpoints) https://github.com/bitcoin/bitcoin/pull/9154
< bitcoin-git> [bitcoin] fanquake closed pull request #9154: Add recent checkpoints to remove CPU load during sync (master...f/new-checkpoints) https://github.com/bitcoin/bitcoin/pull/9154
< bitcoin-git> [bitcoin] carryforward opened pull request #9155: [trivial] update comments for tx weight (master...master) https://github.com/bitcoin/bitcoin/pull/9155
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/87ab49e4fe38...924745dd6f5f
< bitcoin-git> bitcoin/master fa42e4a MarcoFalke: [qt] Make network disabled icon 50% opaque
< bitcoin-git> bitcoin/master 924745d Jonas Schnelli: Merge #9145: [qt] Make network disabled icon 50% opaque...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #9145: [qt] Make network disabled icon 50% opaque (master...Mf1611-qtNetworkIcon) https://github.com/bitcoin/bitcoin/pull/9145
< gmaxwell> Anyone know where I can go to sign this? http://imgur.com/a/iv3m6 doesn't say much but it's pretty unobjectionable.
< 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.
< luke-jr> gmaxwell: I emailed them a few days ago asking and got no response
< jonasschnelli> bench gives me something like: SHA256,36,0.030114054679871,0.032101750373840,0.031019667784373
< jonasschnelli> Are the time values in ms?
< jonasschnelli> And is the time value * count or per a single execution?
< gmaxwell> microseconds, IIRC. and not per count, count is already divided out.
<@wumpus> count is divided out otherwise it'd be entirely pointless :) I don't know the unit hough
<@wumpus> the header row should really have unit indicators [ms] [s] or such
<@wumpus> appears to be seconds, looking at the code
< gmaxwell> indeed.
< gmaxwell> ... 30 microseconds is absurdly slow for sha256 unless that is testing someting non-obvious.
<@wumpus> doesn't it depend on how much data it is hashing per run?
< gmaxwell> er 30 milliseconds.
< gmaxwell> Yes, if it's a lot of data, indeed.
<@wumpus> and yes, hashing benchmarks are best expressed in MB/s or such
<@wumpus> would make sense at some point to split the bench into multiple tables, with one for hashing and CRCing algos
< 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.
< 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)?
<@wumpus> right, probably there should be a specific benchmark for that
< jonasschnelli> (what I'm trying to do is to compare it against ChaCha20Poly1305AEAD per byte at the end)
<@wumpus> well in that case you should absolutely compare MB/s not anything else
< 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)
< jonasschnelli> BUFFER_SIZE = 1000*1000; (for the hash test)
< jonasschnelli> 31 milliseconds per 1MB, right?
<@wumpus> e.g. something like I did here https://github.com/laanwj/crcbench
< jonasschnelli> wumpus: thanks..
<@wumpus> jonasschnelli: yes
<@wumpus> 1000*1000/0.031019667784373 -> 32,237,611 bytes per second
< gmaxwell> jonasschnelli: sounds like it, yes. which is only 32.2 MB/s which sounds quite slow.
< jonasschnelli> -O0
< gmaxwell> openssl speed sha256 on my sluggish laptop says 96,185,000 bytes/s.
< gmaxwell> oh okay.
< gmaxwell> well you -O0 is "make bencmarks worthless" :P
< jonasschnelli> It's not the numbers i want to compare, just for understanding
<@wumpus> why would you compare benchmarks with O0?!
< gmaxwell> s/you// :)
< jonasschnelli> I just don't wanted to configure/compile again. :-)
< jonasschnelli> Will to the benchmark on a different machine... and fix the clock, etc.
< jonasschnelli> I guess benchmark on a Mac laptop with tons of applications open doesn't really make sense.
< gmaxwell> Just don't use the results for _anything_ O0 radically changes the performance profile of different code.
< jonasschnelli> Yes. I learned that from my IBD benchmarks. :)
< 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.
< jonasschnelli> SHA -O3 on Skylark: SHA256,256,0.002107024192810,0.004232339560986,0.004217050969601
< jonasschnelli> Same setup, ChaCha20Poly1305@openssh (own draft implementation): 0.00278858
< gmaxwell> hm. thats not that impressive!
< jonasschnelli> Well.. faster then I have expected.
< gmaxwell> run "openssl speed sha256" on the same hardware.
< * jonasschnelli> doing...
< jonasschnelli> sha256 64116.34k 140875.75k 245123.77k 296262.31k 320731.87k
< jonasschnelli> I took the ChaCha20Poly1305 from openssh: https://github.com/jonasschnelli/chacha20poly1305
< 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)
< 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.
< jonasschnelli> Yes. Thats true.
< gmaxwell> and better, it should wipe the floor with sha256 on arm.
< jonasschnelli> Also, i'm not sure about the constant time properties of chacha20 here: https://github.com/jonasschnelli/chacha20poly1305/blob/master/chacha.c
< 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)
< jonasschnelli> gmaxwell: I guess the implementation above is more or less from DJB itself.
< jonasschnelli> not sure if the openssh guys did modificate it, though
< gmaxwell> it looks fine to me.
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #9156: Add compile and link options echo to configure (master...2016/11/configure) https://github.com/bitcoin/bitcoin/pull/9156
< bitcoin-git> [bitcoin] Leviathn opened pull request #9158: Removal of "free transaction" logic from codebase (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9158
< bitcoin-git> [bitcoin] Leviathn closed pull request #9158: Removal of "free transaction" logic from codebase (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9158
< sdaftuar> sipa: are you planning to PR the rest of your shared-ptr-all-the-things branch soon?
< 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
< 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
< sipa> sdaftuar: several parts of that branch are included in #8580 now
< gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
< sipa> there is one more commit that makes ATMT take a shared_ptr
< sdaftuar> yeah i was thinking i'd rebase on that one, as that'll help during processing of reorg'ed out transactions as well
< sipa> i could just push the one remaining patch into 8580, but it's already quite big
< sdaftuar> no problem, i can be patient (and help review!)
< sipa> i'll run a benchmark for those PRs soon
< bitcoin-git> [bitcoin] ryanofsky opened pull request #9159: [qa] Wait for specific block announcement in p2p-compactblocks (master...cmpct-announce-wait) https://github.com/bitcoin/bitcoin/pull/9159
< bitcoin-git> [bitcoin] ryanofsky opened pull request #9160: [trivial] Fix hungarian variable name (master...hungarian) https://github.com/bitcoin/bitcoin/pull/9160
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/924745dd6f5f...b42291334651
< bitcoin-git> bitcoin/master fd6bb70 Russell Yanofsky: [qa] Improve sync_blocks error messages.
< bitcoin-git> bitcoin/master 05e57cc Russell Yanofsky: [qa] Fix sync_blocks timeout argument...
< bitcoin-git> bitcoin/master 7943b13 Russell Yanofsky: [qa] Avoid 2 list comprehensions in sync_blocks
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9136: sync_blocks cleanup (master...sync-clean) https://github.com/bitcoin/bitcoin/pull/9136
< morcos> What is the assumption for how the wallet supports txs for which some of the inputs are yours and some aren't?
< morcos> I'm asking in context of the bumpfee command.
< morcos> In particular is there a way to identify such wallet txs?
< 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
< 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
< Victorsueca> what about this:
< Victorsueca> instead of using the IsMine logic, when the bumpfee command is issued then check whether the needed private keys are available
< Victorsueca> if not available then assume the transaction was not involve the user in a way that allows him to use bumpfee
< Victorsueca> does*
< Victorsueca> sounds less resource-consuming than checking the IsMine logic
< 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.
< morcos> This is why listtransactions and gettransaction return erroneous results
< Victorsueca> what would be the appropriate way to suggest a new GUI feature?
< shinyg> Hi people, I was after a little assistance from those who know more about Bitcoin Core and those who support Wikipedia.
< 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?
< 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
< 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)
< shinyg> got it
< achow101> also, IIRC bitcoin.org and the bitcoin foundation are no longer related