Block lattice

[monsterer]

Requesting a confirmation takes almost the same amount of resources as responding to one, I don't see a DDOS angle other than simple network flooding.

Well, since you don't store historical votes, everyone must be called upon to vote again if a syncing node is presented with a fork, no? You can't just take the opinion of one node at that point, surely?

I still don't see bitcoin as completely trustless, determining the highest block is trustless but you still need to trust where you got your wallet and that it's implementing the protocol correctly.

These points are completely orthogonal to the problem we are discussing.

You also need a way to determine if you're connected to a partition, since there's no upper bound quarum on hashrate there's no trustless way to determine connectedness.  With voting you can observe if you've received a quarum and make that determination.

Partition tolerance is the same in both cases; in bitcoin the votes are the blocks.

[clemahieu]

Requesting a confirmation takes almost the same amount of resources as responding to one, I don't see a DDOS angle other than simple network flooding.

Well, since you don't store historical votes, everyone must be called upon to vote again if a syncing node is presented with a fork, no? You can't just take the opinion of one node at that point, surely?

Correct.  If a node is syncing and it detects a fork, it sends N request packets to its peers.  Each voting peer sends 1 response packet back to the sender with their vote.  The initiator is committing equal network traffic compared to the responder.

This manual vote request only happens if the node is shut down while a fork is being negotiated and doesn't see the final conclusion.  Because it's a lattice, it's only affecting the one account that intentionally created the fork, the rest of the chains are unaffected.

I still don't see bitcoin as completely trustless, determining the highest block is trustless but you still need to trust where you got your wallet and that it's implementing the protocol correctly.

These points are completely orthogonal to the problem we are discussing.

You also need a way to determine if you're connected to a partition, since there's no upper bound quarum on hashrate there's no trustless way to determine connectedness.  With voting you can observe if you've received a quarum and make that determination.

Partition tolerance is the same in both cases; in bitcoin the votes are the blocks.

Partition tolerance, yes, partition detection is different though.  With voting if I'm getting votes that sum to 15% of total supply, the network is split.  With hashing if I'm getting a 1Mh/s rate is the network split?  Maybe.  I can guess if I know and trust an expected hash rate.

[monsterer]

This manual vote request only happens if the node is shut down while a fork is being negotiated and doesn't see the final conclusion.  Because it's a lattice, it's only affecting the one account that intentionally created the fork, the rest of the chains are unaffected.

And if that one account had sent a lot of transactions which, say a large proportion of recipient accounts then built upon, it surely affects more than just that one account in total?

Partition tolerance, yes, partition detection is different though.  With voting if I'm getting votes that sum to 15% of total supply, the network is split.  With hashing if I'm getting a 1Mh/s rate is the network split?  Maybe.  I can guess if I know and trust an expected hash rate.

That only makes sense if you know what percentage of total stake is supposed to be voting at any one time.

[clemahieu]

This manual vote request only happens if the node is shut down while a fork is being negotiated and doesn't see the final conclusion.  Because it's a lattice, it's only affecting the one account that intentionally created the fork, the rest of the chains are unaffected.

And if that one account had sent a lot of transactions which, say a large proportion of recipient accounts then built upon, it surely affects more than just that one account in total?

Right, it could affect more accounts, accounts that received from the fork that was just outvoted, they're all invalid.  The issue is, if the local node that's synchronizing didn't see the final vote for this block by virtue of the fact that we have it locally but the network voted against it, that indicates those derived blocks didn't wait for proper confirmation indicating they're actually in collusion on the fork.

If receivers wait for vote confirmation on a block before receiving it they have no chance of their chains being rolled back.

Partition tolerance, yes, partition detection is different though.  With voting if I'm getting votes that sum to 15% of total supply, the network is split.  With hashing if I'm getting a 1Mh/s rate is the network split?  Maybe.  I can guess if I know and trust an expected hash rate.

That only makes sense if you know what percentage of total stake is supposed to be voting at any one time.

[monsterer]

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

[clemahieu]

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

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.

[monsterer]

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.

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.

[clemahieu]

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.

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.

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.

[monsterer]

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

[clemahieu]

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

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.

[monsterer]

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.

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

[clemahieu]

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.

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

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.

[monsterer]

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

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

[clemahieu]

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.

[clemahieu]

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

[monsterer]

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

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.

[Cryptorials]

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?

[clemahieu]

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

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.

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.

[clemahieu]

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?

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.

[monsterer]

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.

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.