< GitHub32> [bitcoin] ptschip opened pull request #6842: limitfreerelay edge case bugfix: (master...limitfreerelay_edgecase) https://github.com/bitcoin/bitcoin/pull/6842
< GitHub135> [bitcoin] mitchellcash opened pull request #6843: Trivial: Correct spelling mistakes in doc folder (master...spelling_fixes) https://github.com/bitcoin/bitcoin/pull/6843
< michagogo> Hm. Turns out -? is the documented way of doing it
< michagogo> And --help works too
< michagogo> but -h just starts the node
< michagogo> ...which can't easily be immediately stopped...
< gmaxwell> our commandline has never been very unixy. It's gotten better.
< GitHub179> [bitcoin] lclc opened pull request #6844: [REST] Add sendrawtransaction (master...sendrawtransactionREST) https://github.com/bitcoin/bitcoin/pull/6844
< morcos> so script checking is only single threaded in AcceptToMemoryPool? Is that so we are saving our processing power to process blocks quickly?
< morcos> But if we're pushing the signature validations into a cache, isn't that a bit backwards?
< morcos> hmm, no that doesn't make sense b/c cs_main is locked, so they wouldn't conflict
< gmaxwell> it's just inherently single threaded due to locking orginization. and the threading overheads mean that threading just two signatures is probably not a win.
< morcos> huh?
< morcos> doesn't ConnectBlock also only thread 1 tx at a time?
< morcos> why would it be a bigger win there?
< morcos> i just hacked it together, it does seem faster, although its not a huge gain, it significantly reduces the big outliers in ATMP
< morcos> in the recent spam attack with a lot of 100txin txs, i think it would be nice
< morcos> of course i'm sure my hacked together code might not be thread safe, so i might still be missing what you're talking about
< gmaxwell> well perhaps the world has changed since I tried it before!
< morcos> i've only done a cursory look, it seems like the signature cache already has a lock..