Topic: Ripple XRP distribution requires immediate formalization - page 5. (Read 5917 times)

This doesn't work as well. I'm not lying to you. We really worked hard on this problem and implemented the best solution we could come up with.

First, IP addresses are useless. You can only prove your IP address to someone you cannot to directly. Expecting clients to connect directly to every validator so they can see their IP address doesn't scale. You could have a central authority to which you connected and received proof of your IP address, but we're committed to having no central authorities. A malicious node could simply claim it got transactions from many different IP addresses and thus little proof of work is needed. If you make the node do proof of work to get other people's transactions in, this becomes an attack vector.

Account address only works if accounts are scarce, which gets you back to the same problem of how to keep accounts scarce.

CAPTCHAs don't work because you need a central authority. How do you prove to a machine that you solved a CAPTCHA for another machine not under common administration?

No, because someone who did that would wind up divesting themselves of their ability to attack the network. In a PoW scheme, an attacker doesn't lose anything by continuing to attack. Also, in the XRP scheme an attack is only possible by a stake holder and only in proportion to their stake. In a PoW scheme, attacks are equally possible to non-stake-holders, those most incentivized to launch them.

All you can do with XRP is overload the network and deny service. To do it, you have to keep putting more XRP behind each transaction than those you're trying to keep out are willing to put in their one single important transaction.

The proof of work is merely an iterative process which should increase individually for each user based on ripple address, ip, etc. to automatically normalize network utilization conditions based on an analytical process which basically says:  HEY YOU, work this many times harder if you want us to listen to you because you been yappin too much lately. It's like when you enter your password too many times incorrectly, now wait 5 minutes or fill out this captcha.

Today, anyone invested in a large amount of xrp(like you guys) could attack the network, and so effectively your solution is no different than an attacker investing in computing power. Worse, assuming the idea is for xrp to stay cheap and affordable then anyone with a lot of money could take over the network, which means that it wont stay cheap, and xrp will become valuable as factions compete for control. Stamps aren't cheap you know, and they aren't reusable the way they are with bitcoins.


Remind me why you need an extra 50 billion xrp on the side? I think you are well intentioned but the "ben bernanke" factor here is simply too strong to ignore. I'm still very excited to see it in action, I read about the technology years ago and it's awesome that it is coming to life. Could you spare a poor fella a couple ripples please sir

some people will say bitcoin coin distribution is unfair, others will say ripple is unfair. i have few ideas how to make it more trustworthy and transparent. you can announce schedule how ripples will be distributed. for example: at least 10% of coins will be distributed before day x, 20% will be distributed before day y, etc. you said currency distribution will depends on adoption rates, but this can also used, for example you can say no more than 30% of coins will be distributed before we reach x transaction avarage per day or before there are y accounts.

I'll see what I can do about getting a status page going.

Is there a place to read about the development status of Ripple then? I didn't see anything in the Ripple wiki but I could have missed it.  Thanks

Haha. 

Geez, now I feel like I have to come up with a clever reply, but I'm too tired. Can you just imagine I said something really clever here? How about a free math joke:

Q: What is purple, commutes, and is worshipped by a few people?

A: A finitely-venerated Abelian grape.

(Warning: computer science humor ahead)

Do you plan on pruning it?

Yeah, but it's in Alpha.

Start by sending some here: rDRho51t4StfNqEWrYKBAteJKyDeo5crZz 

Is there a timeline yet for getting out of Beta?

Yes. It doesn't work well. An attacker will optimize their system for creating the proof of work while legitimate users will have to make do with whatever they've got. Also, an attacker can create proof of works in unlimited supply -- only the rate at which he can produce them is bounded. So if he has enough of an advantage over you, you will never get in ... ever. Then what do you do? Upgrade your computer?

We're basically committed now. We're not centralizing control -- we carefully designed the system to not require any central authorities and to use a democratic consensus process rather than proof of stake. We'll be giving billions of XRP away to try to keep the system free for as many people as possible for as long as possible. We are committed to decentralizing the system.

If you believe it will succeed if centralized, why should we decentralize it? And if you don't believe it will succeed if centralized, why do you think we would centralize it? Or do you think we don't want it to succeed? We firmly believe Ripple will only succeed if decentralized.

Additionally here the ripples are being destroyed, so to think that it would act as an incentive to keep the infrastructure reliable like with bitcoin is void in this case, therefore the added value that txn fees provide in bitcoin are not present here. Therefore why should xrp's have an exchangeable value to begin with? This merely further de-democratizes the system since xrp's are not available for public minting. I think you chose to imitate bitcoin incorrectly in this aspect.

Thinking deeper into the subject, are ripples even necessary? Why manage network security through another form of currency?

From a business model point of view yes this allows for the creation of value, but perhaps is not the most efficient approach to a truly decentralized system you are proposing.

Have you considered sustaining network stability through an algorithmic combination of dynamically throttled client side "hashcash" proof of work requirements, linked to transaction size, address/ip traffic amount, and other relevant variables, which adjusts according to network strain? Now that would be beautiful.

I say get rid of XRP all together it is a bad solution to a problem and creates more unnecessary complexity. Either that or allow the community to decide how ALL the XRP will be distributed, assuming your true priority is to solve a specific security problem. Thinking you can solve a problem by centralizing control is wrong, unless the solution offered is simply the excuse to centralize control.

I agree. Transaction fees are big issue for BTC as well.

You mean with an unlimited supply of XRP? That would have us essentially selling every transaction and ensuring the system never becomes decentralized.

If you mean with a limited supply, we'd run out. We'd either have to raise the price, essentially auctioning them off, or strictly limit who can buy how many, which I think defeats the point.

We want to make the system free to many people for as long as possible.

This is actually a very hard problem.

Even better... it will make BTC and Ripple very close connected.

How about 1 satoshi instead?

Idea how to give away XRP:

You must make a commitment to fill any orders that want to buy XRP above some predefined threshold...

For example, people will always be able to buy XRP from you at $0.001

Benefits:

1. People will always be sure that they can buy "fuel" to drive.
2. You will be able slowly cash out money
3. There will be price stability, such needed thing in the beginning.

What difference would that make though? If they're scarce, the cost of transactions and the reserve should come down by consensus. If they're plentiful, what's the issue?

The consensus process isn't XRP proof of stake, it will be purely democratic. The consensus process sets the transaction fees and reserve.