Shelby Moore
Dec 22, 2016 · 3 min read

Quoting from the whitepaper:

two conflicting payments that are published concurrently could only have been created by a dishonest user

Afaics, this fundamental assumption which your design hinges on, does not work in a crypto-currency system.

What if a user needs to increase the transaction fee paid because none of the miners are including the transaction?

The body of a transaction specifies the amount transferred from the payer to the payee. The transaction-fee specifies the payment from the payer to the miner whose block contains the transaction.

But what if the contract between the payer and payee is that the transaction fee is to be taken from the amount paid to the payee?

Edit: Fuserleer (eMunie developer) has pointed out that this requires external synchronization which is generally impossible on networks, e.g. wherein a company has multiple nodes across the network which issue transactions asynchronously. Thus employing the blockchain as the synchronization mechanism. If the company tried to employ their own blockchain for synchronization, then forwarded the transactions to your blockchain, then it requires one node to synchronize to do the forwarding, which is not resilient. In general, asynchrony can’t be avoided.

A user can’t be permitted to honestly reuse an address as would be the case in partial orders or an account balances design, thus you need a global UTXO. But how can all the nodes synchronize on a UTXO set if they are not synchronizing on a single longest-chain? In the presence of double-spends, the resolution is probabilistic thus nodes could disagree as to the valid UTXO set. Or do nodes allow downstream transactions for all the conflicting double-spends? I am envisioning this could become a mess of downstream transaction spaghetti which is in essence is inflating the money supply. The system continues to track and allow transacting of all double-spend forks, thus both are money.

if two conflicting transactions were published at about the same time, the identity of the prevailing transaction might remain undetermined for arbitrarily long periods of time.

Which if any of the scenarios I wrote above are valid, then honest users can have their coins indefinitely frozen.

Note that this scheme can be used to settle conflicts between blocks of multiple parties simultaneously. Furthermore, the settlement scheme need not be confined to conflicts regarding fees, and can be applied to any double-spending.

This should have many pitfalls. Coordination is what a permissionless, trustless consensus protocol is supposed to solve.

fast blocks can be created, up to the limit imposed by network congestion and bandwidth that is required from nodes to receive a full copy of all transactions

That is O(n²) which is not scaling. Low hashrate nodes need the same infrastructure for transaction volume as higher ones.

This will reduce the need for large mining pools

Which thus seems to ameliorate to some extent the above claim.

The new difficulty, with which the new reference block should be mined, is given again through the formula that uses the time that elapsed between xn−1 and xn to update TARGET. The formula should aim for a predefined λ for which nodes are believed to have sufficient bandwidth, e.g., 1 MB per second.

This requires a centralized hardfork to increase the throughput limit of the network.

Additionally, I didn’t dig into the consistency proofs which afaik are dealing with the pairwise ordering not a total order, thus I don’t understand conceptually how it could be possible for blocks which don’t coordinate on a total order to coordinate their agreement on difficulty retargeting. I expect some vulnerability or flaw in your analysis around this conceptual point.

These numbers assume that blocks (e.g., of size 100 KB) propagate to the vast majority of mining nodes within 5 seconds.

You model approximately 10 second confirmations presuming propagation to the majority of systemic hashrate within 5 seconds.

That is unacceptably slow for a social network such as Steem(it) which needs to place each user action on the blockchain. It is too slow for microtransactions that need real-time confirmation.

Lastly I don’t see how this design resolves the claim (which I think it a fact) that proof-of-work is a winner-take-all power vacuum due to disproportionate rewards accruing to those with more economies-of-scale. Your design might remove the losses for small miners due to orphaning via propagation delay, but that is not the only economy-of-scale factor driving proof-of-work towards the winner-take-all power vacuum. Also I intuitively anticipate some sort of difficulty retargeting attack which disadvantages lower hashrate miners, because the weaknesses in your design will popup in the areas where you are trying to avoid having a total order coordination among the miners.

    Shelby Moore

    Written by