Sybil is a real pain, and HashCash (via I2P, which had it as an anti-DoS option) was the first obvious attempt at a solution that worked. It would be better done with Argon2 now, but it still burns coal and is a bet that evil nodes don't have more power than all the good nodes put together - it seems we aren't always going to win that bet.
Will proof-of-stake would be any better? It doesn't feel as suited to things other than currency to me, because: what value does the deposit have? We'll see how it turns out when deployed, it's hard to predict how people will react.
There's a surprising amount of heat in the field now. Lots of activity, like this interesting work, some very strong opinions. Please don't eat me! I'm quite happy to leave it be and move onto other things.
The author's goal for this design seems to be to increase mining decentralization, but there's another big advantage to a blockless graphical ledger over a blockchain. By attaching proof-of-work to each transaction rather than to a block of multiple transactions, a blockless scheme asks miners to answer a simple cost-benefit question: does the payoff to putting the transaction in the ledger (in transaction fees and seignorage) exceed its cost (in hashing resources)?
Particularly when seignorage is zero, so that a miner's only compensation for providing proof-of-work to a transaction is the fee it offers, this eliminates a free-rider problem created by blocks in a scheme like Bitcoin's; as long as you can include as many transactions in a block as you like, the cost of including another one is nil, and so miners have an incentive to include every transaction that pays a non-zero fee, no matter how small [0]. That means the equilibrium price of putting a transaction into Bitcoin's blockchain, for example, may never rise much above zero. That's a real problem for the long-term security of the Bitcoin blockchain.
Per-transaction proof-of-work eliminates that problem by making both the cost and reward of adding a transaction to the ledger a function of the properties of each transaction, rather than of an arbitrary aggregate of transactions.
0. This isn't true if there is a binding limit on the size of blocks, as there is now in the Bitcoin protocol. But a wholly arbitrary block-size limit is a terrible solution to this problem because it is unresponsive to economic factors. It may be possible that a non-zero equilibrium price of transacting could arise in response to other constraints (like the risk of "orphaning" a large block due to the increased time it takes to propagate around the network), as some people have argued in the course of Bitcoin's ongoing block-size war.
What does it mean for a transaction to reference previous transactions? Is it just listing them, rather than using them as inputs?
> If two conflicting transactions appear, as more transactions are added to the
DAG-chain, the number of confirmations of one of the two will increase, but the other will not
Is that just because people go with whichever has the most references and/or proof-of-work so far?
16 comments
[ 3.4 ms ] story [ 37.9 ms ] threadTo my understanding it works out as a combination of prediction market style betting and bidding for a block to be accepted.
Will proof-of-stake would be any better? It doesn't feel as suited to things other than currency to me, because: what value does the deposit have? We'll see how it turns out when deployed, it's hard to predict how people will react.
There's a surprising amount of heat in the field now. Lots of activity, like this interesting work, some very strong opinions. Please don't eat me! I'm quite happy to leave it be and move onto other things.
Particularly when seignorage is zero, so that a miner's only compensation for providing proof-of-work to a transaction is the fee it offers, this eliminates a free-rider problem created by blocks in a scheme like Bitcoin's; as long as you can include as many transactions in a block as you like, the cost of including another one is nil, and so miners have an incentive to include every transaction that pays a non-zero fee, no matter how small [0]. That means the equilibrium price of putting a transaction into Bitcoin's blockchain, for example, may never rise much above zero. That's a real problem for the long-term security of the Bitcoin blockchain.
Per-transaction proof-of-work eliminates that problem by making both the cost and reward of adding a transaction to the ledger a function of the properties of each transaction, rather than of an arbitrary aggregate of transactions.
0. This isn't true if there is a binding limit on the size of blocks, as there is now in the Bitcoin protocol. But a wholly arbitrary block-size limit is a terrible solution to this problem because it is unresponsive to economic factors. It may be possible that a non-zero equilibrium price of transacting could arise in response to other constraints (like the risk of "orphaning" a large block due to the increased time it takes to propagate around the network), as some people have argued in the course of Bitcoin's ongoing block-size war.
> If two conflicting transactions appear, as more transactions are added to the DAG-chain, the number of confirmations of one of the two will increase, but the other will not
Is that just because people go with whichever has the most references and/or proof-of-work so far?