Comments (8)
This goes back to the same proposal as before: separating coinbase spends from non-coinbase spends.
Upsides: protects non-coinbase spends from the de-anonymization risks associated with coinbase outputs. Coinbase outputs are likely to be attributed to either 1) a pool, or 2) a future p2pool consolidation transaction. Both cases lead to a strong heuristic (or worse) that indicates the decoy use is ineffective. If either 1 or 2 weren't true to result in the heuristic being weaker, then possibly this would be a non-issue. This would occur usually if p2pool use was small but not infinitesimal.
Downsides: force a "chrurn"-like spend of coinbase outputs for each miner, including mining pools and p2pool users. Implementation complexity.
I'm generally in favor of requiring this churn. Prevent non-coinbase spends from using coinbase outputs.
There are several options for how to handle rings for coinbase spends:
- Remove rings entirely and cut the losses, saving on efficiency.
- Select decoys from other coinbase outputs.
2 is interesting to me. Here are some strategies to keep in mind for option 2:
- We can set the ringsize to any number. Can be 16, can be 3.
- We can allow several numbers, eg: 1 (no decoys) and 3.
- We can select coinbase decoys from the same block. Eg: 2 decoys from the same p2pool block. This doesn't work for pools where there would only be 1 output.
- We can impose different rules on coinbase outputs that are unique to the block and those that are non-unique to the block. For example, where there are 3+ coinbase outputs in a block, we can use 2 decoys from that block. If there are only 1-2 coinbase outputs, we can enforce 0 decoys.
My first impression (subject to change) is the following:
If a coinbase output is being spent, then a wallet checks to see how many coinbase outputs are present in that transaction. If there are 3+, then set ringsize as 3 and select 2 decoys from the same block. If there is only 1 or 2, then select 0 decoys. Consensus code should perform this check to ensure p2pool users aren't sending coinbase rings without decoys.
This is one of the simplest ways to account for public pools mucking things up, while providing some basic level of protections for the coinbase outputs for p2pool users. In practice, this should mean that each p2pool spend is hidden among 2 other real p2pool miners in the same block. Consolidation transactions will result in negative heuristics, but they should be meaningfully less bad for a relatively small cost.
TODO: research/discuss this much more :)
Note on private miners and mining pools that was discussed in previous materials: this is now a non-issue in my mind. I am grouping these with p2pool users and focusing on protecting those instead.
from research-lab.
After thinking more, I am not sure this proposal is the right direction. Enote consolidation being statistically significant, and consolidating enotes with small amounts being expensive, is a general problem not specific to coinbase enotes. Implementing a specific solution for coinbase enotes amounts to elevating the circumstances of miners to first-class status in the protocol, without solving the more general problem.
If another major project on the scale of p2pool becomes active in Monero and would benefit from specific protocol changes (not trivial benefits - privacy and scaling benefits even), should we hard fork to accommodate them? To support protocol longevity by reducing hardforks (and not setting precedents that would justify a relatively higher rate of future hardforks), it seems better to aim for general solutions to problems. In this case, one general solution to the privacy impacts of consolidation would be a global membership proof. The cost of consolidations might be addressed by using aggregate membership proofs that scale sub-linearly with the number of memberships being proven (i.e. number of tx inputs).
from research-lab.
rings only of coinbase outputs
In practice, the ownership of coinbase outputs is publicly known (p2pool and most centralized pools publish this information), so such rings would do very little in terms of privacy. You could find the output that is owned by the same entity in each ring and that would reveal the real spends (and the amounts) in most cases.
It would actually be better if the "coinbase consolidation" tx didn't use ring signatures and only had one output. Such transactions would be very small and fast to verify (no membership proofs and range proofs needed) and would not leak any useful information since one output means the outputs have not changed ownership. The subsequent spend of the consolidated output would be fully protected.
Provably spent coinbase outputs would also enable more efficient pruning strategies. Currently about 15% of all newly created outputs are p2pool coinbase payouts, needlessly cluttering the output database.
2 decoys from the same p2pool block
As noted above, that would not work. P2pool publishes the address that owns each coinbase output. If you consolidate multiple outputs, all rings will have exactly one output owned by the same address, which leaks the real spends.
Example with a 3-input transaction (ring members and their p2pool address):
ring 1:
42yAHAH5at...6dy78x2gbp
48gjGsibKv...gxUPMe5N7g
4BBb6ZBPPP...RKtLi1jcMb
ring 2:
48gjGsibKv...gxUPMe5N7g
47ab14EokG...vu6JqWMsGw
44YdBost8R...2nZ55pXeCU
ring 3:
4AxaapsBMR...dqmAZLqaGN
48gjGsibKv...gxUPMe5N7g
42Pv7DvpXF...4NCR5NWC2K
You can immediately see that the transaction is made by the miner 48gjGsibKv...gxUPMe5N7g
.
The only way how this could work is if the wallet had access to the p2pool sidechain and selected all decoys with the same owner, something like this:
ring 1:
47ab14EokG...vu6JqWMsGw
48gjGsibKv...gxUPMe5N7g
4BBb6ZBPPP...RKtLi1jcMb
ring 2:
4BBb6ZBPPP...RKtLi1jcMb
47ab14EokG...vu6JqWMsGw
48gjGsibKv...gxUPMe5N7g
ring 3:
48gjGsibKv...gxUPMe5N7g
47ab14EokG...vu6JqWMsGw
4BBb6ZBPPP...RKtLi1jcMb
from research-lab.
There are two design choices available, leading to four combinations that differ from what we have today (coinbase and normal enotes mixed together).
Choice 1: membership proof (normal enote membership proofs would change to only reference normal enotes)
- no membership proof: coinbase enotes are spent directly with no decoys/ring signature
- coinbase-only decoys: coinbase enotes are spent with membership proofs that only reference coinbase enotes
Choice 2: tx type to spend coinbase enotes
- normal tx: coinbase enotes are spendable as a distinct input type in normal transactions (e.g. alongside legacy inputs and normal seraphis inputs)
- coin consolidation tx: coinbase enotes are exclusively spendable in a special tx type that is designed for consolidating coinbase enotes
The easiest and most efficient approach would be no membership proofs + normal tx. Balances would not need to be segregated, and the tech stack would not need to maintain another tx type (although separating the tx types would mean less dependencies to deal with when upgrading only one tx type).
- The main downside to this approach is the introduction of anonymity puddles between txs with only coinbase enotes (consolidations) and txs with mixed input types (spending from a general balance without taking extra care to consolidate coinbase enotes). It's easy to imagine some wallets mandating coinbase enotes be consolidated, while other wallets don't mandate that, leading to the implementation-defined puddling that we want to minimize. Currently there is no wallet-mandated consolidation, so consolidation vs free-spending is a user-choice distinction.
- A secondary downside would be exposing a fraction of the total input amount in normal txs (anywhere from 0%-100%).
from research-lab.
I propose that consolidation txs do NOT use ring signatures for inputs and instead expose the inputs being spent directly
The main downside of not using decoys here would be leaking amounts, as coinbase outputs are not encrypted. If consolidation txs used rings only of coinbase outputs, we could at least break this amount linkage (the new output(s) amount(s) would be unknown due to not knowing precisely which inputs are being spent). Hence, if we're going to add a new consolidation tx type, I'd certainly favor keeping ring sigs for this new tx type.
from research-lab.
The only way how this could work is if the wallet had access to the p2pool sidechain
The wallet would not need access to the p2pool sidechain as it could just select previous (owned) coinbase outputs (though this is of course problematic for a new miner with no/few previous coinbase outputs).
You make a good point (one I overlooked; that of p2pool publishing output ownership), which suggests no-rings on consolidation txs makes more sense now.
from research-lab.
Good point about the addresses @tevador - that's something I didn't consider.
from research-lab.
Are Global / Full chain membership proofs really looking likely/soon enough to completely table this conversation?
I don't personally see an issue with having miners in a bit of an "elevated status" -- they're pretty much vital to any PoW chain anyway, and p2pool is something that tackles an inherent issue with PoW: pool centralization.
Plus, it's not like anyone was suggesting an extra hard fork specifically for this change so the whole thing about 'rate of hardforks' doesn't quite ring true for me.
from research-lab.
Related Issues (20)
- Exploring Trustless zk-SNARKs for Monero's payment protocol HOT 107
- Bulletproofs++ HOT 2
- Investigate possibility of reducing 10-blocks lock HOT 19
- Remove the burning bug as a class of attack with a modified shared key definition HOT 2
- Remove Extra Coinbase Locktime HOT 5
- Consider Switch commitments for future supply security HOT 29
- Radical idea for forward secrecy and instant wallet sync HOT 13
- Flashproofs
- Avoid selecting coinbase outputs as decoys HOT 2
- Scale the blockchain with recursive ZK proofs HOT 2
- Archiving historic nullifiers with mutator sets HOT 1
- Porting Utreexo to Monero HOT 7
- increasing uniformity of number of inputs/outputs
- Class Group-based ZK SNARKs
- Add scripting to Monero via the specification of R1CS circuits HOT 14
- based monero address decentralized IP address, Abolish ipv4 and ipv6 HOT 8
- potential measures against a black marble attack HOT 29
- Mining protocol changes to combat pool centralization HOT 16
- Catalogue of Monero decoy selection algorithms HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from research-lab.