15

There are three main ways to fix this. The first one is to attempt to select outputs which are unrelated, if possible. This only works if you are sending an amount of monero that can be represented with unrelated outputs. This means that if you have received a single payment, you won't be able to select unrelated inputs, since they're all related - unless ...


6

You must choose mix inputs of the same amount as the one you are spending. Other than that there are no restrictions, though it's not a good idea to choose a really recent output (less than 10 blocks old -- you'd also have to modify the daemon and/or wallet to do so). The wallet currently chooses outputs as follows: 25% are chosen randomly from "recent outs"...


6

If you have log level 2 IIRC, the whole transactions are dumped to the log. Output selection is random, within "priority" levels. Priority levels are determined by which outputs are related to outputs already in a transaction that's being built. This means that if you have enough outputs, you'll end up with unrelated outputs as inputs. The usual disclaimers ...


6

One option would be modifying the selection algorithm so that it selects ring partners in a similar date range to your own outputs. Then all of the transactions in your ring would be from the same date range, rendering this sort of analysis useless. RingCT will make this sort of solution a lot more practical, as the presence of correct output denominations ...


5

Essentially, RingCT increases the number of usable outputs to mix with and reduces the need to use multiple outputs for transactions. The first part is easy - because RingCT hides the amount, all transactions are interchangable. I can mix a 10 xmr output with a 1000 xmr output... because you can't see the amount on the chain anymore. For instance, in the ...


5

I'm not sure how this can/will be addressed in the future, but a few ways to avoid the issue now are: Mine some coins in addition to buying them. If you mine even a half a coin per week, that slow trickle of coins into your wallet will produce outputs spread out over time. If you make a large purchase of coins, then don't withdraw them all at once. If you ...


5

There is a lot of code indeed. Since you mention temporal alignment, I assume you mean selection of the real outputs (as opposed to fake ones). The code is in src/wallet/wallet2.cpp, and the interesting functions are: get_output_relatedness: this returns a score for how much two outputs are thought to be related (ie, same tx, from similar heights...) ...


4

You cannot. It will be set when the transaction is mined.


3

Accounts are groupings of subaddresses for presentation purposes. There is also the side effect that when you spend out of an account, any outputs received at any subaddresses within that account may be combined. This is purely wallet logic. Funds cannot usually be spent across subaddresses which span multiple accounts because of wallet logic. The wallet ...


3

Both cases are possible. Filler.


3

Note: I am currently maintaining the Mymonero backend. Mymonero currently selects outputs at random over the complete set of possible outputs. So guessing the real output is not necessarily trivial. The wallets try to select dummy outputs with a bias towards newer outputs, based on research indicating that there is a bias towards the real output being spent ...


3

For your particular case: use the latest version of monero-wallet-cli, and set min-outputs-count 1000. This will tell the wallet to not include a second unneeded input. However, your transaction will look different from the majority of other transactions, which tend to have 2 inputs. As this new code gets used more and more though, there will be a good mix ...


2

In theory, you could choose yourself if the software supported it but I don't see much benefit in doing so. In practice, the current monero-wallet-cli has 2 different transaction building algorithms depending on which transfer command is invoked. The 2 commands for the monero-wallet-cli are transfer and transfer-original. I'm not familiar with how they ...


2

If you have unspent outputs from non-rct transactions, they are mixed with other non-rct transaction outputs in the same manner as before (an attempt is made to find a mixin number of other outputs of same amount). Then, the amounts of each output in the new rct-transaction are separately "masked". Each verifier (all other nodes), create an "identity" ...


2

I am not sure what is the method used by MyMonero but the reason to be diferent of the core its because its developed separately, the devs are not the same.. Tecnacly you could choose the inputs to mix with yours by hand, but I belive that there is no wallet allowing this at the momment


2

Just adding the codes to the functions referred to by @user36303 for those who don't know how to access it. get_output_relatedness: // This returns a handwavy estimation of how much two outputs are related // If they're from the same tx, then they're fully related. From close block // heights, they're kinda related. The actual values don't matter, just // ...


1

This particular problem does not apply, since half of the fake outputs are selected from the last 1.8 days or so. The rest are taken from the rest of the blockchain. So as the chain grows, the recent outputs selection is not affected, only the "whole blockchain" tail is. That said, improving the fake output selection algorithm is something that'll have to ...


1

This issue is a known problem. A solution is discussed here: https://github.com/monero-project/monero/issues/1673. A solution hasn't been created yet but the general plan is, as you suggested, to use some kind of probability distrubtion to selected inputs. In the edit in the first message of the above github issue, olarks mentions he is using data from ...


Only top voted, non community-wiki answers of a minimum length are eligible