Applying Ripple Consensus model in Bitcoin

[jl2012]

Although I don't like the loan-based idea of Ripple, I think its consensus model is useful in protecting bitcoin against 51% attack.

Read more here: https://ripple.com/wiki/Consensus

We can apply consensus on top of the current PoW model. When a block has got 6-confirmations, nodes (both miners and non-miners; "validators" in Ripple jargon) will sign the block with their private keys, as a vote of its validity and uniqueness. In a normal situation, all honest nodes should come to consensus, and honest miners will never accept any conflicting blocks. Therefore, any secret 51% attack (secretly mining and suddenly releasing a longer chain) will never succeed for more than 6 blocks. Even a 1-million USD worth transaction is perfectly safe with 6 confirmations, which is not really safe with pure PoW.

There will be 3 classes of validators:

Elites: Same as Ripple, these validators should be non-anonymous to avoid Sybil Attack. Elites could be bitcoin merchants, devs, trusted OTC traders, and active forum participants. Elites will publish their GPG/bitcoin public key hash on their websites or on the forum.

Miners: Miners will include GPG public key hash (or public key hash of an empty bitcoin account) in their coinbase transactions, so they don't need to maintain a hot wallet for this purpose. Miners could be anonymous or non-anonymous.

Riches: Riches are holders of big account (aka. proof of stakes). For the same safety reasons, riches will publish an alternative GPG/bicoin public key hash with a specially crafted transaction. Riches could be anonymous or non-anonymous.

There will be overlapping between 3 classes of validators, especially if some were anonymous. Therefore, anonymous Miners and Riches will have lower voting power.

As long as the validators are highly diversified, the risk of these people colluding to defraud is extremely minimal. If they do so, that will destroy their real-world reputations.

In case of network-split, for over 6 blocks, we may need some human interventions. AFAIK, a split in this scale has never happened; and if it did, it would be a disaster on its own and the consensus model would not make it worse. Actually, the consensus model will make the system more robust against a network split, as people will find a large proportion of validators missing, and they will reject any new transaction until the network is re-merged. The current bitcoin client does not give any warning in case of suspected network split.

As we have checkpoints in Satoshi client, the system is technically not pure PoW. However, checkpoints are usually thousands of blocks behind and that's not enough to protect us against 51% attack. Philosophically, checkpoints are hard-coding the community consensus to the code. Why don't we make this process more decentralised and automatic?

I know this proposal is not new, but I think Ripple is the first one trying to implement this. Let's see how it works then we can implement it to bitcoin. As the bitcoin economy keeps growing, I believe this will give more confidence to all users and investors.

EDIT: I don't think Consensus nor PoW is safe enough on their own for millions USD transactions. However they are much stronger when combined and the whole thing is still P2P decentralised.

[Atruk]

Please, no.

[jl2012]

Please, no.

Please, give reasons.

[jl2012]

In case you do not aware, checkpoints (https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp) are currently applied to Satoshi client. This means no matter how much hashing power one has, he will create a hard fork by trying to replace blocks before the last checkpoint. Therefore, bitcoin is never a pure PoW network.

Currently, checkpoints are implemented for about every thousands of blocks, and it is solely determined by the devs. So theoretically, the devs could hardcode every single new blocks as checkpoints, making themselves as the central bitcoin clearinghouse, working like SolidCoin. My proposal is just trying to decentralise the process of checkpointing. If 6 blocks is considered too short, we may make it every 100 blocks, but definitely not thousands of blocks. 100 blocks checkpoint is not too bad, at least I am sure that the 10 million USD worth of BTC that I received in the morning will become completely non-chargebackable in the evening.

[Atruk]

In case you do not aware, checkpoints (https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp) are currently applied to Satoshi client. This means no matter how much hashing power one has, he will create a hard fork by trying to replace blocks before the last checkpoint. Therefore, bitcoin is never a pure PoW network.

Currently, checkpoints are implemented for about every thousands of blocks, and it is solely determined by the devs. So theoretically, the devs could hardcode every single new blocks as checkpoints, making themselves as the central bitcoin clearinghouse, working like SolidCoin. My proposal is just trying to decentralise the process of checkpointing. If 6 blocks is considered too short, we may make it every 100 blocks, but definitely not thousands of blocks. 100 blocks checkpoint is not too bad, at least I am sure that the 10 million USD worth of BTC that I received in the morning will become completely non-chargebackable in the evening.

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.

[jl2012]

In case you do not aware, checkpoints (https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp) are currently applied to Satoshi client. This means no matter how much hashing power one has, he will create a hard fork by trying to replace blocks before the last checkpoint. Therefore, bitcoin is never a pure PoW network.

Currently, checkpoints are implemented for about every thousands of blocks, and it is solely determined by the devs. So theoretically, the devs could hardcode every single new blocks as checkpoints, making themselves as the central bitcoin clearinghouse, working like SolidCoin. My proposal is just trying to decentralise the process of checkpointing. If 6 blocks is considered too short, we may make it every 100 blocks, but definitely not thousands of blocks. 100 blocks checkpoint is not too bad, at least I am sure that the 10 million USD worth of BTC that I received in the morning will become completely non-chargebackable in the evening.

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.

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.

[Atruk]

In case you do not aware, checkpoints (https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp) are currently applied to Satoshi client. This means no matter how much hashing power one has, he will create a hard fork by trying to replace blocks before the last checkpoint. Therefore, bitcoin is never a pure PoW network.

Currently, checkpoints are implemented for about every thousands of blocks, and it is solely determined by the devs. So theoretically, the devs could hardcode every single new blocks as checkpoints, making themselves as the central bitcoin clearinghouse, working like SolidCoin. My proposal is just trying to decentralise the process of checkpointing. If 6 blocks is considered too short, we may make it every 100 blocks, but definitely not thousands of blocks. 100 blocks checkpoint is not too bad, at least I am sure that the 10 million USD worth of BTC that I received in the morning will become completely non-chargebackable in the evening.

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.

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.

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

[jl2012]

In case you do not aware, checkpoints (https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp) are currently applied to Satoshi client. This means no matter how much hashing power one has, he will create a hard fork by trying to replace blocks before the last checkpoint. Therefore, bitcoin is never a pure PoW network.

Currently, checkpoints are implemented for about every thousands of blocks, and it is solely determined by the devs. So theoretically, the devs could hardcode every single new blocks as checkpoints, making themselves as the central bitcoin clearinghouse, working like SolidCoin. My proposal is just trying to decentralise the process of checkpointing. If 6 blocks is considered too short, we may make it every 100 blocks, but definitely not thousands of blocks. 100 blocks checkpoint is not too bad, at least I am sure that the 10 million USD worth of BTC that I received in the morning will become completely non-chargebackable in the evening.

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.

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.

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

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)

[Peter Todd]

In case you do not aware, checkpoints (https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp) are currently applied to Satoshi client. This means no matter how much hashing power one has, he will create a hard fork by trying to replace blocks before the last checkpoint. Therefore, bitcoin is never a pure PoW network.

Currently, checkpoints are implemented for about every thousands of blocks, and it is solely determined by the devs. So theoretically, the devs could hardcode every single new blocks as checkpoints, making themselves as the central bitcoin clearinghouse, working like SolidCoin. My proposal is just trying to decentralise the process of checkpointing. If 6 blocks is considered too short, we may make it every 100 blocks, but definitely not thousands of blocks. 100 blocks checkpoint is not too bad, at least I am sure that the 10 million USD worth of BTC that I received in the morning will become completely non-chargebackable in the evening.

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.

[Atruk]

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.

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.

[jl2012]

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.

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.

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

[Atruk]

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.

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.

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

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.

[jl2012]

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.

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.

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

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.

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.

[Meni Rosenfeld]

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

[jl2012]

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

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.

[Peter Todd]

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

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.

[JoelKatz]

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.

[jl2012]

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.

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)

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.

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.

[jl2012]

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.

[Peter Todd]

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.

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.