< 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
< luke-jr> if it was okay, ban the peer
< GitHub24> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bf8e68aba68d...d0754799698d
< GitHub24> bitcoin/master 6976db2 Suhas Daftuar: [qa] Another attempt to fix race condition in p2p-compactblocks.py...
< GitHub24> bitcoin/master b55d941 Suhas Daftuar: [qa] Fix race condition in sendheaders.py...
< GitHub24> bitcoin/master d075479 MarcoFalke: Merge #8882: [qa] Fix race conditions in p2p-compactblocks.py and sendheaders.py...
< GitHub159> [bitcoin] MarcoFalke closed pull request #8882: [qa] Fix race conditions in p2p-compactblocks.py and sendheaders.py (master...fix-race-again) https://github.com/bitcoin/bitcoin/pull/8882
< GitHub135> [bitcoin] s-matthew-english opened pull request #8908: Update bitcoin-qt.desktop (master...patch-4) https://github.com/bitcoin/bitcoin/pull/8908
< GitHub27> [bitcoin] btcdrak opened pull request #8909: Change bundle identifiers (master...bc) https://github.com/bitcoin/bitcoin/pull/8909
< GitHub188> [bitcoin] MarcoFalke pushed 20 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/a916677ace1c...94688d8e43e7
< GitHub188> bitcoin/0.13 375437c Johnson Lau: Ping regularly in p2p-segwit.py to keep connection alive...
< GitHub188> bitcoin/0.13 9bbe66e Suhas Daftuar: [qa] Split up slow RPC calls to avoid pruning test timeouts...
< GitHub8> [bitcoin] MarcoFalke closed pull request #8866: [0.13] Backports (0.13...Mf1610-013backp) https://github.com/bitcoin/bitcoin/pull/8866
< GitHub188> bitcoin/0.13 2a8bca4 jnewbery: Add bitcoin-tx JSON tests...
< jtimon> btw wumpus I forgot but I believe #8498 should be in https://github.com/bitcoin/bitcoin/projects/6 too
< kanzure> cfields: see "Error code and correction for a new address type" in https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
< luke-jr> eh, cfields was there.. O.o
< kanzure> well maybe in another room
< 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?
< sipa> you can also use sendheaders
< Chris_Stewart_5> Thanks, just came across that