Creating a fair alternative to Ripple

[Red]

Ripple's basic protocol seems fairly sound in this manner.

Can you link me to this discussion please? Want to see if they do it the way I presume they do it.

[1714017676]

1714017676

[1714017676]

1714017676

[anti-scam]

Ripple's basic protocol seems fairly sound in this manner.

Can you link me to this discussion please? Want to see if they do it the way I presume they do it.

https://ripple.com/wiki/Consensus

[ebildude123]

There is already a fair alternative.
It's called Bitcoin 

[Red]

https://ripple.com/wiki/Consensus

Thanks for the link. I was presuming there was earlier discussion on this forum.

It's all good. I've been researching Ripple technical specs and it is f***ing awesome. Ripple has already implement most of BitCoin's wish list.

No I'm not referring to monetary policy. Just the technical under pinnings. You could fork the ripple code base and recreate the existing bitcoin transaction tree inside it. You could create exactly the same BitCoin rules with added internal exchange trading. No more MtGox. Oh yeah, and you wouldn't need to burn up CPUs, GPUs, FPGAs, ASICs. You could just award the mining transactions to the nodes validating the transactions.

[danyy]

yeah i tiink is an scam, i dont know how the people are spending BTC on it, soon there will be worthless

[anti-scam]

There is already a fair alternative.
It's called Bitcoin 

Bitcoin is a currency. Ripple is a payment network. There's a huge difference.

[nameface]

It would be pretty great if you would pull this off. I've had the same idea but I have nowhere near the ability to pull it off.
I support Ripple because, hats off to them, they are making something necessary actually happen.

[JoelKatz]

You could just award the mining transactions to the nodes validating the transactions.

We have tried to come up with a way to do this and failed. If anyone has any suggestions for a way to do this, I'd love to hear it. The basic problem is that there's no good way to figure out who is "really" a validator in a way that everyone can agree on.

[Come-from-Beyond]

Ripple++

[cox]

I wold really like to see a fair alternative to ripple,

repost from newbie area

In my mind what makes Bitcoin beautiful is not just the genius crypto, it is just as much the balance of the different incentives that encourages community participation. Lets take a look at these:

1 .Mining incentivices participation in network infrastructure creation and participation, both now and in the future. Now mostly for the reward of finding new blocks 25 Btc, but also in the future for claiming the spent fees as a reward for finding the next block.

2. Participation and use of Bitcoins incentivises the increased use of fees for transactions, the genius of having a block interval of approx 10 minutes. Increases the likelihood of people spending fees to speed up the transaction witch again supports the incentives in point 1. Taking Litecoin where transactions are much faster, I see the potential problem that incentives for paying fees will not be there in the same way witch in turn could weaken the incentives for keeping the infrastructure up.

3. For a bitcoin holder there is also the self preserving incentive to participate just to protect the value of your bitcoins. This holds true I guess for many if not all crypto currencies, but I have a feeling that the influence of this effect will be affected by the strength and success of the other incentives.

When it comes to ripple I can only see the influence of point 3 witch effect in turn is minimized by the lack of incentives 1 and 2. This will in my opinion likely be leading to tipping the balance of incentives in the direction of OpenCoin, witch already from the beginning needs to build most of the infrastructure to get it up and running. If this assumption holds true this will definitely increase the likelihood of OpenCoin gaining way to much control of the infrastructure.     

[Milkshake]

Hashcash that scales with Moore's law would be a solution in my opinion.

[Red]

We have tried to come up with a way to do this and failed. If anyone has any suggestions for a way to do this, I'd love to hear it. The basic problem is that there's no good way to figure out who is "really" a validator in a way that everyone can agree on.

Sometimes I think you are taunting me...
I actually came up with an algorithm for this when discussing [SteadyCoin] consensus building. It's somewhere back in my post history. Ripple's consensus building is slightly different but I can summarize my original logic. Maybe it can be modified for ripple.

The validation/consensus logic was a variant of BitCoin's block consensus absent the PoW calculation. Each node executes a sequence of deterministic steps:
1) Generate a "candidate set" of validators.
2) Choose a primary validator from the set using a distributed random number generator.
3) Broadcast the primary validator's block to the other validators for confirmation.
4) Each confirming validator broadcasts an "Announce" transaction signaling they are now building upon this new block.
5) Each validator listens for Announce transactions from others on its personal known-nodes-list (Ripple's UNL) to confirm consensus has been reached.

---
1) A validator is in the candidate set if its "Announce" transaction is present in the current building block and in each of the preceding (N) blocks. [Good validators are consistent]

2) At each block interval (X seconds), each node chooses its primary validator by:
  a) Ordering and hashing all received transactions since the previous block.
  b) Comparing that hash to candidate set nodes using a distance function.
  c) The closest node becomes the primary validator.

3) If a node calculates itself to be the primary validator, it completes its block by generating any coinbase transactions and broadcasts its signed block hash.

(Theoretically, if every node was well connected and persistent they would all receive the same transactions, calculate the same primary validator, and be able to complete the final block according to pre-specified coinbase rules.)

4a) If the proper hash arrives from your expected primary validator, then "Announce" your confirmation by issuing a signed transaction that builds upon that block.
4b) If the proper hash doesn't arrive (or is invalid) presume the primary validator to have FAILED in its duties. Remove its "announce" transaction from your current building block set [(N) block candidate-validator penalty] and repeat 1-4.

5a) If a majority of the nodes on your personal known-nodes-list "announce" on the same block as you, all is well.
5b) If a majority of announcements aren't receive, then you are partitioned from the main network. STOP external trading.
5c) If, however, a majority "announce" on a block you are not expecting, then you must presume either you have FAILED (missed some transactions) or something malicious is happening.
  c1) Request the majority block and validate it.
  c2) Identify transaction differences between yours and the majority block.
  c3) If you missed transactions, announce on the majority block and continue.
  c4) If the majority block is missing transactions, announce on the majority block, re-broadcast the excluded transactions, and continue.
  c5) If there a double spends or conflicting transactions, Broadcast malicious user WARNING and halt any related external transactions.
  c6) If re-broadcasted transactions (c4) fail to confirm in the next block, Broadcast validator DoS WARNING.

Because of its (UNL) equivalent the system converges similarly to Ripple.
---
CoinBase reward/mining transactions can be assigned to validators using any pre-agreed upon rule set.

[StableCoin] dynamically adjusts the generation amount and distributes new coins to combat price instability. It doesn't have a default reward for validators.

BitCoin could use its "winner take all" rule to award all 25 BTC to the primary validator. The randomness of (2) above would spread the coins around over time.

Alternately, each new block reward could be spread among all the candidate validator nodes mining pool style.

Sybil validator attacks could be mitigated by either 1) requiring candidate validators to be non-anonymous (i.e. Ripple's UNL), or by 2) requiring candidate validators to put up a forfeitable (4b) fidelity bond.

  

[JoelKatz]

Sometimes I think you are taunting me...
I actually came up with an algorithm for this when discussing [SteadyCoin] consensus building. It's somewhere back in my post history. Ripple's consensus building is slightly different but I can summarize my original logic. Maybe it can be modified for ripple.
...

While I believe this can be made to work from a technical angle, I'm very nervous about how well it will work in the real world because of the incentives it creates. We want validators to have a strong incentive to broaden their UNL to avoid a network split. In this scheme, each validator you add to your UNL costs you money, and there's a much greater risk that the set of validators will be a small group that refuses to listen to anyone outside the group and presents a "take it or leave it" choice to the outside world.

Assuming you want the mining rate to be relatively fixed, every node except the one that "mines" a block now has an incentive to prevent a consensus being reached on that block because that's one more reward it won't get rather than a chance at that reward. Bitcoin doesn't have this problem because every miner has a strong incentive to build on the longest chain. I'm not sure how you could replicate that in this scheme.

[Red]

While I believe this can be made to work from a technical angle, I'm very nervous about how well it will work in the real world because of the incentives it creates. We want validators to have a strong incentive to broaden their UNL to avoid a network split. In this scheme, each validator you add to your UNL costs you money, and there's a much greater risk that the set of validators will be a small group that refuses to listen to anyone outside the group and presents a "take it or leave it" choice to the outside world.

Understood. This may be needlessly long.
TL;DR Summery: The KNL/UNL should optimally be the "non-anonymous" subset of non-malicious nodes.

See below for details. Especially the end where it mentions "fidelity bonds".
------
In my original "known-nodes-list" concept the KNL served more as a sanity check. If all your friends disappeared, you are probably forked (5b). Stop transacting and figure out where everyone went. Possibly even notify the HUMAN operator.

The role of UNL you describe, is actually handled by the validator "candidate set". That's where every time you add someone to the candidate set it splits the pie into smaller slices. Theoretically, it should have a set of well define rules that all other validators are required to follow. (i.e. 1) If they've been present, and 2) they are randomly chosen, and 3) their block validates, then 4a) everyone has to accept it.) <-- BitCoin style consensus.

So, if more people show up to validate you, theoretically, have to accept them. Those who don't accept a valid block are supposed to be presumed MALICIOUS (badly written 4b). The trouble of course is at the edges. What about transaction mismatches. Are those accidental (5c3-4) or malicious?. Certainly, if someone doesn't included a "slam-dunk" previously missed transaction (5c6) it should be considered malicious.

Assuming you want the mining rate to be relatively fixed, every node except the one that "mines" a block now has an incentive to prevent a consensus being reached on that block because that's one more reward it won't get rather than a chance at that reward. Bitcoin doesn't have this problem because every miner has a strong incentive to build on the longest chain. I'm not sure how you could replicate that in this scheme.

Here you are talking about the (4b) malicious node case. You are certainly right, my description is hand wavy on what to do about deliberately non-compliant nodes. Believe it or not I was attempting to SIMPLIFY the description.

The set of non-malicious validating nodes is the "candidate set of validators" minus your personally known malicious nodes. (4b, 5c6) Your KNL/UNL should optimally be the "non-anonymous" subset of non-malicious nodes.

The set of anonymous validator nodes needs to be policed using a forfeitable fidelity bond. In this case a fidelity bond is a transaction that sends a predefined amount of a validator's coins to an output claimable by "ANYONE". No non-malicious node should allow anyone to claim those coins, except for three specific circumstances.
1) The sending validator can claim his own coins. This results in him taking himself out of the validator candidate set.
2) If the chosen validator (2) produces a non-validating or DoS block, the next-chosen non-anonymous validator can claim the FAILED validator's fidelity bond.
3) If a validator fails to come to consensus and "announce" within the next (Y) blocks, the next-chosen non-anonymous validator can claim his fidelity bond.

There is no automated mechanism to anonymously reclaim a lost fidelity bond. The bond can only be claimed by a human personally appealing to a human consensus of non-anonymous validators.