Topic: Why Ripple™ is against everything Bitcoin - page 14. (Read 45626 times)

Then release the source code. Stop making excuses and actually match up your claims on your site.

Bitcoin was not released in a closed source state, and it is not unreasonable to expect competitors to match that.

We 100% agree. This is why Ripple will be superior to other payment systems. Once the source code is open and the network is decentralized, these kinds of things cannot happen. These kinds of protections will be structurally guaranteed.

It was very difficult to design a payment system that required no central authorities. Many problems could have easily been solved just by having some authority make decisions. Why do you think we went to all the effort to design Ripple the way we did? We learned a lot from Bitcoin.

If a transaction is not validly signed, even if it gets in a consensus set, it still can't be applied to the ledger. If a conflicting transaction is already in a prior ledger, then again, the transaction can't be applied even if it gets in a consensus set (this is basically the definition of "conflicting"). The consensus process only orders transactions to prevent disagreement and double spends. It can't make a transaction valid if it doesn't follow the rules.

So what's the case where this is an issue? If both versions of the transaction are validly signed and neither has yet been included in a fully-validated ledger, then who cares which one gets in?

Except doing actions to the letter of the order rather than the spirit of the order with powerful government agencies is a great way to end up in prison or somewhere worse. OpenCoin Inc is a central point of failure.

There is a difference between allowing certain transactions - bitcoin has a similar change in 0.8.2 with tiny transactions becoming non standard - and creating new currency.

The solution to your threat would be to simply release the code and tell them to implement it themselves - while validators are popping up left and right.

Hmmm, what will happen if more than 51% of the validators on the network telling you that a conflicting transaction has been sent by the same initiator of your version of the transaction, while in fact, they are all lying?(the initiator only sent one transaction)

I have another question.
If you can inflate XRP at will, what is stopping you from printing additional 200% of current amount of XRP when government "asks" you ?

If they offer you a choice: either this or Guantanamo, what will you do ? Will you choose Guantanamo ? Will all of your administrators who control central Ripple servers choose guantanamo ?

Ripple is a joke and the owners are a pathetic bunch of crying losers who regret selling MtGox[1] before it got popular and before it raked in alot of millions. Those same losers are now trying to, in a pathetic way, make up for that mistake-of-a-lifetime by pushing Ripple down everyone's throat.

[1] https://en.bitcoin.it/wiki/MtGox

Like Bitcoin nodes do, all Ripple servers flood transactions across the network. When a Ripple server receives a transaction, it performs the following operations:

1) It checks if it has ever seen this transaction before. For now, assume it hasn't.

2) It checks if it has received the transaction from a cluster peer (server under common administration) that has already checked the signature. For now, assume it hasn't.

3) It internally queues the transaction to have its signature checked and puts the server it received the transaction from on the transaction's exclusion list.

4) If the transaction is received from any other servers, those servers are added to the exclusion list for the transaction.

5) When the transaction gets to the head of the line, the signature is checked. For now, assume it's valid.

6) If the server is able to, it checks if the transaction can apply to the current ledger. If not, it will not forward the transaction.

7) The server forwards the transaction to every server connected to it that is not on the transaction's exclusion list. When sending to cluster peers, it sets a flag indicating it has already checked the signature.

That doesn't change the fact that you inflated XRP at your own sole decision. Let's take a look at bitcoin v0.8.2, the core devs agree to a change, independent miners are required to adopt it, not just the core developers.

It's also not worth arguing "but in the future".. because you have a product now. The excuse for being in beta have being long gone after Gmail has being in beta for what, years? Which is why the real beta testing happens behind doors, and you release when you are ready.

If so, what's your theory for why we did it? Are you just arguing this point because you hate us or are you really committed to this argument?

We were pretty clear from the beginning that we would support changes to transaction fees and reserve levels that would keep the system cheap. The price of XRP had gone up by a factor of nearly four. I don't think anyone believes it had any significant inflationary effect -- maybe it increased circulation by .04% but in exchange it decreased the cost of entry by a factor of four.

How do they just "forward"? You mean they forward to every validator in the global network to see if there is any conflict?

You are assuming the case that validators are honest, and that users will trust honest validators. This is a bad assumption to make, just like making all your users become liquidity providers on anything they trust.

Someone can singlehandly cause people to lose money by telling people to trust X in exchange for free "BTC", send them the free BTC, and watch as them being a liquidity provider exchanges something like Bitstamp IOUs for those IOUs.

You should also see the ads for this week on bitcointalk

The validators just forward the transactions to each other and each one will include the one it saw first in its initial proposal. One of three things will happen:

1) One transaction will get a majority and the other won't. In this case, that transaction will be included, permanently conflicting out the other.

2) Neither transaction will get a majority. In this case, servers that have seen both transactions (which should be almost all of them) will pick a winner based on a deterministic rule. The transaction that wins by rule should get in during the next round.

3) Somehow, both transactions get a majority (doubt this will ever happen, but suppose it does). In this case, a deterministic rule again determines which transaction gets in.

Really, all you need to do is agree on the order of transactions. Validators do that by agreeing on candidate transaction sets in distinct chunks.

It is against the people's interests who want XRP to go up (but since you're playing central bank with the currency and how it is offered, not going to happen on a significant scale). Less account reserve = more XRP in circulation of the economy = inflation.

You just inflated Ripples.

What I meant is what if the two transactions I sent to distinct groups of validators conflict? I should not be able to double-spend right?

Distinct Ripple networks (if they exist) don't have to agree on anything. If you have validators who have no validators in common, you have distinct networks. To join a network as a validator, you must agree to reach a consensus with some subset of the validators in that network. You also take on a responsibility to manage the set of validators you try to reach consensus with.

I expect, at least for awhile, the Ripple network to have a list of "core validators", likely with a few run by OpenCoin, at least one from each of several major gateways, and probably a few run by well-known groups such as universities and where nearly every other validator has nearly ever validator on that core list on their own list.

Domains (like 'ripple.com') can publish a list of validators they recommend and other validators can select a list of domains to gather validators from. This permits other people to manage some portion of your validator list if you wish to defer that to someone else.

In the event of horrible neglect in maintaining validator lists, long before the network actually split, your node would report that it was no longer seeing a supermajority among its validators and would stop validating. You can pretty much only have an actual split if you start out in a broken state and never converge at all. This is because in order for a split to hurt you, you need to wind up on the minority side of it, which means you won't be seeing anywhere near the number of agreeing validations that you expect.

What about my question? How do you reach global consensus? I can propagate two versions of one transaction to two different non-overlapping groups of validators, what will happen?

Absolutely. We change the rules all the time -- primarily to add features.

You're talking about the account reserve. That actually wasn't a rule change but simply the result of the execution of a transaction that changed the reserve, which is stored in the ledger. This certainly wasn't a stealth change, in fact it was widely requested and, as far as I can tell, didn't harm anyone's interests.

There was no change to any rule. The rule operated the same, just on a changed ledger. However, we had fairly recently added the logic to negotiate the change in the reserve level. Had someone not updated their software to support that change, that would have created a hard fork.

To prevent this problem in the future, we are almost finished implementing a coordinated change process. The only time this will cause a validator to be unable to continue is if a supermajority opts for a change that the validator doesn't support. The change process will have built in delays so you will know at least two weeks before adoption that a rule change has a significant chance of being adopted. That should give people time to realize the change is likely to happen if nothing changes, analyze the code, and make a public case against the change if it's a bad one. Validators will be able to "veto" changes if they believe they are harmful to the network. The current plan is for a node to vote to support a change if that change has held 80% support for two weeks. Support is, basically, yes votes minus no votes out of the total.

Sorry, didn't see these.

Every validator signs every ledger it wishes to validate, that's what validators do. Right now, all validators are run by either OpenCoin or those working closely with us. But that will change.

We'll probably have to wait for the source code to open to make this argument academic.

Anyone who wants to can be a validator once the source code is open. Validators participate in the consensus process (assuming people listen to them). They judge what is a valid transaction by applying the network rules, checking signatures, and so on.

They are subject to change by supermajority. Validators participate in the rule change process -- again, to the extent that others are willing to listen to them.

Gateways have no control over how Ripple transactions take place. They can, of course, refuse to honor their commitments outside the Ripple network. This will hurt those, and only those, who chose to trust that gateway.

Gateways and validators have nothing to do with each other. As far as the Ripple network is concerned, gateways are just accounts that issue transactions that follow network rules just like everyone else.