Initial reactions:<p>1. Sybil-resistance (faking strong consensus by deploying cheap replica nodes you control) in a protocol like this is crucial. All I could find is this:<p><i>To prevent Sybil attacks, it uses a mechanism like proof-of-stake that assigns weights to participants in committee selection based on the money in their accounts.</i><p>2. Every non-proof-of-work protocol I've seen, including Ripple Consensus Process and proof-of-stake creates a problem of initial coin distribution. PoW systems have a clean distribution mechanism based on external resource consumption. Non-PoW systems produce an airdrop situation. Players start with no funds, and so can't stake. The creator of the network manually assigns ownership, with important long-term political consequences (e.g., Ripple).<p>3. The lack of an incentive structure around fees in protocols like Ripple creates bizarre economic consequences. For example, Ripple is guaranteed to lose money stock because fees are simply burned, rather than given to the consensus leader as in Bitcoin.<p>4. So far, I haven't seen anything in the paper regarding denial of service attacks on nodes. In other words, I see no negative incentives levied on those who can sign transactions from flooding the network with useless spam, bogging everything down.
This seems like a thoroughly thought out version of a DAG (directed acyclic graph) based currency. I don't have time to go through it with a fine toothed comb, but I'm curious about others' reactions.<p>There are well known problems with DAGs: lack of incentive to run full nodes, tip choice attacks, flooding/spam attacks if there are no fees, and many and varied types of Sybil attacks.<p>For flooding or spam a transaction proof of work isn't enough. Not only does it "waste" a lot of energy (though at the edge nodes where it's less visible than mining farms) which negates part of the purported benefit of a DAG, but it's vulnerable to ASICs or botnets. If you can short a cryptocurrency on any major exchange that supports short selling then it will get attacked with the goal not of stealing coins or censoring transactions but of just destroying it.<p>Tip choice attacks combined with Sybil attacks can be very sophisticated. Tip choice is "random" but randomness cannot be verified. 3, 18, 593, 3, 3, now prove those were not random numbers modulus 1024. You can't of course. So I can non-randomly choose the transactions I link to. If I combine this with some sophisticated analysis of the network's transaction structure and physical topology I might be able to skew the network in some disastrous way over time in ways that would be completely undetectable since my apparently "random" tip/link choices were not in fact random. Then I can do something like short the coin and do something nasty to the network.<p>Attackers can be very <i>very</i> creative, and attacks only get better.<p>Last but not least: there is no mining mechanism in a DAG coin, or at least I've never heard of how one could be done. This means DAG coins are "Big Bang" coins that begin with all the money that will ever exist. This is problematic from an economic point of view and opens a huge can of worms around what is done with that money and how it is distributed to initial holders.
This sounds an awful lot like each transaction can consume exactly one UTXO, but can have multiple UTXO outputs. This would cause progressive "shattering" of the UTXO set into millions of low-value "dust" UTXOs, a problem that Bitcoin is struggling with (specifically, how best to incentivize "cleaning up" the UTXO set by making transactions with multiple inputs, even though that increases the overall transaction size).<p>"We adopt what is commonly known as Bitcoin’s unspent
transaction output (UTXO) model. In this model, clients
are authenticated and issue cryptographically signed
transactions that fully consume an existing UTXO and
issue new UTXOs."
It would be good if the authors would have extended figures 20, 21, and 22 out to networks of size 20,000 or more nodes. Or at least described what they expect to happen. I.e. if you have many more nodes, does the throughput remain above 1k tps?<p>I also always like authors who are willing to acknowledge the limitations of their work. If this work described the limitations I didn't see it; maybe they think there are none :-)
At this point, are these papers simply to reduce the cost of verification?<p>It seems thats the only problem in the crypto world, but I dont know if verification will ever be scalable.