Bitcoin Forum

Hey everyone, I designed a system which, for lack of a better term, is called a block lattice.

https://github.com/clemahieu/raiblocks/wiki/Block-lattice

The idea is each account in the system has a block chain that is controlled only by them, all chains are replicated to all peers in the network.

The advantage of doing this is each account can order their own transactions meaning no proof besides a digital signature is needed.

I think this goes a long way toward scalability by removing block intervals, mining, transaction fees etc and wondered what everyone thought.

It appears (from the writeup) that you are unaware of sybil attacks?

The graph of transactions in bitcoin already functions like what you describe (except 'accounts' are single use txouts); Bram Cohen likes to call Bitcoin without the blockchain "bitpeso".  In Bitcoin the blockchain is overlaid on top of "bitpeso" to resolve "complex forks" (using your language) in a manner that allows someone to join the network and know which resolution is authoritative in a way which is both robust to sybil attacks and does not require membership (because a membership process would create control over the system).

In your description you appears to liberally conflate forks and double-spending.  In Bitcoin, double spending a traditional txout requires malicious behavior, just as you describe.  Blockchain forking in the absence of double spending is benign and no different to the "multiple resolution rounds" you mention from your resolution protocol but fail to describe detail sufficient to permit any analysis.

We have a section on Sybil attacks in the attacks documentation https://github.com/clemahieu/raiblocks/wiki/Attacks

The resolution protocol is a balance-weighted vote by account holders in the network, this is the core of what prevents sybil attacks.  In order to attack the network, you need to have ownership in the network in proportion to your attack weight.

Unless every owner a token is going to be online mining all the time, then mining will need to be delegated. So some pools have more weighted-balance voting power than others. You need to offer some incentive for mining. Profits accrue to those with the most economy-of-scale if the incentives are market (competitively) priced, thus you will likely end up with the situation that Bitcoin had where a single pool or potential grouping of large pools had more than 51% of the hashrate but in your design this would be more than 51% of the voting power.

Is a cascade of intertwined inter-chained reorganizations when multiple double-spends are reverted by a fork more onerous than in a single block chain? Isn't that complexity similar to the reason you rejected multiple inputs and outputs (https://github.com/clemahieu/raiblocks/wiki/Rejected-features#multiple-inputoutput-blocks) in transactions?

The key failure in your design is the lack of incentive to have a consensus. What is the incentive for voting nodes to agree with the correct fork and for minority nodes to agree with the majority fork? Seems to me they can all disagree and no one can prove otherwise, because they can pretend to have never heard the votes of others (no way to prove receipt of a vote on the internet). This shows that without the objectivity of a PoW, then there is no objectivity and you end up in chaos.

In PoW, miners have an incentive to reach consensus because otherwise their rewards won't be honored by the longest chain. In your system the majority of the vote is the winning fork, except there is no penalty for delaying for an indefinite period acknowledging receipt of such a vote. Thus complex game theories arise. Even more critically, the majority vote may be split among multiple forks, such that there is no consensus, because you have multiple chains thus a plurality of permutations of forks.

I do want readers to note which of the three posters in this thread was able to state directly the design error. That should be instructive to investorswhich lead developer is most qualified.

These are good, in-depth questions.


Since we don't use mining to order transactions or resolve forks, adding mining for the initial distribution would be rather vestigial.  It also seems that so far, despite everyone's best efforts to make mining more distributed and focus away from large pools or enthusiasts, we've only achieved moderate success.  In the end we want the initial distribution to go to people, not hardware so we're distributing 100% of the supply through a captcha on the site under "Get Blocks" according to a fixed distribution schedule.  https://github.com/clemahieu/raiblocks/wiki/Distribution-and-Mining


The rollback does cascade though the window for a rollback is very small compared to traditional cryptos.  On a traditional crypto block_interval * confirm_count is the range of uncertainty, with RaiBlocks the range of uncertainty is ~1 network propagation interval i.e. how fast can network packets reach everyone in the network.  Once everyone has received one fork, subsequent forks would be instantly rejected.


Primarily this is mitigated by the fact that if a node doesn't create a fork, there is nothing to vote on, no consensus is needed.  If I have a signed block chain A0->B0->C0 and it's published, no one can vote between C0 and let's say C1 because there is no signed C1.  If you don't sign forks, no one can vote on your transactions.


Well-behaved nodes are configured to flip their vote if they observe their fork variant as having fewer votes than another.  The only way to vote is to have a balance tied up in the network.  To vote to confuse the network is to destroy its value which destroys your investment.  The incentive is to retain value in the system rather than accumulate rewards through inflating everyone else.

I don't comprehend your notation and its applicability, but I was just thinking conceptually that you have a these N block chains operating orthogonally, thus any one can receive the transfer of value from the other. Then you can have double-spends and what not. So then you can have different block chains disagreeing about a plurality of different orthogonal block chain states. There is no global unified state, that is the entire point since missing the global PoW block period to force timely consensus to this single objective reality. If we don't want a global state, then we must use a probabilistic forking structure such as Iota's DAG (https://bitcointalk.org/index.php?topic=1216479.msg12777035#msg12777035) to obtain Byzantine fault tolerance (https://en.wikipedia.org/wiki/Byzantine_fault_tolerance). You've conflated the independence with the determinism required for global coherence. Global coherence with individual realities (relativism) can only be probabilistic. I believe this follows from Brewer's theorem (https://en.wikipedia.org/wiki/CAP_theorem) which says it is impossible to have all three of consistency, availability, and partition tolerance.


Not necessarily. They could collude to steal value from another fork by double-spending to the other fork and then disagreeing about the objective time of spending. Perhaps other complex game theory as well. Also it may not be intentional. Per my point above, the objective reality may be indeterminate and the system may have a plurality of minority realities (votes). That is what I expect to be the normal mode due to chaos theory.

Sure, I don't mind explaining.  Even though all accounts have their own chain, each chain consists of blocks that have a single successor and if multiple successors are published, they're arbitrated through voting.  Starting off the ledger can answer two central questions 1) Is this block hash in the ledger and 2) Is a block the head block for an account.  This functionality can be verified in https://github.com/clemahieu/raiblocks/blob/master/rai/secure.cpp ~ line 2660.  When blocks are published, they're flooded to the network, this ensures everyone observes the state change seen by other nodes.  When we receive a new block we check question 1 on the hash of this block.  If it's already in the ledger we discard the message because the block has already been processed.  If it hasn't been seen, we retrieve the hash for the previous block and check question 2 on the previous block hash.  If the previous block is the head block for that account, we can enter this in to the ledger, this is a valid state change for this account.  If the previous block is not the head block, we can check question 1 on the previous block.  If the previous block is already in the ledger we deterministically know we have observed a signed fork.  When representative nodes observe a signed fork, they start periodically broadcast their votes on a fixed interval until consensus is reached.  When any node observes a fork they listen for representative votes and change their ledger to match the vote winner.  As you can see votes are only published and blocks are only rolled back if there is is a deterministic fork.  If there is no fork, the ledger can be updated without engaging in voting because there is only one possible state change for that account.

Allowing forks to be arbitrated separately is a design feature of the system.  This system is similar to side-chains taken to an extreme.  In side-chains we break apart the block chain to allow smaller groups of accounts to be arbitrated, hopefully at a higher speed.  In this system a side chain represents one account.


I'd be interested in having you expand on this, specifically the 50% attack documented in https://github.com/clemahieu/raiblocks/wiki/Attacks I think you'd have some really good insight.

On the plurality of minorities point, nodes are configured to change their ledger to match the block with the highest amount of votes, it doesn't need to have an absolute majority, just the largest minority.  As voting rounds go on, smaller minorities will disappear until there is a single conclusion.  This assumes the incentive to vote correctly holds.  We need to remember that votes come from having a balance in Rai, accounts that don't have Rai can't vote.  Voting to collude on a fork is destructive to integrity of the system and votes only come from having a stake in the system, so voting to collude is voting to destroy the value you hold in the system.

If we used an analogy using the bitcoin market cap which is right now ~4.2b we'd be saying, a group of people with 2.1b$ invested in bitcoin are working to mine double spends in to the system which would destroy their 2.1b$ investment because people would no longer use bitcoin.  I think this is improbable.

Some further discussion that might be helpful:

https://bitcointalk.org/index.php?topic=1216479.msg12822716#msg12822716

https://bitcointalk.org/index.php?topic=1216479.msg12829829#msg12829829

Apologies if I hadn't had the time to focus in on the points in your reply.

I see discussion about violating CAP though the only way someone could violate this is if they're claiming all 3 conditions can be simultaneously satisfied.  I haven't seen anyone claiming resilience against partitioning and without this they could be claiming at most 2 of the three, possibly 1 or 0, which may not be useful but doesn't violate CAP.

Getting globally consistent state is fine though it comes with two penalties, confirmation delays and transaction throughput limitations.  If we could trade off some of this global state knowledge for faster confirmation time and higher transaction throughput, this would be desirable.

There are some things we can discard and still get consistent transactions, if we start with a globally consistent state and have two transactions A sends to B and C sends to D, we don't need to know which occurs first, both would be correct applied in either order.  Bitcoin totally orders these transactions whereas RaiBlocks partially orders them.

Breaking the block chain in to a partially ordered set gives desirable performance at the expense of unneeded total ordering.

I agree with at least this part of your post. And getting the details correct on this goal is where we are now.

This is similar to a problem in electrical engineering of solving metastability.  https://en.wikipedia.org/wiki/Metastability_in_electronics  Either make your transistors switch faster or wait more wait time to increase the probability of a correct conclusion.  RaiBlocks is analogously making the transistors switch faster by only ordering things required to make sure there aren't chain forks.

All of this is implemented in the rai::ledger_processor block visitor class https://github.com/clemahieu/raiblocks/blob/master/rai/secure.cpp

Where do you store the votes for fork resolution?

From the wiki:


This isn't the case. Double spends affect the sender and receiver(s) of the transaction - so potentially, they could affect every single blockchain in the system.

Interesting idea, i'll check out the link

Votes and conflicts are stored in memory until a winning percentage is reached and an extra amount of time has elapsed, the goal being to discard forks as fast as possible.

You're right on the description though, it should probably be "malicious accounts" since an account that breaks the protocol and accepts a fork before it's settled is effectively malicious as well, for all we know they're the same person or in collusion.  The important point is that if B is named as a recipient of a transactions that's forked, unknown to them, B can continue to process other transactions while it waits for this fork to settle.

What stops an avalanche of rollbacks is blocks are only rolled back if another block receives a majority vote and votes are weighted based on account balance.  The worst avalanche that could happen would be for the successor to the genesis block to be rolled back.  If the genesis key published this ancient fork everyone would observe this conflict and start a tally.  All the representatives would kick off their periodic vote, of which 99.99% would vote for the original block and whoever published the conflict would get the .01% vote.  No one would roll back anything because a majority was never reached.  Flipping blocks past the heuristic wait period is analogous to a >50% attack.

Awesome, let me know if you have any issues.

Remember, the Rai supply is distributed through a captcha so new people will be able to try it out without mining or trading.

Presumably raiblocks uses a UTXO system, then? Otherwise you'd be able to DOS the entire system by sending doubles spends to everybody, continuously.


With no historical evidence of voting, how can a peer who is syncing tell a legitimate chain set from a fabricated one?

In addition, doesn't this mean that if you have enough stake, you can arbitrarily rewrite history by voting on historical forks?

Each block has an individual proof of work attached to it for simple throttling, generating forks would require generating this work as well so people could spam forks as fast as they could perform normal transactions.  Is this what you were talking about or could you elaborate a bit more?


If a node sees a fork during bootstrap it can directly request votes from peers in place of the automatically sent votes it would have received had it been online.  This sounds along the same lines as the "Bootstrap poisoning attack"  https://github.com/clemahieu/raiblocks/wiki/Attacks  I know some bitcoin wallets do a basic level of cementing to protect from malicious nodes sending a bunch of forks that aren't the tallest.

Yea, if someone owned >50% of the entire RaiBlocks marketcap they could rewrite history, that's also on the attacks page but I think the thing that puts it in to perspective is how much that would cost.  If we use bitcoin as an example, someone wouldn't need to rewrite history for it to be completely destructive, they would just need to be able to rewrite a couple days of transactions demonstrating they own >50% of the hashing power and people would flee.  I think since the cost of getting >50% of the hashing power is necessarily less than the cost of getting >50% of the entire market cap, the balance weighted votes are a stronger guarantee.

Sure. If sending a double spend to an account requires the recipient account to wait for fork resolution before it can continue to spend funds (since the final balance is now in question), then it becomes possible to use double spends as a DOS mechanism. However, if there was a UTXO system, there are effectively many different accounts per user, so you wouldn't be able to DOS like this as you'd only cause one UTXO to be in conflict.


This is another DOS angle. You could set up a lot of malicious seed nodes to just broadcast fake blockchains to everyone at no extra cost. Since the syncing node must then request for new votes to resolve the historical forks, they essentially start draining network resources. If there are enough syncing nodes, this can quickly becomes a system wide DOS.


If you look at standard POS systems, this is mitigated to some degree because the votes are recorded in the chain, so you can replay all the history. They do suffer from the keys from the past attack, but raiblocks as described doesn't even have basic protection of the vote history.

I see what you're describing now; yes there is indeed a UTXO set, we named them receivables though they're the same concept. Sending is a two phased process to defend against exactly what you're describing, some malicious attacker naming a target account and generating forks.  In the send phase a send block is created reducing the sender balance and creating a receivable which can only be claimed by the destination. The receiver needs to bring in this receivable at a later time they choose after they deem the send sufficiently settled.

With this we can see that within a couple network propagation intervals a receiver can be sure there are no forks because all normal nodes repeat the send acknowledging it. Representatives create a slightly heavier packet that includes a signed vote which observers can look up the signer, check their balance, apply a vote weight depending on their balance, and check for quarum.

They nice part about each account running their own chain is they all have a 100% vested interest in maintaining their own chain and 100% authority over what goes in it and when. If any forks are observed in the few seconds after send a receiver should immediately add more wait time before accepting a block out the pending/UTXO set.  Basically receivers have the option of receiving things out of order.


I think there is some mitigation in place for this. In the attacks documentation we call this Block Gap Synchronization, it's the ambiguous state between is this a junk block or is this a valid block but I just missed something. One mitigation strategy is by virtue of the fact that during normal operation, nodes passively listen for votes and don't take preemptive action. Nodes listen for and tally votes, the only time they request votes is on startup syncing or if a block got a bunch of votes but it doesn't fit in the local ledger meaning we missed something and were pretty sure it's not junk because it got a fair amount of votes.

I don't want to sound disparaging, but that's already how bitcoin's UTXO system works. Users create transactions in their wallets by linking inputs to outputs and then signing. No one can change that outside the client. The only thing which changes outside the client is the sequencing of transactions, which is provided by the blockchain.


The trouble is because there is no historical voting evidence, any historical fork will require active effort to resolve.

In POW syncing nodes can trivially verify and resolve historical forks without any additional work from miners - the longest chain always wins and the  true elegance of this system is that is does not distinguish between a syncing node and a regular node; this makes it very robust.

Agreed it's very close to what the UTXO set does. One difference is all unspent outputs are serialized and essentially combined under a single head block so a lite client could prune everything except a few head blocks for each account regardless of the number of transacions that make up their balance. This of course is a boring optimization that's been proposed for Bitcoin but never implemented.

The other reasons for breaking things up this way is to greatly decrease the number of race conditions in the protocol that need arbitration.  There's no race condition of who mined the block, whether A->B happened before or after A->C or in which block a transaction needs to be placed. All of these are benign race condition that need arbitration even in the presence of a network of all good actors.  When we allow each node to control their own chain in this way we have no arbitration for benign reasons, only the malicious cases. This also means nodes can treat forks as second class citizens without someone ddosing the network with transactions creating delays.

This gives transaction throuput limited only by hardware speed I.e. No block size discussion and transaction latency limited only by network speed I.e. No block interval discussion. Clearing transactions as fast as possible means we don't have end user confusion of "why isn't my transaction confirming" or "what fee do I put on my transaction and what does that mean"? Plus giving users what they expect in currency, native instant transactions.


We drop the blocks that are voted against because all that really matters is the final conclusion. Storing historical votes might not cover all vote options I.e. A node publishing a fork only to people bootstrapping in which case there's never been a vote on this block but it's equally as irrelevant as a block that's voted out.

I'm not sure I see how. Given a recipient A and two transaction senders B and C, if B and C send a transaction to A simultaneously, you still have the same problem - both of them attempt to update the data structure in A at once?

That's actually a great example of the benefit of the system, when B and C send to A simultaneously, two receivable entries are created that A needs to accept in to its chain.  A gets to create two blocks X receives from B and Y receives from C and it gets to pick the order they're placed in to A's own chain.  It could pick Y -> X -> HEAD or X -> Y -> HEAD but it picks one, signs each, and announces to the network the order A decided for its own chain.

I also threw together some animations for the confirmation and fork consensus procedure.  Let me know what you think.
https://github.com/clemahieu/raiblocks/wiki/Double-spending-and-confirmation

where does it store the wallet file? or how do I backup my wallet?  (on windows)

On Windows it stores it in C:\Users\<user>\AppData\RaiBlocks\backup

Doesn't this mean that A needs to be online at the time of receipt in order to convey it's decision to the network?

If A is offline, UTXO entries accumulate.  Eventually when A is online to spend, their wallet will look at the UTXO set and pull in blocks they missed while offline.

Sending is two phases:  
Send: Deduct delta from source balance, mark block as receivable in UTXO set  
Receive: Remove block from UTXO set, increase destination balance by delta.  

When I have free time I will get back to your "block lattice" (afair originally named "block list"?) thread, but I don't have time right now. Appears the issue will be something about having multiple partitions and prevention of double-spends globally and/or the ability to send a transaction to any block list at any time.

Multiple partitions don't come for free. You give up something. This is what I meant about the CAP theorem.

Multiple partitions is odd, RaiBlocks, like all cryptocurrencies doesn't operate while partitioned.  Please expand, you can be very specific when you find time.

As monsterer and I have been alluding to up thread, afaics you have not definitively stated the frame-of-reference—employed by your ("every UTXO output has its own block chain") design—for Byzantine fault tolerant consensus, so I have now expended the time to research, think, and hopefully correctly define it.

Your design's frame-of-reference for Byzantine fault tolerant consensus is majority of the vote by the "voters" which have locked a suitable amount of coins (value). We must determine the (game theory) objectivity of this frame-of-reference and the impacts within the CAP theorem.

The record of who are the majority throughout the history of time must be recorded in the history of the consensus, otherwise there is no consensus about what the majority was and thus what it is now. For example, if someone controlled sufficient coins in the past (greater than the number of coins that were locked for voting in the current public consensus history), they could erase the entire history from that point, by publishing a new block for their historical UTXO (even if they historically spent them subsequent to the historical block where they were UTXO) locking their coins for voting and then voting to make their revision of history the dominant majority. The major distinction from (and flaw compared to) Bitcoin's PoW is that competing versions of history are not compared by the accumulated amount of resources committed to each version. In Bitcoin's PoW, the longest chain accumulates all the PoW in the chain (thus unlike in your design, in PoW there can only be one longest one and thus only one majority!), but afaics in your design all the coins locked subsequent to a fork revision of history are not accumulated in comparison. I suppose you could propose to accumulate locked coin-days-destroyed, but the problem is there is not objective measure of "days destroyed" that the adversary can't game. Or you could propose to accumulate some other resource as a measure of the longest chain which could not be readily fabricated by the adversary, but I would have to analyze a specific proposal (which afaics you have not yet made). Essentially the issue is long-term "nothing at stake" (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/).

Now I've read up thread that you claim that you don't even store a record of the vote history, but not only does this appear to show you are somewhat myopic about how your design functions, and also as monsterer pointed out, if you don't store the history then there is no way for a node which is not omniscient to know what the objective consensus is without invoking trust (and decentralized currency must be trustless else it devolves in numerous ways to centralized currency). About whether you are storing the voting implicitly, afaics your design must record as transactions which coins are locked and the implicit entangling of cross-spending between chains implicitly records which chains elected which forks, but I guess you are correct that voting is not even implicitly stored if voters (defined by locked coins) are not injectively (and non-surjectively) mapped to chains (i.e. if voters don't correspond to chains).

So the "partial ordering" in your design is really unknowable levels of durable partitioning and thus non-durable consistency, because there is no way to guarantee anything about confirmation and objectivity of the majority consensus now or anytime into the future.

The only way around this is to rely on "weak subjectivitiy" (https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) where trust in the social consensus provides the long-term checkpoints. Problem with that is there may be disagreement in the social consensus in that case usually "might makes right". However in that case, Bitcoin is also subject to "might makes right" where the 51% attack can revise history as well. If you don't store records of voting short-term, then there is no trustless objectivity from last "weak subjectivity" check point. Without recording the voting, the confirmation of a transaction is unknown (nebulous).

Since your coin is named RaiBlocks, perhaps you had seen the following before:

https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/


Even if you do record the voting, then the problem is there is "nothing at stake" in the short-term and thus history can be rewritten in the short-term. The various proof-of-stake algorithms attempt to penalize short-term adversarial behavior to eliminate this "nothing at stake" hole.

Assuming you work out how to penalize short-term adversarial activity (and not just rely on the non-quantitative game theory myopia that adversaries won't be self-interested because they devalue the coin and thus their holdings in the coin) to remove "nothing at stake", rely on "weak subjectivity" of social consensus for long-term check points, work out how to incentivize fast recording and propagation of majority confirmation, then you will have achieved some form of block chain scaling, but until those specifics are revealed (not yet invented?), then we can only speculate. One thing that appears to be clear in your RaiBlocks design is that every full node must receive and verify every transaction in your system, so that aspect of scaling hasn't been improved.

Btw, I will tell you that I worked out those design issues already. Essentially my comments above are directing you to my design.

Monsterer and I have been having discussions and you may not be in as much agreement as you believe.


Those words are in quotes though it is not factually a quotation.


There is no such thing as Byzantine fault tolerance since the byzantine problem is stated in terms of separation of communication a.k.a. network partitioning.  Only after partitions have been merged can a final conclusion be reached for instance bitcoin isn't tolerant against partitioning since if the network was partitioned and each separate segment was generate separate block chains, a conclusion as to which is the longest couldn't be reached until the partitions were merged and the results compared, hence it would no longer by a byzantine problem.  Please read up more on the topic before commenting on them.


Again, the CAP theorem states that all three states cannot simultaneously be achieved so by the nature that RaiBlocks, in addition to any crypto currency, does not claim it can operate while partitioned, this means at most we're claiming 2 out of 3 which by definition satisfies the CAP theorem and no cryptocurrency out there is violating it.  Please read more before commenting.


That's not correct, the consensus now is all that matters.  For instance as humans we don't have a record of all governments and all decisions going back to the beginning of time yet we have a consensus about what we agree to at this moment.  A historical record can be interesting but the only thing that matters is consensus at this current point in time, only historians care about anything else and currency isn't about a history lesson.


This seems to be erroneous.  Historical consensus cannot override contemporary consensus, contemporary consensus is the only thing that matters with RaiBlocks.  The only way to erase history is for the current consensus to flip blocks a.k.a. a true, >50% attack.


This is describing a >50% attack, all cryptocurrencies are vulnerable to this though RaiBlocks give a stronger guarantee.  With RaiBlocks >50% of the MARKET CAP needs to vote to flip, with PoW only 50% of the mining strength needs to flip.  If you look at BitCoin's market cap of ~4billion, and ask: could you gain majority mining power with ~2 billion in mining hardware?  Absolutely.  PoW is a weaker guarantee.



Again, looking back to the beginning of time is unnecessary, whether Tlok in his cave in 5000BC got a majority vote is of no consequence today when I spend my money, no one cares, it's just slow.


This speculation is unnecessary since I'm making no such claim.  The algorithm stands as-is.


What's at stake is market cap which is why voting is given, in proportion to balance held, to value holders.  Only people holding value in the network truly care about its health.  A >50% attack definitely does have something at stake, they're destroying the currency that they own 50% of.  Would a bitcoin holder who held 2 billion in bitcoin start DDOSSing the network or mining in forks?  Absolutely not, they'd lose their investment.


As has already been fully and completely demonstrated, a fully history is unnecessary.


Monsterer and you have fewer agreements than you believe.


That's true, in fact most people who use bitcoin are invoking trust because they trust the wallet they're using to correctly evaluate which chain has the highest block work and not log the password to their private keys.  As much as people want to believe otherwise, all cryptocurrencies have a degree of trust when downloading a wallet and bootstrapping to the network.


This seems to be a fundamental misunderstanding of the system as a whole.  Voters are a one-to-one function of chains, though it's not onto since accounts can designate a representative to vote with their stake on their behalf.


Since all chains are replicated to all peers, there is no partitioning.  Again, this system, like all cryptos does not insure correctness in the case of partitioning.  I don't know why the CAP theorem ever needs to be brought up, no one ever claims their crypto works when the network is partitioned.  If you ever cite the CAP theorem again, please directly and succinctly cite where someone is specifically and directly saying their crypto will work in the case of network partition, otherwise you're technobabbling.


Durability is ensured as much as durability can be assured in any distributed system, by broadcasting the transactions to all nodes.  Do you mean Durability in the sense of ACID transactions or is this a new definition of durability?


I'll defer commentary on this conclusion until proper reading is performed.


That may not be the only way, it's impossible to prove unknowns; this is a flawed conclusion.


Again, history cannot be rewritten without a >50% stake in contemporary consensus in which case 50% of the market cap is voting to destroy their investment.


You're stating this is myopic but this is the exact rhetoric people use when rebutting against why miners wouldn't start mining forks in to BitCoin.  Destroying the protocol destroys future profit in the protocol hence it's in the miner's and voter's best interest to come to consensus instead of creating volatility.  This seems to be a fundamentally flawed application of game theory.

I will wait to see a public post from monsterer if he disagrees with my assessment. Are you referring to private discussions with him? Because in my quick perusal of his public posts in this thread, they seem to be congruent with my points. Feel free to point out a case where you think his points are not congruent with mine.


Perhaps American English is not your native language? I did not quote you. If I did, I would have used the normal forum quoting as I always do. Placing a phrase between double quotes can also mean that the quoted description is an example of how someone might say it (not specifically any person, since the quote was not attributed to any person).


Do NOT again write an absurd condescending remark that assumes I hadn't yet researched the fundamental concepts.

Try to remain respectful please (and leave the ad hominem diarrhea aside) as we had been up thread.

I have no idea what rational basis you have told yourself to justify assuming I don't understand the definition of Byzantine fault tolerance. How could I possibly be commenting with so much technical knowledge in your thread if I hadn't yet researched the fundamental concepts.

https://en.wikipedia.org/wiki/Byzantine_fault_tolerance


Your understanding of Byzantine fault tolerance is incorrect. Per the definition above, Bitcoin delivers the same expectations (symptoms) for CAP (consistency, access, and partition tolerance) to all observers which are participants in the longest chain partition. The probability of a failure decreases probabilistically over time as the number of confirmations on the longest chain increases. There are degenerate cases such as the 51% attack where Byzantine failure occurs.

Note the double-spending on a minority chain is not a Byzantine failure, because by definition the minority chain is invalid.

There is no such thing as absolute anything in the universe, thus arguing that Byzantine fault tolerance is not universal is a vacuous assertion. Byzantine fault tolerance is defined for a system and the defined objectivity of the system, not for universal absolutism.


This ad hominem noise again.

Yet another vacuous argument demonstrating that you do not understand that Bitcoin is partition tolerant within its Byzantine fault tolerant objectivity. Byzantine fault tolerance doesn't mean that CAP has to be fulfilled for those observers who are ignoring the longest chain rule or who are unwilling to accept the probabilitistic nature of the expectations (and thus the fault tolerance). Within Bitcoin's objectivity of the longest chain, all three of the CAP attributes are attained. And my criticisms of your design are about its ill-defined objectivity.

Let this technical rebuttal be instructive to you on the fact that my skills/expertise/research in this area are higher than you apparently assume (given your condescending remarks and your continual unwillingness to accept that 3 experts gmaxwell, monsterer, and myself have come into your thread and graciously tried to explain that your design has serious flaws).

The rest of your reply really seemed to start going off the rails of rational logic. But I will try to find the desire to reply to it point-by-point after I cool down from the lashing of your condescending assumptions above.

According to the writer's handbook https://writing.wisc.edu/Handbook/QPA_quoting.html  Quotations are literal quotations and should cite references, Adding Clarification, Comment, or Correction requires square brackets around what you're modifying.


No ad-hominem assertion has been made, I remarked that you don't know what you're talking about, not that the comment is incorrect because you as a person are making it.  This is an incorrect application of the ad-hominem logical fallacy.


That's the question, I think you're actually technobabbling and don't have technical knowledge.  I think you've mined technical phrases and are repeating them, incorrectly.


The continuous citation of the CAP theorem is ridiculous.  BitCoin does not have partition tolerance according to the cap theorem "the system continues to operate despite arbitrary partitioning due to network failures"  BitCoin does not operate in the presence of arbitrary network failures, this it categorically wrong.  No cryptocurrency can operate while partitioned, they can recover from partitions but they cannot operate while partitioned.  CAP does not apply to any cryptocurrency ever, repeating it at all is absolutely absurd.


Nothing ad-hominem about it, you're wrong because it's an incorrect conclusion, not because you're the person making it.  I'm sure you're capable of making a correct conclusion.


I'm sure you'll have no problem writing up another post ;)

http://www.apastyle.org/learn/faqs/use-double-quotes.aspx


http://www.scribendi.com/advice/when_to_use_double_or_single_quotation_marks.en.html

---

I warned you not to write condescendingly to me again. Now I will more forcefully state the facts.

I can see I am dealing with a pedantic Dunning-Kruger jackass who has too limited understanding of the technical field to discern technobabble from expertise.

Arguing with someone who is not knowledgeable enough in the field to know whey are acting as a Dunning-Kruger jackass, ends up being an enormous waste of time and effort for the expert.

When you are ready to come down from your ignorant high horse and learn, let me know.

Note most readers here are not knowledgeable enough to discern that you are not an expert. Thus you can probably convince them to invest in your project. The proof of failure will come down the line. No need for me to educate you beforehand, given your attitude.

Bitcoin does "continue to operate despite arbitrary partitioning due to network failures".

Again you conflate the double-spend on a forked network in your mind a claimed refutation of CAP, because you assume CAP is only useful in an absolute frame-of-reference. But absolute frames-of-reference do not exist in the universe. And this shows you do not understand the definition of "Byzantine fault tolerance", because it only applies to the nodes on each of the forked networks as to whether the objectivity of the system has remained intact and the nodes can continue to operate within that defined objectivity.

Essentially what you are trying to say with your design and your arguments in this thread, is there is no possible objective frame-of-reference, because there never can exist an absolute one. You conflate absolutism with relative objectivity (which btw is all we have in our universe, because nothing is absolute).

At least Bitcoin achieves CAP up to the limitation that networking partitioning can fork the Bitcoin network and the participants on each fork can continue to operate. Whereas, your design doesn't even achieve assurances of objectivity even without network partitioning.

I do not appreciate your ad hominem accusations claiming/implying that I am generally not correct in my logic because it is another attack on my person instead of refuting a stated technical issue. (Nothwithstanding that my logic is correct and you are not skillful enough to discern it yet)

Also you conflate a) refuting a stated fact; with b) making a statement about a person's need to read before commenting. The former is not ad hominem, the latter is ad hominem. Period.

Edit: also you are assuming CAP only applies to the physical network partitioning, but it also applies to logical partitioning. Bitcoin is resilient to logical partitions (forks) because of the longest chain rule. Your design is not analogously resilient, which monsterer and I have explained.

Perhaps you missed the fact that I already stated that without recording of the voting, there is no way to know when "now" is as it pertains to confirmation of consensus being attained. How is the payee supposed to know when to trust the payment and release the goods or services?

---

---

This is because you have no objective means of determining which set of "now" is the reality. Thus you assume that the online nodes will just magically agree on the "now" they all have. The fact that you can't see that you've failed to even define the way the majority chain is objectively determined, should be indicative of that you are not sufficiently knowledgeable to design a new block chain paradigm.

Two or more errors don't make it correct. You can state that your system flies to the moon and if that assumption is based on foundational errors then no one can disprove your claim. The proof will come in the fantastic devolution of your system in the wild.

Also you seem to have lost the point that if the historical coins locked was only 1% of the coin supply, then only 1.1% of the coin supply would need to be retroactively locked to rewrite history in the lack of durable objectivity in your system.

I am not going to go back and forth with you on the comedy of errors. It is a pointless waste of my scarce time.



Logic fail. You are assuming every coin is locked so every coin votes, which means no coins can be transacted. Duh.


You habitually conflate orthogonal concepts.

Even if the vast majority of users do not run full nodes, the security of Bitcoin is still based on the objectivity of the full nodes, which your design does not possess.


The astute people such as Gregory Maxwell understand how critical it is that no party has 51% or even 25% of the network hashrate. Do not let what fools write misdirect you on the objectivity of Bitcoin.

I'm afraid I largely agree with TPTB_need_war; without a voting history, I find it hard to see how there can be a reliable, unforgeable consensus for 'now'.


This is true in the real world because time travel is impossible.  Cryptocurrencies must strive to make time travel, voting on past history, or presenting fraudulent histories very hard, or the 'now' won't be reliable or consistent.

It seems like the analogous situation in bitcoin is being fed shorter block chains that were dropped.  When synchronizing we don't give shorter chains to people because it's irrelevant, we only give people the longest one a.k.a the contemporary state.

What would voting history give?  What if they only replay certain votes?  History is really unnecessary.

In bitcoin you can give any node any set of chains - the node simply chooses the longest one; this is trustless and always consistent.

If you had voting history in raiblocks, at least the synchronizing client could make some kind of judgement based on several forks which it is presented with. As it stands, it has to ask other nodes which is correct, which is not a trustless operation and on top of that, said nodes must expend their own resources to re-vote on the historical forks (the DDOS angle, I've previously mentioned).

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.

We also use stateless UDP rather than TCP so far fewer network resources are consumed.

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

I guess it's an engineering tradeoff, do we want fast confirmations and unbounded global throughput at the expense of edge-case trust which I still find fairly impractical.

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?


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


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

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.


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.

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?


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

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.

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.

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.

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.

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.

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

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 (https://docs.google.com/document/d/13s6BKzRq9oD5Me55JBRzR7BdvjJ44QKqPu2lf-JsAlU/edit?usp=sharing)

Let us know if there are any issues.

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

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.

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?

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.

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.

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.

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

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

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.

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

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.

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?

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.

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.

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.

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.

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.

Look where we are now...this thread is legendary. hahah

Am I right that the majority of this thread (all the talk about storing votes on chain or not) comes down to this exact problem? A bootstrapping node can be fooled with a fork if whoever had the majority vote at the time of the fork votes differently when this new node is syncing for the first time. That brings up another question: if nodes A and B have all the voting power at block 100, but today at block 500,000 the voting power is owned by nodes C and D -- won't a new bootstrapping node, encountering a fork at block 100, ask for votes from nodes A and B? What if those nodes are so old they are offline forever by now? Or even worse if their private keys have been compromised since block 100, then anyone can trick a bootstrapping node and send them off on a new fork starting at block 100...?

What is bootstrap poisoning? (https://github.com/clemahieu/raiblocks/wiki/Attacks)

The Wiki mentions an attacker holding onto an "old private key" with a balance. What is the difference between a new private key with a balance and an old private key with a balance? A private key is a private key.