Pages:
Author

Topic: [ANN] Joinmarket - Coinjoin that people will actually use - page 12. (Read 84864 times)

full member
Activity: 223
Merit: 130
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:

Quote
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.
newbie
Activity: 42
Merit: 0
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
sr. member
Activity: 321
Merit: 250
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.
sr. member
Activity: 261
Merit: 518
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.
legendary
Activity: 1135
Merit: 1161
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?
legendary
Activity: 1596
Merit: 1027
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!
sr. member
Activity: 261
Merit: 518
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
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.
sr. member
Activity: 261
Merit: 518
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.
legendary
Activity: 2618
Merit: 1006
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.
legendary
Activity: 1974
Merit: 1029
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.
member
Activity: 132
Merit: 17
Someone seriously needs to make stats on volume and estimated amounts earned.
legendary
Activity: 1400
Merit: 1009
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
legendary
Activity: 2618
Merit: 1006
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?
sr. member
Activity: 261
Merit: 518
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.
full member
Activity: 142
Merit: 104
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.
member
Activity: 132
Merit: 17
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.
newbie
Activity: 25
Merit: 0
2% is not "insane"...

In the current system, it kind of is.  The average is significantly lower, and as such is pretty crazy compared to best options.
legendary
Activity: 2618
Merit: 1006
2% is not "insane"...
sr. member
Activity: 261
Merit: 518
I think this project is amazing as well, and I really enjoy using it as my preferred method for coinjoin txs. However I do have one complaint. The other day I was using the sendpayment.py script. The command was exactly:

Code:
python sendpayment.py -C -N 4  0 

The script put the transaction together, and presented me with the options and a "y/n" prompt. I pressed "y" without paying too much attention and ended up paying some asshole 2.8 BTC to send a little over 5. Which is more than half of the bitcoin controlled by my privkeys. Sad

A couple suggestions:

1. Kick those people from the IRC with 50%+ fees.

2. Present the cjfee in something other than satoshis or have an alert that says you're about to pay an insane amount.

Thanks for the feedback. Sorry for you loss.

I made this commit https://github.com/chris-belcher/joinmarket/commit/be8b63fa332d18a4ba71d68e3894d29d4c9db7c8
It displays the coinjoin fee as a percentage and prints out a huge warning banner if its above 2%

Code:
[2015/07/20 02:45:10] total coinjoin fee = 2.1%
============================================================
============================================================
============================================================
WARNING   WARNING   WARNING   WARNING   WARNING   WARNING  
============================================================
OFFERED FEE IS INSANELY LARGE.OFFERED FEE IS INSANELY LARGE.
============================================================
WARNING   WARNING   WARNING   WARNING   WARNING   WARNING  
============================================================
============================================================
============================================================
send with these orders? (y/n):
legendary
Activity: 3920
Merit: 2348
Eadem mutata resurgo
I think this project is amazing as well, and I really enjoy using it as my preferred method for coinjoin txs. However I do have one complaint. The other day I was using the sendpayment.py script. The command was exactly:

Code:
python sendpayment.py -C -N 4  0 

The script put the transaction together, and presented me with the options and a "y/n" prompt. I pressed "y" without paying too much attention and ended up paying some asshole 2.8 BTC to send a little over 5. Which is more than half of the bitcoin controlled by my privkeys. Sad

A couple suggestions:

1. Kick those people from the IRC with 50%+ fees.

2. Present the cjfee in something other than satoshis or have an alert that says you're about to pay an insane amount.

Ouch, that sounds like you got the rawhide treatment.
Pages:
Jump to: