These are the identities that I see..
I understand that the DarkExchange identity comes from the peers.txt file. Should there be anything in the log to confirm connection via the I2P router. Or is there someplace in the I2P router console to confirm the Dark Exchange client? I'll poke around.
...
Dark Exchange uses the peers.txt file to find the first peer/peers. From there, it tries to download the list of all peers in the network. Unfortunately, there is something wrong with that part of the initialization, and Dark Exchange seems to be giving up before downloading any peers. I can't work on it right now, but I will later. It looks like I'll be up late tonight fixing bugs. |
|
|
|
As I described in the PM sent to you, I explicitly set the classpath jar sequence, and removed the possibly redundant org.bouncycastle package from the i2p jar. The application launches OK and finds the DarkExchange peer listed on the Identity tab. The search does not present an exception but I do not see any search results when I enter ..
I Have Bitcoin To Send BY Bitcoin Transfer
I Want United States of America, Dollars Sent by Dwolla
There is no change in the log file as a result of the search attempt.
I think there are still some issues with Dark Exchange connecting to the network. Check the identity tab. If you're fully connected to the network, you should see 3 identities (including your own). I'll look at the I2P bouncy castle issue. I didn't realize I2P included the bouncy castle jar. It's funny how I'm not getting that issue on any of the computers I'm using. Clearly there is much to work on still.  |
|
|
|
how counter-party risk is mitigated on such a exchange i.e. what are the chances that after I transfer my bitcoins to some anonymous guy I get any fiat in return?
Currently there is none. However, Dark Exchange has a concept of identities which link a user name to a public key/private key. All messages between clients are signed (which seems to be what's breaking with bouncy castle at the moment) and you can view the public key before accepting an offer from someone. This gives an incentive for people to guard their identity and build up a reputation. If you're exchanging with someone you don't know and have never exchanged with before, you probably don't want to exchange large amounts. Once you become more confident in that person, you can start exchanging larger and larger amounts. In the future, I hope to implement a web of trust like feature on Dark Exchange to help people determine who they can trust. |
|
|
|
"lein run" complained about not finding drift*-SNAPSHOT, changed that and it runs. Takes A LOT of memory though , which is not really unexpected for Java in general... Why not use (native!), it would make things look less ugly  I also got the same error here. What do you think of seesaw BTW? I guess it's the best that clojure has available currently. Edit: Got two peers, so me and dev only? The search list should (for testing at least) really display all the offers , or at least all offers that use a preffered currency. I put a "bitcoin for euro by mail" offer, does someone see it? EDIT2: On the first run, the identity tab was empty. Restarted it w/ and w/o :development: It was faster, takes a bit less memory, I now have an identity displayed. How are the normal and :development versions different other than that they maintain separate identities? It looks like I forgot to update a reference to the snapshot version of drift in the development environment. This should only affect those running with lein from a git check out of Dark Exchange. I just pushed a fix. You should have seen 2 other peers, both of which are me. One is a server I just have running constantly so there is someone to connect to, and the other is my real account with a couple offers. If do a search with I Have set to USD cash by mail, and I Want set to bitcoin, bitcoin transfer, you should see one of my offers. The other you should see with a I Have of bitcoin, bitcoin transfer, and I Want of USD, Dwolla. I don't really want the search to ever show all offers, but it may be nice to look at all the offers from a specific identity. There are two differences when running in development vrs production (w/o :development). First and most obvious is the database. If you look at config/db_config.clj you'll see that :production uses the "dark_exchange_production" database, and :development uses the "dark_exchange_development" database. The files for these two databases can be found in the data/db directory of your Dark Exchange install. To initialize the network, Dark Exchange uses a list of known peers listed in the resources/peers.txt file. When you run in development mode, the resources/development-peers.txt file is used instead. This keeps the production and development networks separate. |
|
|
|
Strange, it looks like an issue with bouncy castle. I'll have to take a look at it tomorrow. I've created an issue for it: https://github.com/macourtney/Dark-Exchange/issues/1I installed I2P OK. Then I downloaded and installed Dark Exchange. After I created an account OK, I attempted to trade US dollars for bitcoins and this error occurred... ERROR [darkexchange.model.interceptors.signature-interceptor]: an error occured while signing or verifying a signature on the client side.
java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: SHA1WithRSAEncryption, provider: BC, class: org.bouncycastle.jce.provider.JDKDigestSignature$SHA1WithRSAEncryption)
at java.security.Provider$Service.newInstance(Provider.java:1245)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:220)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
at java.security.Signature.getInstance(Signature.java:324)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:90)
at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:202)
at darkexchange.model.security$sign.invoke(security.clj:139)
at darkexchange.model.user$sign.invoke(user.clj:141)
at darkexchange.model.interceptors.signature_interceptor$sign.invoke(signature_interceptor.clj:17)
at darkexchange.model.interceptors.signature_interceptor$client_interceptor.invoke(signature_interceptor.clj:47)
at darkexchange.model.interceptors.interceptor_util$compose_interceptors$fn__4707$fn__4708.invoke(interceptor_util.clj:4)
at darkexchange.model.interceptors.identity_interceptor$client_interceptor.invoke(identity_interceptor.clj:17)
at darkexchange.model.interceptors.interceptor_util$compose_interceptors$fn__4707.invoke(interceptor_util.clj:4)
at darkexchange.model.interceptors.interceptor_util$run_interceptors.invoke(interceptor_util.clj:9)
at darkexchange.model.interceptors.client_interceptors$run_interceptors.invoke(client_interceptors.clj:10)
at darkexchange.model.client$send_message.invoke(client.clj:26)
at darkexchange.model.peer$get_peers_from.invoke(peer.clj:98)
at darkexchange.model.peer$all_network_destinations.invoke(peer.clj:152)
at darkexchange.model.peer$download_peers_background.invoke(peer.clj:159)
at darkexchange.model.peer$download_peers_background.invoke(peer.clj:164)
at darkexchange.model.peer$download_peers_background.invoke(peer.clj:155)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.SecurityException: class "org.bouncycastle.crypto.Digest"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:807)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at java.security.Provider$Service.newInstance(Provider.java:1221)
... 26 more
ERROR [darkexchange.model.interceptors.signature-interceptor]: an error occured while signing or verifying a signature on the client side.
java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: SHA1WithRSAEncryption, provider: BC, class: org.bouncycastle.jce.provider.JDKDigestSignature$SHA1WithRSAEncryption)
at java.security.Provider$Service.newInstance(Provider.java:1245)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:220)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:190)
at java.security.Signature.getInstance(Signature.java:324)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:90)
at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:202)
at darkexchange.model.security$sign.invoke(security.clj:139)
at darkexchange.model.user$sign.invoke(user.clj:141)
at darkexchange.model.interceptors.signature_interceptor$sign.invoke(signature_interceptor.clj:17)
at darkexchange.model.interceptors.signature_interceptor$client_interceptor.invoke(signature_interceptor.clj:47)
at darkexchange.model.interceptors.interceptor_util$compose_interceptors$fn__4707$fn__4708.invoke(interceptor_util.clj:4)
at darkexchange.model.interceptors.identity_interceptor$client_interceptor.invoke(identity_interceptor.clj:17)
at darkexchange.model.interceptors.interceptor_util$compose_interceptors$fn__4707.invoke(interceptor_util.clj:4)
at darkexchange.model.interceptors.interceptor_util$run_interceptors.invoke(interceptor_util.clj:9)
at darkexchange.model.interceptors.client_interceptors$run_interceptors.invoke(client_interceptors.clj:10)
at darkexchange.model.client$send_message.invoke(client.clj:26)
at darkexchange.model.calls.notify$call.invoke(notify.clj:10)
at darkexchange.model.peer$notify_destination.invoke(peer.clj:92)
at darkexchange.model.peer$notify_all_peers.invoke(peer.clj:134)
at darkexchange.model.peer$add_destinations.invoke(peer.clj:147)
at darkexchange.model.peer$download_peers_background.invoke(peer.clj:161)
at darkexchange.model.peer$download_peers_background.invoke(peer.clj:164)
at darkexchange.model.peer$download_peers_background.invoke(peer.clj:155)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.SecurityException: class "org.bouncycastle.crypto.Digest"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:807)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:488)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at java.security.Provider$Service.newInstance(Provider.java:1221)
... 28 more
|
|
|
|
TL;DR: https://github.com/macourtney/Dark-ExchangeYou read that right! Dark Exchange is a 100% decentralized p2p exchange. No more worrying about exchange websites going down or locking your account. You now have complete control of your bitcoin exchanges and accounts. Because Dark Exchange is decentralized, it can't work like Mt Gox or Trade Hill. Instead, it works more like bitcoin-otc and Bitcoin Market. You post offers and others accept them, or you can search all of the offers on the network and select the one you want. Dark Exchange will walk you through the process of completing a trade. Advantages: 1. Dark Exchange can never be shutdown by anyone (including me) for any reason. As long as there are at least two nodes on the network, the exchange is up and running. (Actually this is more of a goal than a feature at this point. Though I tried to program it this way, I'm not sure if it will really stand up to real world use yet. But, that's why it's called Beta.) 2. No bitcoins or other money is held on a central server. You have complete control over your money the entire time. 3. Virtually all currencies and payment methods are supported. Any currencies or payment methods not already included can be added quickly. 4. No commissions. Free to use. 5. Open source. All source code for Dark Exchange can be found at: https://github.com/macourtney/Dark-Exchange6. Runs on the I2P network. All connections are end to end encrypted, and privacy is under your control. Dark Exchange is in Beta right now. Though I've run as many tests as I can think of on it, I'm sure it won't work exactly as advertised right now. I'm looking for intrepid people interested in helping me test Dark Exchange by using it. All information on how to to download, install and use Dark Exchange can be found on the Dark Exchange wiki: https://github.com/macourtney/Dark-Exchange/wikiIf you have any troubles installing or using the exchange, let me know so I can start entering in issues to make Dark Exchange better. And since it's the 4th.. Let's all declare independence from centralization with Dark Exchange! |
|
|
|
I've been working on a pure p2p exchange for a while now: https://github.com/macourtney/Dark-ExchangeI'm very close to a release. All of the initial features are done. I'm currently working out some bugs. I would say I'm planning to release this week, but I've said it so many times before, the words are meaningless. I'll release it.. eventually. |
|
|
|
An exchange as strong as the bitcoin network needs to be developed. P2P power, network trade system...
I've been working on a p2p bitcoin exchange for a couple months now. I'm pretty close to an initial release. Here's the code: https://github.com/macourtney/Dark-Exchange |
|
|
|
... maybe a good decentralized trading platform can emerge of it, who will tell...
I've been working on a decentralized exchange for a couple of months now. I'm very close to an initial release. Keep an eye out for a big announcement in a week or two. Here is the code so far: https://github.com/macourtney/Dark-Exchange |
|
|
|
The previous poster is correct all the government would need to do is shut down the exchanges and this house of cards will tumble and be destined just to be niche market catering to the technically savvy.
They won't be able to shut it down when the exchange is decentralized: https://github.com/macourtney/Dark-ExchangeOne of these days I'll have a beta out. |
|
|
|
Morpheus, I want in on your beta, if you're able!
On second thought, I'll open the beta up to the whole forum. Keep an eye out for an announcement soon (hopefully in the next week or so.) |
|
|
|
... Maybe instead of a new centralised exchange some clever nut will develop a p2p one.
Funny you should say that, I've been working on one for about a month: https://github.com/macourtney/Dark-ExchangeI'm pretty close to a beta. It's fully open source and no fees. It uses the I2P network to connect p2p, which means all connections are encrypted end to end. Awesome!!! I can't wait for it to be ready. I'll donate then. Do you want in on the beta? |
|
|
|
... Maybe instead of a new centralised exchange some clever nut will develop a p2p one.
Funny you should say that, I've been working on one for about a month: https://github.com/macourtney/Dark-ExchangeI'm pretty close to a beta. It's fully open source and no fees. It uses the I2P network to connect p2p, which means all connections are encrypted end to end. |
|
|
|
Hey guys, I just want to let you know Paypal decided not to allow people to sell bitcoin with their service (this also includes Mt Gox USD). You may be able to sell for a while, but be prepared for Paypal to freeze your account. I know this from experience. |
|
|
|
|
Yes, my account was restricted by Paypal. I'm refunding as much of the payments as I can. Any of them that I can't refund, I'll go ahead and process. Please be patient, it may take a while to get to everyone.
This weekend was the worst possible time for Paypal to restrict my account. Oh well...
|
|
|
|
Really? Ok.
What about June 30 - July 3....?
Does anyone have any major conflicts with those dates?
That's right before the 4th of July. Though it doesn't conflict directly, I'm sure some people may already have plans for those dates. |
|
|
|
|
Show Posts
