[ANNOUNCE] Zero Reserve - A distributed Bitcoin Exchange

[anu]

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

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 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.

[1714168901]

1714168901

[1714168901]

1714168901

[1714168901]

1714168901

[phelix]

Retroshare based Ripple without XRP and without premine 

Will try the latest version.

[anu]

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

[greBit]

RetroShare (retroshare.sourceforge.net) is a prerequisite.. If you are not a user of RetroShare yet, recent NSA revelations suggest that you start now.

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/)

You’re right. Forward security; we’re working on it. We will probably have a solution soon.

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

[phelix]

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

[anu]

It should really be marketed at users who want an alternative to Facebook

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.

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

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.

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

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

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

You’re right. Forward security; we’re working on it. We will probably have a solution soon.

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.

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

 

[greBit]

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.

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.

[Jutarul]

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.

[anu]

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

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.

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.

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.

[killerstorm]

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).

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.

[klaus]

klasse anu !

[virtualmaster]

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

[becoin]

A tech paper is here:
https://mega.co.nz/#!vZ80yQJS!ccrCBREYZrOPr8oK7C9StVGuDmYENNYwrFiPXZVQldM

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?

[phelix]

A tech paper is here:
https://mega.co.nz/#!vZ80yQJS!ccrCBREYZrOPr8oK7C9StVGuDmYENNYwrFiPXZVQldM

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.

[OnkelPaul]

A tech paper is here:
https://mega.co.nz/#!vZ80yQJS!ccrCBREYZrOPr8oK7C9StVGuDmYENNYwrFiPXZVQldM

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?

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.

Onkel Paul

[anu]

A tech paper is here:
https://mega.co.nz/#!vZ80yQJS!ccrCBREYZrOPr8oK7C9StVGuDmYENNYwrFiPXZVQldM

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.

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.

[becoin]

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

Got it. Thanks.

[Mike Hearn]

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 ....

[anu]

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.

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.

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.

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.

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

Please let me know how it goes.

[Jutarul]

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).

You can do same thing with colored coins: each user can issue his own coins.
...
This is absolutely unrelated to technical implementation.

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.