Topic: Block lattice - page 2. (Read 8357 times)

Oh I see. Looks interesting.

I like getting rid of the need for wasteful commercial mining without the rich getting richer aspect of PoS, although I do worry about participation both for the number of full nodes and for the number of representatives getting votes. I think i saw something about a kind of weighting to stop a single representative getting a huge amount - can you explain that more please because at the moment all I can see is 99% of users never even looking at it and therefore 99% of the votes going to whatever account the person providing the wallet sets it at.

I'll clarify how this is anticipated. Basically in hinges on votes are determined by the value you store and voting like this would destroy this value. It's like buying mining hardware and mining in opposition of tip, if you can pull it off you've destroyed your investment.

RaiBlocks is unique rather than just bitcoin with voting substituted for proof of work. Whether it does what you need depends on what you intend to use it for. There's two breakage scenarios for bitcoin, one it's breaking the protocol going forward by eclipsing the network's hashing power and then there's the breaking the protocol going backwards by making longer branches going back in time. For RaiBlocks both breakage are the same. If you're using the protocol as a storage of value, breaking the protocol forward is sufficient to destroy any value held since no one will want to exchange for it. If you're looking for a generic immutable database that prints old results even if the protocol is broken going forward then RaiBlocks won't serve that purpose.

The next easiest way to break both RaiBlocks and bitcoin is to convince half the network to modify their node either to vote incorrectly our just reject a block chain branch, even if it's the longest. I think with the recent evidence that even with good reason it's hard to get nodes to agree on how to change their protocol, this is an unlikely scenario for either.

Of course I wouldn't try to convince anyone to not use bitcoin if RaiBlocks isn't an improvement for your use case. If nothing else this can alleviate traffic off of bitcoin where it satisfies the users needs.

Another point I think needs addressing is the votes themselves. Are they transactions? What are they? Why can't I double spend my votes?

In plain PoW blockchains, the asymptotic security comes from the fact that consensus on all historic transactions is constantly being reinforced by the addition of a new block to the chain. The more blocks get added, the higher the security for any given block in the history, because changing that historic block requires re-doing all the work built on top of it.

If you can add a section to your paper explaining the parallel to this, it would be helpful.

Representatives make a single vote on every block they receive so the receiver can count network quorum but unless there's a conflicting block they don't vote again since there's no other candidate block to consider.  In the document I added a Confirmation Procedure section to better describe how a single block is confirmed.  Let me know if that clears anything up.

Based on some feedback in another forum I added a "Confirmation Procedure" section which goes over how a single block is confirmed either through lack of opposition + quorum or through voting.

I'll have to think about how to quantify the agreement rate, to me it seemed pretty straight forward: nodes observe vote traffic and change their vote to match the winner.  Ideally this should converge after 1 vote interval but we do 4 to account for delays or dropped packets.

One difference with this compared to PoW consensus is there's no randomness injected in to the result.  In PoW if two solutions are published and one has a higher block height, that answer could change after the next block based on the randomness of who came up with a solution faster.  With voting the only randomness would be from nodes making random votes rather than agreeing with who they see as the winner.

If voting only happens when there is a signed fork, doesn't that mean there are no visible confirmations and if so then how does somebody receiving a payment know at which point it is safe to accept it?

This kind of peters out half way through? It seems to identify a set of good features for a consensus design to have, but it never goes on to explain how they are achieved - e.g. the asymptotic security.

I haven't built one, I wasn't aware of the need.  Windows 32bit? 7, 8, 8.1?

Version 7.2.0 has been released which is recommended for everyone and is available on https://raiblocks.net

The RPC processing system has been rewritten to operate asynchronously in addition to other performance improvements.

We also added RPCs dedicated to payment processing which gives a non-polling way to wait for payments.

A whitepaper has been arranged for viewing https://docs.google.com/document/d/13s6BKzRq9oD5Me55JBRzR7BdvjJ44QKqPu2lf-JsAlU/edit?usp=sharing

Let us know if there are any issues.

This is one of the reasons all(?) other cryptos have an ongoing consensus, which continually produces blocks (even if they're empty) because it allows a constant stream of participation data to be gathered.

I think you might need to revisit your terminating condition, or the idea of not having delegates...

You're right this area could use some work, possibly some long-term node-local trending on vote participation to gauge active total supply.

The representative system was made so the majority of balance holders can be offline while representatives dedicated to staying online can do the voting.  I envision places like exchanges: Poloniex, Cryptsy, BTCC, and your own metaexchange, crypto banks, universities, or corporations would set up a node and publish their representative address people could use as their voting representative.  Unlike mining these voting nodes don't require large capital investment to generate PoW to keep the network healthy, primarily they need a moderate amount of bandwidth and storage space and high availability.

Balance-weighted voting also allows balance holders to manage global decentralization by making sure no representative gets a disproportionate vote.  Right now with mining pool PoW centralization there's nothing people can do to prevent it.

The representative is a property of the account number, just like the balance.  It's changed by the account publishing a change block to name a new representative which can be done at any time and the ledger handles changing the representative weights when transactions are performed.

50% of supply seems very large - what if the nodes controlling 51% are offline at the time the vote is required?

Anyone with a balance can vote on transactions and their vote is weighted based on their balance + the amount that's been named to them by others.

The voting protocol says voters must change their future vote to be the block with the highest observed vote count. This makes voting converge toward a single result with good actors.

Voters have an incentive to vote the protocol because they hold a balance in the network.

Votes are weighted on balance so a person with 1 RAI has proportionally less influence than someone with 1 billion RAI.

Voting completes heuristically as the vote total for one block increases past a confirmation point.

Confirmation points are configured right now as:
No observed forks and a vote tally totaling > 50% of supply
At least one fork and a vote tally for a single block > 15/16 of supply which we declare the the winner.

Unrelated question: are there delegates, or can anyone vote on transactions? If there are no delegates, how can you tell when voting is 'done'?

Maybe a better way for me to describe RAI is that forks are always attacks. If a node is presented with a valid state transition, I.e. A block that represents a single transaction owned and signed by the chain's owner it takes it as a de-facto 100% vote. Since all nodes are rebroadcasting a block as they accept it, within a couple seconds we can be sure if anyone anywhere has seen a fork I.e. an attack. If no forks are observed no vote takes place because there is only one option.

That was ripple's original trust-lines design. The new one is called 'last ledger close', wherein participants vote on the current transaction set and the current ledger closes every 3 seconds. There is no stored vote history (as far as I know).

I didn't realise RaiBlocks had no requirement to generate a 'current' consensus.

From what I understand ripple had transitive trust network that needed to be built up.  You needed to trust something at which point votes from that node would count.  The node you trusted would in turn trust other nodes which was supposed to build up your trust network.  With RaiBlocks you set a representative which hands the voting power of your balance to them until you change it.  You can name yourself or some local group that has a machine set up for doing votes but it's all still balance weighted and there's no transitive trust relationship.

Ripple also needed a vote for every block on every block interval, with RaiBlocks it's entirely possible for hours or days to go by without voting, as long as no one signs a fork, no voting is possible on your chain because there's only one option to vote on.

Am I right in thinking RaiBlocks actually shares a lot of Ripple's consensus characteristics?