Anyone who still trusts TradeFortress on Ripple (especially the ~3-5 ppl. who still trust both him and BitStamp!) should simply send the BTC back to him and set the trust limit to 0.

Well, behind the scenes quite a bit of development is going on so I would rather see it as a focus and communication problem in the sense of they need to focus on a certain feature that has widespread appeal (like the recently added Bitcoin bridge protocol) and communicating it far and wide.

I also would love to see more simple clients popping up, though that again might be a problem as client developers probalby want their own server at home to test against a running server. Also what would be really cool is to see someone use Bitcoin, Ripple or (maybe even better suited for this?) OpenTransactions transparently, meaning user accounts are secretly managed and trading on a live network but don't even necessarily need to know about this.

I find it highly hypocritical by the way from a centralized webwallet operator with no expressed intent to open source any of his services who actively paid people to advertise against Ripple to call others "paid shills".

Anyways, back to work - I need to compute some more ledgers!

What do you mean exactly? s1.ripple.com is not the only rippled out there, just saying... at the moment it's rather a question of "what do I need and what can I throw away safely".

Maybe you want to say that it makes not much sense to work with the ~24k account network right now and I should make sure to be able to scale to millions of accounts already? Also I disagree with the "network to nowhere" statement. If you meant something else, maybe give me a link to these simulations.

Nice, I personally work simply with the web socket client in Python and rippled, but it might help others.

Currently the most limits concern the rate rippled can actually serve ledger data vs. new ledgers being created.
Maybe I'll try to put some stuff in a local redis or other nosql database so I don't kill or choke the public servers that much...

Anyways, that's details and bitcoind would also have problems if I requested the utxo set + balances for all nonzero addresses at any height...

Back to topic I guess one of the main issues would be to find someone to write a reasonably extendable client to be used by gateways and making rippled more secure and stable. There is a lot going on however, so I'm sure they use the summer not just to chill on the Bahamas with their vc funding.

Edit:
About xrp and market making:
I'm not too sure if xrp have to be market makers by design. They have the very useful property of being 100% accepted, on the other hand though they are volatile. They might be useful as intermediates in paths but I'm not too sure if there is a lot of money in this as to market make, Jed would also need to trust at least one (to gain high arbitrage: a little trusted which in return is more dangerous!) IOU gateway to exchange his xrp at a profit to these IOUs.
If the gateway is already very liquid like bitstamp there will be a lot of people and lines trying to underbid you, if it is badly connected to other gateways like trade fortress, there might be a reason for that...

Das mit der Berechnung war auf deinen Post bezogen:

Die 0 ist z.B. eine Ziffer die vermutlich schlechter abschneiden dürfte, ich hab aber jetzt keine Lust, diese seltsame Gewinnmethode auch noch zu implementieren (da man z.B. mit A-F nie gewinnen kann, auch wenn das die häufigsten Ziffern sind). Vielleicht nach dem WE oder so. Statistik kann einen bei Losziehungen durchaus schon mal in den Hintern zwicken, mir scheinst du potenzielle Schwächen in deinem Zufallsgenerator zumindest schon mal viel zu leicht als "mathematische Spinnerei" abzutun.

Edit:
http://blockexplorer.com/q/getblockhash/249901 sollte dann relevant sein.

Man könnte noch testen, welche Zahl bei jedem Block gewinnt... scheint aber doch noch recht zufällig zu sein, trotzdem kann es gerade beim Zählen von Ziffern durchaus auch zu statistischen Problemen kommen, gerade wenn man sich ansieht, wie Mining funktioniert.

Da du nur Ziffern von 0-9 erwähnt hast, dachte ich, du rechnest den Hexwert des Hashes eventuell in eine Dezimalzahl um.
"Berechnen" tue ich diese Werte, indem ich einfach die jeweiligen Ziffern zähle, nachdem ich die führenden Nullen gestrichen habe - wie auch sonst? Ich hoffe doch, du hast diese Werte (auch mit größeren Sample-Sizes als nur 2x 1000) selber ebenfalls berechnet?

Wieso nicht einfach ein script schreiben + nachprüfen?

Schaust du die Hexadezimalrepresentation an (also hat dein Hash auch "A", "B" usw. bis "F" drin stehen)?

Edit:
Erste 1000 Blöcke (1-1000):
'0': 3484
'1': 3418
'2': 3455
'3': 3478
'4': 3392
'5': 3489
'6': 3596
'7': 3602
'8': 3539
'9': 3541
'A': 3495
'B': 3501
'C': 3456
'D': 3461
'E': 3555
'F': 3474

1000 aktuelle Blöcke (248001-249000):
'0': 3149
'1': 3089
'2': 3179
'3': 3221
'4': 3138
'5': 3260
'6': 3284
'7': 3162
'8': 3199
'9': 3069
'A': 3053
'B': 2954
'C': 3013
'D': 3006
'E': 3045
'F': 3049

Zahlen sind natürlich kleiner, da mehr Nullen am Anfang entfernt werden müssen.

Bevor man das von Google übersetzen lässt, dann doch lieber gleich auf Englisch, besonders da die Seite ohnehin nicht auf Deutsch ist!

"die 0en vor dem Hash" ist auch nicht gerade logisch (die sind nämlich Teil vom Hash) und es gibt vermutlich immer noch leichte Bevorzugung von gewissen Werten, aber sei's drum... ich will bei sochen "penny auctions" sowieso nicht mitmachen - mir ist das eben nur grad beim Drüberschaun aufgefallen.

Weil man bei Rücksendung an die gleiche Adresse genau weiß, wieviel wirklich transferiert wurde.

Wenn 4 BTC in 3+1 aufgespalten werden, die an jeweils andere Adressen gehen, kann man das nicht gleich so sagen. Gehen 3 wieder an die gleiche Adresse zurück, sieht man auf den ersten Blick, dass da 1 BTC ausgegeben wurde. Generell sollte eigentlich jede Transaktion an eine leere, frische Adresse gehen - alles andere ist eher nicht so gut für die Anonymität.

Gibt es in den Hashes von Bitcoin Blöcken nicht überdurchschnittlich viele Nullen?! Immerhin müssen die ja extra mit vielen Nullen beginnen...

Well, then don't call them currency but asset - anyways, XRP are the only thing in Ripple that can be transferred without issuing trust atm. and they are also intended to be "path shorteners" by allowing people to pice their IOUs against XRP. I'll have to look at market orders too to make an educated statement, but if I look at the trust graphs for USD and BTC alone, Ripple is heavily dominated by Bitstamp at the moment. It depends on market orders, but I guess BTC.Bitstamp and USD.Bitstamp are also useful for direct trade without XRP as intermediate already as well (e.g. against CNY from various issuers).

Once I finish my stuff, I might publish some of it - which should give ppl. a better estimate of what is going on in "Rippleland" (e.g. I have seen VERY different estimates about how many XRP are now dispersed amongst users). I'm not too sure about the format though and how to actually profit from it (I invest already quite some time), maybe charge some BTC amounts for a paper on coindl.

I very much doubt you understand what these "folding@home" type of projects are actually calculating on your hardware and how much it is related to curing cancer...

Ripple without native currency is similar to villages.cc... also cross currency path finding there seems quite horrible to me once it would gain traction.

I would rather see a Ripple implementation that lets you use other currencies (e.g. BTC, LTC...) next to XRP as native currencies. As you anyways don't need a lot of XRP in your whole lifetime however I am not too sure if this would really ever pay off.

I somehow understand why so many people here are so much against XRP - I don't get however why so many people don't look beyond that. The price of one BigMac buys you more XRP than you probably need in your lifetime and that's the only single transaction you need XRP for. Compare this to Bitcoin... anyways, I'll continue to work on my project(s), have fun bashing/flaming.

If coinbase integrated with Ripple, you could trade the coinbase IOUs you get by depositing there for anything...

Anyways, I'm currently working a bit on/with Ripple so I might be too biased to give useful comments here atm. I generally like the idea and system that IOUs are made more explicit to users (you trade for example USD.MtGox for BTC.MtGox, not USD for BTC on Gox!) and also more fungible/tradeable.

If you just want to move fiat from the US to e.g. HK, then Ripple might really be better suited for you than always using BTC as an intermediate currency. Also if you want to keep a balance in BTC and buy things that are priced in different currencies, Ripple might allow that in case you do trust a gateway (which is in the end exactly the kind of service coinbase offers - deposit coins to them and get them back later) that is reasonably well connected in the Ripple network.

Ripple to me is more of a transfer/payment network while BTC is more like the gold in a high-security bank vault.

What do you want to accomplish with this thread though? It will only stay here if it is relevant towards Bitcoin, otherwise it will be moved/locked. Only asking for "general thoughts" is a bit weak imho.

Depending on the implementation it might get hard to do so though, arbitrary precision for example would be awesome (miners then would just ignore transactions below a certain individual dust value) but as far as I understand it, currently "bitcoins" are defined as 10^8 atomic units ("Satoshis"), adding more than 3 places might become quite hard (21 million * 10^8 Satoshis * 10000 > 64 bit number), though as any change like this would anyways require a hard fork, that would be a long planned change anyways.

Nearly all of these values CAN be changed, the question is rather if they WILL be changed or SHOULD be changed. Some should but likely never will, some should and will and according to some people there will be some values changed that shouldn't be changed (just look at the max_block_size threads...).

Maximum increase in difficulty over 2016 blocks: 4-fold (e.g. from 100 to 400)
Maximum decrease in difficulty over 2016 blocks: 1/4th (e.g. from 100 to 25)

About 8 decimal places:
My guess is that it allows to have microBTC with still 2 places after the decimal seperator (microBTC-cents), these 1/100th of a currency unit are historically quite widely used and just from thinking about it, 21 million "coins" would have to be split eventually if Bitcoin gained any traction.

A lot of these numbers probably just evolved from "gut feeling" and maybe sometimes necessity or easier computability (e.g. why are SHA256 hashes 256 bits long and there's no SHA254? Because 256 bits are a power of 2 and are easier to handle by computers). To stay with piotr's example: If you just have phillips screws lying around, you're probably just going to use these, if you have torx screws, maybe you're more likely to use them. Also if you have the feeling that it might be more aesthetic or useful to have a better headlight, you might make it a bit brighter, but won't be really able to explain with very detailled arguments why now a headlight with 100 watts and not 95 watts...

Why not use Bitfinex or some other trading platform?

Offer an RSS feed as well, so seeders would just need to clear old torrents from time to time... [/list]

WTF?!

You did not contact me after the GLBSE meltdown and then you give away the proceeds from my share to other share holders as bonus? It was certainly not part of that contract that I have to be proactively reading this thread to receive any dividends (that you could easily have sent me as you (still) have an address associated with my share). Since when does one have to be "active" to be a share holder?

I'm certainly NOT pleased in how this is/was handled...