Hello!
I'm glad to see you're still around and looking at some of the more advanced issues within the space. I'm really liking how you laid out the issues and the trouble with this type of implementation. These are the exact issues that I've been thinking about solutions to over the last year and I finally found a strategy that has none of these issues mentioned.
Hello Evan! It has been more than a year since we exchanged words.
Aren't you a bit amazed that I can deduce and describe much of your design details without ever being informed of them?
Last time we interacted, the masternode concept was borne. I wonder what might be hatched during this interaction.
If you review the quotes of Evan I dug up and if you understand how he implemented InstantX, then you can deduce very obviously how he is intending to implement faster TPS, as I explained. To resummarize, the block chain hash combined mathematically (hashed?) with the inputs to a transaction is used to determine which quorum of masternodes can sign the transaction, then if M of N of them sign, this is broadcast to the block chain and the transaction is considered confirmed even before the block chain has produced the next block. Note Evan specifically stated inputs and not outputs and I assume the reason is so you can't game which masternodes can be the quorum, but then each input needs to reach a mathematically determined quorum separately (don't know if he has realized that yet), and thus the number of signatures on the block chain will increase by the average number of inputs per transaction (multiplied by N!).
Thus the negative implications of this increased TPS and instant confirmations (which will be realized in his design) are as I stated upthread:
Block chain becomes more bloated due to N times more signatures, not less.
However, signatures only need to be stored for a few thousand blocks. There's simply no chance of a reorg rearranging days of transactions unless something went terribly wrong with the network. In that case, the Bitcoin code is actually setup to halt, which is better than having two competing chains for that long. So in this case, bloat is not an issue.
So long-term bloat is not an issue by essentially employing the conceptual equivalent of checkpoints. But there is a serious issue with large blocks which Bitcoin is having intense struggle over, as it forces centralization of mining whether you use IBLT or whatever, because otherwise the propagation delay of large blocks leads to high orphan rates and exacerbates attacks vectors such as selfish mining. Since Dash doesn't have any where near Bitcoin's volume, this is unlikely to be real world issue for Dash any time soon. But if we were applying your design to a very high volume coin, then we'd have a problem with this design. I won't rehash all the details about the block size debate. There are ample other threads and news sites to explain about that in detail. Any way, sounds like you don't have to solve that issue before January. You can focus on your other core priorities I suppose, since this issue isn't one Dash needs to address until volume increases very significantly. And if volume if ever increases that much Dash will have a much larger market cap and more reason to invest again in further development.
Also, instant transactions are now a natural result of the evolution design, not something build on top as they are currently. Instant transactions built in this way also are anonymous. We're talking about a different technology.
Yeah it is clear to me how you were creating a unifying design.
Immunity to 51% attack is an incorrect claim, because the block chain hash determines which quorum, thus a chain reorganization can rewrite which quorum was authorized to M of N sign.
The proof of work hashes we use are buried deeper in the blockchain for Evolution, beyond the reach of chain reorganization. It's also multiple hashes that will decide the quorum structure, we're calling this technology the quorum-chain.
Well this means masternodes can plan well in advance if for complex game theory. I haven't tried to work out all possible game theories. But any way as I stated up thread, it is unlikely the masternodes have an incentive to conspire to that degree because for one reason they are paid very well apparently. So although this design doesn't appear to be applicable to a coin that despises the concept of the 50% per annum ROI masternode, it may be (somewhat paradoxically to the chagrin of haters) be effectively "secure" in Dash.
The instant confirmations can not be trusted because if they are on an orphaned chain (not 51% attack but just the normal process of orphan rate or even 25 - 33% selfish mining attack), then they can be reversed.
In Evolution, miners don't decide which transactions are mined, the masternode network does via Quorum technology.
Okay then essentially the same argument again which is that for as long as we can assume masternodes are so well paid that they don't have incentive to explore ways to conspire, then pseudo-randomness can appear to be equivalent to randomness.
