ukoehb / monero Goto Github PK

On the sixth and final test_aggregated_bulletproof_plus performance test instance here, an exception is thrown with the message: sv/gamma are too large. The assertion statement can be found here, but I don't know enough about bulletproofs to debug it.

Some issues with the TXID calculation:

1. Doesn't explain why the input key images are hashes twice. IMO it's sufficient to have them in the prefix, which would save 1 hash.
2. The final hash hashes more than 128 bytes of data, which requires two calls to the Blake2b compression function. This has the same performance impact as one additional hash. Since 3 hashes take 96 bytes, the domain separation stuff could still fit into the remaining 32 bytes if it was less verbose.

In some places (for example here), code specific to the ed25519 elliptic curve leaks into the Seraphis logic.

It would make sense to abstract that away. Makes more sense in the context of the proposal to switch to a different curve, but also would make it easier to check that the code matches the Seraphis specification.

1. When there is >1 tx pub key included in tx extra:

   • wallet2 generates derivations for every tx pub key and checks every derivation against every output in each tx.
     • Source:
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/wallet/wallet2.cpp#L2219-L2222
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/wallet/wallet2.cpp#L3155-L3156
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/wallet/wallet2.cpp#L3174-L3180
       • monero-project@11ae187
         • Note: it looks like this commit to scan using every tx pub key was added because there was a bug in cold wallets that used the 2nd pub key.
   • The Seraphis lib only checks the first tx pub key included in tx extra.
     • Source:
       • Source 1
       • Source 2
   • The problem: if someone crafts a non-standard tx using the nth tx pub key (where n > 1), then the Seraphis wallet lib wouldn't identify any receives in the tx but wallet2 would.
   • The proposed fix: the Seraphis lib could scan using all tx pub keys in tx extra.

2. When the first additional pub keys vector in tx extra has unequal number of pub keys than there are enotes in the tx:

   • wallet2 generates derivations for each additional pub key, and will then ignore those additional pub keys beyond the number of enotes in the tx and scan the tx normally.
     • Source:
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/wallet/wallet2.cpp#L2224-L2230
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/wallet/wallet2.cpp#L3157-L3158
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/wallet/wallet2.cpp#L3170-L3178
       • https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/cryptonote_basic/cryptonote_format_utils.cpp#L1059-L1063
   • The Seraphis lib doesn't scan the tx.
     • Source:
       • Source 1
       • Source 2
   • The problem: if someone crafts a non-standard tx that includes an unequal additional pub keys than enotes in a tx, then the Seraphis wallet lib wouldn't identify any receives in the tx but wallet2 would.
   • The proposed fix: if there are more additional pub keys than enotes, the Seraphis lib could ignore the additional pub keys beyond the number of enotes in a tx. If there are fewer additional pub keys than enotes the Seraphis lib could just scan using additionals corresponding to the lower indexed enotes.