How old were you when you learned that the Moon in the Southern Hemisphere is upside down? I was today years old…this is my head exploding —> %@*&!$. Ok, the Moon isn’t upside down (that’s Northern-ist) but its orientation changes depending on if you’re north or south of the equator.

“From our perspective, the Moon and the night sky is actually rotated 180 degrees compared to our Northern Hemispherical friends,” Jake Clark, an astronomer from the University of Southern Queensland in Australia, explained to ScienceAlert.

“In the south we see the Moon’s dark ‘Oceanus Procellarum’ sea in the south-east corner compared to in the north-west corner for a northern observer.”

But why does it look like this? Well, because physically, we’re actually upside down compared to someone standing in the opposite hemisphere.

That makes perfect sense & the explanation is quite simple but it’s still messing with my head. How did I not know this? Here’s how the Moon appears in the Northern Hemisphere (from Wikipedia):

And here’s a photo from Brendan Keene in Australia:

Continuing on the extremely sporadic topic of stupid C preprocessor tricks.

It is common to have preprocessor macros that control compile-time behavior. C++11 has std::enable_if to conditionally remove functions and template specializations from consideration, and C++17 adds if constexpr to allow statements to removed conditionally. Removing variables is a bit trickier, though. You can probably manage it by wrapping the variable inside a class that itself uses std::enable_if, but that's even more clunky than std::enable_if already is.

Anyway, for whatever reason, you might want to use the preprocessor's #if directive to perform your tests. Maybe you are preprocessing something for a purpose other than compilation by a C or C++ compiler.

But you're also worried that somebody might misspell your symbol.

// The FEATURE_BLAH macro is defined either as 0 or 1

#if FEATURE_BLUH
... do stuff with feature Blah ...
#endif

Oops, they misspelled FEATURE_BLAH, but the preprocessor doesn't know that, so it happily says, "Nope, it's not defined, skip the body of the #if."

How do you catch this typo?

You can use your adversary's power against him.

Since undefined symbols are treated as having the value zero, you can use an expression that blows up if the value is zero.

// The FEATURE_BLAH macro is defined either as 1 (off) or 2 (on)

#define GET_NONZERO_VALUE(x) (0/(x) + (x))

#if GET_NONZERO_VALUE(FEATURE_BLAH) == 2
... do stuff with feature Blah ...
#endif

The GET_NONZERO_VALUE macro first tries to divide by its parameter. If the parameter is not defined or is defined with the value zero, then that results in a division by zero and you get a compiler error. If the parameter is defined with a nonzero value, then the result of 0/(x) is zero, and adding that to x yields x.

The last wrinkle is using the defined preprocessor pseudo-function to distinguish between an undefined macro and a defined macro whose value is zero.

// The FEATURE_BLAH macro is defined to 0 or 1
// The FEATURE_BLAH_OPTION macro is some value

#define GET_FEATURE_VALUE(x) (0/defined(FEATURE_##x) + (FEATURE_##x))

#if GET_FEATURE_VALUE(BLAH)
#if GET_FEATURE_VALUE(BLAH_OPTION) == 1
... do stuff with feature Blah and option 1...
#elif GET_FEATURE_VALUE(BLAH_OPTION) == 2
... do stuff with feature Blah and option 2...
#else
#error Unknown option for FEATURE_BLAH_OPTION.
#endif
#endif

If FEATURE_BLAH is not defined, then the defined(FEATURE_BLAH) will evaluate to zero, and then you get a divide by zero error in the preprocessor. If it is defined, then defined(FEATURE_BLAH) evaluates to 1, and the expression 0/1 + FEATURE_BLAH reduces to just FEATURE_BLAH.

This is an abuse of the preprocessor, but it may come in handy in a pinch.

Like many, I was surprised and shocked by the election of Donald Trump as president. I believe his ideas, temperament, and inexperience represent a grave threat to our country and world. Suddenly, all the things I had planned to work on seemed trivial in comparison. Although Internet security and privacy are not the most important policy areas at risk, I believe he -- and, more importantly, his cabinet, administration, and Congress -- will have devastating effects in that area, both in the US and around the world.

The election was so close that I've come to see the result as a bad roll of the dice. A few minor tweaks here and there -- a more enthusiastic Sanders endorsement, one fewer of Comey's announcements, slightly less Russian involvement -- and the country would be preparing for a Clinton presidency and discussing a very different social narrative. That alternative narrative would stress business as usual, and continue to obscure the deep social problems in our society. Those problems won't go away on their own, and in this alternative future they would continue to fester under the surface, getting steadily worse. This election exposed those problems for everyone to see.

I spent the last month both coming to terms with this reality, and thinking about the future. Here is my new agenda for the next four years:

One, fight the fights. There will be more government surveillance and more corporate surveillance. I expect legislative and judicial battles along several lines: a renewed call from the FBI for backdoors into encryption, more leeway for government hacking without a warrant, no controls on corporate surveillance, and more secret government demands for that corporate data. I expect other countries to follow our lead. (The UK is already more extreme than us.) And if there's a major terrorist attack under Trump's watch, it'll be open season on our liberties. We may lose a lot of these battles, but we need to lose as few as possible and as little of our existing liberties as possible.

Two, prepare for those fights. Much of the next four years will be reactive, but we can prepare somewhat. The more we can convince corporate America to delete their saved archives of surveillance data and to store only what they need for as long as they need it, the safer we'll all be. We need to convince Internet giants like Google and Facebook to change their business models away from surveillance capitalism. It's a hard sell, but maybe we can nibble around the edges. Similarly, we need to keep pushing the truism that privacy and security are not antagonistic, but rather are essential for each other.

Three, lay the groundwork for a better future. No matter how bad the next four years get, I don't believe that a Trump administration will permanently end privacy, freedom, and liberty in the US. I don't believe that it portends a radical change in our democracy. (Or if it does, we have bigger problems than a free and secure Internet.) It's true that some of Trump's institutional changes might take decades to undo. Even so, I am confident -- optimistic even -- that the US will eventually come around; and when that time comes, we need good ideas in place for people to come around to. This means proposals for non-surveillance-based Internet business models, research into effective law enforcement that preserves privacy, intelligent limits on how corporations can collect and exploit our data, and so on.

And four, continue to solve the actual problems. The serious security issues around cybercrime, cyber-espionage, cyberwar, the Internet of Things, algorithmic decision making, foreign interference in our elections, and so on aren't going to disappear for four years while we're busy fighting the excesses of Trump. We need to continue to work towards a more secure digital future. And to the extent that cybersecurity for our military networks and critical infrastructure allies with cybersecurity for everyone, we'll probably have an ally in Trump.

Those are my four areas. Under a Clinton administration, my list would have looked much the same. Trump's election just means the threats will be much greater, and the battles a lot harder to win. It's more than I can possibly do on my own, and I am therefore substantially increasing my annual philanthropy to support organizations like EPIC, EFF, ACLU, and Access Now in continuing their work in these areas.

My agenda is necessarily focused entirely on my particular areas of concern. The risks of a Trump presidency are far more pernicious, but this is where I have expertise and influence.

Right now, we have a defeated majority. Many are scared, and many are motivated -- and few of those are applying their motivation constructively. We need to harness that fear and energy to start fixing our society now, instead of waiting four or even eight years, at which point the problems would be worse and the solutions more extreme. I am choosing to proceed as if this were cowpox, not smallpox: fighting the more benign disease today will be much easier than subjecting ourselves to its more virulent form in the future. It's going to be hard keeping the intensity up for the next four years, but we need to get to work. Let's use Trump's victory as the wake-up call and opportunity that it is.

The Honey Badger of BFT Protocols Miller et al. CCS 2016

The surprising success of cryptocurrencies (blockchains) has led to a surge of interest in deploying large scale, highly robust, Byzantine fault tolerant (BFT) protocols for mission critical applications, such as financial transactions.

In a ‘traditional’ distributed system consensus algorithm setting we assume a relatively small number of cooperating nodes that can tolerate some number of faults. But in a cryptocurrency setting we have large numbers of mutually distrustful nodes operating in network conditions likely to be less predictable. The fancy way of saying that a distributed system can cope with active adversaries is Byzantine Fault Tolerance (BFT). The trade-offs we make with cryptocurrencies may be different too:

Cryptocurrencies demonstrate the demand for and viability of an unusual operating point that prioritizes robustness above all else, even at the expense of performance. In fact, Bitcoin provides terrible performance by distributed systems standards: a transaction takes on average 10 minutes to be committed, and the system as a whole achieves throughput on the order of 10 transactions per second. However, in comparison with traditional fault tolerant deployment scenarios, cryptocurrencies thrive in a highly adversarial environment, where well-motivated and malicious attacks are expected (if not commonplace).

Moreover, response time and contention are not the critical factors for many blockchain applications (e.g. some classes of payment and settlement networks). What these applications often do need though is throughput in order to be able to sustain high volumes of requests. As regular readers of The Morning Paper will know, what do you do when you want to trade latency for throughput? Batch. And indeed we’ll see that HoneyBadgerBFT does indeed employ a clever batching strategy…

The problem with existing BFT systems, show Miller et al., is that they rely on some variation of weak synchrony. In practical terms, they use timeouts to tolerate network delays within some bounds. “The liveness properties of weakly synchronous protocols can fail completely when the expected timing assumptions are violated (e.g. due to a malicious network adversary).” Even when the weak synchrony assumptions are satisfied in practice, such protocols can significantly degrade in throughput when the underlying network is unpredictable. See §3 in the paper for a discussion and demonstration.

HoneyBadgerBFT [is] the first BFT atomic broadcast protocol to provide optimal asymptotic efficiency in the asynchronous setting. We therefore directly refute the prevailing wisdom that such protocols are necessarily impractical.

All of which makes this paper interesting on a number of levels: from a CS perspective it covers a lot of ground, enough to fill up my paper queue for several days covering gaps in my knowledge; and from an application point of view it’s highly relevant in the blockchain and cryptocurrency world. HoneyBadgerBFT (https://github.com/amiller/HoneyBadgerBFT) is designed for two key deployment scenarios among others:

• Confederation cryptocurrencies in which a conglomerate of financial institutions jointly contribute to a Byzantine agreement protocol to allow fast and robust settlement of transactions.
• Permissionless blockchains with enrolment open to everyone, but that can still deliver acceptable throughput and latency:

To achieve security in this setting, known consensus protocols rely on proofs-of-work to defeat Sybil attacks, and pay an enormous price in terms of throughput and latency, e.g., Bitcoin commits transactions every ∼ 10 min, and its throughput is limited to 7 tx/sec even when the current block size is maximized.

HoneyBadger BFT goals

HoneyBadger is designed to be resilient to censorship (aka ‘fairness’), which means that an adversary cannot block proposals from target nodes, and to deliver practical throughput.

Our overall goal is to build a replicated state machine, where clients generate and submit transactions and a network of nodes receives and processes them. Abstracting away from application specific details (such as how to represent state and compute transitions), it suffices to build a totally globally-consistent, totally-ordered, append-only transaction log. Traditionally, such a primitive is called total order or atomic broadcast; in Bitcoin parlance, we would call it a blockchain.

The system model assumes that each pair of nodes is connected by a reliable authenticated point-to-point channel (which can be built on top of unreliable foundations of course). “The delivery schedule is entirely determined by the adversary, but every message sent between correct nodes must eventually be delivered” That sentence caught my eye – it would be a strange adversary that had the power to delay messages, but not to drop them! Perhaps we treat this as a very long eventually, whereby with enough retries it is assumed the internet infrastructure does its work and a way is found through in the end? The adversary can control up to f faulty nodes, giving correct operation so long as there are N ≥ 3f +1 nodes.

• If any correct node outputs a transaction tx, then every correct node outputs tx.
• If one correct node has an output transaction sequence s₁ and another correct node has an output transaction sequence s₂ then s₁ is a prefix of s₂ or vice-versa.
• If a transaction tx is input to N-f correct nodes, then it is eventually output by every correct node (Censorship resilience).

HoneyBadger BFT implementation

HoneyBadger proceeds in epochs, with a new batch of transactions appended to the (shared) committed log at the end of each epoch. In each epoch, nodes choose a subset of the transactions in their input buffer and provide them as input to a randomized agreement protocol. At the end of the agreement protocol, the final set of transactions for the epoch is chosen.

At this high level, our approach is similar to existing asynchronous atomic broadcast protocols, and in particular to Cachin et al., the basis for a large scale transaction processing system (SINTRA). Like ours, Cachin’s protocol is centered around an instance of the Asynchronous Common Subset (ACS) primitive. Roughly speaking, the ACS primitive allows each node to propose a value, and guarantees that every node outputs a common vector containing the input values of at least N −2 f correct nodes. It is trivial to build atomic broadcast from this primitive — each node simply proposes a subset of transactions from the front its queue, and outputs the union of the elements in the agreed-upon vector.

Standard ACS would not give the desired censorship resilience or throughput properties though. HoneyBadger uses threshold encryption to prevent an adversary from learning which transactions are proposed by which nodes until after agreement has been reached, and it uses an array of techniques to improve the throughput of ACS:

In this paper, we show that by stitching together a carefully chosen array of sub-components, we can efficiently instantiate ACS and attain much greater throughput both asymptotically and in practice. Notably, we improve the asymptotic cost (per node) of ACS from O(N²) (as in Cachin et al.) to O(1).

In a threshold encryption scheme, any one party can encrypt a message using a master public key, and it requires f+1 correct nodes to compute and reveal decryption shares for a ciphertext before the plaintext can be recovered.

In order to make ACS scalable in terms of throughput a batching policy is used in which of N nodes proposes B/N transactions from its queue in each epoch (B is the overall batch size). The batch size is chosen so that the communication overhead of a round is absorbed. The set of transactions chosen by a node is encrypted using threshold encryption. One the instance of ACS is complete, the output is therefore a vector of ciphertexts which can then be decrypted. Thus the set of transactions is fully determined before any adversary can learn what they are.

For ACS itself, whereas Cachin et al. use multi-valued byzantine agreement (MVBA), HoneyBadger uses an alternative scheme proposed by Ben-Or et al.:

The instantiation we use is due to Ben-Or et al. [9] and has, in our view, been somewhat overlooked. In fact, it predates CKPS01 [15], and was initially developed for a mostly unrelated purpose (as a tool for achieving efficient asynchronous multi-party computation [9]). This protocol is a reduction from ACS to reliable broadcast (RBC) and asynchronous binary Byzantine agreement (ABA). Only recently do we know of efficient constructions for these subcomponents, which we explain shortly.

In the first phase RBC is used to disseminate proposed values, and then N instances of the ABA protocol are used to agree on which proposed values are to be included in the final set. The binary agreement element is instantiated with a protocol from Moustefaoui et al. based on a cryptographic common coin and with O(1) running time. Explanation is given in the full version of the paper.

Evaluation

We demonstrate that HoneyBadgerBFT is indeed scalable by performing an experiment in a wide area network, including up to 104 nodes in five continents. Even under these conditions, HoneyBadgerBFT can reach peak throughputs of thousands of transactions per second. Furthermore, by a comparison with PBFT, a representative partially synchronous protocol, HoneyBadgerBFT performs only a small constant factor worse. Finally, we demonstrate the feasibility of running asynchronous BFT over the Tor anonymous communication layer.