Applying Ripple Consensus model in Bitcoin

[caveden]

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.

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

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.

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.

[peewee]

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.

[TierNolan]

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.

Does the reference client actually do that?

[TierNolan]

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.

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