< 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
< 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)
<@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.
< 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.
< 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
< 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
< 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
< 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