XRP are ~7.5% distributed amongst users, RippleLabs doesn't issue any IOU, so these are 100% not under their control. Also anderl did not post proof of Ripple's alledged centralization by the way.

These charts are so wrong, it is hard to find a starting point. For one thing 1 Bitcoin address != 1 Bitcoin user. These stats are based on address balances, not users. XRP can NOT be controlled by their creators, since it in fact is an open source and distributed system (just like Bitcoin too - the Satoshi block chain acts as central authority there) and most people would likely disagree with them issuing more XRP to themselves.

It is really frustrating to take time to post educated opinions by the way if the other party is just copy-pasting big red text instead of answering in a meaningful way. If you want to have the same experience (without the big red text, as this is disabled there) please go e.g. to the battle.net forums and open a thread there convincing people that it would be a great thing for Blizzard to accept BTC for WoW subscriptions.

Well, enlighten us then...

Well, then they'll eat up whatever the market bid for those XRP and XRP are more distributed. It's not like ripple exists solely to transact XRP, unlike bitcoin. Beyond about one USD worth of them to get started you never will need to touch them again any more if you don't want to.

If you choose to 'invest' in XRP, then that's your own problem, as I said to use ripple that's not important.

Ripplescam is very similar to one of these warning statements of banks citing that miners could create bitcoins at will, it is used to buy drugs and who knows what they are calculating anyways... probably you are cracking launch codes to help north Korea getting a nuke! All presented nicely and with pictures as 'evidence'. They usually also present a solution, in this case people were paid to link to inputs.io as the 'real alternative' on this forum. The scammer went on, the myth remains.

Sorry, but apparently you fell for some nice pictures and some explanations that sound technical enough to be 'true' but easy enough for you to understand... I get it that it looks nice, that does not make it right though. Unfortunately a lot of people also don't understand it if you give a technical explanation why this is wrong because they 'understand' the pictures but not decentralized systems for example.

In my opinion it is just a waste of ressources to write a client in Java (as most people around here expect to use a browser anyways to trade on an exchange platform) and a web frontend and stanradrd conform API would work much better.

If you use standards, you can use any FIX enabled client anyways and you would have a hard time to compete with these while also coding a high throughput exchange engine that has to match orders etc.

Also please publish some performance numbers and include load tests and simulations, since this is very often a problem with "homemade" exchange engines.

Rippled compiles, runs, builds history and behaves as advertised.

Could you give an example for this "common practice" where a company claims their software is fully open source but it actually is not working or incomplete?

Also I stopped being retarded, thanks for the nice reminder.

I wouldn't use your client if it were hand optimized Assembler written directly on HDD with a magnetized needle!
This is not against Java (you just happen to write your client in Java), but against another API reinventing the wheel again.

Fact is, most people want to use their established trading clients they already know. Realistically people who code these clients will NOT develop a connector to your software with the n-th reinvention of a custom market API any time soon and people trading on your platform also will not have the few thousand USD lying around that it costs to have such a connector built.

There are industry standards out there for market data and trading APIs. Use them.

Mal schnell nachgeschaut (nach AT):
Von den Spesen (insg. 25 USD) abgesehen, war der Wechselkurs damals recht mies, k.A. ob das dann meine Bank oder irgendeine am Weg war... Laufzeit war damals 2-3 Tage glaube ich, auf jeden Fall recht flott.
Ich würde mich wohl mittlerweile eher bei Kraken oder Bitstamp verifizieren und einfach BTC von BFX auf die Exchange abheben und dann eine normale SEPA Überweisung von der Exchange nach einem Trade veranlassen. Dürfte einiges an Gebühren und Nerven sparen und hilft (gerade bei Kraken) auch ein bisschen denjenigen, die sich mit den Bestimmungen in der EU auseinandersetzen müssen.

Wenn der Markt während des Transfers natürlich crasht isses blöd, falls du also ein echter "bear" bist, solltest du da wohl eher die Gebühren für den SWIFT-Transfer von BFX schlucken als das zu riskieren.

Support anschreiben, dann bekommst du manuell einen "verliehen".

Ich habe meinen eigentlich nur in der Signatur, trotzdem melden sich da 1-2 neue User pro Tag damit an... O_o

Well, while it is easy to fork Ripple right now (just as Bitcoin in its inception) the network effect is still strong with RippleLabs.
While the technical part (rippled, the client, ripplecharts...) ist just copy-paste, you would have a harder time to convince people to actually accept and use your fork.

There is no "claim", there is PROOF it is open source:
https://github.com/ripple/ <-- all code for several different projects is in there, all under a permissive license. Also you are posting in the very announcement thread for this stuff... why do you speak of "claims"?

You cannot know if your USD are used to trade BTC or LTC. If other currencies are added in the future, this gets even more complicated.
I would love to receive interest for lending USD in BTC however for example.

Enjoy trading on margin there!
http://www.reddit.com/r/BitcoinMarkets/comments/1xigeh/psa_btce_is_fucked_do_not_use_mt4_trapped_in_short/
http://www.reddit.com/r/BitcoinMarkets/comments/1xipb1/this_gif_from_freenode_btce_sums_it_up_someone/

Make sure to implement an actually used API (not your own implementation) like Bloomberg, OpenMAMDA, FIX or the likes...
It is very unlikely that people will want to use your Java client to trade, no matter how well it is designed.

BIP32 for generating addresses...

It is specific to their bitcoind, a lot of database backends I've seen so far however think that if they send a transaction, all they need to store is the TXID at the time of sending and they'll be able to retreive that same transaction later down the road from the block chain.

We need to know once it has been fixed...

Just to be sure that people understand what the problem is:
Make sure that TXID is NOT a key in your database - TXID can be (and now for sure will be, just to mess with you) changed after you broadcast the transaction. The set of (Amount, destination address, timestamp) however will not be changed by this, so make sure you either hash this data (to have something of constant size) or use it in plaintext as key to look up if transactions actually took place.
This can (and maybe does!) affect Bitfinex too, bitcoind/bitcoin-qt and probably armory also don't really expect TXIDs to change after broadcast. Please don't just dismiss this as a screwup of gox or something specific to them, this can very well affect a good part of existing services, despite it being known for some time that transactions are malleable.

You apparently have no idea what "ponzi scheme" even means.

Try 2 weeks...
You apparently weren't on Bitfinex in April 2013

Well, I already successfully lent out money at over 4000% APR on bitfinex on multiple occassions. These times will come back, if you continue to act like lenders might agree to receive worthless sh*t (I certainly would NOT want to get any LTC for example and I have no control over how USD I lend out are used - they could be buying BTC or LTC) or that traders are in any way supposed to get some 100 USD Bitcoins just because someone didn't deposit enough BTC over at Bitstamp.

That insurance fund is a relatively stupid thing to begin with - there are probably however people who do not want to be able to loose a single cent. While I would accept to loose a few percent of the money I lend out (which is quite a bit more than what you claim to have lost) I don't think that liquidating at beloww 100 USD when BTC are traded at 600 USD a few minutes before is something that should happen.

If people don't want to be able to loose a single cent - pay for insurance. If you want some risk - lend uninsured. If you want to snatch up sub 100 USD BTC just because the BTC funds at Bitstamp are depleted and the order book gets thin at the bottom... maybe go elsewhere.

In other news, I'm up a few 100 USD from the trade I announced before in this very thread. If you did what I did, you'd be celebrating right now instead of hatin' on lenders. I can show you some data from last April, I'm sure I would be happy to lend at THESE rates, which will come back if you scare away the current lenders with the stuff you propose.

It seems like you have no idea what you are talking about... "Ledger" is the balance of all accounts, orders and trust lines on Ripple, there is no "owner" - it is (like the satoshi block chain) a single distributed database that has a globally agreed state from time to time (in Bitcoin ~every 10 minutes via PoW, in Ripple every ~10 seconds via Consensus).

What you probably mean is "validators" (the nodes used to reach consensus). Yes, just like miners in Bitcoin, validators can theoretically form cartels.

They do not have a chance to create more XRP - just look at the code and api, there is no transaction that could do that. This is just as ridiculous as the articles that claim bitcoin miners could create any amount of coins at will.