Have you tried asking WisePass for help? He claimed to he was going to refund BTC to the person who had complained to him. If you are dissatisfied, I'd recommend that as a first step.

So you are saying the tag line for BitCoin should be:

BitCoin: It's the Ripple for illegitimate business.

So you are saying the tag line for Ripple should be:

Ripple: it's the BitCoin for legitimate business.

This is a key feature of Ripple. Transparent relationships between parties, public visibility of trust and balances, and public verifiability of transaction.

It is absolutely everything the traditional banking system isn't. Once the public gets used to transparency in their personal financial dealings they will begin to demand it of banking institutions as well.

Ripple was born in this forum, so it seems appropriate to discuss its future here.
Bitcoin without mining
Re: Distributed Bitcoin Exchange

NOTE: This post is idle speculation. Please treat it as such. I do not work for OpenCoin. I have no privileged information that doesn't come from forums or OpenCoin web sites
--------

So the other day I was trying to explain how OpenCoin might not actually be XRP speculators (as is the common wisdom). My basic guess was, maybe OpenCoin plans to just sell XRP to other companies so they can use XRP to activate their user's Ripple accounts. Seemed a plausible expedient way to see some substantial ROI. Then ahbritto posted something that has been nagging at me ever since.  Re: XRP Ripple money what advantage ?
Later while reading this thread, virtual currency trading wars bitcoin versus ripple xrp
I run across a web article that concludes:
Normally I would just dismiss that out of hand, EXCEPT I noticed a comment by JoelKatz on the article.

--- Begin Idle Speculation -----

So maybe, XRP and Ripple Accounts aren't designed for us after all. Maybe OpenCoin is starting to see Ripple as simply THE GLUE between other financial services providers. Basically, a peer-to-peer international version of the Automated Clearing House (ACH).

Please note that in this vision, we (currency users) are NOT the peers in BitCoin's sense of P2P. Nor are currency users even necessarily Ripple address/account owners. We might simply be Google Wallet users sending money to users of (China's version of PayPal). Or Dwolla users buying Zynga freemium upgrades. The actual Peers would be "federated" companies like PayPal, Google Wallet, Dwolla, FaceBook, Zinga, XBox Live, etc. Basically anyplace where users can have accounts and any type of currency or credits. The Ripple System just handles the inter-company exchanges and currency conversions. (Send $10 from google/sourceID to dwolla/destinationID.)

This concept substantially reduces the scalability issues inherent in Ripple ledger maintenance and consensus building. It also creates an pretty substantial business model for OpenCoin's XRP stash. They become the inter-currency market-maker by using their XRP as intermediate currency.

Note that being a "market-maker" doesn't require speculation. OpenCoin would make money on the ask/offer spread. Notice that if you want to exchange $1,000,00 USD for its equivalent in OTR (other) and you use XRP as an intermediate currency. Then there needs to be $2,000,000 USDs worth of XRP liquidity in the marketplace in order to determine a price.

USD/XRP (OpenCoin sells $1,000,000 worth of XRP at "ask") 
XRP/OTR (OpenCoin buys $1,000,000 worth of XRP back at "bid")

Big companies exchanging currencies don't have to care what the actual price of XRP is. They only have to care about the overhead inherent in the spread. Normally, market speculation keeps the market spread small. But conversely, if OpenCoin keeps the spread small on their own, it reduces the incentive for other speculators to even try to compete.

------
So I see two possible Ripple Systems.

Ripple 1.0 - The Ripple I presumed was being built. An improved version of BitCoin, with faster transactions, low volatility and much improved usability. But one that kept BitCoin's essential P2P vibe. "We users, are creating, owning and trading currencies AMONG OURSELVES."

Ripple 2.0 - A Ripple that seems much more appealing to venture capitalists. One where increased interoperability and reduced costs provide a, hopefully, compelling new feature to an existing user base. "This company I'm funding can inter-trade with these other companies you're funding. Our users will pay extra for convenience."

I guess the open question is, "Should any of this matter to me?"
Does it matter to you if Ripple becomes version 2.0 instead of becoming 1.0 first?

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.

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.

Thank you for the offer webr3. Actually chapes on the Ripple forums trusted me with some Canadian Dollars to help me though my learning process. I've got a pretty good handle on Ripple now. I invite you to look me up on the Ripple forums. I'm about to launch a project you might be interested in. (Busy typing about it now.)

OK, so now the whole process makes a lot more sense. I misunderstood the direction of coin send you were testing. I setup the trusts, re-sent 1 XRP and successfully received your three IOUs. Awesome!

You've created a really cool system.

 

Hi TTBit,
You called this "beta testing" so I want to give you a test report. I'm a noob with these coin clients so feel free to tell me to check the nut behind the keyboard. That said, here is what I see on my end.

1) Dividend Rippler
https://www.dividendrippler.com/account?_=rHUipvsbBKagmU5qxFYCVfRoHKkBaYztm2
Your site shows "failed payments". You said above that those can be ignored.

2) BitCoin
I'm using Electrum 1.7.3 but it shows that I have a zero balance.
BlockExplorer report my address as "Never seen"
http://blockexplorer.com/q/addressfirstseen/186ZJv7Bm1ydrsVxPDuVtdJNZZUwAXL2jH

3) LiteCoin
My LiteCoin client is still syncing the block chain, so I can't take its opinion as authoritative.
However, the litecoin explorer reports "Address not seen on the network."
http://explorer.litecoin.net/address/LP5KRWi12LaKvNX2G1JMwrLFuQm26wYr8W

4) TerraCoin
Notice that on DividendRippler I didn't configure a TRC account. (I'm on a Mac and I couldn't immediately find a Mac client.)
https://www.dividendrippler.com/account?_=rHUipvsbBKagmU5qxFYCVfRoHKkBaYztm2
However, your system attempted to send me TRC anyway.
THIS MIGHT BE A BUG. I'm not sure where those TRC would go if successful?

Anyway, that's my report. I hope it is helpful!
Red

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.

  

@chrono.v, I do appreciate your taking the time to comment on my thread. I understand your view of BitCoin. That has been the dominant opinion since I first came to this site in 2010.

The [StableCoin] topic however is not a debate over which ideological currency is better. It is merely a discussion of the ways an immediately value-stable currency could be created. This thread gives an introduction.
https://bitcointalk.org/index.php?topic=179918.0

So by definition the [StableCoin] topic is about creating a non-speculative currency. One where, if you save the value of 1 loaf a bread in stable coins today, in 50 years those stable coins will be worth 1 loaf of bread.

Hi brenzi, welcome to the [StableCoin] topic. As you mentioned Ripple I wanted to link you to another thread where I was analyzing Ripple from a [StableCoin] perspective.
https://bitcointalk.org/index.php?topic=188266.msg2026191#msg2026191

@several,

Anyone fixated on who owns how many XRP doesn't understand the Ripple System. Inside Ripple XRP isn't intended to be used as money. That is purely a projection of BitCoiners onto Ripple. It also has absolutely nothing to do with the [StableCoin] concept. Even when implemented inside the Ripple System a [StableCoin]'s value will have no dependency on XRP at all.

Price is a measure of instantaneous supply vs instantaneous demand. Demand for a currency will always grow over time. There will be more people creating new types of valuable goods and services in the future. products and people that don't even exist today.

More available goods/services chasing the same amount of available coins means currency prices will change (not be stable). To preserve stable prices the amount of currency available to be traded must scale with the amount of goods/services seeking to be traded.

Occasionally then amount of goods and services available for trade will fall compared with the amount of currency available for trade. That will need to be compensated for as well.

My pleasure. Glad it was useful to someone. Once the contracts feature of ripple is a little more fleshed out, distributed issuing of custom currencies inside of ripple will be a real game changer. (I hope!)

Monday Bump. It was a sleepy weekend.

Here goes. You have some pretty cool ideas TTBit.
rHUipvsbBKagmU5qxFYCVfRoHKkBaYztm2

Thanks! Was hesitant to send XRP when it said offline.
It looks like a cool service.

]The processing system is currently offline, data may not be up to date! [1046]

Is this system still functional?
Can I sign up when it is offline?
Is the Giveaway still active?

]The processing system is currently offline, data may not be up to date! [1046]

Is this system still functional?
Can I sign up when it is offline?