< phantomcircuit> gmaxwell, any mention of the original purpose of the co processor?
< luke-jr> phantomcircuit: tpearson seems to think it's clearly designed for the purpose of being a backdoor (#Talos-workstation)
< gmaxwell> it's really weird that it gets commands just raw out of the instruction stream like that.
< ossifrage> gmaxwell, I've seen other processors with bolt-ons that do the same thing. I guess it can be lower overhead then having the co-processor show up in the memory map
< ossifrage> I can't imagine you'd want to do it in a deeply OOO processor though, but if you have a simple pipeline it might be an easy choice
< gmaxwell> sipa: any new grep results (anything higher than 101?)
< sipa> gmaxwell: no, just 101
< Jmabsd> the nomenclature "scriptPubKey" and "scriptSig", is this for historical reasons as in back in 2009 you had P2PK so the output script was literally a "script-with-a-pub-key-in-it", and the input has a "script-with-a-signature-in-it", hence scriptPubKey and scriptSig ??
< sipa> Jmabsd: maybe
< sipa> you'll need to ask the system's creator :)
< Jmabsd> sipa: ah. easy peasy. what's this gmx.de email again. :))
< sipa> i like to think of the scriptPubKey as the pubkey for a higher level cryptographic signature system called script
< Jmabsd> anyhow i guess that is a very rational understanding for the original motivation to the nomenclature.
< sipa> and the scriptSig is the signature to that scheme
< Jmabsd> ah!
< Jmabsd> ah interesting, makes sense!
< sipa> i have no idea if that's the name's origin, however
< Jmabsd> are we in a place today where you can assume that every relevant participant in the Bitcoin ecosystem will be fine with Bitcoin transactions with version = 2?
< Jmabsd> i'd guess so, though legacy seems to be version 1. i didn't check statistics for what's actually in blocks today.
< sipa> ?
< sipa> v2 was introduced by bip 112
< sipa> i'm not sure what you mean by "will be fine"
< Jmabsd> sipa: of what effect in the real world is the version number attached to _transactions_
< Jmabsd> (BIP 112 relates to block version not tx version)
< sipa> Jmabsd: no, tx version
< sipa> Jmabsd: block version 2 was assigned a meaning in bip 34
< Jmabsd> sipa: ah, i can't find the word "version" allude to transaction version anywhere in BIP 112, what did I miss? sorry if this is too obvious, if so derp.
< sipa> bip 68 too
< sipa> bip 112 includes the text "transaction version less than 2"
< sipa> bip 68 includes "This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on.
< sipa> "
< sipa> Jmabsd: i think your questions are probably better suited for bitcoin.stackexchange.com
< sipa> this channel is mostly about developmemt of the bitcoin core software
< jonasschnelli> should calculating the ecdh secret be done the secp256k1 sign or on the verify context? Or does it even matter?
< ken2812221> I wonder why the linter failed? https://travis-ci.org/bitcoin/bitcoin/jobs/414449333
< aj> ken2812221: probably doesn't like the , in the template syntax? foo<bar,baz>
< ken2812221> aj: thanks, might need to fix this linter bug.
< provoostenator> Re preciousblock RPC: "Treats a block as if it were received before others with the same work", what exactly is meant with "same work"?
< provoostenator> Is "work" defined as delta blockheight times current difficulty level?
< instagibbs> provoostenator, blocks * difficulty level, or there abouts yes. So with a one block fork it will always select the one your preciousblocked
< provoostenator> instagibbs: thanks
< gmaxwell> provoostenator: well not quite, because the forks could have different difficulty levels.
< provoostenator> So if the fork happened in the current difficulty period, then block height delta is all you need. But otherwise you need to take the surface area under difficulty x height chart.
< gmaxwell> right.
< gmaxwell> though thats kind of overcomplicating it. The software already tracks that 'area' for every block (by adding up the reverse of the targets).
< provoostenator> I know, I'm trying to visualize it.
< provoostenator> I know, I'm trying to visualize it.
< MarcoFalke> PSA: Don't merge to master until the travis issues are resolved. I just recently purged all caches to fix some issues and would like to avoid further cache corruption.
< provoostenator> I can use a sanity check on my reasoning in #13930 (bottom comment) by someone who thoroughly understands how blocks are connected and/or invalidated.
< gribble> https://github.com/bitcoin/bitcoin/issues/13930 | Better explain GetAncestor check for m_failed_blocks in AcceptBlockHeader by Sjors · Pull Request #13930 · bitcoin/bitcoin · GitHub
<@sdaftuar> provoostenator: that looks correct to me