Topic: [Whitepaper] The Decrits Consensus Algorithm (Read 2364 times)

I don't know enough about bitcoin's memory cache or the python or pypy implementation's memory cache to comment. It seems silly to be hitting the disk for any reason for transactions that are not very old. Even with bitcoin's bloated transactions, 300 bytes/sec is pitifully small and anyone should be able to keep several hours' worth in memory without an issue.

The 700ms is the time required to build a (500kB) block from already verified transactions. The 1.7s was an estimate based on be expected Dead-on-arrival rate vs. my actual DOA rate. It may include disk/network/hasher latency, but I don't really know.

It doesn't reduce the overall latency, but it certainly does divide it up into smaller amounts. That is all that matters for getting confirmations. And as I said, the bandwidth factor is significantly reduced so the latency of transmitting the data is all during the original transaction, not during the record transmission.


There is no competition - one voice controls one block of time (unless there are so many that multiple control each block of time, then they use a modulo function to determine which transactions they include). Duplicated transactions in subsequent records that did not acknowledge the earlier other are just ignored, and they do not pose any real penalty on data transmission or verification time. Double spent transactions are resolved by ceding to the record that controlled an earlier block of time - most of the time, this is covered in a little bit of detail in the paper. Unfortunately for the sake of SPV nodes this might require a "reversed transactions" log which still won't require much resources. But maybe not, as if they are worried enough to see their balance update, they will notice that it did not update anyway.

Making the records more frequent does not at all reduce the latency that is the product of: the laws of physics and processing delays.

My (admittedly slow) node spends about 700ms processing generating new Bitcoin blocks, plus another 1.7 seconds processing new P2Pool blocks (which are every 30 seconds). This is with a SSD, BTW.

Edit: Given the aggressive block record times, how are accidental forks and orphans (children of potential forks) handled?

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%.


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.

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?

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.

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.

have a ipo?

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.

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.

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

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

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."


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."


All of section 3.


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.


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.


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.


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.


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


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 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.

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).

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.

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

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

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.

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

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.