phlip9

+ Since Libra uses a HotStuff variant, you need to control 2/3+ of the voting power to violate safety, i.e., double-spend. In exchange, however, you only need to control 1/3+ to halt progress (liveness).

Some issues, however:

1. His argument against BFT is "legal systems are efficient" (lmao). Also, the whole point of HotStuff (vs. PBFT etc...) is linear O(N) communication complexity outside of cascading proposer failures...

2. He clearly didn't investigate move bytecode-verifier, which asserts linearity.

3. Strong disagree on the untested crypto-primitives argument. curve25519-dalek is audited (x2) and written in Rust; simple and minimal; not a bloated, unauditable mess like TLS.

4. Consumer protection can be built on top via the wallet providers.

To be honest, the whole money laundering point is so overblown anyway. For comparison, Bitcoin's transaction history is totally transparent and fairly simple to run basic clustering and taint analysis algorithms for deanonymization. People trying to avoid AML need perfect OPSEC and extreme discipline not to recombine change outputs. In Libra the privacy is even worse, since it uses an account-based model. I greatly suspect that it is easier to avoid AML in our existing system than it would be in a Libra world.

FWIW, if you're trying to avoid AML today, then you should use ZCash or Monero. Both have cryptographic privacy that hides both the amount and sender+receiver.

It seems the Congressman mistook an unofficial 3rd-party js repo whose author is Nigerian as an official Libra project...

Adding on to this, nQUIC (and Noise specifically) is significantly better for use-cases where CAs and traditional PKI don't make sense, e.g., p2p, VPN, TOR, IPFS, etc...

I agree that APT is not one of these cases. Currently APT has a root trust set that is disjoint from the OS's root CA set, but they could easily do HTTPS and just explicitly change the root CA set for those connections.

EDIT: from the nQUIC paper:

> In particular nQUIC is not intended for the traditional Web setting where interoperability and cryptographic agility is essential.

On another note, I think it would be helpful to expand some points for other readers:

> nQUIC also doesn't have a 0-RTT mode. Noise proponents can say "That's a good thing, 0-RTT is a terrible idea".

0-RTT is dangerous because of replay attacks. It pushes low-level implementation details up the stack and requires users to be aware of and actively avoid sending non-idempotent messages in the first packet.

> Maybe so, but you don't have one and TLS does. If society decides it hates 0-RTT modes because they're a terrible idea, we just don't use the TLS 0-RTT mode and nothing is lost.

One major point of using Noise protocol is to _simplify_ the encryption and auth layers, remove everything that's not absolutely necessary, and make it hard to fuck up in general. Things like ciphersuite negotiation, x509 certificate parsing and validation, and cryptographic agility have been the source of many many security critical bugs.

From an auditability perspective, Noise wins easily. You can write a compliant Noise implementation in <10k loc, vs. OpenSSL ~400k loc.

> But if as seems far more likely we end up liking how fast it is, Noise can't match that. Doesn't want to.

HTTP is insecure, but faster than HTTPS. Most sites now use HTTPS regardless. 0-RTT is insecure and while it might be OK for browsing HN, removing 0-RTT makes it much harder to fuck up.

From the Cardano paper [1] p. 47,

> Even if the attacker could find a strategy to generate an alternative chain with valid leader selection data, presenting this chain and its blocks generated at slots that are far ahead of time would not result in a successful attack since those blocks far ahead of time would be rejected by the honest stakeholders and the final alternative chain would be shorter than the main chain.

At first glance, the attacker then needs to gain the keys for almost all of the bonded stake at some point in the past. This is obviously a stricter requirement than holding keys for 2/3+ of the stake at some point in the past, but still seems remotely plausible when targeting the small set of validators in the early bootstrapping period. Remember also that these early validators could be totally cashed out of the system and thus have actually have no disincentive not to sell their keys.

Actually, even controlling only 2/3+ of some past stake, the attacker can likely grind on the randomness beacon outputs (since they control all the shares) to ensure his controlled keys have near 100% of the slots in the next epoch. Then the long range fork would be of a similar or possibly even greater length than the honest fork.

[1] https://eprint.iacr.org/2016/889.pdf

The validator set changes as people bond or unbond coins in exchange for stake. Running a fair and secure initial distribution is a somewhat orthogonal problem; perhaps you can run an open auction. Any Proof-of-Work or Proof-of-Stake systems has issues with low security in the beginning. Consider that until late ~2012 the total hashrate of the Bitcoin network was less than the hashrate of a single Antminer S9.

> This is the general problem of proof-of-stake: it assumes the presence of consensus in order to arrive at consensus. This is because consensus is reached by utilizing the scarce resource that is the chain’s token, but without consensus in the first place this token isn’t scarce at all.

Consensus and scarcity are tightly related. The consensus process and protocol spec are what make the token scarce, since by definition the majority agree on the token's inflation rate, supply, block reward, etc.... What happens when validators try to fork and change these parameters? They are directly incentivized to do so, yet similarly, what happens when Bitcoin miners try to change the block reward? Of course, they don't hold all the power; with sufficient cause and collaboration, users can signal a user-activated soft fork, or simply choose to follow the original unmodified fork.

> Proof-of-work uses something external to its chain as the scarce resource that determines consensus (energy), while proof-of-stake uses something internal to its chain (the chain’s token). This means that when a PoW chain forks, the two chains have to share the external resource, while the resource is copied for PoS chain forks.

Yes, this is called the "nothing-at-stake" problem, and it is solved by punishing validators who equivocate. This enforces scarcity of voting power across forks. The point is they can't exercise their voting power on both chains. As soon as they vote on one fork, they are committed. The validators on the other fork are incentivized to delete their stake if they vote on the other fork simultaneously.

1. Assume we have some set of "validators" who control the global consensus process. They come to consensus on the current global state of the system. These validators are vaguely analogous to miners in Proof-of-Work consensus.

2. These validators have coins bonded as collateral in exchange for more voting power in the consensus process.

One key idea necessary for Proof-of-Stake is to punish Byzantine validators, i.e., those who deviate from the consensus protocol, by destroying their bonded stake. If you misbehave, then you lose some proportion of your collateral. Thus, validators have incentive for participation (from rewards and fees) and a _disincentive_ for malicious behavior.

This is in contrast to Proof-of-Work consensus, where there is no way to punish a specific miner that misbehaves--we cannot programmatically take away physical mining ASICs. Changing the Proof-of-Work function is only an absolute last resort as it unfairly punishes the other honest miners.

So what constitutes misbehavior? When can we confidently punish another validator? An example is when a validator publishes signed attestations for conflicting forks--an example of equivocation. When presented with signed evidence of equivocation, the honest majority of validators can agree to punish the equivocator. This punishment system solves the original "nothing-at-stake" problem where a validator has no disincentive not to contribute to both sides of a fork.

On another note, the OP seems to misunderstand the fundamental consistency vs availability (in the event of a partition) trade-off that consensus algorithms must to make. Bitcoin's Proof-of-Work is more AP with probabilistic eventual consistency. In the event of a partition, the side with less mining power will make transactions unaware of the partition. When the partition heals, all transactions on the weaker side will revert, effectively double spending all transaction recipients on that side.

In contrast, many Proof-of-Stake protocols use a more traditional PBFT-style consensus process which favors consistency over availability. In the case of a partition, the weaker side will simply become unavailable (if it contains less than 1/3 of the voting power). In the event that no partition has >2/3+ of the voting power, the entire system will become unavailable. Also in contrast to PoW's eventual consistency, PBFT-style Proof-of-Stake allows for finality as soon as the validators come to consensus on the next block.

At ~50% hash power and with a victim who waits <10 confirmations you still only have a ~1/2+o(1) probability of mining a longer private chain. The point is if you can maintain the 50% long enough, you can expect to eventually have the longer chain.

You can also have <50% hash power and double spend, it is just progressively less likely to succeed. The calculations in the Bitcoin whitepaper (p.7) for choosing a transaction confirmations threshold assume the attacker can maintain their attack indefinitely [1].

To clarify, the whole point of selfish/stubborn mining is to increase your mining profit by wasting the honest miners' time when you withhold new blocks (so they unknowingly mine on a shorter chain) and then trying to propagate your withheld block faster when you see an honest miner release a new block. Therefore you get a greater effective proportion of the network's hash power. Of course if you're more than one block ahead of the honest chain, you can just propagate the next block in your withheld chain. But, when you're attempting a double spend, your withheld chain has to remain private the entire time otherwise the victim would see the honest transaction invalidated and cancel the e.g. exchange withdrawal.

There's a cool paper on some extended selfish mining strategies combining eclipse attacks [2].

Also interesting to note is that selfish mining is only profitable if only a few miners are using it, like a kind of prisoner's dilemma [3].

[1] https://bitcoin.org/bitcoin.pdf [2] https://eprint.iacr.org/2015/796.pdf [3] https://arxiv.org/pdf/1411.7099.pdf

However, as long as you have any source for the most recent block that the MITM does not control, they cannot trick you into following a shorter chain. In other words, as long as any side-channel (malicious or otherwise) posts blocks, you can always follow the longest chain. The Blockstream Satellite [2] was created for this reason -- so that nodes always have a reliable side-channel separate from the bitcoin protocol to verify blocks coming from the bitcoin network. Alternatively, some nodes check Tor mirrors, which should be difficult for adversaries to control.

[1] https://eprint.iacr.org/2015/263.pdf [2] https://blockstream.com/satellite/

[1] Zcash: https://z.cash/