Open jagerman opened 5 years ago
bitkis
commented
5 years ago Bad wordings and not quite accurate/missed explanations on our side.
We've made some modifications to the document, hopping now it explains things better. Please take another look at those.
P.S. Happy New Year Jason :)
jagerman
commented
5 years ago The edits don't really address my concerns. To summarize:
the list isn't completely consistent because it depends on announces being received, but announces can arrive and expire at different times on different nodes.
The list can change even for a single SN during a transaction lifetime if one of the SNs selected in the auth sample reaches an expiration threshold. (For example: if you have a N-second expiration and the payment includes an auth sample node with N-2 seconds to expiry).
RTA Payment ID is unique since PoS Proxy needs a new one-time identification key, as well as an RTA payment ID, for each RTA payment;
- because the RTA payment ID is based on a random value generated by a single component on the network (i.e. the PoS proxy), this means that network component can be modified to choose their own supernodes: you just modify the code to keep generating one until you get one that you like (i.e. one that selects several of your own supernodes). For example, when you need to generate a payment ID, spend half a second generating them and choose whichever one selects more of your own SNs.
Edit: another example where this inconsistency will matter is on SN restarts. If I restart my proxy SN then it will, until a full announce cycle has passed, have a very different view of active nodes on the network. Is the network just going to simply reject any POS payments that get submitted to a freshly restarted POS proxy, because they will have the wrong signatures? Or will initiated payments just fail for the first couple of minutes until the POS proxy is brought back up to the (roughly) common state? Both outcomes are terrible, but the only way to avoid them is either throw away validity (in which case SNs game the system) or to use something more like the blockchain synchronization mechanism that I suggested in #187.
bitkis
commented
5 years ago Thank you Jason. It appeared some important information was still missed in the document at the time you reviewed it. Sorry about that.
To summarize, the whole idea is to allow inconsistency such that the index of a SN - auth sample participant varies within some known range.
because the RTA payment ID is based on a random value generated by a single component on the network (i.e. the PoS proxy), this means that network component can be modified to choose their own supernodes: you just modify the code to keep generating one until you get one that you like (i.e. one that selects several of your own supernodes). For example, when you need to generate a payment ID, spend half a second generating them and choose whichever one selects more of your own SNs.
Hmm... half a second, really? :) We're talking about finding a strong hash collision here
Regarding the restart example: yes, you proxy SN would need to wait a full announce cycle to start processing the payments. Terrible? But wait, isn't a blockchain node useless until it complete synchronizing its blockchain? :)
jagerman
commented
5 years ago Hmm... half a second, really? :) We're talking about finding a strong hash collision here
There must be something else missing, then, from your description. I'm assuming that the proxy SN generates the payment ID. If I want to cheat the system, I just generate many payment IDs and the resulting hashes well in advance (e.g. using a GPU) and then, when I process an RTA transaction, I choose whichever pre-hashed value selects more of my own auth SNs. No hash collision is involved. If you move the payment ID generation to the POS terminal, instead, then the POS terminal gets to do the cheating.
I'm more concerned, now that you point it out, about the use of a slow hash here: that's adding a huge computational load on the network for handling RTA transactions and is going to cut the maximum potential RTA TPS of the network by something like 40x. It's also entirely unclear whose job it is to validate them, and what happens if they fail validation.
I'm also unclear how it will enter the network consensus rules since there will be different consensus rules on different nodes and at different times, and thus identical data can potentially cause a chain split. It seems as though this could be used to deliberately attack the network: create RTA transactions that uses a barely-valid SN auth sample until the network splits due to slightly different visibility on different parts of the network.
I can only conclude that it won't be part of the network consensus rules, but that means I'm back to being able to manipulate it: i.e. have my own proxy SN use my own 8 RTA SNs which will be modified to be perfectly happy to lie about being selected into an invalid sample.
Terrible? But wait, isn't a blockchain node useless until it complete synchronizing its blockchain? :)
A node restart takes around 5 seconds on a decent machine, and only very rarely has to resync anything (and if it does, it's typically just one block). You're talking about something that is going to take 13 (5s + 1m) to 121 (5s+10m) times as long. 5 seconds of downtime is manageable, a minute (or 10 minutes) of downtime is not even comparable.
It actually doesn't appear to have any of the listed advantages:
False. Consistency in a decentralized network means that all properly performing network nodes agree on an answer. The blockchain-based list is indeed consistent, but the sample selection doesn't only depend on that; it also depends on the announce-based list, and the announce system can easily differ across individual nodes. Network latency, local system clock differences, node restarts, and momentary connection losses can all contribute to such inconsistencies. Thus the algorithm is not consistent across the network. You even stated as much earlier:
It is completely irrelevant if it is "high" because if it isn't 100% you cannot reject RTA transactions that used the wrong supernodes, and if you can't do that then you allow proxy SN operators to cheat the system by altering their proxy SN to use their own 8 RTA SNs all the time (and thus capture all of the fees of every transaction through that proxy SN).
Something either is or is not consistent. If random chance makes something "even more consistent" then it is not consistent. See point 1.
This has the same cheating potential as having an inconsistent list: even if the list itself wasn't inconsistent, this opens up another exploit: I could simply craft a payment ID (rather than using a fully random ID) designed to choose as many of my own SNs as possible.
I'm also concerned here by the use of payment IDs: if this is a payment ID included in the transaction then it is relying on a feature that is already deprecated by Monero and on the way out (even in its encrypted form) in favour of using vastly superior one-time subaddresses. But perhaps you just mean an internal payment ID rather than a transaction payment ID?
It is unclear to me what this means. If you mean that any supernode can obtain the same list given the same payment ID, then this is just point 1 again (and is not true because the list is not consistent). If it means that the SN sample can be verified by some other node then it is similarly wrong: there is neither the temporal data (which SNs were valid at block X?) nor the sample consistency that would be required to perform such verification.