Topic: Applying Ripple Consensus model in Bitcoin (Read 5059 times)

That is good.  However, I think the signed statement is to strong.

A softer version would prevent hard forks

"If this promise is signed by the miners of 96 of the last 128 blocks (so 75%) then I promise not to mine any other chain, unless that chain is at least 6 blocks longer than this one."

Does the reference client actually do that?

First let me apologize for my relatively new participation in this thread on on this forum...it actually feels embarrassing to post on this thread with such a low post count and such a new presence.  I'll explain right off that I am not an expert in cryptographic hash functions and my coding is so dated  that the source for bitcoin reads like greek to me.

I do however have a great deal of business experience with some military training on computer security.  I spent hours searching the boards to find a thread just like this one and hopefully I'm posting this in the right place. 

 I knew that there had to be a discussion already about addressing the weaknesses of bitcoin...specifically the compromise of the 51% weakness in bitcoin.  Many have assumed that this was only relevant to a smaller network but you guys have touched on the bigger issue here.

Unfortunately, the nature of bitcoin at large difficulties is manifesting in exactly what we're seeing - a migration to large pools.   This is exposing a very very large weakness in the system that can bring bitcoin down.    A large scale DDOS attack that is well coordinated can easily bring down enough of the network by targeting the large pools that one could replace the blockchain with an alternative model while the majority of the system was offline.   Sadly this doesn't even require a great deal of resources and the exposure gets more and more pronounced as this phenomenon perpetuates.

I know the anarchists that love bitcoin for its lack of government will balk at this but a system (even if its a concurrent system run by the major pool operators to validate the blockchain) of officiating needs to be put in place asap (can be read limited government).  Presumably the concurrent checking system offers the most benefit but it removes some of the power and transparency from the entire network. 

I would propose that this forum forward the idea of a bitcoin coalition that is comprised of developers, pool operaters, exchanges, and elected participants to meet at least once a year and to be accountable for changes to bitcoin for the betterment of bitcoin.   Even a summit once a year and an agreed upon system of checks and balances to ensure the integrity of the blockchain would go a long ways to to ensuring that we all have something real in a decade.

Destabilizing bitcoin because we want to be stubborn about not putting in a system of checkpoints or checking measures will inevitably lead to failure..like it or not Bitcoin is no longer just a social experiment...there are livelihoods, retirements, and hard earned money riding on the motley crew of individuals that operate on this forum and support the infrastructure of bitcoin... I think we should take responsibility for that.

Please let me know your thoughts, PM me or tell me I'm what a government whore I am publicly but I'd like to see this brought into the light if I'm on target.

This could be done right now, with no modification in Bitcoin protocol. It could be a parallel protocol. Nice idea.


The length of a chain is not the number of blocks, it's the the total aggregated difficulty. As long as they new node has one connection with a non-attacker node, he'll fetch the correct chain.

Go right ahead; no-one is stopping you. Merchants especially should be using chain monitoring to determine when something may be going wrong and they may want to stop accepting orders. But don't use chain monitoring for miners, at least automatically: a false alarm of the monitoring mechanism can be used as a way to create a network split in itself.

If this idea is too controversial, could we first build it as an alarming system against chain split and massive chain rewrite? This is particularly useful in a case of network split, as some people will find that many validators are missing suddenly.

If someone has enough hashing power to rewrite every single blocks up to block #1, the IBM 4758 will still accept it as the legitimate chain but I don't think that's what we want. Human intervention is unavoidable in such circumstances. The question is, to what extent we could tolerate a blockchain rewrite? 6? 100? 2014? 210000? There must be a cut-off point where human intervention is needed.

The bitcoin wiki (https://en.bitcoin.it/wiki/Contingency_plans#Many_historical_blocks_replaced) suggests that 6+ block rewrite is unacceptable and warrants taking down the network for more than a week to fix it manually. If we believe it is the right way to handle massive blockchain rewrite, why couldn't we consistently implement checkpoints based on human consensus?

As the IBM4758 is programmable, the list of validators could be updated manually. With remote attestation, it is not possible to inject malicious validators to the system.

If people are really uncomfortable with the concept of "elites", we could restrict it the "miners" and "riches". The identity of miners and riches could be determined automatically through the blockchain and no human intervention is needed. (With miners using the consensus scheme would not undermine the security, see below)


As the automatic checkpoints are for blocks with 6+ confirmations, someone may fork the chain up to 5 blocks. In this case, people will only accept payments with at least 6 confirmations. Trying to replace a block with 6+ confirmation is not possible because all honest mining and non-mining nodes will treat the original block like a hard-coded checkpoint. Although an evil miner may try to extend his own illegitimate chain, no one would accept it: once consensus is made, it is irreversible without human intervention.

For the alert system, I think it is controlled by the devs. As they are not constantly monitoring the network, an automatic warning system would help. Also depending to much on the devs during emergency is just another single point of failure.

I think there are a few ways that could work that might be interesting. For example, a minute after a block was found, mining pools could issue a signed statement that they commit to never publish a block not built on a chain that includes the recently found block. If you had such signed statements for significantly more than 50% of the hashing power, you wouldn't need to wait for any more confirmations.

But fundamentally, consensus can only work if you change the rules that the longest chain is the valid one. Otherwise, nobody can really promise a particular block will remain valid.

That would be a fairly fundamental change in Bitcoin.

Proof of work via SHA256 hashing is really nice because you can validate it by machine. For instance a nifty project would be to get some remote attestation capable hardware like the IBM 4758 cryptographic coprocessor often used by banks. Basically what's special about it is the hardware itself is exceptionally difficult to tamper with, and additionally IBM includes a mechanism called remote attestation where the hardware will tell you what software is running on it. Since these co-processors are used for many, many different purposes IBM can't release hardware that lies without damaging a significant amount of trust in them.

So, what you would do is write a very small, very simple piece of code that implements the Bitcoin block hashing algorithm. What this code would do is accept encrypted messages from anyone, either the query "What's the legit block chain?" or the statement "Here is the next block in the chain" Since the messages are encrypted the operator of the service can't prevent someone from telling the hardware about the best known chain, so anyone making a query asking what the chain is can be pretty sure that the response is accurate. The existence of this service would allow others to use it to bootstrap their own clients without needing to know any honest nodes at all.(1) Smart Property is a good example where this service would be useful. Additionally it could argument or replace the checkpoint mechanism.

The problem with Ripple-style consensus is stuff like the above just can't be done because maintaining a list of public keys associated with trusted entities is fundamentally a task that only humans can do. For Ripple human consensus is probably a reasonable idea - Ripple depends on human evaluation of trust relationships anyway - but applying that concept to Bitcoin would turn it into something very different than it is now.

It also isn't a given that it would make Bitcoin any more secure either: if miners use this consensus scheme too, then by breaking the consensus you can either re-direct hashing power to your new, illegitimate chain, or failing that, turn the hashing power off to make a 51% attack easier. For non-miners consensus can help, but only in the sense that the consensus is warning you something is wrong, so you shouldn't trust transactions for now until we figure out what is wrong. Bitcoin already has a primitive version of that with the alert system anyway.


1) You do need a RNG to create nonces to prevent replay attacks. Also note that neither the client nor the server need a clock; if a 51% attacker does not exist, the length of the valid chain will always outpace any false chain. That said, at least having an uptime timer is useful so clients can determine if the server has been running long enough to have been told about the best block; similarly a message counter is also useful.

Multiple servers should exist, and clients should always query multiple servers and also automatically provide out-of-date servers with updates. You will have to be careful though to ensure queries for the chain and update queries are always exactly the same length. Additionally client behavior for either action needs to be identical to ensure updates can't be censored. (without breaking the encryption of course) The fact that the hardest PoW's in existence have about a 98% chance of being Bitcoin block hashes (2% chance of being orphans) could be useful.

Clients do need to have a way to prevent attackers with control of their upstream network connections from setting up these servers themselves. Simply having a list of trusted pubkeys of people who you trust to set such a server up with one good option; the hardware itself tends to be fairly expensive too. You can also get clever and have the server create a PoW based on their identity; a Bitcoin PoW for an invalid block is nice because determining the value expended is relatively easy. You can also have the clients pay for each message by performing the PoW on your behalf, and recording the hardest PoW found to in turn use as your proof that the server is legit.

As long as people have the freedom to choose which elites to trust (or not trusting them at all), that would be fine. Although I call them elites, they are just some people with real public identities. Everyone could be an elite if want. If they were caught telling lies, their public keys will be blacklisted and their reputation will be ruined.

And this system functions only when there is a hostile 51% attack or a network split. If there was no 51% attack or network split, everything is equivalent to pure PoW and whoever you trust makes no difference. If there were a network split, the system will help you to identify it and again it is irrelevant to who you trust as long as your validator list is highly diversified. If there was a 51% attack, you have to trust somebody (e.g. devs) anyway, instead of blindly accepting the hostile chain rewriting 5000 blocks.

Yes, consensus is a step backward of blockchain, but this doesn't mean it is totally obsoleted and we could use it strengthening PoW. We will see how it works (or not works) on Ripple. If a pure consensus model works, then consensus on top of PoW must work.

I agree this is not of the highest priority but I think it is something has to be done before bitcoin can support millions USD transactions.

I think having to trust specific entities - even if they are multiple and diversified - is against the spirit of Bitcoin.

So that leaves miners and riches, effectively some PoW/PoS combination.

I have my doubts about the consensus model - it looks like a step backwards, what Bitcoin would have been before Bitcoin (and the blockchain) was invented. But assuming it proves itself technically, I'd be open for an alt that uses consensus for synchronization, and PoW for initial distribution (as opposed to Ripple's centralized model).

The list will only get more and more diversified. If bitcoin stays as a mini-economy with everyone highly connected, no one would spend millions of dollars to 51% attack it.

Decentralized checkpointing is only used to prevent massive blockchain rewrite. It does not replace mining. If there were no massive re-write, the checkpoints were not needed. If 70% of validators get kidnapped by aliens, the system will stop for a while as that will trigger the network split alarm and require human intervention. If no network split was found, the system will continue to work as usual.

Let's get past the point where checkpoints after mid-2010 really don't serve a purpose and the earlier checkpoints just make sure clients are on the right blockchain. I'm not sure you realize how connected many of the people on your list are, but you still want to implement some new checkpointing system you thought about enough to come up with layers of without coming up with enough  to offer some rules for it.

There are things to be paranoid about in cryptocurrency, but your anxieties seem misplaced. You seem to think the people are less fallible than the computing when you need to flip that around.

Have you considered this dietary supplement called Pimozide, I hear it helps people that nothing else can.

There is no single point of failure. With the collapses of Pirate and GLBSE, we still have MtGox, BTC-E, bitstamp, bitcoin-central, Bitcoin Foundation, Bitinstant, Coinbase, Bitcoinstore, MPEX, SatoshiDice, Bitcoin Magazine, BFL, all devs, all moderators and donors of this forum, all individual members of Bitcoin Foundation, and a lot more. The list is growing exponentially as bitcoin economy grows. If 50% of them collapsed on the same day, that's essentially the end of bitcoin and there is no point to protect the blockchain anymore.

Some people I listed may not be very trustworthy individually, but it is extremely unlikely for a majority of them colluding to defraud, while at the same time controlling 51% hashing power.

Retep makes no direct comment on my proposal. I'd like to know what he thinks

A link would be helpful. You have to understand though that after an event like last years twin towers of the Pirate and GLBSE collapses, most or all validators not being so trustworthy is a tremendous concern.

Retep makes a much more beautiful case than I can, because at the moment I am a vodka fueled trolling monster.

The reason why checkpoints are included in the reference client isn't to define what the valid blockchain is. They are included primarily so that during your initial synchronization with the network, when your client has no idea what the valid blockchain is, someone can't create an alternate blockchain from scratch with a lower difficulty, but equally long history. Remember that for much of Bitcoin's history difficulty was so low that an attacker would have a relatively easy time creating a chain with a higher total work up to that point. With checkpoints if your client happens to initially connect to evil nodes broadcasting a fake history, it will eventually hit a checkpoint, see that the hashes don't match, and at worst simply fail to sync up until it finds an honest node to connect to. For instance I run the only testnet DNS seed, (new in 0.8 ) and if the IRC channels also used for seeding were down I could easily make clients believe any chain they want by mining my own chain and advertising only evil nodes I controlled. (testnet has only one checkpoint, just 500 blocks in) Of course, testnet BTC are worthless, so I'd accomplish nothing more than annoying people.

The second thing checkpoints do is they remove the requirement to actually do ECC verification for transactions in any block prior to the last checkpoint. Basically if a transaction is in a block protected by a checkpoint, you can be sure that the transaction is valid, thus you can skip checking the signatures and instead just check the transaction and block hashes to make sure you have the correct data, and update the unspent transaction output database. This significantly speeds up initial synchronization on slow machines.

The checkpoints may be chosen solely by the devs, but it would be significantly harder to sneak in malicious checkpoints than it would be to steal your coins any other way. They're just a list in src/checkpoints.cpp and any change to that list gets reviewed by lots of people. For instance I'm not a developer, but I personally made a point of reviewing Gavin's new checkpoint proposed for 0.8, and lots of people on IRC reviewed the change as well.

You can always turn checkpoints off by using the -checkpoints=0 flag. If for some reason there was a re-org event large enough that thousands of blocks were re-organized disabling checkpoints and using the new, longer, re-orged chain might be a perfectly reasonable thing to do, although trust in Bitcoin at that point would probably be so shaken it might not matter much.

It is not difficult to name 100 elites (and we also have miners and riches). As the economy expands, we will have thousands of merchants working as validators (they will do it for free to protect themselves). One or two of them missing would not be a problem at all. If, however, a large proportion of validators were missing, it may suggest a network split and everyone should stop accepting new transactions. The Ripple wiki has explained how this works.

The block signatures need not to be written to the blockchain. They are P2P circulated and stored in a seperate database. Validating nodes only need to keep signatures for blocks after the last checkpoints. (Actually only the signatures for the last block is required, because they are also confirming all of its parent blocks)

WIth these validators my concern is not rewriting the chain. It is denying blocks validation because people just up and disappeared.

6 blocks is just a convenient number. I think as much as 100 blocks is reasonable and a split in this scale is very very unlikely. People like Pirate cannot exploit this system unless he has 51% hashing power; and even Pirate has 51% hashing power, he has to control at least 51% of validators before he could rewrite the chain.

I don't mind checkpoints as they are implemented. I worry about the ripple validation model because chain splits aren't actually that uncommon for a block or two, so as unlikely as a six block split is the six block split would be a concern in the validation model if there is a split vote between the two forked chains. There's also the more practical matter of just how much data is going to be added to the block chain if numerous parties from three distinct classes are signing every block once it reaches a depth of six.

Trusting the core devs as they develop the software now is easy, because everything they commit is open. Expanding the circle of people to trust with such an intimate part of the software seems potentially messy. What happens if a number of your Elite validators just stop validating. Pirate and many of his pass through operators had great OTC ratings before the world burned and fools lost their money. You introduce a potential vulnerability that can come through a shortage of signatures on top of the one from a potential drop in hashing power.

That and the only proof of stake systems at the moment (PPCoin, Novacoin), seem to have implementations that aren't all that vetted.