Search content
Sort by
Showing 20 of 56 results by themgp
Currently peer discovery is implemented with a centralized server. The server waits for N users to connect, then sends a message containing the IP Address and port of all participants. This approach is vulnerable to denial of service and is a single point of failure, but on the up-side any compliant server can be used. I still believe distributed peer discovery is ideal, but that can always be added later.
The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:
1. Each participant starts a Tor Hidden Service.
2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.
3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.
+ No traffic ever leaves the Tor network
+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous
It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.
P.S.
Here is an example of a 10-way CoinJoin I generated using my library:
http://tbtc.blockr.io/tx/info/894d10fea8e017789e80e2965d3421572e42e19ba8c6f51ce4a22b3c40b0f831
This is similar to what a CoinJoin transaction would look like in practice, except a more secure implementation would mix the outputs around better.
The centralized method is also NAT-friendly if Tor is used. Here is an idea for anonymous peer discovery and communication:
1. Each participant starts a Tor Hidden Service.
2. Using Tor, each participant connects to a peer discovery server, which is itself a Hidden Service. It announces the ID of its Hidden Service and open port.
3. The server then sends each participant a list of the Hidden Services. The participants then connect to these Servers and proceed with the decentralized CoinJoin process.
+ No traffic ever leaves the Tor network
+ No port forwarding / NAT traversal is required (in this sense it is more user-friendly than a non-anonymous
It should be noted that in order to prevent inputs and outputs from being linked by participants more complicated measures such as the blind signatures discussed on the first page must be used.
P.S.
Here is an example of a 10-way CoinJoin I generated using my library:
http://tbtc.blockr.io/tx/info/894d10fea8e017789e80e2965d3421572e42e19ba8c6f51ce4a22b3c40b0f831
This is similar to what a CoinJoin transaction would look like in practice, except a more secure implementation would mix the outputs around better.
If you are writing a Java library and are planning on using a DHT, have a look at TomP2P. Its what i used in http://coinmux.com.
Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?
I found the thread when reading this article from 7 months ago. What has happened since?
http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/
I found the thread when reading this article from 7 months ago. What has happened since?
http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/
I'm still actively working on the implementation I have started Coinmux. I have taken a break for the last month after spending 3+ months working on it nights and weekends. Hopefully there is a Bitcoin God that wants to offer me a job to work on it full time.
Themgp, that looks really interesting! I'm sure others wish you could work on it full time, too!
How far away is it from being usable for an average Bitcointalker?
The main problem right now is getting an available set of users to do a CoinJoin - the idea doesn't work if no one is using it. I think if i had a few weeks of solid work on Coinmux, it would be something where a user with a general understanding of bitcoin addresses and public/private keys that wanted to increase their privacy would want to use it. Hopefully I can find the time soon.
I'd be curious to know what a "complete" implementation is. I'm guessing no one other than the owners of the donated BTC can say for sure... and AFAIK, they haven't said yet.
The OP mentions "complete", which I imagine would be a coinjoin implementation which would be considered by Core Dev worthy of inclusion in the reference client (needing cosmetic, standardizing and/or translation changes or only). Now this may remain a theoretical assessment if the goal is to see 3rd party implementations such as blockchain.info's.
Coinmux *seems* very good, and must be a front-runner, subject to informed criticism such as the input from Cryddit.
@solex, I don't know if it's ever been articulated. That and the fact that the coins haven't moved was basically my gripe, not a specific jab at @nanobit (although, this is open-source software developed by volunteers: asking for time estimates is bad form).
Agreed.
I'll not take the "seems" statement as an insult.
Coinmux has got quite a way to go from where it is now to where i envision it when finished. And if "complete" means that the implementation is merged into the reference client, i'll never get there as i did not write it in C/C++ (and i'd probably end up writing some pretty shitty C/C++ anyway).There is now 42 BTC donated: https://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk
Was the plan to pay 100% to the author of the first complete implementation, or for piece-work in progress?
Was the plan to pay 100% to the author of the first complete implementation, or for piece-work in progress?
I'd be curious to know what a "complete" implementation is. I'm guessing no one other than the owners of the donated BTC can say for sure... and AFAIK, they haven't said yet.
Could someone kindly give a status update on when will we have a real-world, usable CoinJoin (besides the implementation on Blockchain.info)? This thread is huge, and I'm sure many casual readers would like to see a tl;dr to learn will this result in a usable client soon, or what's the plan?
I found the thread when reading this article from 7 months ago. What has happened since?
http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/
I found the thread when reading this article from 7 months ago. What has happened since?
http://bitcoinmagazine.com/6630/trustless-bitcoin-anonymity-here-at-last/
I'm still actively working on the implementation I have started Coinmux. I have taken a break for the last month after spending 3+ months working on it nights and weekends. Hopefully there is a Bitcoin God that wants to offer me a job to work on it full time.
The extant solution for anonymous networks (Tor) requires extra steps that many users won't do,
Tor is actually quite easy to bundle, and some other programs (like torchat) already do. I'd assume that someday there would be bitcoin clients offered with bundled tor.I was looking at Orchid (a Tor library) today and saw Mike Hearn's name on a github pull request: https://github.com/subgraph/Orchid/pull/9 with the comment: "I need this fix for bitcoinj."
Yeah, but I'm just saying that it's pretty worthless if they store the logs.
And if they don't store the logs... well, that's probably illegal, at least in US and Russia
The only safe CoinJoin solution I see is p2p based, with some tricky encryption.
But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.
I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".
Though it has two big disadvantages, over p2p coin mixing:
1) You need to trust the service to really destroy the logs
2) It doesn't come for free.
So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.
Not to mention that it would be dangerous for whoever runs this server.
And if they don't store the logs... well, that's probably illegal, at least in US and Russia
The only safe CoinJoin solution I see is p2p based, with some tricky encryption.
But still I think this will never beat services like bitcoinfog, assuming that they indeed remove the logs as they claim.
I mean: you deposit your money and withdraw ~98% of it, while your deposit is still unspent - destroying a log at this moment leaves absolutely no traces and it's actually a perfect "privacy for the real world".
Though it has two big disadvantages, over p2p coin mixing:
1) You need to trust the service to really destroy the logs
2) It doesn't come for free.
So I also find CoinJoin as a nice and possibly useful project, but IMHO centralizing it around a server would just defeat the purpose.
Not to mention that it would be dangerous for whoever runs this server.
The CoinJoin client I wrote, Coinmux https://github.com/michaelgpearce/coinmux is P2P and open source. Its still in its early development phase though. Having spent the last 10 years building web applications, building a true P2P application is definitely more difficult than building a server-side solution (which you have to trust).
Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.
And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.
And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.
It looks awesome! Keep up the good work!
Thanks! I forgot what a pain in the ass making a desktop app is. This was a good reminder.
Hey all. I released a new version of Coinmux that now has a graphical user interface. It still defaults to using the Testnet network, but you can now easily change that in the preferences menu if you are adventurous with your Bitcoin.
You can view an animated GIF with two participants mixing their coins on the Coinmux homepage http://www.coinmux.com.
Here is a full-sized direct link to the animated GIF http://coinmux.com/images/animated-coinmux.gif.
And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.
You can view an animated GIF with two participants mixing their coins on the Coinmux homepage http://www.coinmux.com.
Here is a full-sized direct link to the animated GIF http://coinmux.com/images/animated-coinmux.gif.
And of course, all of the code is available on Github at: http://github.com/michaelgpearce/coinmux.
After reviewing your coinmux code, I can identify a problem. And a solution.
The good: no evidence appears in the blockchain about whose inputs are associated with which output. That's part 1 of the solution.
The bad: Someone eavesdropping on the protocol messages, including a nonparticipant, can associate both inputs and outputs with IP addresses. Fixing this is completely necessary before coinmux is viable, especially since the primary attack on network privacy is via traffic analysis.
The solution: Implement a Dining Cryptographers Network among the participants, and you are immune to traffic analysis. Here's a wikipedia article about the Dining Cryptographers' problem which it's based on.
http://en.wikipedia.org/wiki/Dining_cryptographers_problem
In a DCN, topologically the participants are arranged in a circle, where Alice is next to Zebulon and Bob, Bob is next to Alice and Carol, Carol is next to Bob and Estelle, etc.
Each adjacent *pair* of participants generates a shared key stream - which can be as simple as repeatedly incrementing a nonce and encrypting it to get each new block of the key stream. You can use Diffie-Hellman key agreement to create a shared secret to key the stream.
Then each participant publishes XOR of the keystreams he shares with his two adjacent participants and the message he wishes to broadcast. When all of these published messages are XOR'd together, the broadcast message magically appears because each keystream has been XOR'd with it twice thereby cancelling out the keystreams. Different participants can write on different parts of the block, creating different messages. And the participants can iteratively publish the block with updates, if they use a different hunk of their shared keystreams each time. I'm thinking that the obvious implementation here has the 'block' that's getting updated include the image of a transaction. The participants would each add their inputs and their outputs, then signatures (not valid if anybody changes outputs) in a later round.
The benefit is that nobody monitoring the protocol messages can tell where the messages (or the parts of messages, IE inputs and outputs) originated, even if they saw every last message and every published XOR. Not even the participants can tell anything about the origins of any part of the message written by someone else.
It has some limitations; For example if two people both try to write on the same blob of bits at the same time, then the 'message' that appears in that blob is binary garbage. So there are conventions about 'reserving' blocks in previous rounds, where you agree that whoever reserved the block can write things in it and others shouldn't, and ways to detect which participant has broken the convention so that they can be cut out of subsequent rounds, etc. Also, it requires O(n^2) overhead where n is the number of participants, so it doesn't scale well past a few dozen people per mux. It's kinda clunky.
But it does work, and it's completely trustless in that NOBODY can de-anonymize, or even distinguish, the participants.
The good: no evidence appears in the blockchain about whose inputs are associated with which output. That's part 1 of the solution.
The bad: Someone eavesdropping on the protocol messages, including a nonparticipant, can associate both inputs and outputs with IP addresses. Fixing this is completely necessary before coinmux is viable, especially since the primary attack on network privacy is via traffic analysis.
The solution: Implement a Dining Cryptographers Network among the participants, and you are immune to traffic analysis. Here's a wikipedia article about the Dining Cryptographers' problem which it's based on.
http://en.wikipedia.org/wiki/Dining_cryptographers_problem
In a DCN, topologically the participants are arranged in a circle, where Alice is next to Zebulon and Bob, Bob is next to Alice and Carol, Carol is next to Bob and Estelle, etc.
Each adjacent *pair* of participants generates a shared key stream - which can be as simple as repeatedly incrementing a nonce and encrypting it to get each new block of the key stream. You can use Diffie-Hellman key agreement to create a shared secret to key the stream.
Then each participant publishes XOR of the keystreams he shares with his two adjacent participants and the message he wishes to broadcast. When all of these published messages are XOR'd together, the broadcast message magically appears because each keystream has been XOR'd with it twice thereby cancelling out the keystreams. Different participants can write on different parts of the block, creating different messages. And the participants can iteratively publish the block with updates, if they use a different hunk of their shared keystreams each time. I'm thinking that the obvious implementation here has the 'block' that's getting updated include the image of a transaction. The participants would each add their inputs and their outputs, then signatures (not valid if anybody changes outputs) in a later round.
The benefit is that nobody monitoring the protocol messages can tell where the messages (or the parts of messages, IE inputs and outputs) originated, even if they saw every last message and every published XOR. Not even the participants can tell anything about the origins of any part of the message written by someone else.
It has some limitations; For example if two people both try to write on the same blob of bits at the same time, then the 'message' that appears in that blob is binary garbage. So there are conventions about 'reserving' blocks in previous rounds, where you agree that whoever reserved the block can write things in it and others shouldn't, and ways to detect which participant has broken the convention so that they can be cut out of subsequent rounds, etc. Also, it requires O(n^2) overhead where n is the number of participants, so it doesn't scale well past a few dozen people per mux. It's kinda clunky.
But it does work, and it's completely trustless in that NOBODY can de-anonymize, or even distinguish, the participants.
I've thought through this some more. I could implement this, and it wouldn't be terribly difficult. In fact, I think I can even implement it without changing my current communication API (see my data store requirements in a previous post). My main problem with it is that it only solves one thing that i can't solve by simply encrypting every message published to the Director and a DCN doesn't solve a larger issue.
With using TomP2P and adding message encryption, the Director can still connect IP addresses to Inputs/Outputs but the Participants cannot. A DCN will solve this. But an outside observer would most likely still be able to connect IP addresses with the resulting published transaction just by watching the Coinmux network and watching the Bitcoin network. While the observer cannot directly correlate an IP to a specific Bitcoin output address, just knowing the transaction and the IP addresses involved is still a pretty big leaked piece of information.
If I use an anonymity network (i.e. Freenet), it would solve both issues. Neither the participants nor the director would be able to associate an IP address to a specific input/output, and an observer would not be able to associate a transaction to any IP addresses.
I had looked at I2P for this project previously but ruled it out due to it not behaving as a data store (which Freenet and TomP2P both are). Looking at the I2P documentation again, they did mention someone adding Tahoe-LAFS support (https://geti2p.net/en/comparison/freenet), but I don't have any information about that.
I also looked at I2P before I knew about TomP2P. Since I2P supports both TCP and UDP (https://geti2p.net/en/comparison/tor), it may be possible to combine it with TomP2P. AFAIK, Tor does not support UDP so TomP2P + Tor is not possible.
I just saw this: https://geti2p.net/en/docs/applications/supported#decentralized-file-storage (though i can't view eepsites right now since i don't have I2P installed). I2P definitely goes back on my investigation list.
I had looked at I2P for this project previously but ruled it out due to it not behaving as a data store (which Freenet and TomP2P both are). Looking at the I2P documentation again, they did mention someone adding Tahoe-LAFS support (https://geti2p.net/en/comparison/freenet), but I don't have any information about that.
I also looked at I2P before I knew about TomP2P. Since I2P supports both TCP and UDP (https://geti2p.net/en/comparison/tor), it may be possible to combine it with TomP2P. AFAIK, Tor does not support UDP so TomP2P + Tor is not possible.
The cryptographer in me says I should do this, while the engineer in me thinks this may be (too) difficult to implement. (And I'm a much stronger engineer than cryptographer!) I still haven't totally wrapped my head around it from an engineering perspective, I'll do that once I get the GUI for Coinmux working. But I am a believer in keeping Coinmux simple. Bitcoin has some warts, but its really pretty simple as far as crypto goes. I'd like to keep that same philosophy for Coinmux.
One of the easiest things I can do to limit who sees the the IP address of published messages is to encrypt them. Both the Director and Participants have a public key as part of their first message broadcast. Other than the Director's first announcement message and the Director's subsequent status updates, all other messages can be encrypted so only the involved parties can decrypt the messages. The IP address would still be leaked, but only those in the mix can make sense of what's going on. While not a cryptographically perfect solution, this would make traffic analysis more difficult and less useful. This may make put Coinmux in the "good enough to be useful" category. This wouldn't be great, but as an engineer, I realize everything has tradeoffs.
The Coinmux protocol itself was not designed to hide IP addresses/participants, only to facilitate communication. As i first imagined what the protocol would look like, I had always considered using Freenet for message communication and to provide anonymity at the "network layer." Coinmux was designed with a Freenet like system in mind with the following properties: untraceable message insertion, immutable messages, ability to post multiple messages to a known location/key, and all messages publicly retrievable from a known key. TomP2P allows for all of these except the untraceable message insertion. TomP2P was really only selected due to it being available as a Java library and ready to be embedded in an application. Well, that and it's faster than Freenet.
I'd rather try to solve this at the network layer than the protocol layer. This allows for the network layer to be easily changed (I have 3 implementations now - TomP2P, the filesystem, and a memory implementation used for testing). I am still actively considering switching to using Freenet as originally planned. Bitmessage is another option, though i believe their API is inadequate. Maybe there is a way to use Tor. Or maybe some new Altcoin becomes a viable option in the future. Or maybe i can push harder on TomP2P: is it possible to shuffle messages around the TomP2P peer network before inserting them to provide anonymity? The protocol doesn't care who inserted the message, only that it gets inserted. As it is right now, none of the options outside of TomP2P meet the requirement of "easy to use" as they require an additional application running.
Anyway, there are lots of different options and all of them have tradeoffs, but I am pretty open to anything that will work. I'll need to let what you wrote settle on my brain a little more.
One of the easiest things I can do to limit who sees the the IP address of published messages is to encrypt them. Both the Director and Participants have a public key as part of their first message broadcast. Other than the Director's first announcement message and the Director's subsequent status updates, all other messages can be encrypted so only the involved parties can decrypt the messages. The IP address would still be leaked, but only those in the mix can make sense of what's going on. While not a cryptographically perfect solution, this would make traffic analysis more difficult and less useful. This may make put Coinmux in the "good enough to be useful" category. This wouldn't be great, but as an engineer, I realize everything has tradeoffs.
The Coinmux protocol itself was not designed to hide IP addresses/participants, only to facilitate communication. As i first imagined what the protocol would look like, I had always considered using Freenet for message communication and to provide anonymity at the "network layer." Coinmux was designed with a Freenet like system in mind with the following properties: untraceable message insertion, immutable messages, ability to post multiple messages to a known location/key, and all messages publicly retrievable from a known key. TomP2P allows for all of these except the untraceable message insertion. TomP2P was really only selected due to it being available as a Java library and ready to be embedded in an application. Well, that and it's faster than Freenet.
I'd rather try to solve this at the network layer than the protocol layer. This allows for the network layer to be easily changed (I have 3 implementations now - TomP2P, the filesystem, and a memory implementation used for testing). I am still actively considering switching to using Freenet as originally planned. Bitmessage is another option, though i believe their API is inadequate. Maybe there is a way to use Tor. Or maybe some new Altcoin becomes a viable option in the future. Or maybe i can push harder on TomP2P: is it possible to shuffle messages around the TomP2P peer network before inserting them to provide anonymity? The protocol doesn't care who inserted the message, only that it gets inserted. As it is right now, none of the options outside of TomP2P meet the requirement of "easy to use" as they require an additional application running.
Anyway, there are lots of different options and all of them have tradeoffs, but I am pretty open to anything that will work. I'll need to let what you wrote settle on my brain a little more.
Good stuff - I hope it will explode
Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that.
Testnet is the proper solution to that. Let people test it using testnet coins and the problem about the bitcoin private key risk goes away.
I totally agree. It is set up right now to work off testnet by default (the user needs to set an environment variable to connect to Mainnet). Unfortunately, the testnet knowledgeable audience is a lot smaller, and CoinJoining needs multiple people running it at the same time. Hopefully in time, this will resolve itself.
And i'm not sure i really made this clear in my original posting, but the only thing needed to run Coinmux is Java and the Jar file available from http://github.com/michaelgpearce/coinmux. You don't need to have BitcoinQT installed and it does not require downloading the blockchain to your computer. I'm trying to make something that an average Bitcoin user will be able to understand and use.
Good stuff - I hope it will explode
Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.
I think this is a great start, your protocol needs a little work and I am writing something off of it.
Feel free to share your thoughts. I haven't gotten any feedback on the protocol yet.
Good stuff - I hope it will explode
Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.
How does Coinmux find other users? And if it doesn't, can it implement a Bitmessage chan?
It uses a java p2p library http://tomp2p.net/ to create DHT of users.
Yep. It uses TomP2P. My initial implementation was going to use Freenet, but I didn't want to require needing any external applications running.
In Coinmux, I call the communication layer a Data store in the code. There is an implementation using TomP2P, the file system and one that uses only memory for testing purposes. It's straight forward to implement these and I did also consider Bitmessage. Unfortunately, the Bitmessage JSON API looked to be very heavily tied to a specific user in the UI with no way to create a new user via API or send messages as a specific user. This lead me to stop investigating it further.
Hey all. Short update, here is the first transaction that Coinmux has created on the main Bitcoin network and a transcript of the output as shown on the console from one of the peers.
https://blockchain.info/tx/b5b8c60836d22964138d05c0bd42f9f06ccef81cd3150641a9436f6173ded6c0
(Its kinda cool that it confuses Blockchain.info's "Estimated BTC Transacted" for the transaction!)
https://blockchain.info/tx/b5b8c60836d22964138d05c0bd42f9f06ccef81cd3150641a9436f6173ded6c0
(Its kinda cool that it confuses Blockchain.info's "Estimated BTC Transacted" for the transaction!)
Code:
~/Downloads $ COINMUX_ENV=production java -jar coinmux-latest.jar -p 2 -a 0.001 -o 1GQypfLSim1xndF5jupFrNoJi9U9LFLLzp -c 1Jd7Hiv43MeHMkPKU4bbSJqvQeZxqLj5iu
Enter your private key:
***************************************************
Starting...
[Participant]: Finding coin join message
[Participant]: No available coin join
[Director]: Inserting coin join message
[Director]: Inserting status message
[Director]: Waiting for inputs
[Participant]: Finding coin join message
[Participant]: Inserting input
[Participant]: Waiting for other inputs
[Director]: Inserting message verification message
[Director]: Waiting for outputs
[Participant]: Inserting output
[Participant]: Waiting for other outputs
[Director]: Inserting transaction message
[Director]: Waiting for signatures
[Participant]: Inserting transaction signatures
[Participant]: Waiting for completed
[Director]: Publishing transaction
[Director]: Completed
[Participant]: Completed - Transaction ID: b5b8c60836d22964138d05c0bd42f9f06ccef81cd3150641a9436f6173ded6c0
CoinJoin successfully created!
Enter your private key:
***************************************************
Starting...
[Participant]: Finding coin join message
[Participant]: No available coin join
[Director]: Inserting coin join message
[Director]: Inserting status message
[Director]: Waiting for inputs
[Participant]: Finding coin join message
[Participant]: Inserting input
[Participant]: Waiting for other inputs
[Director]: Inserting message verification message
[Director]: Waiting for outputs
[Participant]: Inserting output
[Participant]: Waiting for other outputs
[Director]: Inserting transaction message
[Director]: Waiting for signatures
[Participant]: Inserting transaction signatures
[Participant]: Waiting for completed
[Director]: Publishing transaction
[Director]: Completed
[Participant]: Completed - Transaction ID: b5b8c60836d22964138d05c0bd42f9f06ccef81cd3150641a9436f6173ded6c0
CoinJoin successfully created!
Hey all, i just released v0.1.0 of Coinmux (followed quickly by 0.1.1 to fix a couple of minor UI issues) which is my milestone for having things functional on Testnet. I'm ready to move on to building a GUI to sit on top of the code already there and make it easier to use.
But before I do that, I want to try it out on the Bitcoin MAINNET and with some STRANGERS on the Internet! I've never done either!
I'm hoping a couple of you are brave enough to try it with me. I want to do a small CoinJoin transaction, 0.001 BTC (a little less than 1USD) . To get a suitable wallet, I simply went to bitaddress.org, created a new wallet for the CoinJoin input, and then sent 0.0015 BTC to it from my main wallet (a little extra for miner fees). Any address with a balance > 0.0015 will work, but I would not recommend using your primary wallet. There shouldn't be any issues, but better to be safe than sorry.
If you are interested, there is a link to download the latest Java client here: https://github.com/michaelgpearce/coinmux. To use the Mainnet Bitcoin network instead of Testnet, you'll simply need to set an environment variable COINMUX_ENV=production. On a Unixy OS, you should be able to just type this command in the terminal/console where you run the Java command. On Windows, i believe you use the SET command, but its been years since i've used Windows.
I'm on Freenode IRC at #coinmux via webchat: https://webchat.freenode.net. Hopefully one or two people will come find me.
Thanks!!
But before I do that, I want to try it out on the Bitcoin MAINNET and with some STRANGERS on the Internet! I've never done either!
I'm hoping a couple of you are brave enough to try it with me. I want to do a small CoinJoin transaction, 0.001 BTC (a little less than 1USD) . To get a suitable wallet, I simply went to bitaddress.org, created a new wallet for the CoinJoin input, and then sent 0.0015 BTC to it from my main wallet (a little extra for miner fees). Any address with a balance > 0.0015 will work, but I would not recommend using your primary wallet. There shouldn't be any issues, but better to be safe than sorry.
If you are interested, there is a link to download the latest Java client here: https://github.com/michaelgpearce/coinmux. To use the Mainnet Bitcoin network instead of Testnet, you'll simply need to set an environment variable COINMUX_ENV=production. On a Unixy OS, you should be able to just type this command in the terminal/console where you run the Java command. On Windows, i believe you use the SET command, but its been years since i've used Windows.
I'm on Freenode IRC at #coinmux via webchat: https://webchat.freenode.net. Hopefully one or two people will come find me.
Thanks!!
... and of course, you can generate an address from bitaddress.org and get some Testnet coins from TP's faucet.
https://www.bitaddress.org/bitaddress.org-v2.6.5-SHA1-fa763c2bbc97e1b37bc6d3945647aed869ec8c18.html?testnet=true
http://tpfaucet.appspot.com/
https://www.bitaddress.org/bitaddress.org-v2.6.5-SHA1-fa763c2bbc97e1b37bc6d3945647aed869ec8c18.html?testnet=true
http://tpfaucet.appspot.com/