Block lattice

[monsterer]

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

[clemahieu]

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.

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.

[clemahieu]

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

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.

[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?

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.

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.

[monsterer]

voting like this would destroy this value.

Why is that a problem? Take out a short on an exchange, vote like that, decrease value -> profit?

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

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.

Sure, the way I hope it will shake out it there are already groups out there who run nodes, exchanges, interest groups, banking institutions.  Ideally for any wallet they control they'd have a voting representative they'd name for any accounts they control.

The number of full nodes is a concern as well, indeed as far as I know there isn't a method out there to incentivize a node for performing the essential service of reproducing the full blockchain to new nodes, at least one that can't be gamed.  This was one of the reasons why we tried the no-in-chain-rewards system, mining seemed to be heavily rewarding a small group of people who perform a very specific task.  If there are incentives for people to run businesses around the technology we think there's an incentive to keep the ecosystem healthy by running representatives or full nodes.  At least the cost of running a full node with RaiBlocks is just bandwidth and disk space, rather than heavy CPU/GPU/mining hardware costs.

There isn't a way the protocol can determine if a single entity has disproportionate voting strength because it can't disprove account collusion; I think PoW systems have a similar issue where mining pools become disproportionately strong.  I think one benefit RaiBlocks has in this aspect is account holders have zero-friction to make a change if they think a group is getting too powerful, they can simply name a new representative.  Compare this with mining where the only way for me to make a mining pool less strong is to invest in mining hardware myself.

Let me know what you think.

[clemahieu]

voting like this would destroy this value.

Why is that a problem? Take out a short on an exchange, vote like that, decrease value -> profit?

Is this different than with bitcoin?

To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.

[monsterer]

Is this different than with bitcoin?

To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.

Yes, it's different. See this discussion: https://bitcointalk.org/index.php?topic=1382241.0

This is relevant, because Raiblocks uses the PoS security model.

[clemahieu]

Is this different than with bitcoin?

To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.

Yes, it's different. See this discussion: https://bitcointalk.org/index.php?topic=1382241.0

This is relevant, because Raiblocks uses the PoS security model.

Since putting a block in an accounts's chain requires it to be signed by the account owner, how does the stake key holder sign blocks for an account it doesn't have the key for?

[monsterer]

Since putting a block in an accounts's chain requires it to be signed by the account owner, how does the stake key holder sign blocks for an account it doesn't have the key for?

It doesn't. But voting with historical stake will no doubt present the relevant problem.

[clemahieu]

Since putting a block in an accounts's chain requires it to be signed by the account owner, how does the stake key holder sign blocks for an account it doesn't have the key for?

It doesn't. But voting with historical stake will no doubt present the relevant problem.

This attack is feasible for systems that grafted voting on top of a bitcoin style block chain where transactions are unordered.  With RaiBlocks an account signs a total order for all transactions it generates.

Rewriting history of an account can only be done by the account owner themself, representatives can't do this.

[monsterer]

Rewriting history of an account can only be done by the account owner themself, representatives can't do this.

So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?

[clemahieu]

Rewriting history of an account can only be done by the account owner themself, representatives can't do this.

So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?

How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.

[monsterer]

Rewriting history of an account can only be done by the account owner themself, representatives can't do this.

So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?

How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.

Since every account is a partition, I can present a fork where the historical stake has been sent to an account which I control before it was originally transferred somewhere else. Then I sign the fork with that same stake.

[clemahieu]

Rewriting history of an account can only be done by the account owner themself, representatives can't do this.

So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?

How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.

Since every account is a partition, I can present a fork where the historical stake has been sent to an account which I control before it was originally transferred somewhere else. Then I sign the fork with that same stake.

You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.

If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.

[monsterer]

You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.

If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.

How do they tell the difference between my fork and their fork?

[clemahieu]

You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.

If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.

How do they tell the difference between my fork and their fork?

Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger.  Unless the stake holders from their perspective are voting for the new block, they won't evict a block.

It sounds like your describing a system where nodes compute accumulated stake in order to find a "highest branch"; RaiBlocks doesn't operate this way.

[clemahieu]

This is also why storing historical votes is unnecessary per our previous discussion. Votes only matter when they're actively being taken off the network and weighed by the current ledger state.

This is to prevent history rewriting.

[monsterer]

Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger. 

So at the very least, nodes which are syncing would accept my fork as truth? Also possibly online nodes if my fork was presented within some window of time?

[clemahieu]

Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger.  

So at the very least, nodes which are syncing would accept my fork as truth? Also possibly online nodes if my fork was presented within some window of time?

Sounds right I think, bootstrap poisoning is one attack vector.  One way to address this would be to bootstrap to your representative or whoever gave you your wallet code.  Presumably if you trust them enough to download and execute a program that manages your private keys, you can trust them to bootstrap you correctly.

Another option is to bootstrap to someone you're interested in sending to, a merchant perhaps, because in the end the only thing that matters is if they'll accept your payments as valid and they'll tell you what they're accepting through bootstrapping.

Another problem would be if almost everyone simultaneously changed their representative while forks were occurring. This would would require every account to be online and simultaneously signing a change to their representative; interesting but I don't see that actually happening.