DIP: aj-tx-vuln for enforcing transaction hygiene / rejecting vulnerable txes #129
Conversation
coolaj86
changed the title
|
Regarding |
|
That's not what this is about. This is about enforcing the Lexicographical Sort security update that was introduced back in 2015 to not reveal excess information about senders and receivers through the improper positioning in list indexes. |
| outputs are sorted, completely deterministically, as specified in | ||
| "Lexicographical Indexing of Transaction Inputs and Outputs". | ||
|
|
||
| Transactions with version 3 or lower SHOULD print a warning and MUST return an |
There was a problem hiding this comment.
who / what is printing this warning?
| (NOTE: this is compared in the _SAME_ byte order as written in the transaction) | ||
| - The length SHOULD be checked before comparing | ||
|
|
||
| As a side benefit, this also makes it possible to index transactions for |
There was a problem hiding this comment.
| As a side benefit, this also makes it possible to index transactions for | |
| As a side benefit, this also makes it possible to index transactions more |
| much information is made available without any breaking changes to existing | ||
| Master Nodes: | ||
|
|
||
| Before a transaction is signed: |
There was a problem hiding this comment.
it is not clear what this means
|
|
||
| For example, consider | ||
| [598fa5c477ebef8ab74979c8a51d159d8c028b332af973020ec58ec807f009cc](https://insight.dash.org/insight/tx/598fa5c477ebef8ab74979c8a51d159d8c028b332af973020ec58ec807f009cc), | ||
| which was selected while sampling transactions at random just minutes ago, and |
There was a problem hiding this comment.
| which was selected while sampling transactions at random just minutes ago, and | |
| which was selected while sampling transactions at random, and |
| - there are two recipients | ||
| - the sender's change address is `Xf7JKrFdbQaWTZszRsQthm2s4xXCX2uZRb` |
There was a problem hiding this comment.
explain how you know this in the dip?
| 1.0 recipient 1 or xpub 1 | ||
| 0.7 recipient 2 or xpub 1 |
| We can know, with very high confidence that: | ||
|
|
||
| - there are two recipients | ||
| - the sender's change address is `Xf7JKrFdbQaWTZszRsQthm2s4xXCX2uZRb` |
There was a problem hiding this comment.
Also this is VIRTUALLY impossible to be the case as one input and output both have the same address XmZQkfLtk3xLtbBMenTdaZMxsUBYAsRz1o that seems significantly more likely to be the change don't we think?
There was a problem hiding this comment.
Mentioned above, this was a typo. I had several txes open in the inspector and I copied from the wrong example.
I can go back and find the example that's typical of what I'm talking about. Picking 4 non-CoinJoin TXes at random, one of them will use the vulnerable naive implementation.
Formalize enforcement of security vulnerability fix as per "Lexicographical Indexing of Transaction Inputs and Outputs".
Preview
https://github.com/dashhive/DIPs/blob/dip-aj-tx-vuln/dip-aj-tx-vuln.md
TL;DR
A naive implementation of construction a transaction leaks information about the senders and receivers.
This is a known vulnerability which is fixed by "Lexicographical Indexing of Transaction Inputs and Outputs", however it is NOT ENFORCED by the nodes that are verifying transactions.
This summarizes the technical details of "Lexicographical Indexing of Transaction Inputs and Outputs", and provides a path forward to enforcing that vulnerable messages from poorly implemented clients are rejected.