Bitcoin Forum

tl;dr: Proposal and prototype for a distributed exchange not requiring a banking gateway. Implemented as a plugin for Retroshare. Licensed under the LGPL.

The Achilles heel of Bitcoin is the exchanges. Centralized as they are, they can be stifled or even shut down by a number of means, by a number of players. Should that happen, price discovery of Bitcoin will not work any more. To address that, we offer a distributed exchange without the need of the banking system. Some intro is here:
https://github.com/zeroreserve/ZeroReserve/wiki (https://github.com/zeroreserve/ZeroReserve/wiki)

A tech paper is here:
https://github.com/zeroreserve/ZeroReserve/wiki/zeroreserve.pdf

In short, ZR uses the Ripple idea of Ryan Fugger to get money in and out of the exchange, although I prefer to give credit to Hawala. ZR has nothing to do whatsoever with ripple.com. There is no pre-mining, no company, just code, no strings attached.

This is still prototype software. Anything may or may not work. Security is only what the underlying Retroshare provides. Currencies are therefore only defunct or fantasy currencies such as German Papermark(1923) or micrograms of Fools Gold. Nothing you do has any effect on the real blockchain - its all TestNet.

Once the issue list (https://github.com/zeroreserve/ZeroReserve/issues?state=open) has all serious issue resolved, we'll announce a final test run and then start the life network.

Zero Reserve has been developed on Linux. It builds and runs on Windows, too. OSX has never been tried, but there is no particular reason it should not work on this platform.

RetroShare (retroshare.sourceforge.net) is a prerequisite.. If you are not a user of RetroShare yet, recent NSA revelations suggest that you start now. Once you are on Retroshare and have some friends, you should be able to install and play with ZeroReserve. You should also be able  to use this link to get and subscribe to the Zero Reserve Forum:
retroshare://forum?name=ZeroReserve&id=b87d0a5577ced312d88a0ee8176e24a1

The code and an installation guide is here:
https://github.com/zeroreserve/ZeroReserve

Some setup is needed to get ZeroReserve ready to trade:
https://github.com/zeroreserve/ZeroReserve/wiki/Getting-started-with-Zero-Reserve

Please get involved to help make this happen. Everything, not only coding is of help: Media work - spreading the word, Graphics / web site design, Testing and anything that helps to get critical mass.

Retroshare based Ripple without XRP and without premine  :)

Will try the latest version.

For testing, I'll accept any friend request on

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

xsBNBFIM8egBCADDohCoKY2XJqtoBIbAO/JoWmpkDd93BCA+WzVnnx9sKWA4ZSLB
k7KcqxBFopJdAQq4RojXGfOcV8GZS1J9sgBUf8vfFND/BwUnuYGRueuwyGrQgUdN
XUEMEXFgPZASwmNGc8+3ZXdBTAjoiLiy9FZ090xwyJtskky80omzf0pI9G6hUBfM
PaL03MQZxBRItDMXP9u28qP2DGQ5kCt2s/OQ61lkvPIhNqAZ0Kbq/KR7TdIdbZZ2
8qB3aoQD3qT/SUo1IXyf/3JVQlZ6mnND/4uKQTnu7llVXHCoFNWrzT0IPMlQGIJD
Th3x4uPxlZ5rnxyr/1dVon6U1JxusqDerPaxABEBAAHNIU5hYnUgKEdlbmVyYXRl
ZCBieSBSZXRyb1NoYXJlKSA8PsLAXwQTAQIAEwUCUgzx6AkQ3RwkIz9yOfwCGQEA
ANu5B/94E7JcvVSGaC89uhcKkRL8tkxbRF+CiUOAU0WiJqk5xIZokg1SemyVloJ8
jMGk2I/RxfvrGXBlhsq294mvpZK2hh0kRs3C/LO9LLRCaJKrm4N3qfsAVYfPjv9q
uUShUgJr/34gOewrKp/ccGX4BY1OqtiXmcTnh9F0x3j4KMVq5JIFBfohTfZMGWUW
WD19VmuOPkUJmbHHErY1dLa7oRmNUwKS0R0YdFQH5X2YHfx9sz14uX/nXhgP1zKU
V3JIv0kwa2q3uQltcDI2pFesCLCh3pvRBf16lQ7csAS2/X2XQXBAp7LL3gWJgANO
0/s+fI17lRzgwqcGUnN/vPaRzZ1U
=Z6CD
-----END PGP PUBLIC KEY BLOCK-----
--SSLID--d3d256d7385afcae8c5c10125e17e775;--LOCATION--BigBox;
--LOCAL--192.168.2.102:63614;--EXT--79.229.117.149:63614;



Just post your Cert below

I just wanted to point out that if you are genuinely worried about the NSA snooping your communications, do not use Retroshare. It should really be marketed at users who want an alternative to Facebook, i.e. where the adversary is a corporation looking to sell your data to advertisers.

With the NSA - a global passive (mostly) adversary, this firstly will offer zero protection for your metadata. i.e:

• The entire history of every single connection you make to your 'friends' would likely appear in the NSA's dataset.
  
• IPs, duration, geo-location etc
• Metadata is great as it is compact, easy to store and amazing for data mining when you collect A LOT of it

So once your metadata is available for data mining, perhaps you are automatically flagged up as a person of interest, as you once made a connection, perhaps outside of retroshare, to another machine which was within 3 hops of a suspected terrorist.

Cue the analyst who examines your internet life and sees you are a user of encryption software.

Cue the zero-day exploits on your endpoint or perhaps one of the 300 or so of your 'trusted' friends. Private keys are exposed, along with all of the communications you have ever made.

I quote a developer, Cyril on 1st September (http://retroshareteam.wordpress.com/2012/12/28/cryptography-and-security-in-retroshare/)

We should probably rationally assume that the SSL implementation is not forward secure. So the moment any one of your 'friends' has their endpoint compromised, this will also allow the NSA to decrypt the entire history of your SSL communications with them.

Not that im paranoid or anything :)

But this does motivate the need for anonymity software that works (metadata protection) and perfect-forward-secrecy to design for the inevitable compromise of crypto keys.

Not that this detracts at all from your project which looks very promising

About the NSA: At this point it is more important to have an NSA spyable decentralized exchange for Bitcoin than no decentralized exchange at all.

added a link on http://blockchained.com

I view RetroShare as a F2F framework for which one can develop applications. I am doing Zero Reserve. It'd be cool if someone did develop a FB lookalike plugin, though.


The services can establish that your IP communicates with another's. But the patterns are completely useless. For example if you run Zero Reserve, a lot of traffic is order book updates. Other is payments which you are only routing, but which are not yours. There are forum posts which your RetroShare is merely routing - which you may never read. Meta information just drowns in meta noise.


That's why it is so important that everyone uses encryption software *always*. Thats the thing with freedom: Use it or lose it.


They are working on it - there is already a branch for it - and I guess it'll be ready before Zero Reserve is. For now, I am preparing to hook up TestNet. For that, the current security should be sufficient.



 :)

I was just making a general point about the core features of Retroshare, not your specific use of it.

The key point is that if you are worried about the NSA, you should not depend on a tool such as Retroshare for 'subversive' communication as it will not protect you.

Having the entire history of every connection you make with your 'friends' in order to communicate encrypted information is highly valuable information, especially if you are using Retroshare for subversive purposes and believe yourself to be safe.

Anyone genuinely worried about state sponsored snooping should realise that A) hiding your metadata is crucial and B) endpoint security is extremely weak so you should expect your keys or those of your friends to be compromised at some point.

Interesting project which may be able to integrate well into the bitcoin ecosystem! One of the deficiencies of bitcoin is that it doesn't allow you to easily trade items which are not denominated in bitcoin (leading to the prevalence of exchanges to establish prices), making electronic bartering difficult. Projects like colored bitcoin or ripple tried to alleviate the problem by introducing the role of issuers/gateway and introducing a point of trust into the system, where denominated items can be converted.

Zero-Reserve seems to go one step further and abandons the role of issuers/gateways entirely by making each participant an issuer in their own right (which levels the playing field for borrowing). Thus Zero-Reserve seems to be the Yin to the Yang: Where bitcoin is based on a trust-free environment, Zero-reserve is based on a trust-rich environment, where the trust is scoped to the connections you define and have a legal handle for.

Also, if I understand the implementation right, the ledger is local and scoped - only those transactions are of any concern which are either conducted by or through you. Thus you always have perfect accountability.

There may be some privacy issues along the road, e.g. a trust-rich environment only works if the nearest nodes know themselves well.

A few things I noted and may facilitate adoption:
- there seems to be an economic incentive to perform intermediation (transaction fees). Thus the system encourages individuals to establish many trust connections and to keep their ledger online in order to facilitate transactions.
- routing is automized through the Retroshare software system, where inactive nodes do not participate in signing transactions.
- right now the system seems to be time-less, i.e. it only supports simple swaps or transactions. But integration with bitcoin as a timestamp server may be able to facilitate loans with interest and payment schedules, which is a feature which would eat into the market share of loan sharks.
- the concept seems to be independent of Retroshare and may end up in different incarnations using different systems.

Yes, you should select friends you give credit carefully. As for privacy: Unless you explicitly pay your friend, for example to balance the account, there is no way to tell for a hop whether or not the previous hop is the buyer or just another hop. Dito for the next hop.


Yes, that is my motivation in doing that - cutting out the parasites. Ripple is as big as Bitcoin, if we let it. And the beautiful thing is: Being fiat money, Ripple is largely orthogonal to Bitcoin - not a competition. It can be Ripple Bitcoin, an IOU, and it will always be clear that this is not the same as a Bitcoin in the block chain.

You can do same thing with colored coins: each user can issue his own coins.

Trust is still required, i.e. if you happened to get Alice's coins, and Alice won't pay back, it will bite you.

However, if Alice happens to be an individual with great track record, she can issue lots of coins, and people will be glad to use them.

So "point of trust" is inherent here, and issuers/gateways have a special role only because agents which can prove their trustworthiness can get more business.

This is absolutely unrelated to technical implementation.

klasse anu !

I use Retroshare and I will try this plugin
An excellent project..
 :) :) :)

I can't open this file. I used all major browsers and all they stop at different points of the download/import process giving irrelevant warnings. Any idea what might be the reason?

Working fine here. Note that you can not click the link but need to copy/paste it because the forum does not properly recognize the link.

They don't want you to read this because it would undermine their worldwide influence. Never underestimate their power to disrupt your internet connections and subvert your browser to show irrelevant warnings. ;D

Onkel Paul

I managed to upload it on GitHub:
https://github.com/zeroreserve/ZeroReserve/wiki/zeroreserve.pdf

Someone told me just yesterday that I can download the Wiki with
$ git clone git@github.com:zeroreserve/ZeroReserve.wiki.git

and just now discovered that the GitHub wiki is just another git repo. You can add anything.

Got it. Thanks.

This is excellent. Congratulations on your launch. I'm curious to know if you ever watched the contracts talk I gave in London back in 2012 - it mentioned using the original ripple concept to implement a P2P currency exchange.

I see in your paper you plan to use a micropayment channel for despamming the order book. Just be aware that implementing payment channels is somewhat non-trivial, at least if you plan to do it the same way we did for bitcoinj. Although all your current code is C++, you might want to look into using bitcoinj via JNI rather then rewriting it all yourself. But if you choose the latter, please consider being compatible with our wire protocol.

I'll try and make some time to try this later. I'll be trying it from a Mac though ....

No, but it seems quite likely that the meme travelled from that talk to me, now that I think of it. It came from a conversation with a friend who mentioned you a few times in another context. Most likely you can claim credit for Zero Reserve ;) - Will try to track the history.


Interesting. I didn't consider bitcoinj so far because I thought it would need to run as an external process on a VM and I would need to job-control it and talk with some rpc to it. Your examples look like integration is quite simple - just linking.


Please let me know how it goes.

There are limitations coming from technical implementations. bitcoin works through a shared ledger, while zero-reserve seems to operate through a distributed ledger. Thus clients do not have to store the entirety of the global transaction log, which should make this in principal more scalable. Also there is no build-in scarcity, so it has the benefits of a debt-based credit system. The shared ledger/blockchain is a technology to enforce irreversibility and transferability (scarce objects) in a cyber world. You only need these features if trust is low between two participants or the future prospect of honoring debt is diminished.

I like implementations like colored coins because they innovate on top of the bitcoin protocol to offer more solutions to potential needs, but not everything which you hit with a hammer is a nail. One of the issues of bitcoin is how to make it scalable. The answer is to keep as much traffic out of the shared ledger as possible, and only use it as a means to anchor additional systems, i.e. utilize the irreversibility generated through the blockchain growth and transfer that into other systems through some sort of transaction protocol.

There are specific use cases where colored coins should be superior to anything else, but I am afraid that low level bartering may not be one of them, because of scalability issues. E.g. zero reserve doesn't require you to pay any transaction fee if there is a direct trust line between two entities. Thus you can do high-frequeny exchanges and bookkeeping more easily without the cost overhead of paying the mining industry.

If the 'Bitcoin purchase payment' exchanges coins and ripple-style IOUs, would it also be possible
to hook more than one blockchain into Zero Reserve and exchange between them (i.e. completely trustless)?

It would be possible to hook several coins into it but cross transactions would have to rely on trust in your friends (=people you trust with money).

There is no need for F2F if all you want from ZR is a distributed order book. I'd suggest to do a standalone app for that, distributing the orders using the standard, anonymous P2P approach and glue it to the block chains you have in mind. This is much simpler than ZR - so simple in fact that I wonder why nobody has done it yet.

Part of the motivation for ZR is to provide an alternative to banks to get fiat in and out of the Bitcoin system (or another coin if someone cares to do that). That problem simply does not exist when dealing only with coins.

Oh, I'm not after credit, I'm just interested to see if the work I put into documenting and doing talks had some impact in the end :) Implementations are the expensive part, ideas are cheap (around here at least).


There are various ways to do it. I did some experiments with auto binding the bcj API into C++, although you still need to ship a JRE with your app. You can delete some files to reduce the size but it's still gonna be on the order of 10-20mb extra. On the other hand, RetroShare alone is 70mb on MacOS.

https://github.com/mikehearn/cppjvm/tree/master/mytest

I made a quick attempt to play with ZR this afternoon, but unfortunately it dampened my enthusiasm somewhat. It was extremely difficult to make RetroShare work. Indeed, I found RS to be hopelessly confusing and the GUI to be quite flaky and badly designed (ignoring that it looks like a Linux app even on MacOS). Firstly it wouldn't import my PGP key for some reason, so I let it create a new one for me. Then I tried to open the forum link but it didn't seem to have registered with my browser. Then I tried to find a way to add that forum within the UI, but there wasn't one. Eventually I figured out I needed to add a friend, but I don't have any RetroShare friends, so I went through another very ugly website to add the Austrian pirate party. It didn't work. Seemed like network issues, but eventually it managed to get a connection to the DHT - it was just very slow. But even then I couldn't add the forum.

So I talked to some guys in one of the chat channels, who told me I need to add a friend who has the forum to be able to subscribe to it. I guessed that means I'd need to add you anu - but I don't know how because I don't have your certificate. Eventually someone told me I should make friends with a bot called Cupcake, so I pastebinned my cert to that person and they made the bot add me as a friend. Then finally I could find and subscribe to the ZeroReserve forums. However they appeared to be empty. My new friend in the chatroom (thanks Tatjana if you read this) told me to reconfigure the bandwidth throttles from the default, so I did, and eventually things appeared. But it took a long time and only some of the messages appeared. Many were marked as "missing", and the font sizes around the app are sometimes randomly too small to read.

Now I'm not exactly a newbie when it comes to computers, but given the ridiculous process required to use even the built in features of RetroShare, my enthusiasm for trying ZeroReserve was somewhat reduced. Although DHT/turtle routing may be the right technical design, it's hard to imagine a distributed exchange taking off when based on a platform that's so very ugly and hard to use.

Is it possible to use some of the RetroShare code perhaps without the complicated friending/setup process and all the rest of the UI paraphernalia?

If I was doing this myself, I'd probably implement a raw broadcast network and have the entire social/debt graph on every node. Once the graph is obtained doing an A* search over it locally is quite reasonable and should be fast enough. I'd do it in Java for the cross-platform support and lack of buffer overflows, as JavaFX in the latest JDK8 is a very modern toolkit that works well on at least MacOS and Linux (supports Retina-resolution GUIs, animations, embedded webkits etc). And the UI would be specific to the app in question rather than a plugin to some larger framework.

I hope you don't take this feedback the wrong way - I really want to see ZeroReserve take off. I'm just not sure it's going to whilst tied to RetroShare.

RetroShare is still in early stages and is first and foremost a friend-to-friend communication and file-sharing platform (which in this context works much better and faster than Tor or Freenet because you explicitly allow trusted friends to know your IP), so such kind of teething problems are to be expected, especially when your first use is slightly a bit out of its original context.

ZeroReserve afaik is the first plugin created by other than the original RetroShare developers, so it's all very experimental still.

Not taking it wrong at all - I really appreciate it. I share many of your concerns, particular the Lotus-Notes-ish feel and the unnecessary difficulties to get up and running. Also the difficulties on getting Zero Reserve on mobile devices. And I am sure the RS developers share them, too. But there are also some strengths in RS which you seem to perceive as weakness...


That was my original plan. I was already in the process of stripping down RS when the developers of RS convinced me to do it as a plugin, promising they'd cater for my needs. My needs are indeed addressing many of the issues you raised.

But I think you misunderstand the friendship issue. Both Ripple and RS is about F2F, not P2P. You can't just go with any peers, like the Bitcoin network can. That means you need to set up your friends - there is no way around that. Your particular problem was that you entered the RS network without existing friends. It would have indeed been easier if you had messaged me your key and used the key I posted above.

Bootstrapping the friend network is IMHO the most cruicial issue. I hope that maybe some trusted members of the Bitcoin community start a kernel of users. Take Casascius, for example. He may not trust me, but I am already trusting him not to run away with my Casascius coins - I could easily trust him a little bit more. One sided trust is sufficient. But it has to start with a kernel - which may become a set of super nodes. From that kernel it will be easier to grow the network outwards.


That seems to raise both privacy and scalability issues. The beauty of the pure F2F approach is that it is strictly local and no information beyond friend-of-friend is known. Also, if you want to use the graph to do the routing a-priori, you need updates who comes online and who goes offline on each node from the entire network. Imagine that on a network with a million nodes or more. Sure - datacenter manageable. But I'd like to keep ZR manageable on a cell phone.

The routing as I implement it takes into account whether or not there is available funds on a route. You certainly do not want *that* information to travel beyond the 2 parties concerned.


The current C++ is just over 5KLOC. I doubt that it will get much bigger than 10KLOC. It should not be so difficult to port Zero Reserve to Java. It has been done with Bitcoin. Which may be a good thing anyway - the first implementation is bound to end up warty.

I did it that way because I am sure this will give results quickest. After what happened lately, I feel it may be a good thing to send a strong message to certain parties: "If you trouble the exchanges too much, you will lose control entirely because then everyone will/must go P2P."

OK, great to hear that.

Yeah, having the entire graph locally means you learn the debt-line relationships between nodes, which isn't great, though I haven't thought about whether node identity can be obfuscated somewhat.

Tomorrow I will try and compile the plugin. BTW for some reason I still only see about half the messages in the forum.

Mike and his Java. It's almost as if he works for a company chained to to the dark language by a product that shall not be named.

http://cdn.arstechnica.net/wp-content/uploads/2012/09/java.jpeg

Haha. I'm wearing pants! The funny thing is, I hardly ever use Java at Google. Almost all my work there was C++ (and a mishmash of Google specific languages like Sawzall).

Actually when I started on bitcoinj I thought, ugh, Java. I didn't want to use it but that was the price of entry for Android. The very early bitcoinj code looks more like C++ than Java.

Over time I came to appreciate it a lot more. The Bitcoin community is really spread out over all the major platforms, so easy portability is a big win. Elimination of lots of kinds of security bugs is another big deal, especially when dealing with money. And these days it's possible to make really slick GUI apps as well, it's not just for server side stuff anymore.

But - it still has a bad reputation. One of my side projects now is to show people it's not so bad really. The biggest pain for now is the big size of the JRE for bundled apps, and integrating with C++. I've done a lot of experiments towards making that easier, like using source-to-source transpilers. Python, Ruby, LISP etc all have JVM based implementations that make interop a breeze.

Anyway, this is offtopic. You use the language/platform most appropriate for the current job. For ZeroReserve if RetroShare provides so much important functionality then it makes sense to integrate with that.

looks cool

same

Hi all,

I want to answer some of the complains/issues here. Some of them are valid. some not. hope the detailed answers do not offend anybody.

+++++++++++++++++++++++++++++++++

We are discussing here in a Bitcoin Forum. If this is important, you should drop your interrest in BTC . IMHO the Bitcoin transactions are snooped too with METADATA + Money Data.

A/I explains why we they do not accept Bitcoins as donation method. http://cavallette.noblogs.org/2013/07/8333#eng


This isn't correct. RetroShare exposes some MetaData but you can define which of them are exposed. And reduce them effectively.  

File Sharing is made with TurtleRouter:
http://retroshareteam.wordpress.com/2012/11/03/retroshares-anonymous-routing-model/
Communcation via Distant $feature to non friends through the RetroShare Network via TurtleF2F
https://retroshareteam.wordpress.com/2013/08/08/distant-chat-and-messaging-using-generic-tunnels/

The distant functions obfuscate the communication in the RetroShare network. They do not need a direct connections to friends. Only a chain of friends to your endpoint, which activate Turtle-Routing.



Normally your friendlist contains up to 50 users, and normally 5-10 needs to be online.
Secure endpoint environment is important. IMHO AirGap is the only working security feature, still can be pierced with social engineering.
This is a general claim, and valid to all Software as we know it.
How much of tech. max. 5000 Facebook friends are real friends with contact everyday or once a month?

TOR Support:
It is planned to have IPv6 Support http://sourceforge.net/p/retroshare/code/6735/ hopefully in v0.6
IPv6 offers the ability to use TOR via https://www.onioncat.org/
OnionCat is a VPN-adapter which allows to connect two or more computers or networks through VPN-tunnels. It is designed to use the anonymization networks Tor or I2P as its transport, hence, it provides location-based anonymity while still creating tunnel end points with private unique IP addresses.

If you know a silver bullet for anonymization, pls tell me. Haven't found one yet.

This could happen to all people which use any encryption software. Or any cypher technology. i want to point out we are discussing here on a Bitcoin Forum aka CryptoCurrency. If this is true, you are already a person of interrest.

late, but it is in trunk now: http://sourceforge.net/p/retroshare/code/6738/
Enabled PFS for SSL connections, based on a 4096 bits safe prime. This is retro-compatible, meaning that old peers will connect to the new one using PFS if they act as a client (meaning they request the connection)

-------------------------

The GXS backend for General Cache Exchange is e revised and improved cache system. atm the cache system for Forums and Channels and browseable directorys is really bad implemented.
With the GXS release new features are implemented. rumours say twitter-wall-alike, decentralized Wiki, etc ...
the direction is more socialising stuff, and offers better and other features implemented too.
Think of a decentralized GIT repository... how cool could that be. Really decentralized as much as possible. Push and Pull via "Distant Git". git remote add origin GPG:location or something similar.

Haven't tested GXS yet, but it is openBeta development status. 2 packagers provide Win Portable Nightly builds, 1 is creating Ubuntu Builds, 1 is creating openSuse Builds. Arch & Gentoo should be able to compile it on their own with GXS enabled. atm GXS is implemented but switched off in trunk. You need GXS peers to test the new features.
Any new features are easier to implement with GXS.

------------------------

If your PGP is using DSA/elgamel it is not possible to use them for retroshare. only RSA keys are possible.
RetroShare will bloat your keyring probably. this is why it is using its own keyring.
your mail address in the pgp key will counter the pseudonymity/anonymity


It is confusing because it is new. the whole pure F2F approach is new and confusing. but you will get used to it.
yes it is not the best design. hopefully some QML/QT4 designers jump in and help to improve the Gui.

imho, if software is fancy, the time should have been invested in security instead. we all remember DeCryptoCat.

You can't add a forum from nothing. You need a friend who is subscribed to this forum and shares it to you.
This is a generic newbie question. heard it hundred times now. it was confusing for mee too when i started using RS.
http://retroshareteam.wordpress.com/2013/01/19/retroshare-forums/ <-- detailed explanation in DevBlog

Of course you need a friend to communicate in a Friend2Friend Network. Facebook, ICQ and Skype had the same Issue when they were used the first time of your life. Bootstrapping.
Thats were the Chatserver kicks in.

Its not ugly, its called Retro :P
Its not a bug, its called a feature.
It was designed this style as much as i could. No Java Script, no Third party things, no Content Delivery Network, no analytics/beacon/cookies/widgets/adds, no logging, no piwik, no anything.
Rock solid plain HTML like 1995.

The ChatServer are crippled RetroShare nodes. They offer ONLY Chatrooms like a IRC Server for example.
For some legal reasons they do not forward or exchange any traffic. NO File Sharing. No Forum Sharing. No Channel Sharing.
Compared with a IRC Server, you wouldn't expect from an IRC Server to serve Forums or Files or anything.
For Privacy Reasons the chatserver runs in DarkNet Mode. It has a static IP address, so there is no need for any Discovery or DHT. #OPSec Keep as much private as possible. Disable all features which are not needed.

For more information please read:
http://retroshareteam.wordpress.com/2013/01/06/privacy-on-the-retroshare-network/
&
http://sleeplessbyte.com/blog/2013/07/31/retroshare-network-configurations/

It only needed some time to add your RS-Key to the chatserver, and the chatserver key to your RS friendlist. Connect attempt is done every XX seconds.  

Small simple picture-rich HowTo: https://retrochat.piratenpartei.at/w2c/howto.html

The ChatServer breaks the whole "serverless" approach. To counter this issue, the ChatServer has only a limited Friendlist. If you add yourself to the Friendlist via https://retrochat.piratenpartei.at/ you will add yourself at slot #1 and kick out the user of slot #101. FIFO
This forces the users of the ChatServer to bootstrap their friendship network and become independent of the ChatServer till he kicks them out.
Other Users provide for newbies Bots which run 24/7 and add without permissions to only share public chatrooms or forums.

Information about the ChatServer: https://retrochat.piratenpartei.at/w2c/info.html

https://bitcointalk.org/index.php?topic=295930.msg3173564#msg3173564 <-- post #3 in this thread

This is related to the cache transfer things. All subsribed Forums of the friendly bot are transferred to you. Every Forum you subscribed is writeable. Every subscribed forum is shared to your friends.
cache system which shares the forums/channels is implemented very bad. all is resent always... new GXS implementation will do that in a more GIT Style. Resend only Deltas.
Synching the cache needs his time the first time.
The Forums are reimplemented with the GXS too. atm they are shown as missing if the data is not synched yet.

True. Though starting together with a single friend or together with group of friends is a lot more easy. Than starting without any advice or friends to connect.

+++++++++++++++++++++++++++++++++

Related to the bad Gui.
I am in contact with the Team of http://www.mailpile.is/
They maybe want to add RetroShare as a Mail Backend to solve the Problem of the METADATA with PGP encrypted Mails.
Distant Messaging of RetroShare is more scaleable and is totally decentralized. And solves the MetaData Issues of e-Mail because they are forwarded through the RetroShare network like packets of FileSharing.
Pls consider: the ChatServer itself blocks all FileSharing. You need "real" friends with AnonRouting/Turtle enabled to participate.

If you are interrested in Mailpile Frontend for RetroShare, please drop them a line and ask them friendly if they want to put it on their ToDo or Technololgy of Interrest lists.

++++++++++++++++++++++++++++++

@Mike
Pls get in contact with https://github.com/G10h4ck/RetroShare-Android-Client G10h4ck, he is implementing RetroShare for Android.
Atm he is doing it for RetroShare noGui via the SSH-RPC interface.
He is planning a RetroShare miniCore for Android too (future).
Have a look at the Repos of https://github.com/RetroShare/ There is the https://github.com/RetroShare/pyrs Python Retroshare Interface Library



+++++++++++++++++++++++++++++++++

All in all these questions are known "Newbie" Problems. i faced 99% of them too and had similar feelings about RetroShare. Especially the undead WebForum which made me feel the whole project is abandoned and undead  dropped years ago. no active userbase. But this isn't true. The RetroShare users do most communication inside. Offline from any webcrawlers or spying or advertising or any organizations.
There are several RetroShare Island-Nets in the world. Without any connection between. Without any knowledge of existence.
I have heard of Closed-Private-RetroShare networks for a defined group of users.

If anyone has detailed or generic questions, please feel free to ask.

Read http://redd.it/18vsq5 before ;) it solves most questions.

If someone is interrested to run its own ChatSever to bootstrap RetroShare in his favored community, like a BTCchat or any other topic to bootstrap the UserBase. pls let me know. I would kindly help you to setup the ugly frontend and the retroshare-chatserver backend.

or ask directly in one of the ChatServer rooms:
https://retrochat.piratenpartei.at/ & HowTo https://retrochat.piratenpartei.at/w2c/howto.html
The other chatserver shares the same rooms: http://retrosharechatserver.no-ip.org/w2c/en/ and is community driven.

You are free to run RetroShare without any connection to other RetroShare-Nets and use it only as DarkNet for your closed circle of friends as a secure communication tool.

br cave

Thanks cave. I realise that trying to use it with no friends was a mistake :) Still, sites like Facebook have ways to help you resolve that problem (by helping you find friends, etc). Bootstrapping off existing social networks is not a sin, I feel.

Hi anu,

very cool idea. I added your RS certificate, here's mine:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

mQINBE/DVk0BEADd0cA56Yb5s/LweuZmUUUD4juwCi2WdUAmpqR/+Inh4mPu61l9
PLm+K47dCTgbvFM0e49F9tvrX7lL9YmdVOYHZZ5qT5AowPaurpKHnAaFT6dWCgD/
RYkqnIlGCWcQrmYeYtZiWqjPwguuSEiTRPnQwrgxsxUOJsNfUa5h420zBMW3YVJ8
yKVF+UvuNyK1Lm5vYjB5pj/Ir1yNxnYgnHh9KksA7Xs1vbSfm2CGarJeI9+Gi1KX
uHHA9lJ/C6koaU/jlYm9k7GItkxI9U/6G++Y0kVV5tA2/eTGfRQ4WC58H/jQvYU8
aSYhHx0Ib9AppBFxnhBpY+o4chcBTyjQDNQcGYNtkKAI3d1NKPhhjfzj425kwEpL
k1eNkKAi36R2uRNyxhaDRAF8bSZ+xpCsvt5DgOjOmJ6mY5E33piW1QgQLvhNQeve
d+Xzzr9b0/ODObL2wqJ4MXlafCAlUUV7GkDtWE5PVmLDfrfoMIJpRowwW5cL0IV9
QbeV+9ZdUa/y1scXglWVT+K61j4yWESt6z85vi4KsW/r4El2Ncrdde2cohfqElwD
wbCJ0E43ENqgzwhLw2px2BjqTFB0kfe3xBbXgNW3sz2HCYj3NnzyyWN9QKtLEVyw
WxUa4zTmZU9diV8uFaFIwttAlQ/Bi9r1fscdMXACHZ3zGVgwpB/mPmjdGQARAQAB
tBtLeW9vIEt5b28gPGt5b29AcmlzZXVwLm5ldD6JAj8EEwECACkFAk/DVk0CGy8F
CQeGH4AHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCBYX1XGOPC6n9tD/93
pbYlmeQyZce6TT0GScKK5nOgwnd9UI5H3OYTvgZklbt6KRUPlCKvAGieNgTipllb
JS2VE087WNKLLSgdf29J0s8WCytGG/geOaLlW8lNBVJrlUi6evKt3zm1suL6UQg5
v9NA0EPz3r47rGAQdSsjM+E7wUlKjDBpKlbwDU68+HmaV1/he8NVC1hbmTyZAYMV
8Qq/nOWVFZzsnZswffYjoZLn+UOfalVtbmXnGFcgaVYgnkHDDMedHmqJqWIUDX+p
YNLmVZ2x88QFVwkLUImohzOlfOo89VNMUFTqwAtcpCHH1K7X5W5fGc6F1fSOyqfb
SsifNzyw+xmmPXXBlnvcAeC+/a1uxoNWvagjAYhaEpw4PfEceW+6Bfa71M52kVfU
VyOhoSbfyAA1dbBGZ29T7w2bNQL8rw9dMe6IMi+0gHIXe0fWHvWZ5lHjMPG8sula
QS9ycLRAikgizWWW2vWSbQ7i+ejcUOKG79uOo7Agab4XSOPfVWymIPRIX3/1ljh4
RyaPKS03wNcuGQcpxgOkMOXztkGrCN2eyOwoeECH2zy+ZOK0Ks3pi4T972t2ExYf
jP970pUxyE9iQp4xGbSG2eNuzEvRw6WCAMJQpvwhg5xf3v7OP2t31MebMMT3SkVD
9YThBmLSzsVrRJJqVnLCcTpyAEI4qKJETnRdSs3ulw==
=BkWJ
-----END PGP PUBLIC KEY BLOCK-----
--SSLID--e100bc19687ee06fb6749b8787251d6f;--LOCATION--Laptop;
--LOCAL--192.168.1.5:15593;--EXT--46.19.137.116:15593;


I also sent you a distant message, for testing purposes, did you get it?


Cheers

Added.


Yes. That went very smooth - just had to click on the certificate link to add you. Just like Zero Reserve, that works as long as there exists an unbroken chain of friends connecting us and you have my key.

The difference to ZR is that ZR routes Bitcoin orders or payments only as long as there is an unbroken like of credit. So I granted you 2000 ug of Fools Gold and 2000 Zimbabwe Dollar.

You should now be able to see the Forum and a number of chat lobbies, especially Zero Reserve.

Newbie question here https://bitcointalk.org/index.php?topic=305480.msg3273678#msg3273678

Just got this:

http://farm6.staticflickr.com/5443/10051454613_be390d127d.jpg

when I tried to deposit some coins on an exchange. Probably old hat for many, but it came as a surprise to me. Wonder how long until we are obliged to register all addesses with BB. Gotta hurry up to get this out. It feels like the pain with centralized exchanges might get intense enough so the inconveniences of setting up RetroShare don't register any more.

yeah it's been known for a while

http://www.reddit.com/r/Bitcoin/comments/1lpfg7/bitstamps_new_verification_requirements/

but no wonder at all. Of course they have to follow regulations.

Also not such a big deal if using such exchanges. They know your bank account and see where the fiat's coming from anyway.

They knew an account number, but reliably only if you withdraw fiat.

Let's see if this affects their volume. But I guess it doesn't, people don't care
about extra work when doing their taxes (and/or the extra risk) or perhaps use fake ID for such purposes.

Hi OP,

Maybe I overread the part where you explain how you will manage to implement the whole idea without a gateway to the traditional banking system, as you promise in OP?
I think your idea is great and deserves attention but how exactly are you trying to skirt the need for any bank accounts tied to the system?

I hope there is some way to use peoples bank accounts or paypal or whatever to settle debts automatically. If you would rely on people meeting in person to settle their debts this cannot work on a global scale. If you rely on Bitcoin's world wide adoption for this to work, it could take decades to become a viable alternative to bank transfers or PP.

Just an idea: This Open Transactions guy suggested the decentralized use of peoples bank accounts within his system (where he had the "The HOLY GRAIL!" thread). It made sense by the time I was reading it. You may want to take a look, its in the OP: https://bitcointalk.org/index.php?topic=212490.0

also find answers and descriptions in the last post: https://bitcointalk.org/index.php?topic=212490.msg2384304#msg2384304

Cheers

Because the bank is YOU. Or ME. If we're friends, you'll see in the system that the balance between you and me is currently maybe EUR +2000,-. And tomorrow maybe EUR -600,-. Depending on all the action between you and me or our friends and friends' friends.

We may choose to settle the balance between us eventually from time to time with some fiat cash, or not. Either way, we'd all continue to use our regular bank accounts as usual, without our respective banks suspecting anything.

We need to understand that the banking industry is very much unlike, say, the semiconductor or the aerospace industry in that we all can trivally create their products. There is nothing banks can do we can't also do. What we all (the Bitcoin community) are doing boils down to making the entire banking system redundant.*

Ripple** and hence Zero Reserve are ancient ideas: The Hawala Money Transfer System (http://themonetaryfuture.blogspot.de/2009/08/hawala-precursor-to-anonymous-digital.html) is around since well over 1000 years. Ripple / Hawala works - it it the oldest money transfer system currently in existence. The difference to Zero Reserve: Modern networked computers make it possible that everybody can be a Hawaladar - the computers are taking care of the complexity to find a line of trust through the social graph. That was the challenge all along, not the fact that we can grant each other credit***.

As Herzmeister said, we will be using the banking system for a while, because many accounts are bound to get unbalanced, for the simple reason that all our income all goes to the bank. The difference to a centralized Bitcoin exchange is that when settling that, it is a random transfer between private accounts, from the bank's POV. They can't easily block that as they can with MtGox.



* Making the world a better place as everybody gets the dividends. It will be also more difficult to crowd fund wars than to (central)bank fund them.

** Using the word Ripple to make explaining easier. But ZR is not associated in any way with Ripple Labs or any other company.

*** In fact that is also a challenge - we have been conditioned since 100 years to keep friendship and money apart: Friends are people you party with.

Here's my key to retroshare, if anybody wants to join in, PM me your key and i'll add you as well.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

xsBNBFJXQTEBCADGaQm6Lcndq2FbVAs2CwbZmowz9tLFdEw/99M4nrDDh7Kp1xUi
aXFvNhBxFGZH3kJzovgWTSP4PuQl5WyF/dtgZgSf2NX5yv96+Lh2EW4E/HwmQfut
iv8E1q8NuQLKQbkz7XudB1cAgd4gEwkZn0p2xlJOy2p6XTYfqW4eeWvTEGtQBdNs
Mk0E5cXKn0ik25dkniRQz076suRFFdM1lCEjTyHlBxQ2mxn2LLBAirtn7Ftglccq
5WW2LZVPgaVc88z5PDAuB3hQ4Ie8CEgqs39EC09p2/wHP/hu+Vu+0lyhRK2I/7x1
Q+OtWMMIQKiekgUaEo72EuzO/zjjnPhnmPbDABEBAAHNJUpvZSBTbW9lIChHZW5l
cmF0ZWQgYnkgUmV0cm9TaGFyZSkgPD7CwF8EEwECABMFAlJXQTEJENuTboMYP3oq
AhkBAAB8nQf/QUrRavIHrWxEUpq1R4wCDkluuLY5+hpRiptwvDv1kPJ0aNnkwMV2
C1D5OBtKm3zXR0g/G94qguXILxrnRBmkopq3y+TtYkZcEnonJj4tEVSmr3axFt15
E7rKkPTlIV/K4vNsr6htkbAUvK4TJMDIiQWLkZOeSoY+kdysxL3uBpFdC5ibVP3r
kqjSAj3KJ03e0vL7HJ9b+1NDWS3C5aYjjW0v4nO99eHsFns+gf/K4FiMsutZ0rUm
gKytkTem8sibQRdc3sY7ibhlHlHYJpR5VtpUuOqhiymq1BS5uHKB01A4DGcN/IJH
b4WpE/bmHclIbEX3HiFgDd667WK92zuy+A==
=Oq0s
-----END PGP PUBLIC KEY BLOCK-----
--SSLID--25a6aee526312320868964d10bff257d;--LOCATION--Vienna;
--LOCAL--169.254.219.79:7540;--EXT--70.194.1.14:7540;

Adding my key for testing purposes:


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

xsBNBFJrtTwBCADVW1lowhuhtMfXEcThhcA9qfvarkvfqhcUPMLgAuqQVsTe01+0
gny7ViIv3GMczfsPuOhsTCoqTbCcPOMxQxxkrXlVNHsLwwqRfd3Y1b0KfMAPeLcK
peYFKgIWpCesuSz9JiFVtuI5oxYHSYwgjZ77WTxx+xL+fJ6x4lyN09PQd8J8AUY6
8OS7PbgSb55I68Nc0GguuSdSfXuVV5YMuDD/qE94Xo4bHnFTQZAkk/nc45aqcRtU
jRMshNL/ES1wS2TlHQnpbiNhKF0d9qegQ9Z/LqUXKmI+wBbagNnHN/BUkJZZfj2S
WU6kNfxgFXz/YLPrFhmDXjzYPrwyzdrOP8vRABEBAAHNJU9fU2hvdmFoIChHZW5l
cmF0ZWQgYnkgUmV0cm9TaGFyZSkgPD7CwF8EEwECABMFAlJrtTwJEKXD8BLsEiO4
AhkBAAA8cQf9GMVDLWZUzxE7n6W1OOJ7zdxzr1iLlVjYYJxbe6pW04pz4JOEvcp8
FZm8z/pDbieBZwnR20wrvHlagiLlyry6kJRKq5KkDAFxOrVo6ZiB3tehbL8OSm5O
ANKhRSvn8EQDzsDQVFXtAiFJCi4Xj/nVn2qIirBHhPAwr4B1lW8Kfy8SNPHIOfw5
XGi24sDkyhyH0/d54mdfiE+M7KBGV1QjAeyP0Ni5HVs63qkzo8ugRZQ5zcyN3kOC
4Cwsfh5TQQpteRw0fcnNFz63fG8jboKs9C/70HzjWYLMbwKcDQha58WJzI/8A1PH
3H0616mR4ZUsCKsakNiQgVtp92i0WMiNTg==
=mLAe
-----END PGP PUBLIC KEY BLOCK-----

A potential possibility for paying nodes:

https://bitcointalk.org/index.php?topic=62558 - Sustainable nanopayment idea: Probabilistic Payments

Just yesterday I realized a big difference between ZeroReserve and Ripple.com: ZeroReserve's orderbook and normal transactions can be anonymous. You just pay to a hash you can transport otr.

Also the current state of development is impressive already. It seems there is only little missing towards a working implementation.

Indeed, a remote payment is a payment to a hash, not something that makes any sense to anyone except the payer and the payee, like a RetroShare ID. Just like Bitcoin, it is not perfectly anonymous - every hop can tell the previous and next hop. Since the number of hops is small (less or equal to 6, most likely), the chance is significant that the previous hop is the payer and the next is the payee. But AFAIK there is no way to be sure of that and hops don't know what the payment is for.

So indeed, you can pay for furry porn without letting your friends know of your preferences ;)

BTW: I used the word "Ripple", but I think this may give too much credit. Ripple is not doing anything substantial that is not practiced by the banking system, say, in the SWIFT network. In particular, it is pretty much the same as Hawala. And Hawala goes back more than 1000 years. If we can believe certain sources, it goes back 5000 years and was practised (albeit by another name) for payments between the ancient cities of Ur, Uruk, Askalon, Ninive, and Babylon. I'll try to research that a bit deeper and possibly remove all references to "Ripple". Any pointers to that is highly appreciated.

In case you are still opting to start out with bitcoind:
http://dot-bit.org/forum/viewtopic.php?p=5196#p5196   [ANN] Namecoin RPC interface in C++

also: https://github.com/libcoin/libcoin/wiki

Should compile with MinGW 4.6

sorry, this looks pretty weak.

lot of attempts these days by the community at large to use 'Distributed Exchange' to attract attention to themselves.

I am working on a distributed exchange and it has a rich background of theory:

https://docs.google.com/document/d/1cKlN55wX7n0SLvxidLoFVrJnNMJO-Iefr8bVyeHBseg/edit

the link is not my best writing but it explains how to do it with Confidence Chains.

the problem is far more complex than just posting an order book to some shared file somewhere.

you already have something like this with Bitcoin-OTC, http://bitcoin-otc.com/

Sorry, mine doesn't boast any theory. Reason is that I didn't actually invent anything - I just combine known inventions. And the main idea is, as I said several times already, more than 1000 years old - possibly as old as 5000 years. I find it preposterous to put theory into a paper that is not the theory you invented. Look up the Hawala/Ripple theory on the original papers, or rather, clay tablets. The more I get into the topic, the more I find it preposterous that Ryan Fugger wrote a paper claiming stuff.

I believe I referenced all the relevant inventions I am using: E3PC, Turtle Routing along Hawala trust chains, signatures.


I agree. That is why I put all the stuff mentioned above together to make this work. You may have noticed it if you had actually read the paper or played with the code.

No idea what you mean by "shared file". Are you trolling?


Bitcoin-OTC has about as much in common with ZR as Liberty Reserve had with Bitcoin. They do something vaguely similar, but that is it. Again, are you trolling?

http://blockchained.com/stuff/bps_s.png
Vote (https://bitcointalk.org/index.php?topic=251087) for ZeroReserve as your favorite Bitcoin Project of Autumn 2013

I have a question regarding the implementation of the matching engine (exchange) used in Zero Reserve. There isn't a reliable global clock in a distributed system. How can the distributed nodes collectively determine which order comes first and which order comes sometime later?

Nodes don't do anything collectively - the philosophy of ZR is to be strictly local (no reliable information beyond friends). Each node only matches own orders with other orders. Nodes may only have a subset of all orders floating around in the network and that subset may differ from node to node.

Orders are matched as they come in - first come, first serve. After the match, the rest of the order (if any) is placed into the order book. In practise, many nodes won't try to match, because they have no own-orders in the book.

So strictly speaking, ZR is not an exchange, its OTC with the look and feel and the anonymity of an exchange.

Collisions are handled by the seller node - an incoming buy request is denied if it can't be served because another buyer won the race.

That sounds bad, but its not so bad: An order simply needs a few seconds to propagate through the entire network. During that time, nodes closer to the originating node get to see the order sooner.

First come - first serve may lead to sub-optimal deals for the originating node. We'll have to see how bad that is in practise. If its bad, it's possible to implement some counter measures. I expect it to be largely a non-issue.

Thank you for the clarification. It's just that the non-deterministic behavior of an exchange/platform always bugs me:)

Aside from lacking a global clock (and thus a global orderbook), I still have some concerns about this project (all are very subjective):

1) The misleading concept of a friend

A friend I fight a war with is very much different from a friend who happen to attend the same class as I do. Take Facebook friends for example, one can easily make a dozen of new friends on a social network every day. If all my Facebook friends want me to trust them and buy things from me using the credit they issued, shall I comply? A "Yes" or a "No" is too simple to answer this question, but at least we can assume that it is hard.

Another issue is that people regret and people move a lot. If someone buys a bike from a friend, it's highly unlikely that he/she would regret afterwards. But if someone buys thousands of stocks from a friend, the market fluctuations may cause this someone to want the transaction to be reversed, regardless of whether it is right. This may cause conflicts and even end their friendship. Also, developing a friendship that one can trust their money with can take a long time. My personal observation is that as we grow older, even having a few true best friends is a blessing. And in a modern society, we get to meet a lot more people because the mobility of the population has dramatically increased. Establishing and maintaining a long lasting friendship, is (can be) hard.

All in all, people might not enjoy trading frequently with their friends.

2) An established Hawala system doesn't necessarily require modern technologies

I found some video introductions about Hawala system on web. And I got to know that this kind of system has a very long history. And there are currently many Hawala systems functioning in a global scale without a high-tech infrastructure -- cell phones and emails are adequate given that there is someone somewhere that we all trust. I have an assumption (possibly wrong) about these established Hawala systems, take a Hawala system that enables people to move large amount of money in and out of a country for example, my assumption is that there must be someone who has predominant control over both divisions in and out of the country. Thus, a trustworthy Hawala system is, in a sense, centralized. So, my question is, will people embrace a decentralized one?

(Please note that I am not trying to be harsh. A friend of mine pointed me this thread and I need to get a feel of it. My way of trying to understand something is to throw as many questions as possible at it. This project is more revolutionary than all the projects I have thought about developing by now. Keep up the good work!)

Me too ;)


In ZR, a friend is defined as someone who you grant a credit. So it might be someone who you don't like, but trust.


You don't need to. Friends only route payment. Should it so happen that the counterparty is your friend you ( and he ) would not know.


Indeed not. But AFAIK Hawaladar do not usually route over more than one hop and Hawaladar are professionals. ZR takes care of the complexities of routing over far more hops and it doesn't require you to work to participate in the network - ZR takes care of that.


 :)

This sounds like something I'd like to try in the future so I'm will watch this thread.  Good luck with the project I hope you will have success.

We need the distributed exchanges now, more than ever.

this. is there a donation address btw?

Interested to learn more about this.

Here is my retroshare PGP key

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

xsBNBFKyafcBCADO37Fzc8BvQJ5qeC9Gfs9c3J/fP/wmrNcV93irIDSKidq2q2fr
e/HxJO9QO7k47KGJGhbgyNHX21jILIShdw0AwkE+FubyyprHC5FvFHxX8AjWzxWM
CJ8u/ecG7leVSTjI7mrTW5Xf9echbOE64ixZatw971e9hmA0R/BMKWe/KHI82rfx
UsVGEx7nK3sg8EF1lpTZwWV+LUNzbzOCOJriHqrUMSIwm+7K/tWZyKbzhaLs0CwV
41U6Vr1s1aU5sDZyxv1Ix/5G4E4Fgh0bxdSsRt0+Kj283wYQUFLpMGxrw3kls5Tn
6XsZ8YWrWBBvqIFYdQlrAkD4LboauZI1uRxNABEBAAHNLEdpYW5uaSBEJ0FsZXJ0
YSAoR2VuZXJhdGVkIGJ5IFJldHJvU2hhcmUpIDw+wsBfBBMBAgATBQJSsmn3CRDi
dAI5MvF9+wIZAQAA2W8H/0Xm7hadz0WOJUm0gH/h671U47vPCCjWwNEqwg8CqvaW
J9e6cPOk/YSJE43R3ihS9kgVPBcJduy5KTtql7YTW/6VNmUOPz8kl5obgExPDG7a
AwRZVsUdPNd2er0joPqhroGMMbc4EUv8NqfK/f3diQKadGIcaFS10Zd1nejVxjuK
OPUxwP0xdchcZNKr67FdJyDIoRv1kKxdzNQhDAyYeLKCpoqn2XK2YqN3yT8HJrDa
BRSRl3SKitp+hA+6arjZchmSY5kGdH5p25n3aZe82jaGJQimEtMGduYkGY6ihAyS
t8R7AzaFQl3aOCosJy3j/vK70C6z7RIibaOGfi2e18U=
=v7AQ
-----END PGP PUBLIC KEY BLOCK-----
--SSLID--dbb6a35be45e22fa692cdef104d9bce0;--LOCATION--Home PC;
--LOCAL--192.168.1.79:12718;--EXT--99.56.53.173:12718;

maybe i'm not connecting the dots, but in a decentralized exchange, how do we get money from BTC > Fiat > In Hand?

You would only connect to the network through people to whom you have extended some amount of credit (ie people you would trust with money - be it 0.005 BTC, $500 or 50 kilos of fresh fish... whatever currency and in whatever amount you trust them to pay you back if owed to you) - likewise they are only connected to people they would trust.

Imagine there are two books - one is the BTC order book and the other is the debt record. When you buy bitcoin on the order book, you are paying with the credit granted to you by people who trust you to pay them back - all along a chain until it gets to the BTC seller. If you are owed money by your friends, you can collect it - if you owe money to their friends - they can collect it. You deal with BTC more or less anonymously (address to address) and with fiat on a friend-to-friend basis - if I'm understanding correctly.

Sounds like Ripple... except that's crippled.

the whole ripple idea and decentralized exchanges and hawala has my mind going around in circles. :(

I noticed that bitstamp charges a 0.20% on the IOU, if you are sending a large amount of money, would a bank provide you a better rate on the currency exchange. It seems like BoA does not charge you anything over $1000 when buying currency as they make their money on the spread.

For example I would like to do business in Europe. But I use my USD, in a decentralized exchange I am assuming through IOUs, I could be using USD the whole time. My challenge is, if I where spending a lot of money in inventory maybe even paying someone for warehouse space, etc. (not to mention any kind of business fees etc in the european country)

USD -> XRP -> Euro -> purchase an item (some how) -> sell the item with a mark up to make a profit and cover other expenses -> my profit is in Euro -> XRP -> back to my pocket as USD?

What are the (legal) financial gains from a transaction like this.

BTW... I LOVE THE COMMENT: "Rock solid plain HTML like 1995." Gonna make a shirt like that. :)

Exactly. Ideally, you don't always need to get hold of the actual money - you treat your ledger with your friends like money. Even though it is only fiat. You see, there is not much of a difference if the bank owes you money or your friend owes you money.

For example you buy a Bitcoin. At that point you owe a friend $568 (price at the time I write this), creating that money.  Later, you sell your used race bike for $600. At that point your friend owes you $32 and the $568 are destroyed.

This is exactly the same as the banks do: Creating and destroying fiat money. Should this catch on, we, the people can take the banking business out of the banks hands and the wealth the banks skim from us remains in our hands.

My hope is that some years down the road, people entirely walk away from the banking system and ZR only needs to support gold (and some other commodities) and Bitcoin. If the FED is simply forgotten, there is no need to abolish it, as Ron Paul demands. Dito for the ECB/BOJ/PBOC....

ZR has nothing to do with Ripple. While ZR could of course support XRP, they'd not be special in any way. If you believe ZR can help you with your business and what's left is the problem of conversion EUR->USD, I'd suggest to creatively use Bitcoin in the settlement process.

Wait a minute.... I thought we were meant to be avoiding repeating the mistakes of the bank?

From what I understand, it requires you put trust in people. For me, the strength of Bitcoin is that you don't have to trust people, if they send you the coins, you have the coins. In this system, what's stopping someone saying "okay, I trust Anu for $20" and then anu just not coughing up that $20 when required?

The whole benefit of an exchange, for me, is that I don't need to know anyone (other than the exchange) I can just send my money, buy some coins.

Also, based on reading user experiences, it seems this is even more reliant on critical mass for success, yet it's incredibly hard to get started with nobody else there. That seems a bit paradoxical. Have you any way to incentivise people using this? Also, if you're only streamlining relationships with friends, then why do we need this system in the first place? e.g. it requires me to say "I trust anu" but if I already trust anu, why do I need zeroreserve? Or is the main focus on trust chains formed including people you don't know (which would be hard to do manually arrange)

If the focus is on trust chains, wont things like adding bots as friends, or adding the pirate party as a trusted party be bad? I would have thought trust links formed where there is actually no real world 2 way trust, other than some guy in IRC saying "add this bot", undermine the strength and security of the entire system? And with trust chains, doesn't that mean that the whole networks trust or reliability is dependent on how trustworthy and reliable every single person in the network is (e.g. if everyone adds that bot, and the operator of that bot defaults on the amount people have naively trust it with, any transactions that do or have gone through that node - which would be a lot if everyone randomly adds it to get started - will be defrauded?)

I think the idea of a distributed exchange is good, but to me, this particular system has too much of an (unreliable) human element for trust. Although I may have misinterpreted all this.

The banks don't make mistakes, they are the problem. They are huge, centralized, fraudulent, corrupt power centers.


You have no reason to trust me. Do not grant me credit.

Bitcoin and credit money (ZR) are complementary - they solve different problems. The strength of Bitcoin is that it is zero trust. The strength of ZR is that it can replace the banking system's role in moving in and out of fiat.


You don't need to know the counter party. You need to know your friends.


As you state below, its about chains of trust. The purpose of ZR is to route payments through such chains without the need for anyone (even the friends) to know who the seller and the buyer are.

As to the critical mass - that is indeed the problem and if ZR does not achieve critical mass, it will die.


In the context of ZR, a friend is defined as "An entity you trust for X amount of credit". So in the context of ZR, your drinking buddy may not be your friend, but your business partner may be, even though you personally dislike him.

[EDIT] And yes - a friend does not need to be human. Can be an organization, a trading bot, or whatever.

But one of the benefits regularly touted about Bitcoin is that it's not a debt based system, because it's features of the debt based system that contributed to the various financial crisis. I can understand the purpose of it in the context of this system, but if I were you, I wouldn't market it as doing the same as the banks do, I'm not sure that will get you many supporters - at least on these forums. Debt based systems have bad connotations, at least for me.


That's my point though, Bitcoin doesn't require you trust another human. Once they've sent you the money, that's it. Again, that's one of the benefits of Bitcoin. With ZR, you have to place trust in someone, human trust in a human person which is fallible. Bitcoin removes with human element by implement trust using cryptography. Using ZR with Bitcoin, it's just another layer through which people can scam one another, but instead of it being one big centralized exchange scamming, it's lots of little scammers making it harder to actually get any resolution when you are scammed?
You said it yourself, the strength of Bitcoin is zero trust, the fundamental concept of ZR is you must place trust, the features of ZR negate the benefits of BTC.


There's a difference between knowing and trusting. But with chains, you're not just trusting that your friend will pay you back $20, you're trusting that they make good judgements in who they trust. E.g. I may trust my colleague to pay back $20, but what if my colleague naively trusts a bot to pay back $x, any transaction that goes from me through that bot (because of my friend) is relying on all the other people in the chain making safe judgements. So if one node fails (e.g. the bot doesn't pay up) all the transactions that go through that node will fail, right?

So the links between nodes are effectively defined by humans placing trust. Humans are the weak part of any computer system, and this systems seems to be founded on human decisions.


I understand that. But my point still stands, the whole system is founded on other people giving eachother accurate credit ratings - something that the banks failed spectacularly at despite lots of experience. What makes you think the average Joe would be any better at it? And what are the implications of wrongly placed trust? E.g. what happens if there's a big financial crisis again, and all of a sudden everyone has less money available, so all the links between nodes in the network are effectively wrong?

It sounds like it could be a workable system maybe, but I can't help feel a lot of the requirements of users seems to contradict what Bitcoin users would want to do (e.g. debt based system, trust in humans, undocumented off-system transactions)

You make it sound as if the purpose of Bitcoin is to remove all need to trust. It is not. Even in a pure Bitcoin financial world, you need to trust and there will be credit.


It will always happen that people abuse trust. The implication is that you lose that money. So don't trust anyone with amounts you can't afford to lose. I believe that the losses you take with such fraud will be way below the inflation tax and the interest payment to the govt-financial complex.

For now, ZR is only meant as a way to exchange Bitcoins, should govts crack down on the centralized exchanges. It may evolve into a large credit network - I certainly hope so. But it does not have an incentive to turn everyone into debt slaves, as the banking system has. Because of that, I believe it is not prone to create such crisis as the banking system is, with all these wars which are financed by the printing press. And yes, I believe the average Joe is pretty good at rating his friends. I also hope that ZR helps to educate people about what fiat money is, and how it can be used for your benefit.

Of course ZR is no panacea. It is a tool. I can only offer it and people can accept or reject it. Just like Bitcoin. Just like Linux. I certainly hope that people will try it out and help evolving it into something great. If people choose to continue to place their trust into the govt-financial complex instead, I can at least say that I tried my best.


It is well enough that people of the nation do not understand our banking and monetary system, for if they did, I believe there would be a revolution before tomorrow morning.
[Henry Ford]

Hey anu, cool project, congratulations!  It's great to see other implementations of the Ripple concept, and that you are here explaining it to people.

Maybe this will help explain why Ripple is an improvement over exiting debt-based monetary systems:

http://archive.ripple-project.org/paymentrouting.pdf


I think Ripple (in whatever implementation) and Bitcoin complement each other and will grow better together than separately.

Sounds very promising, but I'm missing one crucial point:

Alice has 600 EUR, and she wants to buy a bitcoin.
Bob has 1 BTC, and he wants to sell it for 600 euros.

Classic exchange scenario: Alice sends her euros to exchange, Bob sends his bitcoin to exchange, they both place an order, get eachother's money, withdraw it, everybody happy.
Obviously, they have to trust the exchange in this scenario.

ZR scenario: to whom or where does Alice send her euros, and to whom or where does Bob send his bitcoin?

Euros:
Alice->Friend_1->......->Friend_N->Bob

Bitcoin uses a 2/3 multisig TX where the 3rd party is an (optional) escrow:
Bob->Alice

Again, let me stress that the payment is largely anonymous: Friend_1 does not know that Alice is the buyer. Friend_N does not know that Bob is the seller. Alice does not know that Bob is the seller, and vice versa. That is even true in the case that there are no intermediate hops (Friend_n)

OK, but does this mean that Alice has to trust Friend 1, and also Friend 1's trust in Friend 2, and Friend 2's trust in Friend 3, etc? Because Alice may be careful with who she accepts as her friends, but someone else down the chain may be not as careful (not even untrustworthy, just uncareful) and have an untrustworthy friend.

Even simpler: can Bob somehow claim he didn't receive any euros yet, even if he did?

I'm not very familiar with RetroShare yet, but I noticed some people posting their public PGP key in this thread. Would somebody adding their key imply that they become friends? Because people here are obviously anonymous, there's no real way you can trust random users on a forum. I'd say in order for this to work, you'd have to be very picky (and trust others to be picky as well) when choosing friends?

Right, that is a gap in the chain on the fiat side. To close it, I am using a 2/3 multisig TX on the Bitcoin side to make the whole TX water tight.


I am accepting all friend request on the Retroshare identity I posted at the beginning of the thread. I am far more selective with my "real" Retroshare identity. And even on the "real" identity, not every friend will have credit granted: ZR friends are a subset of Retroshare friends.

Hey Ryan (I guess its you?), many thanks for your encouragement and the link! Great to have you here.

May I use the opportunity to ask you about some history? Has the Hawala system somehow inspired Ripple? How would you compare Ripple and Hawala, aside from the Hawala network being run manually?

Also: Have you ever considered interfacing to any Hawaladar?

OK, I've read the intro post and the tech paper. I still have some questions, forgive me if they're really stupid, but I hope someone has the patience to explain it.

What a user mostly is interested in is to exchange bitcoin for fiat money and the other way around. So he uses an exchange. And he can either buy or sell bitcoins on that exchange, and he can either deposit or withdraw fiat money on that exchange.

Now, talking about a desentralized system as in this case Zero Reserve, I understand it in the end gives pretty much the same result, and that instead of storing fiat money on an exchange, you store IOU's (I owe you)'s in the system? So, when you actually want to say pay your electricity bill you need fiat money, and you can aquire fiat money by exchangig IOU's for fiat money?

OK - perhaps this was poorly explained, but if someone can explain to me in simple terms how the following will take place:

1. I want to buy 2 bitcoins. Do I first set in a buy order, and then get matched by one or several parties, and then have to split up or pay in a single payment the total cost to some person in the system? What guarantees are there that the payment will actually be honoured and that I will receive the bitcoins? I see from the paper that there's a escrow system. Will payments be matched locally, so bank transfers will take place within the same country, or if there's a cash trade, within the same city? Is there any problems or types of scam that can occur here? And also, do I receive full bitcoins, or are these only stored in the system somehow?

2. When selling bitcoins, they're exchanged for IOU's. The IOU's are stored in the system and later exchanged for fiat money, or might be used to purchase bitcoins again? What are the IOU's stored as, and what do they represent, are they tied to the dollar? I assume it's your counterpart(ies) that issues the IOU's? So, if say you live in germany and you had a match in the US, then the US person gets your bitcoins and you now hold some IOU's? You can then exchange the IOU's for a bank transfer within Germany? So you then send the IOU's to another person in germany, and he then sends you fiat money, is that how it works?

So, in theory it could work like this:


I purchase bitcoins at one point. I enter an order, say buiying 1 btc for 700 USD. Someone matches my offer, but since I live in germany, there's no point being matched to someone in the us? Ok, now I have an accepted order, and the price is tied in at 700 USD. I get bank details (how are these transferred?) and send 700 USD to this person. He then sends me 1 btc after receiving this payment. Some days later, I decide to sell my 1 BTC, because it's now worth 800 USD. So I have a match, and I get issued 800 USD IOU's? Then I could trade this back and forth to my hearts desire, but eventually I want to withdraw. Can I withdraw by sending bitcoins directly to someone in the system, or does it always need to  exchanged for IOU's? But for the sake of the discussion, let's say I have now 800 USD IOU's, so then I place an order for a fiat withdrawal, is that so? So when it's accepted, someone is matched and I send the counterparty my banking details, and then he sends me 800 USD? Are the 800 USD IOU's then destroyed? How can it be ensured he actually sends the money, and what if he claims to have sent the money, but I never received it. How is a dispute solved?

What pitfalls are there in such a system and can there arise any 'deadlocks' ? And who's going to be the arbitrator, and who's to appoint the arbitrator? Can people loose money in this system? Can it be hacked?

In general I think a p2p exchange is a brilliant system, but the weak part always seems to be the fiat to virtual currency exchange. I've thought of a system with 'agents', and then you had to appoint trusted ones. So I guess this is a bit similar to that?

And what if someone breaches the trust in the system, how are they punished, are they removed or barred? And what prevents them from entering the system again as a new user, doing the same kind of scam again? And who decided who is to be expelled? And who appoints the ones with the power to make such decisions?

Very interesting concept, and I'm trying to wrap my head around it, to understand it, and to see if there's anything in the system that can be exploited that needs to be taken into consideration.

A p2p exchange where it is straightforward to both buy bitcoins, and extract fiat money must be the absolute perfect desentralized system! Banks can't even know that they're part of it, at least not easily. Still any user should have a dedicated bank account for this in a bank separated from his ordinary financial dealings, as payment for fiat in the first place still is suspectible for fraud (e-bay scam) etc.

Thanks for any insight that you might provide. This thread is very interesting. There's been attempts of a p2p exchange before, but it semed to die.

I got you, and thanks for your response... so in the case of ZR the middle currency can be BTC or anything. (remove the XRP) And I only mention ripple because it has a similar infrastructure of the IOU idea. However your idea is more pure and does introduce a new currency. It just uses its own system.

I have yet to get the exchange setup (a bit intimidated by the procedure for Windows)

No, but as you said, as we both agreed, one of the big strengths/salepoints of Bitcoin is it puts the trust in numbers, in cryptography. Adding another layer on top which puts trust in humans negates the benefit of Bitcoin.

What makes you say that?
Also, that's a big problem with debt based systems: they work well if you know exactly how much money you're going to earn and spend the rest of your life, but in reality, things happen, medical bills, economic problems, house fires, all these sort of things can ruin a person in debt, and their debtor.

I appreciate that, I wouldn't ever want to discourage someone from experimenting, exploring and tinkering with things. I envy you for having the commitment and courage to move forward with things like this, by all means, proceed.

I don't think I understand the system fully though. Could you clearly explain, what happens if Alice buys 1 BTC of Bob, but in the sending of the fiat down the chain, one node is dishonest and doesn't forward the fiat, but pockets it instead, what effect does that have on the chain, and who loses money and how is dishonest behaviour punished?

There are various studies about consumer interest payments coming from various angles. The thing is that virtually all money comes from debt on which interest is due. Even if you yourself are not indebted, you still need to pay interest which is hidden in the price of products, services and taxes.

There was a study for my home town (Munich/Germany) about that. With a fairly typical life style you need to own about EUR 2 Million to break even - taking a profit from the debt system. Everyone else is a net interest payer.


The transaction will not proceed and will time out if he tries to keep his ledger in sync with his friends but does not stick to the protocol.

If he chooses to stick with the protocol, but simply does not update his ledger, then your ledger will not agree with his. The next time the nodes try to reconcile, a QDialog will pop up, telling you that something is wrong. Your friend will find from his TX log that his ledger is correct and yours is wrong.

As you see, you can't cheat that way without getting caught red handed either immediately or shortly thereafter

As said, ZR is relying on Bitcoin to prevent the seller from cheating: A 2/3 multisig. First the seller must place the Coins out if his reach, then payment is made, then the seller releases the coins from escrow.

Its similar to the torn bank note. The escrow is necessary because there is a possible attack vector if its only 2/2: You can initiate  a buy on the entire order book and then simply walk away. Doing so must be costly.

Is it really even necessary to eliminate the risk of a failure in the trust chain?  I mean, if I owe money to Alice, and I'm planning on paying it back with money which Bob promised to pay me, but Bob fails to pay in time, I will still pay Alice, because Alice is a friend. I may not trust Bob in future, but I certainly don't want Alice to cease trusting me.  Then I'd have no hope of escaping the friend-zone.  A major reason hawala networks work is that the participants are willing and able to cover for each other to some extent.  Bob's mom needed a hernia operation, so we all deferred his obligations, lest we be deemed heartless bastards, and since who knows when your own mom is gonna get a descended...whatever.  That distributed compensatory mechanism is what makes the network anti-fragile.

That is how it is supposed to work. There is no need to settle all debts all the time, just like in the banking system. In the banking system, they went so far as to make settlement almost impossible, after they started to de-monetize gold. What does "settlement" really mean? You swap a debt obligation of a friend against a debt obligation of your bank. Calling this settlement is IMHO a joke.

A breach of trust doesn't happen during a transaction. The way it happens is this: Someone uses all available credit with all friends to the limit and then refuses to recognize that debt. That default would remain local - it doesn't affect the network. Its no different to paying your friend's bill in a pub because he forgot his wallet and then the friend later refuses to pay back.

I guess the amount of credit one would be willing to extend to someone depends on the amount of other credit already being extended to them.

Does that sound reasonable? Does Zero Reserve take this into account somehow?

ZR does not know the credit of friend-of-friends. But yeah, that will be the rule: I guess Bill Gates and his buddies won't even bother to open the Credit Dialog for a mere $1,000 while college students would consider it irresponsible to grant that much credit to their friends.


Its definitely reasonable, but ZR does not make any efforts to encourage / enforce responsible credit granting. As said - you know how much credit your friends grant you, but you don't know how much they grant each other. It is the philosophy of ZR to keep data strictly local. So ZR's ability to do so is very limited, even if I thought it a good idea to try - which I don't.

I guess it is about the arrows pointing away from Bill Gates (i.e. to those extending him credit / receiving IOUs from him).

Presumably the people to whom those arrow point don't need to be friends with each other and so know nothing about each other.

It would seem injudicious to make a decision on how much to lend someone without knowing about their other liabilities (a bit like what credit reference agencies facilitate banks in doing now).

Interesting. Watching.

How are things going?

Thanks for asking. Here is the status:

For now, libBitcoin has been repaced by the Satoshi client. I am aware that this is not the best solution, but for now, I need a working testnet mode and I could not make this work on libBitcoin. Before I even think about releasing something that deals with real money I need to make sure that it works with reasonably large networks with bogus money.

The wallet can't do much at this point - it simply shows the total balance and the balance of the addresses. But a "proof of concept" release is getting very close now.

Anu: did you see this on reddit:

BitMarket
over bitmessage.
http://bittext.ch/8wApvESl6y

Very interesting idea. If I understand it correctly, this is a de-centralized Bitmit. I am not understanding how they deal with fraud, however - solving that problem is cruicial. Also how to deal with Vandals who just call it fun to disrupt a system? If they can solve this, they are a very serious competitor to ZR.

I am not entirely happy with my solution to the Vandal problem: I put a price tag to DOS attacks, but for someone who is willing to pay the price, they can do more damage than it costs them.

But then, maybe I am taking it too serious. Seems like nobody attempted to DOS the Bitcoin network so far, even though it seems quite possible.
(Some people called Satoshi Dice a DOS attack....  ;D )



EDIT: I called them a potentially serious competitor. That does not mean I don't welcome this. My purpose is to help making the Bitcoin ecosystem immune to Govt/Bank action. I applaude everyone who does the same.

Ideas to share accross the board.

That could be very interesting.

I would very much like for bitmessage to become more popular and services on top of it will certainly help.

There is now a bounty for making libbitcoin work on Windows:
https://bitcointalk.org/index.php?topic=358298.0

I added a bounty to make testnet work:
https://bitcointalk.org/index.php?topic=358298.msg4560062#msg4560062


It seems that it was a good idea to make the Bitcoin implementation a compile time option and separate it with an abstraction layer.

You could also investigate doing what the Hive folks have done, and use bitcoinj via JNI. There are tools that can autogenerate JNI wrappers into C++ to make the bindings easier. bitcoinj supports not only testnet but also regtest mode in Bitcoin master, which lets you run a private testnet where you can mine blocks instantly. I've switched to regtest mode for most of my testing, it eliminates waiting for blocks or trying to find faucets completely.

First successful "Trade". The Biteasy Blockexplorer shows the associated Multisig Address on the TestNet:
https://www.biteasy.com/testnet/addresses/2N4w1rAVcQ4gWSm3h34w6YJeC6AkZEDEkYc

Curious, how do transactions sent in at the same time are handled?

What method is used to verify that person A's transaction came before person B's transaction? Assuming that they were both sent at the same time.

This is likely the one of the bigger issues when verifying an exchange transaction. Collisions will happen and dealing with them is tricky.

Let me know. Thanks

First come, first serve. Messages are bound to come in serially, even if it is just milliseconds, because they come through the network stack. An incoming message causes reservation of an order, or a part of it. So there are 3 cases:
1. Both requests can be filled, NP
2. The first request gets filled, the second one only partly
3. The second request can't be filled - the seller sends a VOTE_NO message which causes the TX to TransactionManager::abort().

ZeroReserve very much looks like an exchange, GUI-wise. But under the hood it is OTC. Reason is that every ZeroReserve instance maintains an order book and does the matching. Orderbooks of different nodes are bound to differ.

great
Will try the latest version.

OK, the latest version does not crash any more on win32, seems stable so far. I had to remove the -rdynamic option from zeroreserve.pro, though.

I'd like to buy a tnBTC for 500 zimbabwe dollars!  ;D

That's the catch: You need to give credit *in Zimbabwe Dollar* before you can sell TnBTC for Zim$. Orders are not propagated to a hop unless they can at least partly be paid for.

As we were using mainly "Fools Gold" for testing so far, the Zim$ network is too sparse. That's why it didn't arrive here.

Hi, anu, is there a new version of whitepaper?

I absolutely have to update it. The Bitcoin  TX evolved very far away from the whitepaper. It is now a contract: Fiat is transferred when a Bitcoin TX with an agreed upon TXID has 6 confirmations. So it is the Bitcoin network itself that triggers the final commit. Which makes the whole thing ACID provided there is no fork deeper than 6 blocks. No need for multisig.

Looking forward to the new version ;D

Ripple touted as decentralized http://www.coindesk.com/fidor-becomes-first-bank-to-use-ripple-payment-protocol/

Does this project lack marketing leadership?

We need to roll out a TestNet version first. That will happen very soon. Everything works already - under ideal conditions. What I am currently doing is making it work under conditions that are not ideal (a node goes away, credit is insufficient...). I hope we can get 20 or more people to participate in TestNet runs to iron out the last wrinkles. Once TestNet runs smoothly, we will roll out a first production version. That will be in a few weeks. At that point, some evangelism would be most welcome.

In the meantime, what everyone can do to help is:

• Install RetroShare and the Satoshi Client (TestNet)
• Friend Nabu and get on the ZeroReserve Chat group in Retroshare
• Play with RetroShare and ZeroReserve - find bugs

I think the shenanigans around the centralized exchanges showed that ZeroReserve is much needed - particularly the "ban" in China. As said, a running Zero Reserve network will prevent Western government from any ban because all that would do it to drive people from Bitstamp to Zero Reserve. All that doesn't mean Zero Reserve will ever take off - it may spend a zombie life in the data tomb or Github. So yes, "marketing leadership" is lacking.

So how would this work? Would two people find each other on the distributed "Zero Reserve"-exchange and then person A would make a bank transfer to person B's personal bank account, and person B would in turn send XBT to person A's bitcoin address?

Wouldn't that raise a flag and make the bank freeze the bank account of person B for receiving let's say 20 000 USD from perhaps 20 different people from all over the world? Yes, this would be better than using a centralized exchange, but would probably be troublesome for larger transactions.

No, that is not how it works. Like with Bitcoin, "getting" Zero Reserve takes a leap of faith:

Many industries do things you can't do in your basement . Their products require a lot of knowledge and potentially expensive machinery to create. That is not the case for the banking industry. They aren't doing anything anyone can't do. What they do is: They grant credit to those they consider trustworthy. If you use this credit, fiat money is created. You can do that, I can do that. Everyone can do that. The thing is: You don't even need money to grant someone credit - the banks do not have money, either. Banks are not required for a fiat remittance system. This is the dirty secret of the banking industry. Once you understand this, you have taken a step out of the Matrix and freed your mind.

I was writing up an outline of how it works here:
https://github.com/zeroreserve/ZeroReserve/wiki

Currently I am updating the paper for those who are interested in the details of protocols and why it works even in an untrusted environment. You can take a look at it as it is now but keep in mind that this is a work in progress:
https://github.com/zeroreserve/ZeroReserve/wiki/zeroreserve.pdf

Did  the project launched?
I wait for a long time, I remember it  was there last year.

Zero Reserve 0.1 is now pretty much feature complete. It is time to do some testing. Please join tomorrow, Monday, 18:00h UTC. No reason to fear losing money - we'll just trade TestNet Bitcoin against fools gold, Zimbabwe Dollar or German Papermark (1923).

The install procedure is outlined here:
https://github.com/zeroreserve/ZeroReserve
at the bottom of the page.

Installing ZeroReserve is not enough, it needs some setup, which is described in the Getting Started Page (https://github.com/zeroreserve/ZeroReserve/wiki/Getting-started-with-Zero-Reserve)

Please start well before the test tomorrow - it takes some time to download the TestNet blockchain and we also need to establish the friend relationships in Retroshare. You might also want to get some TestNet Bitcoin through a faucet beforehand.

I created the windows installer as linked from the readme.md https://mega.co.nz/#!MVIykABI!fFkRbtdOQDfrIKc0Kke2yfFpS6T17z7q6YxelQ6BJMc
I did build both Retroshare 0.5.5 (7062) and ZeroReserve from scratch using the latest OpenSSL version (1.0.1g). I used ZeroReserve code from https://github.com/zeroreserve/zeroreserve (as of 2014-06-07).

Looking forward to some decentralized trading  ;D

Hmmm.....it does look like people are more into the Ripple-style IOUs, then really solving the banking problem. ::)

Installed it, tested it, used it. I made my first deal and it works!
EXCELLENT JOB !!!  :)

There's a difference here: you don't owe to some huge corporation but your friends. Also ZeroReserve uses Bitcoin instead of XRP. IMHO ZeroReserve has great potential to improve Bitcoin's exchange situation.

For many people, the problem is they are owed by some huge corporations, it's not like when it comes to debts your friend is exactly more credible than some huge corporations. Also, if the debts can only be exchanged between friends, why not just go buying bitcoins from them with cash/bank transfer?(especially the assumption here is you already trust them)


Does that mean I have to have some bitcoins before I can trade? That doesn't sound really ideal.


Exchanges are designed to facilitate trades between strangers, especially when it comes to large amount trading. Also there are other alternatives, but nobody pays attention.

No, you can buy Bitcoins without having any.


That is what ZR does. Even if you do buy from a friend, you would not know. Every deal is "remote",

Zero Reserve is somewhat hard to explain - you need to use it. Just get the code and everything will fall into place.

So I will buy real Bitcoins with these IOUs I guess?


So when saying 'friends', what you exactly meant is 'retroshare friends'?

Zero Reserve friends is the subset of RetroShare friends who you would grant a credit OR who would grant a credit to you. (Zeroreserve does not assume that credit is mutual)

Thanks, so I guess you have something similar to Ripple's 'trust path' then?

Right - this is the original Ripple / Hawala idea. ZR has nothing whatsoever to do with Ripple Labs, however. ZR differs from the current incarnation of Ripple in that it is tied to Bitcoin, not to XRP. Nobody has a special role in the ZR network.

*watch*

The first line reads like an insult to a lot of people's friends. I'd trust my friends more than anyone or -thing I don't know as well, including but not limited to corporations.

I think it's important to formalize trust. Just because there exists some complicated transaction using firends' trust, few would execute it by hand. If ZeroReserve manages to simplify this process enough, it becomes preferable to trusting an ominous entity that tends to eat your funds in one big bite -- like Gox and the numerous other failed exchanges.

Banking -- the trade with IOUs -- is actually quite efficient. It mostly fails on the wrong places piling up trust. If trust becomes more explicit and less reliant on magic entities doing magic things with trust they implicitly get, it's a great approach.

I could agree with you or not, but it's a fact of the world that many would rather trust their money with banks, then with their friends.

Also, under the assumption that you trust your friends, there are still other ways to conduct the transaction, just wire transfer money to your friend using online banking, and ask someone whom you both trust to escrow the bitcoins/audit your wire transfer, such a process is formalizable as well.

Further, if you can have a cryptographic proof of transfer, why the need for IOUs?

I understand your feelings here.
Alas, don't underestimate the thousands of lurkers here! I, for example, didn't contribute a single word here, but am following closely. This time, I didn't feel like actively testing the system yet, the shock of what ripple turned out to be was too much for me I guess..

There are 35k views here.
It will gain more momentum when people actually play with the code.
This one will have, and has to have, an even stronger network effect than Bitcoin itself.

Thank you for what you are contributing to this world.

Ente

Zero Reserve is not Ripple and cannot be. There are no f***ing strings attached. The code is 100% OpenSource.  There is no special entity in the ZR network. There is no ZeroReserve Ltd. This is a communitiy thing, but so far without community. There is money to be made with ZR, too, but like with Bitcoin mining, anyone can. There is even an early adopter effect.


The code is there (https://github.com/zeroreserve/ZeroReserve) to play with. It's quite easy to install. And for Windows users, there is even a install wizard.

Ich kann die Pferde nur zur Tränke führen. Saufen müssen sie schon selber.


Network effect is indeed the key word.


So far I haven't contributed anything, because so far, there are no takers.


Should the test run fail due to lacking participation, I will take that as a vote against truly distributed, OpenSource Exchanges and for the control of Bitcoin through the corporate state. Consequently, I'll withdraw.

One of the lessons learned from bitcoin is that the main driver of adoption is capital formation based on scarcity, basically rewarding early adopters disproportionally. Bitcoin would have probably suffered the same fate as ZeroReserve to date if it weren't for the concept of an arms race.

I still think this project has tremendous merit and would encourage every capable person to look at it and try to apply it to their economic framework. I am myself guilty for not following up on the peaked interest a while ago - there are many excuses but as pointed out above, excuse is irrelevant - what matters is reward.

So to move this discussion a bit ahead in what maybe the right direction, would you please detail how the reward system in ZeroReserve works and how it would facilitate adoption?

Your work and your contribution is truly appreciated.

The routing of payments can carry a small fee. This fee is currently set to "0". the plan is to enable fees and let the market regulate them once Payments can go through multiple routes, so nodes can choose the cheapest route. The more payments you route, the more you earn.

I expect the network topology to move outwards from a "kernel". As the network grows, these nodes at the topological center are more likely to route payments than newer nodes. That is particularly true if you developed strong business relations with your peers and have substantial credit. Large credit makes a route more likely.

There is also the fact that credit is not necessarily symmetric, not even mutual. Participants may know you and grant you credit, even though you don't know them and therefore do not grant them credit.


There is only one way to show appreciation. Follow the "Getting Started" guide (link in the signature) and send your Certificate to
3f40a66fa91aba29487cc6ac938d0687@ns3.ativel.com


In case anyone wonders why this email address looks weird - the email is going into the Retroshare Network, where it is untraceable. The mailbox is actually a Retroshare GXS ID. There are other reasons to install Retroshare than just Zero Reserve. Untraceable Email is one of them.

Would you be interested, if producing a cryptographic proof for a bank transfer, is actually possible?(e.g., if banks start supporting digitally signing bank statements)

If you want to make the project self-perpetuating I am afraid there needs to be a disproportionate reward system. Compensating on a fee alone doesn't provide enough incentive. It needs to compensate for the asymmetry in the network effect: Those who join now need to be rewarded 10x more against those who join when the network is 10x larger. The way it looks right now is that this is not the case, as the reward seems to be not dependent on the time you join the network, but merely on your "personal" network, which you can develop at any time. Failure to understand rewards and network effects means failure to accommodate for human complacency and brain chemistry.

That said - how could ZeroReserve introduce such a reward system? Without the concept of scarcity of a shared token, as in bitcoin, the only other perceivable way is to borrow from pyramidal schemes, where older nodes benefit from the addition of newer nodes. Of course that doesn't extinguish the evil of rent seeking.

True. Actions > words.

Bitcoin made millionaires of people who bothered to invest a few CPU cycles, true. ZR will not be able to repeat that. But then, the risk was very high that Bitcoin would not go anywhere in 2009/2010. ZR would be useful at a relatively moderate network size.

Then there are the other advantages, for example that a Bitcoin purchased with ZR is no longer tainted as one withdrawn from an exchange is.

This.

Change is just a bank run away :)

With ZeroReserve you can trade with strangers by only having to trust your friends.

There's always to sides of a transaction. It's difficult to computationally enforce transfer of non cryptographic currencies and assets - but you can easily transfer IOUs with people you trust.


Maybe a list of features and a FAQ would make it easier to understand ZeroReserve.

I'll start with my current point of understanding:

1. Trade Bitcoins with strangers connected to you through chains of friends.
2. It is relatively anonymous (as long as friend chains don't get guantanamoed). Note you can also be friends with your imaginary alter ego.
3. All IOUs are direct-friend-IOUs.
4. IOUs can be pretty much anything (Dollars, Euro, Gold, ...)
5. To be able to trade you need to mutually exchange Retroshare certificates and grant credit lines in ZR to at least one friend.
6. For now to be friend with the Retroshare node "nabu" helps connectivity (bootstrapping).
7. The more ZR-friends the better as there will be more routes to exchange through.
8. Giving more credit to friends helps trading but is of course a risk.

edit:
This is in a little less than two hours from now:
To give the testing a more realistic feel I suggest we all consider the default IOU "µg of fools" to be worth 1 USD.

Effectively, the Ripple trust path does this by going through someone you both trust, so it's not really different from having that someone escrowing your bitcoins, and at the same time audits your fiat transfer, isn't it?

You don't need to really enforce the bank transfer, you just need to verify that it has happened, before you release the escrow.

I was replying to phelix, not about your design, which I understand perfectly.

Interesting project to be sure.  Will be trying to get a rig setup this evening to give it a quick go :)

great job, I will try it.
I come from china, maybe Chinese need it.

I don't know - it may fit better to Chinese culture and attitude. I've heard the argument quite often that boils down to: "I trust the banks, but I don't trust my friends / family."

I'd like to focus on something else: Bitcoin currently has an Achilles' heel that puts it on the mercy of the government: The exchanges. Being at the mercy of a competitor is usually not a good idea. No idea what is really to blame for the MtGox desaster, but I fancy to think it all started with the theft of 5 Million Dollar by the US government. Then look at the Chinese exchanges - they are forced to live day-by-day and whatever "Rule-of-Law" exists in China, it does not apply to Bitcoin exchanges. Should the Brits choose to shut down Stamp, we are in serious trouble!

And you know, it does not need to be an official shutdown. It is sufficient to harrass them with bogus allegations like money laundering, rape, child porn or collaborating with the Russians (this one has been out of fashion for 2 decades, but will see a comeback). It really does not matter that it turns out after a year or 2 to have no substance to it.

With an operational Zero Reserve network, attacking Exchanges becomes counter productive. It is possible for govt to trace and tax Bitcoins coming from an exchange, while every Bitcoin that comes out of a ZR trade has been anonymized. Governments and central banks may wish to shut down Bitcoin exchanges, but not if something much worse (from their perspective) would replace them. A working ZR network offers an insurance against government crackdown.

I think I should (finally) try this out, too.  If I can get Retro Share & ZR up and running, expect my friendship request soon. ;)

+1, it's my project for the coming weekend!

My certificate:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

xsBNBFOYrYMBCACfRcj9nJnKh3xzHRdDE38v4KeqvhJhcbaMMawupHqKRlTVXd2I
yWwzCxoes6e4k1RDHgtgiComgUw1Sp2JUaP2dr2vQvtPAf/10F8RYOyP0e47Fhdr
aptoSWZprQGP43Fe/RNCtRqwSuIptmqyn04IAoMCQ68GB2CX2JajzH27CiUZxxY8
FE3vWluwqn63Wzb2hhoreAIVJsPLbNrIdhGOPJExlRwo3cTUyogWhbW7ae8PzC46
c4h5nfgZYL6YHxuOT+Hhw6GvlfUZnGgN5ItqiT7AxgQghveuXRIB1MxUJl7fakhE
vNljdeNZxzrVe1kP9WG5EIXxT+8j2R7mSd//ABEBAAHNKURhbmllbCBLcmFmdCAo
R2VuZXJhdGVkIGJ5IFJldHJvU2hhcmUpIDw+wsBfBBMBAgATBQJTmK2DCRALOHnW
4TY0UgIZAQAA1WsH+wRk5L60aFiEaXzxqc4+Aax8FxG6OIewrESUMuPLiICYJJlQ
lYBx30EFehdIGlEDFjKDPe0SIsQGLakx70gGH5WQoYqtR4W6OsfQdnIMv1Z5mGaj
Snn4hEI2EwQhcOdVBHqO5486Ld1Y9WuMPRPNCzT/U0OiYjvUVugIAQR8/NBB3lE5
kEnxzDHqS4h1Y0Gq1yYPkKL6yKSfOAQc6vmt9UzFwguAx3ySdZ60AicwZm2P4xUT
wcnGKlm9AYBvQ4sbRAcmTLe1D1J5fakISpbgpvxGmtYFjlr32OgLk27JQTfnGvmx
HTmC4fpcu4+NHYfKU1RV9j+HHk2Yzcg0S2hAQMY=
=UAE3
-----END PGP PUBLIC KEY BLOCK-----
--SSLID--8b47ffb8ed5211ea9a35711e2a4be7f8;--LOCATION--Graz, Austria;
--LOCAL--10.0.0.7:23304;--EXT--0.0.0.0:1024;

done

"A distributed Bitcoin Exchange" Will do with the currency exchange, like USD, EUR.

A site with the word "center" in the name spams in this thread, how cute. Anything centralized really is a design error. You made my day!

Thanks. What about another test drive?

So how would this work? Would two people find each other on the distributed "Zero Reserve"-exchange and then person A would make a bank transfer to person B's personal bank account, and person B would in turn send XBT to person A's bitcoin address?

Did you read the manual?  ;)

I'd take part this time, since this project looks really good.  (Of course, assuming that I have time when the test drive is done.)

Last test drive I figured out how to do it automated. When the automated tests run smooth, we'll do one on a release candidate.

The seller will never know who the buyer is and vice versa.

Your problem is that you think there is something special about banks. This is what distinguishes banks from companies that do good stuff like Porsche or Ardbeg: Really anyone can do what banks do. You don't need a bank to transfer, create or lend money.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP:SDK v0.9

xsBNBFOf/BkBCACusWfPKzgF+oHkdXQM+Ma0ttvHRf+c1a8qRVFZnWP2TDI5tmnX
pr7uoflarr9/zsReequ65X2tZ4Qrka8VpfcNIX/vf3PH29LHX0QhU+yhQBUtwuSX
KsAL6MnR/GaKyiIgsiFkNWoJ7aHZlU2zc8SBGGDzfc4VnzNzKz/ioqT50fiX7JWC
xBBGgrBaufQ2E73G6J+onfHp/n6q5YuNzaTgZ/c5i3xfGd2AMb8Uvnh6cMFDfI4C
4lu8mI9ZGbOvuYcHzKrUQ0eolSEi+b+RMMKmXue8nrzyUzqnyj08GG81c4K+PoKn
JWui1zSY12TFLNpjgJliSe/iyhvRWyuDO9XvABEBAAHNIk5ld2FyIChHZW5lcmF0
ZWQgYnkgUmV0cm9TaGFyZSkgPD7CwF8EEwECABMFAlOf/BkJENa3MLR/E23QAhkB
AAAryAf9FdJZAZSCZy1CqL7zhpLTx8FqcVY5kvGqaK6hkwW98YYdtG/1+4I5qL14
qs7/duPRSoBuqK6yeheQEtQiUZCwYVbuP4aFsTmVpUSCSJFp//DXdK6p0clAtLoh
UdysyEzLA9Zd43Jz5//TfAGqZ9aDKlO3CAuXR6PRUH+UawT9GUvLeLqBLA896JSI
r2hMQe/tJhWlfPzasvsStP6vJrYQjNDu9pHfJzBJLgbDjmNJ5zB7TS8kWD/7g5gq
i6Py+9ONTr6sNAnWG8KmnUBIpxSX8Ixzbm9FsYo8LBHZUebdxaXXmmAyLUapnAwZ
PU9eyOWebrZGtvJuRKNjmZWUaR7gUA==
=gvzc
-----END PGP PUBLIC KEY BLOCK-----

Added.

All: Please always add the location info at the bottom. RS can connect anyway if your DHT is working, but that may take forever and longer.
[EDIT:] This reveals your IP address and thus your geographical location. If you don't want that, PM me. RS 0.6 offers TOR support for the extremely paranoid, but we're still on 0.5.5.

Also: Credit is location dependent. As long as there is only a name but no location, I can't grant credit.

PM sent.



Where do I find this GXS ID? I tried to send to various numbers I could find in my profile, but none of the emails made it through to my Messages panel.

Its in the upcoming 0.6 release of Retroshare - you won't find it in 0.5.5. In 0.6, you can simply create them under "Identities". Sorry for the confusion.

Also, at this time, the SMTP <-> Retroshare gateways are very limited, for example they work only one direction, from SMTP->RS. We're currently moving to SMTP/MIME as message format (not for transport, obviously). Once this is done, the gateways will work both directions.

edit: public key sent by pm.

How are things?

Anu told me that he is quite busy with some other important matter but that things look good and he is looking forward to the next test round (should be the last testnet round ;D).

Looking forward to another test run

I tried adding your PGP block, Anu, and it fails.  I have to strip out the pre and post parts to get a green check mark.  But, then when I hit next, it fails with "Unknown section type".  

I heard RS changed the key format.  Do you have a new one I can try.  

EDIT: After catching up,  saw you were on 0.5.  Are you on 0.6, yet?  How's ZR coming along? 

I tried installing ZeroReserve on Xubuntu 14.0.4.2 and get the following error.


Also this decentralised exchange may be best suited at intra altcoin exchange to and from bitcoin.