If a wallet has received an output in the past, that means the wallet will know the private key for that output. This is the case even if you restore the wallet from seed.
The private key for the output is calculated as x=Hs(8aR||i)+b, where a is the private view key, R is the transaction public key published with the transaction, i is the index of the ...
Adding to jtgrassies answer:
Perfect hiding and perfect binding are impossible to get.
A perfectly binding scheme implies a one to one relationship, each input is binded to one value in the output.
A perfectly hiding scheme implies a many to one relationship, each output can be hidden amongst many input values.
A slightly different example I can think of ...
This question seems to boil down to whether Keccak is suitable for the random oracle model.
This answer on crypto.stackexchange.com should answer your question: https://crypto.stackexchange.com/q/70707/69644
As far as I know, there is no bias when going from the low order group to the prime subgroup.
Sidenote: there was an unrelated attack related to the ...
As of the March 2019 hard fork, commitment masks are deterministically derived from the per-output shared secret. This means the ECDHinfo part of the transaction will no longer store the encrypted mask.
See the commit here: https://github.com/monero-project/monero/commit/7d375981584e5ddac4ea6ad8879e2211d465b79d
Therefore, to determine the commitment mask, ...
"prefix", "base" and "prunable" just refer to parts in the transaction.
Given the transaction hash is:
H(H(prefix) || H(base) || H(prunable))
"prefix" refers to these fields.
"base" refers to the signatures that follow the prefix.
"prunable" refers to any prunable parts of a transaction.
Here is the source that calculates transaction hashes in Monero.
Let's first recap the concept of input and output spaces. In our Pedersen
commitments, we are perfectly hidden because the input space is larger than the
output space - we have a many-to-one relationship. For our binding, the spaces
are the same size, the relationship is one-to-one, so can only be
computationally bound. The inverse of these relationships ...