Efficient blockchain architecture based on FIDO keys | Hacker News Reader

Efficient blockchain architecture based on FIDO keys

dandanua.github.io

51 pointsdandanua58 comments

If the reward is being able to print money for yourself (that's what a double spend does), there will be very strong incentives to research a way to taper with a FIDO device and keep the results private.

This threat model would not survive the real world even at low adoption rates.

The threat model is heavily based on tamper-resistance of the devices. But I don't think it can't survive.

Also, tampering the device can ruin the network, but it can't print new money.

Who prints new money?

This question is open for invention. A blockchain can have no money at all. People can just play games on it and everyone will agree on the objective history of all games played.

For example, you can assume that there is a fixed amount of money initially distributed somehow (many cryptocurrencies do just that).

Double spend doesn't involve printing money. Especially it doesn't automatically give you twice the amount of cryptocurrency you already had. You need some other half of the double-spend transaction to take from, and that may be tricky to do, especially at scale (and especially if you want your ill-gotten gains to be worth anything).

You can make money off of a double-spend attack, but it's not as simple as 'you double spend, then get as much money as you want'.

> But we can assume that manufacturer has no incentives to make incorrect devices to harm the network.

Whenever I hear about ideas to use hardware to ensure that some fact about the real world is accurate or to act as some kind of incorruptible source of truth, I just have to roll my eyes.

It's wishful thinking to suggest that the manufacturer has absolutely no incentives to make incorrect devices to harm the network... Kind of like how the reserve bank has no incentives to print money and give their rich friends priority access to the new money... That doesn't harm society right? All my rich friends certainly agree!

Once you get hardware involved, it forces people to trust a centralized entity even more than a pure software solution since the complexity and capital barriers go up.

Besides, I don't even see how the hardware-generated ID solves the problem regarding the transaction order... There is still no guarantee that the transaction with the lowest ID will reach all the nodes before the one with the higher ID due to unpredictable network latency during the propagation... What if that lower ID transaction gets lost entirely? Will that account be locked forever (since the ID only increments) - How to recover from the situation where there are gaps between IDs? You would need to timebox it to decide how long to wait before we allow skipping a specific ID... How about we make one of the nodes decide when the time slot ends and maybe call that a 'block'? Wait, that already exists, it's called plain old blockchain.

The hardware signing is not enough for transaction to be accepted. User signing is also required. You need two signatures, that are linked to each other.

As for IDs, this is the right question :)

You are not allowed to have gaps in transactions counter. You have to submit all of them to the network. Sure, you can have some transmission failure due to broken connection or computer failure. For such case a device can have memory of signed transactions (at least recent ones) and re-transmit them until they reach the network.

The author says that PoS algorithms are centralized at heart, but does anyone know how this applies to Nano? I read the paper a few years ago and couldn't find any obvious disadvantages or centralization to it, and it has PoS, no fees, and instant sending.

It's always seemed too good to be true, but I've never seen anyone mention a big downside to it, so I've always wondered.

It's a bit of a strange comment. One could certainly argue that in a proof of stake system a dynamic naturally exists where those who stake more earn more, and can stake more to earn more to stake more...

The thing is though is you could say the same for traditional crypto mining. In either situation one person holding too many opportunities to author new blocks is a chance to double spend (though highly mitigated by simply waiting longer for newer blocks to come through before accepting trades).

Would you say that the existing PoS systems (like Ethereum 2) aren't as centralized as he mentions, then?

ETH2 doesn't 'exist'. There is a heartbeat chain right now, but it doesn't actually do anything. Getting to the next step(s) is the hard part.

Full PoS decentralization does not exist yet. Many attempts exist. Some better than others. Sadly, the complexity (rube goldberg) of PoS far outweighs the simplicity of PoW.

> Full PoS decentralization does not exist yet.

How do you define "full PoS decentralization"? That sounds a bit no-true-Scotsmany.

> Sadly, the complexity (rube goldberg) of PoS far outweighs the simplicity of PoW.

Yes, and the huge energy usage of PoW far outweighs the zero energy usage of PoS. That's the tradeoff.

It doesn't exist because ETH2 doesn't exist. It is the one blockchain that I see as being focused on full decentralization, instead of just stopping at variations of tendermint and a bunch of "approved" validators.

Contrary to popular belief, PoS isn't zero energy usage. My very very very large ETH1 gpu mining operation sits next door to the same large data centers powering all the cloud providers. All getting power from the same hydrodams that would just go to waste otherwise. It isn't like the power can be easily used in other ways... transmission of power is expensive and intrusive.

Bitcoin is an issue because of supply/demand... when the reward goes away, so will the miners. Difficulty will drop to more acceptable levels to cover the loss. ETH1/ethash at least tries to peg to a specific type of hardware that actually has a better roi with older models and doesn't need the latest / greatest.

The tricky bit to make ETH2 work will be the use of zkSnarks. What nobody talks about is how compute (energy) heavy they are currently. It is a bit of moving the goal post if we're going to just end up building asic's again.

>One could certainly argue that in a proof of stake system a dynamic naturally exists where those who stake more earn more, and can stake more to earn more to stake more...

Everyone grows at the same rate though. If someone stakes 1% of the total pool and someone stakes 99%, then after making more they will still be at a 1:99 ratio.

NANO has delegated Proof-of-Stake. It's the representatives who vote on transactions. And it's supposed they don't have incentives to ruin the network. It's true, but a single representative can be captured by villains, who CAN have incentives to ruin the network.

I actually like NANO, their blockchain structure is certainly next level, but it also has vulnerabilities due to PoS consensus.

Hmm, does it guard against minority representatives being able to do damage? If you have thousands of representatives, capturing one won't do much, correct?

If his vote is not decisive then yes. But, in theory, a vote of the representative that has low stake can be decisive. The commitment of two conflicting votes can split the network, thereby ruining it.

Ahh, that's interesting, thank you. It sounds like a low probability scenario, but not impossible.

You can try to raise this probability by DDoSing representatives with high stakes.

> The commitment of two conflicting votes can split the network, thereby ruining it.

Couldn't this be repaired (with probability something like 1-O(compromised stake) per attempt), by exhibiting (in, say, lexicographic order) the two conflicting blocks (thereby invalidating both), and continuing with the chain?

Eg, crude sketch off the top of my head:

  A -> B1
  A -> B2
  A -> B2 -> C2        # built off conflicting chain
  A -> b1 -> b2 -> C3  # resolved chain (block b dead)

The resolved chain would have more blocks initially (2 vs 1), and roughly twice the number of nodes supporting it (since the split chains would by construction be valid to only about half the network each.

I'm not sure the logistics of this works out, so non-rhetorically: could this work? I'm cribbing some intuitions from proof-of-work designs, but it seems like it ought to be possible in principle.

I'm not fully following your logic, but to resolve that problem you need another consensus algorithm over the votes of representatives. And I don't know how we can effectively use the fact, that a probability of harmful representative behavior is very small.

Basically, a representative who splits the network by commiting two conflicting votes is (AIUI) by definition defective, and any representative that observes both potential blocks knows that, and can propagate that knowledge to any representative it communicates with (which must be most of them in order for them know what that (observing) representative's vote was). And once most representatives know that a vote was spoiled, they can throw it out (along with the two blocks it distiguishes between, although I think those still need to stored, just the transactions in them are treated as not having happened).

But, as I said, I'm not sure about the logistics/provable-correctness of making sure that the half of the network that voted one way and the half that voted the other way always have a chance to compare notes soon enough to catch a spoiled vote.

This is not how Nano works. You need to compromise 51% of the online voting weight. There is also no splits in the network. Once a transaction has been confirmed it is final.

Yes, you have to control 51% of the online voting power.

Nano uses open representative voting, not DPoS and you would need much more than a single representative to hurt the network. The largest representative currently has 19.8% of the online voting weigh. An attacker would need to get above 50%.

Nano uses open representative voting. There is no staking.

> I don’t believe it’s possible to find an efficient consensus algorithm, which would be truly decentralized

Unless I misunderstand the meaning of "truly" decetnralized, there is one known. It's called Ouroboros, it's being used by both Polkadot and Cardano. It's a decentralized Proof-of-Stake protocol (currently ~80% of Cardano block generation is decentralized, the goal is to reach 100% in March).

The 2019 paper: https://eprint.iacr.org/2016/889.pdf

(Edit: the article is still an interesting read, thanks for sharing)

this article describes a centralised system with the fido2 key manufacturer as the source of truth

The hardware isn't supposed to connect to manufacturer servers, so how manufacturer is going to make decisions?

the fundamental assumption of the system as stated in the article is that the device manufacturer will simply never attempt to forge keys

It has no incentives to do that. Device keys are second-factor keys. The user has its own, personal (software) keys. You need both to make a transaction.

The idea is that the device manufacturer would create a user, get a bit of the currency, and then spend it repeatedly.

And that the private keys of the manufacturers will never be stolen or discovered.

The manufacturer can deny service to undesirables[0], by refusing to provide them with fido2s (either initial or replacement when broken). If we're willing to accept targeted denial of service we might as well have the New York Times (or whoever) publish hashes and timechain-encrypted transactions for tick N alongside decrypted transactions for tick N-1; that requires less secrity and infrastructure from the central authority.

0: I could give a long list of historical examples demonstrating that is in fact a problem, but frankly, if you (think you) are not a member of any demographic that someone considers undesirables, then I consider you a undesirable.

How do you keep people from simulating a fido key? There is intrinsically no way to detect if the hardware signature was actually done by hardware.

FIDO has a device attestation https://developers.yubico.com/U2F/Attestation_and_Metadata/ But their scheme indeed looks like flawed.

There is a way to make it correct, though. Device manufacturer also has to inject its own root private key into the device. So the device will use additional, third signature on behalf of manufacturer.

Then the root private key gets extracted, because there's lots of money to be had from doing so

If you are the manufacturer, who already know the root private key and can make some fake users, you still won't be able to print new money from nowhere. Yes, you CAN make double spending, but this will just split the network, because every participant will accept only one spend, not both.

Who and how issues the new money? how do you decentralize that? Otherwise you have a central bank and a database is more efficient.

That’s a problem that has already been solved in various ways by existing cryptocurrencies. For example, NANO was premined and then distributed via a faucet that required solving CAPTCHAs. Other cryptos just award holders more coins, or use other solutions.

That is Yubico's flavor of U2F attestation. U2F has been succeeded by WebAuthn, you'll probably want to look at https://www.w3.org/TR/webauthn-2/#sctn-defined-attestation-f... instead.

Why do you feel there's a flaw? The «root» key signs the batch keypair. It's a normal certificate chain.

According to this [1], keypairs are generated randomly on a registration request. To sign such keypairs root private key must be somewhere on the device. But I don't see a mention of this in the docs.

[1] https://developers.yubico.com/U2F/Protocol_details/Key_gener...

There's a separate attestation keypair that is static, is either unique per device or unique per 1k-100k batch of devices and signed by a manufacturer key.

There's no need to keep a "root private key" on device.

https://developers.yubico.com/U2F/Attestation_and_Metadata/ https://fidoalliance.org/fido-technotes-the-truth-about-atte...

Thanks, the second link explains it quite clearly. It's indeed a safe and logical scheme of device verification.

I find this a really interesting take. Wouldn’t someone be able to produce his own FIDO key that can send two transactions with the same sequence number though?

Yes, there should be a defense against device simulations. For example, a manufacturer can insert its root private key in the devices and use it for additional signing.

So the manufacturer must have the private keys copied onto every device, so that key must be present and cleartext on every production line.

And at the same time it must prevent leaking of such key.

Not to mention that leaking of such key could happen from the hardware too.

Just a random terrible incomplete idea in my head. What if instead of the device generating the transaction sequence number, the sequence numbers were provided to the client ahead of time and signed by a trusted third party? Essentially you get a sequence number ahead of time and a window in which to use it.

If you know the sequence number ahead of time then you can attach any transaction to it, including two conflicting. The point of hardware counter is that you (your device, actually) sings a counter along with a transaction. You couple them together in a way, that you can't counterfeit, because you can't tamper the device.

related project from a few years ago: https://news.ycombinator.com/item?id=15382911

(basically uses intel SGX instead of FIDO keys)

In the current use case of FIDO keys, it's in the user's best interest to ensure that the hardware is genuine, not tampered with, etc. In this proposal, it's the reverse: the user benefits from tampering with/simulating the hardware.

Not really. If someone will be able to tamper the device and submit conflicting transactions then this will just split the network. This will be seen and just ruin the network. He can't print additional money in this way.

This is a truly FIDO key producers centralized consensus network.

What happens if you lose FIDO key or key was destroyed in fire ?

You can register another hardware key with your personal (software) key. It's mentioned in the article.

What about in case key is lost or misplaced?

What happens when you lose or misplace a $100 bill?

Reply on news.ycombinator.com