< luke-jr>
to avoid risks of hardware consensus failures, perhaps nodes ought to publish fraud claims when their peers send them an invalid block, and then you can go back and check that block in software - thoughts?
< TD-Linux>
luke-jr, by hardware consensus are you referring to an alternate implementation of the consensus rules?
< luke-jr>
TD-Linux: yes, for example implementing the EC verifications in FPGA
< TD-Linux>
luke-jr, is the purpose lower verification latency, or greater overall throughput? if it's the former, you could just run both in parallel and stop if they disagree (or disable the hardware)
< luke-jr>
I guess it would have to be the latter, since latency over the network is high
< luke-jr>
it would also possibly allow the current code to be the "hardware" and have an emulated fallback implementation for greater consensus-safety
< TD-Linux>
how would you trust fraud claims from peers?
< luke-jr>
TD-Linux: when you got one, you'd run the slower implementation
< jtimon>
regarding #8493, __tau__ suggested that "BlockIndexInterface is a bad name. In general avoid generic terms like Interface, every class is an interface. something like BlockIndexOperations would be better"
< jtimon>
thoughts? other ideas for a name?
< gmaxwell>
every interface performance operations. :P
< luke-jr>
only if you use it. *hides*
< jtimon>
yeah, I guess operations is too generic as well
< btcdrak>
jtimon: I prefer Interface suffix on interfaces.
< wumpus>
what's wrong with Interface?
< wumpus>
it's a pretty standard term in almost any programming language for an abstract way to access certain operations
< jtimon>
ok, I'll leave Interface, I don't really care, the complain was that it was too generic
< wumpus>
it'd be too generatic if you call a class Interface { :-)
< wumpus>
if you suffix it to something it's clear imo
< jtimon>
my conclusion from the little discussions we had on libconsensus: each person seems to want a different thing, and those who agree or have similar ideas want to see it happen in a different order
< jtimon>
for reducing our use of globals it seems to be a similar situation
< kanzure>
jtimon: so which one gets priority
< jtimon>
kanzure: good question
< GitHub90>
[bitcoin] laanwj opened pull request #8911: qt: Translate all files, even if wallet disabled (master...2016_10_qt_translations_wallet2) https://github.com/bitcoin/bitcoin/pull/8911
< achow101>
how close is 8499 to being merged?
< wumpus>
someone just has to pull the trigger
< btcdrak>
achow101: still a couple of tests being written afaik
< wumpus>
not on that pull, IIRC
< achow101>
btcdrak: aren't there already tests in that pull? Or are they not enough?
< wumpus>
*112* comments on #8499, wow, people should really cut it with the offtopic discussion
< wumpus>
github is not suitable for winding discussions because it has no threaded format, just a linear one
< phantomcircuit>
TD-Linux: you cant really get lower latency with an fpga anyways
< TD-Linux>
phantomcircuit, indeed, but the idea is identical for any alternate implementation
< Chris_Stewart_5>
You have to request the block header with a GetHeaders message after receiving notification of a new block on the p2p network, correct?