Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimizing unspent outputs in output set. #253

Open
ghost opened this issue Nov 5, 2021 · 16 comments
Open

Minimizing unspent outputs in output set. #253

ghost opened this issue Nov 5, 2021 · 16 comments

Comments

@ghost
Copy link

ghost commented Nov 5, 2021

Did some research on outputs, found there are many old outputs that have never been included in a group signature. Can this be prioritized as part of the decoy selection algorithm? To select those outputs so that there status is more uncertain whether they have been spent or not.

https://yorha-0x.github.io/dormant-aeon/

@iamsmooth
Copy link

Reasonable idea, but maybe better as an upstream (Monero) issue. Or does Monero somehow handle it better? I guess the larger ring size would tend to naturally do this somewhat, but not entirely.

@ghost
Copy link
Author

ghost commented Nov 6, 2021

Monero things are slightly different with larger signature group sizes and encrypted amounts. All outputs are taken from the same signature pool. Aeon anonymity pool is essentially segregated into different classes by the output amounts. Larger outputs are less likely to be generated and transferred making them more traceable. I can see reducing the number of denominations as being somewhat effective so they share the same pool. (no need for 200,000 300,000 400,000 ... if they all use 100,000). The decoy selection algorithm looks a bit complicated I want to study before I make any conclusion about improvements to that.

@ghost
Copy link
Author

ghost commented Nov 6, 2021

Here is one deficiency I observe in decoy selection algorithm:

Same output spent multiple times in one transaction

These 3 inputs are all part of the same transaction and use the same output as part of their group. It would be impossible for someone to spend an output three times so 2 are proven decoys.

So that would be one basic improvement.

Input: 930f78477b02b24514c4198c23f1b9955703e45069368ae15d3b0d7c84cb7978
Group signature output set (3)
height output_id index coinbase
1,407,911 778a6fe50a7c2c45823ec8d624929c9372f2e78e54ae1fefb828e886a83ea110 388,265 True
1,408,108 13d8101489e706d31a92d581b798f9a57f67a1bd4c4ed5a40843c0d424ef38c8 388,470 True
1,408,179 f6ed9dd14e40bc842eea57603aab036eee25c93d8c309be7c8f43f7b0b593251 388,543 True

Input: d809e09011704abd27638665de4153805fc997907f0bca0b487ad3f5bcbfe32c
Group signature output set (3)
height output_id index coinbase
1,408,101 d5291f45c6305e7c5198e2f303b22c0ae1fb59d29a9b6b347d2868131eb363ef 388,463 True
1,408,172 3bb825f22654b678b7a8c9c59fcada6e3c28965752c5691c9d51e26f9e73fd6d 388,536 True
1,408,179 f6ed9dd14e40bc842eea57603aab036eee25c93d8c309be7c8f43f7b0b593251 388,543 True

Input: 7d5d3c3699d7ac9053e79bad65253ae8b9ba9a488ca02e4f03b95fe4a3efdc12
Group signature output set (3)
height output_id index coinbase
1,407,103 5230719cccfe2d0b27d42685d40887917dd9d5cc0b417f3e32a253f8afb57a52 387,441 True
1,407,416 747f591336abc7a0789d0bffda8e52af9042aac915f9188669658095fae9e6d3 387,761 True
1,408,179 f6ed9dd14e40bc842eea57603aab036eee25c93d8c309be7c8f43f7b0b593251 388,543 True

@iamsmooth
Copy link

iamsmooth commented Nov 6, 2021

I can see reducing the number of denominations as being somewhat effective

Yes this was discussed in Monero before Ring CT. The idea was to switch to some smaller denomination set such as 1s and 5s or 1s, 3s, and 7s.

You have an increase in the number of outputs, but usually not that many:

1 -> 1
2 -> 1+1
3 -> 3
4 -> 3+1
5 -> 3+1+1
6 -> 3+3
7 -> 7
8 -> 7+1
9 -> 7+2

9 denominations reduced to 3 with:

3x 1 output
5x 2 outputs
1x 3 outputs

There could be better ways.

@iamsmooth
Copy link

iamsmooth commented Nov 6, 2021

Monero things are slightly different with larger signature group sizes and encrypted amounts

True, but the basic issue of favoring uniformity (maybe?) and spending every output at least once would still tend to apply, albeit less likely. At one point I do recall an analysis in Monero of some percentage of outputs never being spent. It may be much less now that the ring size is larger.

@stoffu
Copy link

stoffu commented Nov 8, 2021

I don't see this as much of a problem at all; some outputs remain unused in any ring signatures, so they are definitely known to be unspent. So what? How can this be harmful?

@ghost
Copy link
Author

ghost commented Nov 8, 2021

That makes them distinct from other outputs thereby reducing the uniformity and making them more traceable. Also unused outputs can increase the anonymity pool.

Yes there is always some outputs unspent that is just a fact. But imagine using the same output multiple times in one transaction when there are countless unspent outputs.

@ghost
Copy link
Author

ghost commented Nov 8, 2021

Let me rephrase that,

Being unspent makes them distinct from other outputs thereby reducing the uniformity and making them more traceable. Also using unused outputs in group signatures can increase the anonymity pool.

@ghost
Copy link
Author

ghost commented Nov 8, 2021

@stoffu, if you have time, can you see if this is correct? (code and logic) monero-project#8047

@stoffu
Copy link

stoffu commented Nov 9, 2021

@yorha-0x

That makes them distinct from other outputs thereby reducing the uniformity and making them more traceable.

Explain how outputs known to be definitely unspent contribute to increased traceability.

The issue (of using the same output in multiple inputs in the same tx) addressed in Monero PR8047 is a different matter, and I can agree that avoiding this can be beneficial.

@ghost
Copy link
Author

ghost commented Nov 9, 2021

I would say the most important thing about "unspent outputs" is that it reduces the uniformity of the output pool. Known unspent outputs can be separated from the total output pool in a trace analysis when paired with other external information. It provides meaningful information about the state of outputs and any meaningful information can be used in trace analysis.

Also, more fundamentally, I consider the meaning of "right to privacy" to include that "it is not publicly known whether or not I have spent my funds". No one should be able to know if my funds are spent. That includes the opposite: no one should be able to know if my funds are unspent. That is an equally private matter that should only be known to an individual who possess their keys.

Now I am not suggesting removing unspent outputs because I don't know how that would be feasible. But can they be minimized in a statistically unbiased way? Such as why are outputs spent many times in one transaction when there are many outputs which have never been included in a group signature? Also why are there so many denominations for obscure output amounts?

I am just brainstorming here and I appreciate your challenge to explain myself clearly. I hope I have accomplished that but I can't say whether what I write is really true, it is just my understanding. Do you agree that these "unspent outputs" increase traceability or at least infringe on aeon users' right to privacy?

PS Thank you for reviewing that. There is always places to make mistakes so your peer review is very much appreciated!

@iamsmooth
Copy link

@yorha-0x

I consider the meaning of "right to privacy" to include that "it is not publicly known whether or not I have spent my funds"

You can address this yourself with one round of churn after receiving the funds. The sender then doesn't know (others already don't know because they don't know who's funds those were anyway).

I do think it is ideal that all outputs be included in rings if there is a way to do that without causing other problems. If nothing else it increases the anonymity set (using the term broadly), since unspent are clearly not included.

@ghost
Copy link
Author

ghost commented Nov 12, 2021

Yeah, the sad thing is most people don't know about this. Also I have read many times over the year discouraging churning. I hope we can alleviate the situation so that it is not a burden put onto users and is "by default" a protected right like what is promised by most of these cryptonote coins.

Definitely increasing the ring size even slightly would help but I understand the careful work that has been put into this coin to make it lightweight and efficient. So let's not swamp that with one fell swoop before we consider some smaller targets. I am looking at these two small issues which I believe would help improve the situation:

No duplicate group member in transactions.

Combining less used denominations.

@ghost
Copy link
Author

ghost commented Nov 18, 2021

Not seeing much progress on monero PR. Waiting on that before continuing.

@ghost
Copy link
Author

ghost commented Nov 29, 2021

@iamsmooth
Copy link

Without CT, there is a different privacy issue with denominations (related to above reddit). If you use a 100 output to send 1 (w/99 change) the receiver knows you had 100. Can't really be solved without CT or some form of churn or output breaking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants