According to Monero Blocks statistics the highest pre RingCT ringsize was 850. I was not able to immediately locate that transaction on the blockchain.
I was able to find a sample 150 mixin transaction from block 1,067,631 with a size of 70,219 bytes and a transaction fee of 0.69 XMR.
The above pre RingCT ring size and transaction size records were prior ...
Transaction hash, transaction id, txhash, txid, are all terms for the same thing.
When you send a transaction, the tx key will be saved in your wallet cache (assuming you have this enabled, this is the default for most wallets, but for a short time after this feature was coded, it was not the default. Use set store-tx-info 1 to enable, in case it's off).
It will not matter if it is 13 or 25 words seed since the script will just need to add another word in the first, last or in between your seed and create the wallet. Your problem is implementing it for the real monero-wallet-cli/monero wallet since it will take longer to scan compared to mymonero. In mymonero a single query would return that the wallet is ...
There is an outPk for each output in a transaction, and therefore you'll need the outPks from the transactions that created each of the inputs. (Where each outPk is C, i.e. the sum of Ci).
OutPks are stored after the pseudoOuts and ecdhInfos in every version 2 transaction.
It turns out that for version 2, the hash is computed by combining 3 other hashes and then computing the hash of the aggregate.
To be specific, the tx hash turns out to be:
H(H(prefix) || H(RingCTBase) || H(RingCTPrunable))
Where H is the Keccak256 hashing function, prefix is the Transaction Prefix serialized, RingCTBase is the RingCTBase serialized and ...
I made one very simple recovery tool a while ago, by modifying Luigi's tools: https://github.com/JollyMort/xmr.llcoins.net/blob/master/README.md
This one can recover any 2 missing words, provided that you know the address and the checksum word is known.
The last word is a checksum for the first 24 words.
if you miss the last word, you can easily find it deterministically and there's only one solution
if you miss another word, you can brute force all the possibilities that are valid based on the last word. You then need to test these possibilities against a wallet to see if transactions are found. That step ...
The private tx key is named r in the CryptoNote whitepaper. Note that r is randomly chosen. In addition, the private tx key can be used as prove of payment on a case by case basis. That is, in case of a dispute, you can prove that you paid the receiver by publishing the private tx key (which you can obtain from the wallet), the transaction ID, and the ...
The 'tx id' is also known as the transaction hash. It is a keccak hash of the transaction data.
This hash is used to uniquely identify the transaction, which is why it's also referred to as the 'tx id'.
The tx id is actually a hash of 3 hashes:
A hash of the 'transaction prefix', which contains information such as the inputs, outputs, and the 'extra' ...
Monero uses keccak-256, where 256 refers to the bit length of the hash produced.
Note that SHA-3-256 is slightly different, and so will not produce the same result as keccak-256.
This library will produce the correct hash: https://www.npmjs.com/package/keccak
"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.
This is the structure of a Monero transaction, listed in the exact order that the information will appear in the transaction structure: Size requirements for different "pieces" of a Monero transaction
Many of these terms will be confusing to you. A great resource for understanding all of the elements of a Monero transaction is the Zero to Monero ...
Each account in a wallet has a number, and each subaddress in an account has a number.
You can add the account_index and subaddr_indices options when calling the transfer method to indicate from which subaddress (or subaddresses) the coins will be taken.
For example to use subaddress n°3 in account n°2 as source of the coins:
If the transaction pool is empty, a mined block will still have 1 transaction (the miner's transaction claiming the block reward).
So to compute the Merkle tree root, you call the tree hashing function on the single hash of the miner transaction, which is in fact equivalent to doing nothing (Merkle tree root = miner transaction id).