[Whitepaper] The Decrits Consensus Algorithm

[Ix]

The Decrits Consensus Algorithm: Decentralized Agreement without Proof of Work

arxiv link

Decrits is a cryptocurrency that is being developed in the Go programming language. I first decided to create a competitor to Bitcoin in 2011 after studying it for a few weeks and losing my initial appreciation for it. I've posted several proposals since then, refining it as I went. It's been a long process, but the design is essentially complete, it just needs more code.

I've previously posted under the usernames Etlase, Etlase2, and etlase3. Etlase had posting privileges removed because I was too outspoken an opponent of Bitcoin. Etlase2 was hacked in January 2014 (and apparently the original Etlase was at some point prior to that as well). Figuring the account might be sold--and it was--I created a different handle around the same time as etlase3 to cut ties if need be.

The most recent Decrits discussion thread on bctalk is here: https://bitcointalk.org/index.php?topic=189239.0

www.decrits.net is a new forum I've setup for discussing ongoing Decrits development.

I'm tired at the moment and just want to put this out there, I will be around to discuss any questions, comments, etc. here and on the Decrits forum later.

Hope you enjoy the paper, and thanks for taking the time to read it.

[KeyserSozeMC]

This looks interesting, reading.

Wow, damn. Imagine google talking about it.
That new crypto could have a good future, for sure.

[Coin-Moron]

You are late*.
Can succeed only if its not an IPO.

*- Every Altcoin trader's penny are lured and looted already, so no money to buy or trade.

[zrunfeng]

where is the Whitepaper

[SpainCoinDev]

Was it really necessary to switch all terms everybody is familiar with? Anyway, have you read this? Also, you're not providing enough details about how minting goes exactly, or how you plan on avoiding the well-known PoS shortcomings.

[KeyserSozeMC]

where is the Whitepaper

It's in the OP. Find the link.
It's not going to scream "I'M THE WHITE PAPER, I'M HERE".

[Ix]

Was it really necessary to switch all terms everybody is familiar with? Anyway, have you read this? Also, you're not providing enough details about how minting goes exactly, or how you plan on avoiding the well-known PoS shortcomings.

It seems like you're responding to the thread not the paper, which is fine but the thread has its own thread. The paper only introduces like three new terms. I'll edit the OP to make it more obvious. I have read Andrew's paper, and I invited him to comment on mine.

[SpainCoinDev]

He probably hasn't commented because there isn't much to comment on. I've read your paper and it's missing many critical aspects about PoS that you should have covered. That's what I was asking about

[Ix]

He probably hasn't commented because there isn't much to comment on. I've read your paper and it's missing many critical aspects about PoS that you should have covered. That's what I was asking about

Could you provide an example of a critical aspect that I am missing?

[SpainCoinDev]

We could start with this, generically for PoS
- what motivates signers to sign blocks on only one chain if it's costless to stake? aka "nothing at stake" Nobody has no reason not to mine 2 (or n) forked chains at the same time at no extra cost
- Block signer selection, how is it done so that it can't be exploited in any way. The "DCA" isn't described anywhere
- Mining in the past at no extra cost (aka long-range attacks)

Just read the papers you've been referred to, and Andrew Poelstra's treatise on altcoins, Vitalik Buterin's posts on the ethereum blog and so on -to cite some recent material. Address all their concerns and then come back. We shouldn't have to tell you what's already well known, you should be telling us how you're fixing the issues we know. The scenarios you list in section 4 are only of tangential importance and badly addressed anyway.

[for other people reading this Voice=miner who stakes; record=block,DCA ="distributed consensus algorithm" ]

You're also introducing unnecessary (potentially exploitable, or clearly exploitable) complexities CC/CB sound like plain checkpointing, "voice ledger" is another blockchain? how is it secured? what prevents anyone from forking in the past using a voice's signed transactions to invalidate that voice's later blocks by telling the network that voice is no longer mining.

How is the liquidity/opportunity cost different from taking coin days destroyed into account when doing PoS? (both do basically the same thing: the longer you keep the coins locked down, the more you can stake). That opens more attack vectors why does your approach not suffer from that (I'm not going into that but you clearly should).

In a network where Voices are present and timely, transactions will take
between 5-15 seconds to confirm and 105-115 seconds to secure.

you can hardly propagate a tx in 5 secs much less "confirm" -propagate a tx and mint and propagate a valid block ("record"). Your notions of confirm and secure in the paper are arbitrary too.

[Ix]

- what motivates signers to sign blocks on only one chain if it's costless to stake? aka "nothing at stake" Nobody has no reason not to mine 2 (or n) forked chains at the same time at no extra cost

2.2:
"A Voice who creates two Records for the same window of time or includes an invalid transaction is considered in violation of the network protocol and will have its risked Decrits destroyed."

- Block signer selection, how is it done so that it can't be exploited in any way. The "DCA" isn't described anywhere

5.1:
"Each CC, a new order of Records is created by using a random number (see section 5.4) as a seed. Via this mechanism, the Voices have no control over when they will be tasked to create Records."
5.4:
"During each CC, each Voice will include in a Record an encrypted string and a decryption key. The decryption key will decrypt the string from the Voice's Record in the prior CC, and this string will be hashed together with all of the other Voices' strings to generate a random set of data. This random hash will be used to create a new, random order of Records in the next CC."

- Mining in the past at no extra cost (aka long-range attacks)

All of section 3.

You're also introducing unnecessary (potentially exploitable, or clearly exploitable) complexities CC/CB sound like plain checkpointing,

It should sound like checkpointing because it is, although I happened to use the phrase "snapshot" instead. It is not a developer or otherwise centralized checkpoint though, it is a consensus of the network, proven by the signatures of all the Voices. Of course it's possible to get all of the Voices to collude, then have every peer watching the network drop the proof of that collusion, and rewrite the CB however they'd like. It's also possible to rewrite the entire Bitcoin blockchain with enough hashing power, although developer checkpoints do prevent recently downloaded clients from being fooled.

"voice ledger" is another blockchain? how is it secured?

It is part of the consensus block, as with every other piece of network data. It is secured by the ongoing consensus of voices creating records.

what prevents anyone from forking in the past using a voice's signed transactions to invalidate that voice's later blocks by telling the network that voice is no longer mining.

I'm not sure I understand the question. What is to prevent someone else from using a voice's signature to create a transaction that the voice did not make? Public key cryptography and the extreme difficulty of deriving a private key from a public key. What is to prevent someone that owns the key from pretending it signed out in the past? Nothing, but you can't create a fork if you aren't a voice.

How is the liquidity/opportunity cost different from taking coin days destroyed into account when doing PoS? (both do basically the same thing: the longer you keep the coins locked down, the more you can stake).

In Decrits, your money is staked up front and there is no taking that decision back without severe penalties (outside the scope of the inital whitepaper). With the coin-age model, you can do whatever you please with your money, which includes the possibility of staking. Decrits is an active stake where as coin-age is a completely passive, opportunistic stake. Consider how this would apply to an exchange or a bank.

That opens more attack vectors why does your approach not suffer from that (I'm not going into that but you clearly should).

It might, but I haven't thought of any. So could you humor me and go into it at least a little bit?

you can hardly propagate a tx in 5 secs much less "confirm" -propagate a tx and mint and propagate a valid block ("record").

5 seconds is certainly the best case scenario as it considers that a transaction has propagated the network in 2.5 seconds (a reasonable assumption which can be tested against Bitcoin), arrives at the appropriate voice just before creating the next record, and the record is issued and propagates the network in another 2.5 seconds. The network protocol already has O(1) record propagation, in code. Among well connected peers, records will propagate faster than transactions because of the priority system in place.

Your notions of confirm and secure in the paper are arbitrary too.

I think they're pretty well-defined.

4.2:
"Confirmed means that a Voice has wagered all of the Decrits he has on deposit that the transaction is valid based on his view of the network, and Secured means that reversing the transaction could only be achieved by an unresolvable network fork."

If you have more concerns about how that works, feel free to ask.

[SpainCoinDev]

You're just repeating the stuff in your paper again and I can't waste more time on this, sorry. Good luck with decrits

[Ix]

:shrug: Your points are answered in the paper, so what else am I supposed to do?

[Fuserleer]

Plan to check out the paper when I've got some free time, are there any significant changes from what you explained in the original thread or is the basic idea still the same just refined?

Also, just wondering if you've cut any code for this idea yet, you've had it floating around for some time now.

[Ix]

Basically the same stuff refined. The most difficult parts of the network code are coded and working, although some of it still needs to be cleaned up a bit. Go is actually a really fun language to program in, it's more similar to the scripting languages I used to hack as a kid than to C++. I have one more relatively big section of decrits-specific network stuff to get coded, then the RPC interface along with a cheap web GUI and dummy database, and then some open alpha testing will be useful. Maybe about 2 months away? I have some vacation time coming up so it will be interesting to see how much I can do in that time.

[Corleone1918]

have a ipo?

[phillipsjk]

you can hardly propagate a tx in 5 secs much less "confirm" -propagate a tx and mint and propagate a valid block ("record").

5 seconds is certainly the best case scenario as it considers that a transaction has propagated the network in 2.5 seconds (a reasonable assumption which can be tested against Bitcoin), arrives at the appropriate voice just before creating the next record, and the record is issued and propagates the network in another 2.5 seconds. The network protocol already has O(1) record propagation, in code. Among well connected peers, records will propagate faster than transactions because of the priority system in place.

I recently stumbled across one site offering such statistics

While recent blocks tend to propagate faster than older ones, the latency still a appears to range from 4-15 seconds. Older blocks from about a year ago took 5-120 seconds to propagate.

My personal Bitcoin node is set to make 500kB blocks (half the current maximum size). At 5Mbps of upload bandwidth (mid-range to high for VDSL and cable), it will take at least 1 second to send a completed block to a peer. ~10 seconds to send it to 10 peers.

[Ix]

I recently stumbled across one site offering such statistics

While recent blocks tend to propagate faster than older ones, the latency still a appears to range from 4-15 seconds. Older blocks from about a year ago took 5-120 seconds to propagate.

My personal Bitcoin node is set to make 500kB blocks (half the current maximum size). At 5Mbps of upload bandwidth (mid-range to high for VDSL and cable), it will take at least 1 second to send a completed block to a peer. ~10 seconds to send it to 10 peers.

Records are every 10 seconds, so that would cut latency by 1/60th, but the actual data needed to be sent is only a few bytes regardless of the number of transactions (among well-connected peers). And the memory cache is organized in a way so that it is slightly more difficult to receive the data, but once done it is very easy to convert it into a new packet for each connected peer. It's pretty moot though because in testing 100k tx takes milliseconds to process. 5 second confirmations are very much a possibility, although typical will be more on the range of 10-12 seconds.

[coinsolidation]

The primary attack vector on the VL is to create an alternate network
history in which the Voices under the attacker’s control become the only Voices
securing the network. This attack is fairly simple to execute and could even
rewrite the entire history of the network if the attackers control any of the
Voices in the genesis CB.

However, a key concept of the VL is that when a Voice chooses to end his
tenure, he will sign a transaction stating so, and this transaction is added to the
VL. This transaction is the key that unlocks the Decrits that were originally
risked to protect the network. Without it, the Voice does not retrieve his
money. Any rewriting of history cannot possibly include these transactions for
Voices which the attacker does not control.

As I read it:

First paragraph entails that the only voices on the network are the attackers, therefore the second paragraph is redundant since no other voices have been used to secure it.

Additionally, malicious nodes could simply reject other peoples tenure ending transactions therefore locking their funds in a denial attack.

Is this correct?

[Ix]

As I read it:

First paragraph entails that the only voices on the network are the attackers, therefore the second paragraph is redundant since no other voices have been used to secure it.

I probably did not provide enough exposition here about network history attacks/"nothing at stake" that is a popular theoretical attack against PoS. The question is given a node new to the network, how does it decide which history is correct in the face of two or more competing histories, especially when it is relatively trivial to create them without proof of work. The answer is that honest voices could not have signed out on the dishonest network because their signatures would not be valid in that history. If the attacker controls 99% of the voices at any point in history, a new node can still see that one network has 100% of the signatures available (assuming the attackers did not sacrifice their money on the legitimate network to make the attack look stronger), whereas the other only has 99%.

Additionally, malicious nodes could simply reject other peoples tenure ending transactions therefore locking their funds in a denial attack.

Is this correct?

Yes, they can, just as they can reject an honest voice's legitimate record which accomplishes the same thing - the tenure tx is actually part of the record data. However, each record has at minimum 2 days to be accepted by the network (20% of the voices), so the attackers must control at least that amount and every single one of those records to avoid an unresolvable fork. If there is an honest record anywhere in between, it will accept that transaction and the attackers must reject that record as well to continue the attack - they are building a fork.

This will be heavily expanded on in the whitepaper on the network protocol. Not only will there be voices' money at stake, but there will also be the stakes of elevated network nodes risking their money on the fork they believe to be true (or not risking their money on a fork they believe is malicious) so that the current status of the network is visible even when the attacker controls an overwhelming amount of voices and has not created an outright fork.