< gmaxwell>
Anyone know what the status of cgminer solo mining segwit support is?
< sipa>
Lightsword, cfields: ^
< btcdrak>
BlueMatt: you should do a presentation in Milan.
< gmaxwell>
BlueMatt: I don't think fibre is at all obvious.
< sipa>
by the time you've explained basic FEC, and how short ids are collision-resistant, you've already talked for half an hour
< sipa>
oh, and tcp networking roundtrips
< gmaxwell>
Head of line blocking of TCP and the hidden round trips at layer-3 is a good 15 minutes itself.
< Lightsword>
gmaxwell, sipa, cgminer solo doesn’t support segwit yet not sure if anyone was planning on adding support
< jonasschnelli>
sipa: Do you tell me your secret how you measure consumed cpu cycled by a certain C function with gdb?
< sipa>
jonasschnelli: don't benchmark while using gdb
< jonasschnelli>
sipa: Ah. Okay. But how do you measure consumed cycles then?
< sipa>
1) run it many times (like benchmarking tools do)
< jonasschnelli>
Using rdtsc?
< sipa>
2) use rdtsc asm instruction to read the time stamp counter on the CPU and lock your CPU to a single frequency; this gives you sub-nanosecond precision
< jonasschnelli>
Okay... I'll give it a try
< sipa>
the bitcoin and libsecp256k1 benchmark tools just run many times, and give you minimum, maximum and average run time
< sipa>
i have a script that pins my cpu frequency to a single number
< sipa>
and then i just stop other processes on my system until the the minimum and average are close enough to not matter
< jonasschnelli>
I guess depending on rdtsc means a system under heavy load (not the tests) will result in biased results?
< jonasschnelli>
Okay.
< sipa>
rdtsc is only useful for microbenchmarks
< sipa>
as it will occasionally incorporate the time of a context switch
< jonasschnelli>
Do you have that CPU freq script in a gist or so?
< jonasschnelli>
(though not sure if that works 1:1 on my OSX machine)
< sipa>
/etc/init.d/cpufrequtils stop
< sipa>
for A in $(seq 0 7); do cpufreq-set -c $A -g performance -d 2.6GHz -u 2.6GHz; done
< sipa>
it's linux specific and cpu specific
< jonasschnelli>
okay... I play with it. Thanks
< sipa>
for bigger things i just add GetTimeMicros() before and after the code in bitcoind, and log the difference to debug.log
< jonasschnelli>
would benchmarking in a "quite" VM (fresh install, headless almost no background processes) result in more comparable results?
< sipa>
i wouldn't use VMs for benchmarking
< jonasschnelli>
Yes. Right. The VM itself is already influent by the hosts processes.
< sipa>
NicolasDorier: hmm, you have a use case of OP_CODESEP? :o
< NicolasDorier>
sipa: yes
< NicolasDorier>
one sec, finding the case I wrote about in lightning discussion some time ago
< NicolasDorier>
is that if you have a ScriptPubKey with 3 different path.
< NicolasDorier>
and one party wants to sign only for one specific path
< NicolasDorier>
without CODESEP, you need 3 different public key
< NicolasDorier>
with CODESEP, the signer can decide which path to sign by choosing the ScriptCode that interest him
< sipa>
but scriptcode is always from the last codesep to the end
< sipa>
so they'd always overlap
< NicolasDorier>
not always, depends if they are on same branch or not
< NicolasDorier>
if you have 2 branch with an OP_IF
< NicolasDorier>
you put a OP_CODESEP on each branch
< NicolasDorier>
then the signer decide which branch he agrees on signing
< sipa>
oh, right, only executed codeseps matter
< NicolasDorier>
sipa: Even if they are on single branch it can be useful actually, if Alice wants to sign until a certain point in the Script, and on certain condition, a second signature from her might be needed later down the path.
< cfields>
jeremyrubin: is there a squashed version of your checkqueue coming up?
< cfields>
gmaxwell: I haven't looked at cgminer yet, but I can
< sipa>
i assume it will be similar to ckpool?
< cfields>
unsure
< phantomcircuit>
sipa, doubt it
< GitHub117>
[bitcoin] JeremyRubin opened pull request #8671: Minimal fix to slow prevector tests as stopgap measure (master...simple_faster_tests) https://github.com/bitcoin/bitcoin/pull/8671
< GitHub186>
[bitcoin] Cocosoft opened pull request #8672: Qt: Show transaction size in transaction details window (master...qttxsizeindetails) https://github.com/bitcoin/bitcoin/pull/8672
< GitHub172>
[bitcoin] JeremyRubin closed pull request #8650: Make tests much faster by replacing BOOST_CHECK with FAST_CHECK (master...faster_tests) https://github.com/bitcoin/bitcoin/pull/8650
< GitHub82>
[bitcoin] JeremyRubin closed pull request #8632: Speed up prevector tests by parallelization (master...faster_prevector_tests) https://github.com/bitcoin/bitcoin/pull/8632
< GitHub122>
[bitcoin] JeremyRubin opened pull request #8673: Trivial: Fix obvious assignment/equality error in test (master...fix_arith_tests_trivial) https://github.com/bitcoin/bitcoin/pull/8673
< jeremyrubin>
cfields: it is available now
< jeremyrubin>
cfields: but I'm not PR'ing it until I can speed up the PrevectorTests
< jeremyrubin>
cfields: I guess I should say, until #8671 gets merged
< luke-jr>
cfields: were your ckpool changes accepted upstream?
< cfields>
jeremyrubin: perfect, thanks
< cfields>
luke-jr: yes
< CocoBTC>
luke-jr, I saw your reply to the PR, thanks. I'm not entirely sure on where/how to get this value (size + feerate-based-on-weight), or what it is. I'm still working on getting my head up-to-date with SegWit.
< luke-jr>
heh, I meant show both the size, and the feerate
< luke-jr>
not to add them ☺
< luke-jr>
basically you get the feerate with Fee / GetVirtualTransactionSize
< CocoBTC>
Lol! I see. That makes sense :)
< CocoBTC>
Right
< CocoBTC>
Do I need to know/care about nSigOpCost?
< luke-jr>
hmm, not normally, but for incoming transactions it's possibly relevant
< luke-jr>
due to nSigOpsPerByte
< luke-jr>
ah, GetVirtualTransactionSize takes care of that for you
< luke-jr>
just you need to give it the right value as an argument
< CocoBTC>
Well it defaults to 0? Or maybe I read the code wrong.
< CocoBTC>
Right!
< luke-jr>
hmm.. I'm not sure it makes sense for it to have that default :x
< luke-jr>
looks like rawtx and the wallet currently don't provide it
< luke-jr>
probably okay for the wallet side because it's for sending
< luke-jr>
but you can't assume incoming are sane in this respect, so you'll need to provide it