[ANN] Joinmarket - Coinjoin that people will actually use

[btcspry]

I'm a little curious as to how the program picks the person to do the CoinJoin with.  Shouldn't it be the percent with the lowest percentage that can handle the join?  Or am I missing something?  It seems like these 2.8 BTC mistakes shouldn't happen.

[1713400736]

1713400736

[1713400736]

1713400736

[1713400736]

1713400736

[1713400736]

1713400736

[inaltoasinistra]

I'm a little curious as to how the program picks the person to do the CoinJoin with.  Shouldn't it be the percent with the lowest percentage that can handle the join?  Or am I missing something?  It seems like these 2.8 BTC mistakes shouldn't happen.

The order book is not so big now, so a cj tx with 10 parties and 5btc could consume all the order book and reach the 200% fee.

[belcher]

2% is not "insane"...

It's two orders of magnitude above most of the market right now.

The highest obviously-not-in-bad-faith offer is 0.5% per transaction and that guy offers up to 124.01382647 BTC(!)

There's an open issue to display fees in basis points and parts-per-million because the percent unit is too large.

[Sukrim]

The market is still tiny and while early adopters might be happy to offer their coin for nearly free for mixing, this might not be the case in the future. A 2% fee for achieving anonymity is still quite low, adding built in magic default values is not a very sustainable or helpful thing if you want to establish a free market.

Maybe display fee in relative and absolute values, optionally also with fiat prices?

Anyways, please put this warning value in a configuration file and maybe write your 2% as a default in there... but don't hide this deep in the code.

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

[justusranvier]

The market is still tiny and while early adopters might be happy to offer their coin for nearly free for mixing, this might not be the case in the future. A 2% fee for achieving anonymity is still quite low, adding built in magic default values is not a very sustainable or helpful thing if you want to establish a free market.

Maybe display fee in relative and absolute values, optionally also with fiat prices?

Anyways, please put this warning value in a configuration file and maybe write your 2% as a default in there... but don't hide this deep in the code.

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

Two standard deviations above the average is probably a better sanity check

[btcspry]

Someone seriously needs to make stats on volume and estimated amounts earned.

[dserrano5]

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

My fee is around 0.01% and I'm involved in some 3 or 4 joins a week. FWIW.

[Sukrim]

Two standard deviations above the average is probably a better sanity check

I agree, something that is a bit more dynamic towards current market situations would be better.

Oh, and:

2% is not "insane"...

It's two orders of magnitude above most of the market right now.

No, it is not - only if you count individual offers (which could easily be a sybil/collusion attack by a single actor operating several instances with a few BTC each).

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

My fee is around 0.01% and I'm involved in some 3 or 4 joins a week. FWIW.

Ok, so definitely not worth the risk then.

To earn just one single USD per day(!) you'd need to keep about 7 BTC at that rate on a hot wallet while announcing your IP to an IRC server.

Also I am wondering if it is a better strategy to put up several instances with similar configuration and effectively sybil attack the market, hoping you get more volume from people that try to "fan out" to get more counterparties involved or to pool all your funds in one large account, hoping for a "big fish" that wants to launder a lot of money at once.

[belcher]

This message is merely a warning to make people more aware of what they're getting into. Clear information is good for market outcomes. People can still go ahead with the deal by typing 'y' same as before. Though maybe the wording should be changed, removing prescriptive words like "insane".

In the event that prices rise above 2% and many people get bored by constantly reading the same warning, the threshold can be easily changed.

Remember that ultimately the point of JoinMarket isn't to give free money to market makers but to provide privacy at a cheap price.
If we look at the interests of coinjoiners not accidentally paying too much vs investors being faced with a warning for high fees, the interests of the customers wanting privacy should come first.

There was already a shill trying to use this incident to ruin the reputation of JoinMarket on reddit with an editorialized headline, which I reposted sans headline. Opposing that warning won't you more money, it's likely to make you less in the long run.

By the way, almost any investment can look bad if you work out the per-day return. Find the per-annum income and compare, and think about the low risk you take, how little time and effort it takes to run and the fact you're getting paid in a deflationary currency. If you want to raise your earnings the best way is to have more takers as customers. Either contribute to the code or promote the use of JoinMarket to bitcoin users who might be interested.

Someone seriously needs to make stats on volume and estimated amounts earned.

Be the change you wish to see in the world!
https://github.com/adlai/cjhunt
https://github.com/chris-belcher/joinmarket/issues/19

To earn just one single USD per day(!) you'd need to keep about 7 BTC at that rate on a hot wallet while announcing your IP to an IRC server.

Also I am wondering if it is a better strategy to put up several instances with similar configuration and effectively sybil attack the market, hoping you get more volume from people that try to "fan out" to get more counterparties involved or to pool all your funds in one large account, hoping for a "big fish" that wants to launder a lot of money at once.

The IRC server accepts tor.

Higher amounts of bitcoin in one offer command a higher fee (like the high 0.5% fee for the guy who has 124btc) so there is a strong incentive to keep your coins on one bot rather than fanning out.

[belcher]

Edited message phrasing

https://github.com/chris-belcher/joinmarket/commit/00eb9cab006897b3f34a5f858600fdc1a0b548d8


sendpayment.py can still be dangerous if people use --yes which skips the yes/no question.
There needs to be an option for a maximum total coinjoin fee, which will have a default value. Such a flag already exists in tumbler.py

BTW, gmaxwell also chose a fixed fee when fixing the equivalent problem for bitcoin raw transactions.

Code:

commit 9d14e689c86a395c11a530767db4ddf895446ba8
Author: Gregory Maxwell <greg@xiph.org>
Date:   Wed Aug 28 15:41:46 2013 -0700

[raw] reject insanely high fees by default in sendrawtransaction

There have been several incidents where mainnet experimentation with
raw transactions  resulted in insane fees.  This is hard to prevent
in the raw transaction api because the inputs may not be known.
Since sending doesn't work if the inputs aren't known, we can catch
it there.

This rejects fees > than 10000 * nMinRelayTxFee or 1 BTC with the
defaults and can be overridden with a bool at the rpc.

[Blawpaw]

I guess the ecosystem demands this kind of developments but wonder if this will still work against the new Elliptic tracking software!
This is becoming like the old mouse and cat game... While some companies develop new and improved privacy software, others will keep on cracking it!

We need projects like your to be running!
Good Luck for your project!

[domob]

Just brainstorming a bit.  Let us assume that I'm getting paid in Bitcoin by someone I know (and who knows me).  I would like to spend the bitcoins on something this person should not know about.  Such situations can arise a lot; I could be a government worker for some regime spending the money on "foreign" news sites; it could be a friend or relative splitting a restaurant bill and me buying porn; it could be a face-to-face purchase of bitcoins and me not wanting the seller to find out my net worth via blockchain analysis; and so on.

Furthermore, note that it seems fairly easy to make a good guess about whether or not a particular tx is a JoinMarket coinjoin or not.  (Look for multiple outputs of the exact same size for a start, although such transactions can be "faked" easily, of course.  You could also try to keep track of outputs offered by market makers semi-publicly.)

Couldn't the adversary now follow all outputs from all JoinMarket coinjoins starting with the coin they sent me initially, and try to find the one that first stops to take part in JoinMarket transactions?  Assume that I do a few joins with the coins before spending them, possibly including splitting to various outputs and so on (as the tumbler does).  The market makers, however, will probably continue to do more and more joins with their coins (as that's simply what they do).  It seems plausible that this quite simple strategy could, indeed, be efficient in linking inputs and outputs together even through a series of joins.

What do you think?

[belcher]

Just brainstorming a bit.  Let us assume that I'm getting paid in Bitcoin by someone I know (and who knows me).  I would like to spend the bitcoins on something this person should not know about.  Such situations can arise a lot; I could be a government worker for some regime spending the money on "foreign" news sites; it could be a friend or relative splitting a restaurant bill and me buying porn; it could be a face-to-face purchase of bitcoins and me not wanting the seller to find out my net worth via blockchain analysis; and so on.

Furthermore, note that it seems fairly easy to make a good guess about whether or not a particular tx is a JoinMarket coinjoin or not.  (Look for multiple outputs of the exact same size for a start, although such transactions can be "faked" easily, of course.  You could also try to keep track of outputs offered by market makers semi-publicly.)

Couldn't the adversary now follow all outputs from all JoinMarket coinjoins starting with the coin they sent me initially, and try to find the one that first stops to take part in JoinMarket transactions?  Assume that I do a few joins with the coins before spending them, possibly including splitting to various outputs and so on (as the tumbler does).  The market makers, however, will probably continue to do more and more joins with their coins (as that's simply what they do).  It seems plausible that this quite simple strategy could, indeed, be efficient in linking inputs and outputs together even through a series of joins.

What do you think?

Yes probably.

Privacy would be improved if the person you're trading with also uses CoinJoin, so then the transaction graph will continue with coinjoins after your transaction.

Privacy has the element of hiding among the crowd. The more people use JoinMarket the better. I'm hoping the incentives will work out to make this happen. Yield generators have an incentive to tell everyone about JoinMarket so their own income will rise.

[btc4ever]

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

It's good to think about possible attacks so we can look out for them.

Privacy is a multi-faceted idea. I don't think CoinJoin or JoinMarket entirely solve the problem. A single CoinJoin does nothing to help with time-based or amount-based privacy invading, because the deals happen apparently instantly, and if you send in an amount of bitcoin you'll get back out that amount minus fees.

[Adlai]

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

To use git terminology, the plumbing exists, but you've either got to get out a pipe wrench or wait for porcelain to arrive.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

Code:

python tumbler.py --help

[CohibAA]

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

It's good to think about possible attacks so we can look out for them.

Privacy is a multi-faceted idea. I don't think CoinJoin or JoinMarket entirely solve the problem. A single CoinJoin does nothing to help with time-based or amount-based privacy invading, because the deals happen apparently instantly, and if you send in an amount of bitcoin you'll get back out that amount minus fees.

I may not be fully understanding your suggestion, but I believe the tumbler.py already does something like this.  Here is the (current) info from the help file, as pointed out by Adlai:

Usage: tumbler.py [options] [wallet file] [destaddr(s)...]

Sends bitcoins to many different addresses using coinjoin in an attempt to
break the link between them. Sending to multiple  addresses is highly
recommended for privacy. This tumbler can be configured to ask for more
address mid-run, giving the user a chance to click `Generate New Deposit
Address` on whatever service they are using.

I didn't post all the parameters the help covers, but multiple receive addresses, and random timing of transactions are some of the options available.

[CohibAA]

Has everyone updated for BIP66?

JoinMarket Alert Message: Please update from the latest github to fix the bip66 bug

What, if any, repurcussions would takers and makers see if trying to create a coinjoin with someone that has not yet upgraded?  More frequent signature errors?

[belcher]

Has everyone updated for BIP66?

JoinMarket Alert Message: Please update from the latest github to fix the bip66 bug

What, if any, repurcussions would takers and makers see if trying to create a coinjoin with someone that has not yet upgraded?  More frequent signature errors?

Yep, just more frequent signature errors. Then the transaction fails to broadcast.
Nobody loses any money, at worst they fail to gain money.
That was the situation we had up until now and there were not even that many bug reports about it. I'm guessing most people used sendpayment.py and just tried it again then it would work.

It would be a mild inconvenience to people using sendpayment.py but would stall a tumbler.py process. Also anyone who doesn't understand the details of the error message might be very put off, especially if they're using some eventual GUI like an Electrum plugin or Bitcoin Core integration.

[tailsjoin]

Hidden service orderbook viewer: http://ruc47yiosooolrzw.onion:62601/

[superresistant]

 
This project is really interesting but without a light and very simple wallet it is hard to imagine a lot of transactions going on.

With a lot of transactions, whales would come.

Idiot-proof softwares are the ones that work the best.