Their design lacks several of the key features of my design wherein I can (in theory) attain confirmations in seconds or less with real world network performance far in excess of Visa scale with current hardware and internet connections. I did see one key element of my design in their design, but Dash Evolution sort of has this same element too, so this one element is not the key epiphany to get to my design.
The following criticisms of Factom appear to apply to this Bitcoin-NG proposal as well:
Since Factom uses the Bitcoin block chain, it doesn't defeat selfish mining employing my math derivation.Since Factom uses the Bitcoin block chain, it doesn't fix mining so that proof-of-work is unprofitable for ASICs and thus only the users mine.Since Factom uses the Bitcoin block chain, it doesn't eliminate the 51% attack.Factom transactions don't become irreversible for 10 minutes, whereas my design is on the order of a second or seconds to become irreversible.
In Bitcoin-NG, the winner of a block solution does not propagate a block of transactions. Instead that node wins the right to propagate smaller micro-blocks of transactions at shorter intervals than 10 minutes. The next winner of a block solution signs the last micro-block seen, thus tying that (and preceding) micro-blocks into the block chain. The economic incentives to propagate these micro-blocks seems not well designed, and it certainly doesn't solve the selfish-mining nor the 51% attack.
The advantage is of Bitcoin-NG's design is that micro-blocks can propagate more frequently; and thus one huge block doesn't have to propagate instantaneously every roughly 10 minutes. This is essentially eliminates the transient spike of the Satoshi design; and thus improving aliasing error which takes the form of propagation delay and orphan rate in Satoshi's design. However these micro-blocks are not confirmed until the next 10 minute block is won; and thus afaics Bitcoin-NG does not speed up transaction confirmation speed. Blockchain-NG enables the block chain to scale to the rate at which the prior block winning node can process transactions and propagate them to the network; and scales without requiring all nodes to have the same capabilities nor delegate to more powerful nodes such as Gavin's proposed IBLT design.
However, the same criticism I leveled again BitShare's 2.0 design applies, in that the performance will vary every 10 minutes depending on which node has won each successive block.
BitShares 2.0- Any engineer should know the antithesis of reliability is lack of fault-tolerance, i.e. depending on only 1 node for each block validation. Variability in the network hiccups, DoS-resistance, hardware, and other aspects of witnesses will mean that some can't keep up with the 3s block time every time or they drop transactions and transactions need to propagated to further witnesses and blocks. So either will have unreliability on the real-time promise, and/or this will push approval voting for witnesses that are centralized by those who have the resources to defend their nodes and maintain uptime and performance loads. These issues don't matter as much with longer block times and/or lower expectation of tps, but if you are seriously expecting 1000s of tps in 3s block times sequenced (funneled) into a queue of witnesses then issues will amplify exponentially not just linearly.