< 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> sipa: https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000457.html here (forget about R-Value, I was meaning revocation hash)
< NicolasDorier> the basic idea
< 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.
< sipa> have you tested that?
< sipa> btcdrak: NicolasDorier just linked to that as well
< btcdrak> oh lol. I should read the entire log before replying :-p
< GitHub111> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e82fb872ff5c...d077f43f7ecf
< GitHub111> bitcoin/master ff2ed7a mruddy: trivial: remove unnecessary variable fDaemon
< GitHub111> bitcoin/master d077f43 Wladimir J. van der Laan: Merge #8663: trivial: remove unnecessary variable fDaemon...
< GitHub96> [bitcoin] laanwj closed pull request #8663: trivial: remove unnecessary variable fDaemon (master...trivial_fDaemon) https://github.com/bitcoin/bitcoin/pull/8663
< GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d077f43f7ecf...8ea44405e76f
< GitHub0> bitcoin/master 38acbf8 Doug: Remove unused Qt 4.6 patch....
< GitHub0> bitcoin/master 8ea4440 Wladimir J. van der Laan: Merge #8645: Remove unused Qt 4.6 patch....
< GitHub121> [bitcoin] laanwj closed pull request #8645: Remove unused Qt 4.6 patch. (master...master) https://github.com/bitcoin/bitcoin/pull/8645
< jl2012> does signrawtransaction allow signing out-of-range SIGHASH_SINGLE? (i.e. the sighash = 1 bug)
< instagibbs_> jl2012: it skips those
< jl2012> so it won't complete and return error?
< instagibbs_> afaict from the code just skips signing it
< jl2012> thanks
< instagibbs_> jonasschnelli: did https://github.com/bitcoin/bitcoin/pull/8606 fix your issue?
< 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
< CocoBTC> Okay! Thank you for your help.
< luke-jr> np