It's just the hex of a little-endian byte-order encoded number (i.e. when swapped around you get 0xE8D4A51000).
Perhaps this will help you see:
bin = binascii.unhexlify('0010a5d4e8000000')
unhexlify converts the hex to binary and the format specifier <Q used by ...
The Hs value in your failing transaction is incorrect. You've written 4e2918eb07facce065c1fcfe610a5b7d18064d64a7b8844d1844872f6d60159f but it should be f9b573a61a7e27c8dc3d48448e4184c117064d64a7b8844d1844872f6d60150f.
This is happening because your Hs function is doing keccak but not sc_reduce32. You were lucky that in the first transaction, the result of ...
The structure of your whole extra field is:
01 - TX_EXTRA_TAG_PUBKEY (1 byte)
49fa9fbadf1c1a4d054c6cbf918778f869ad02103501d8da7eec8762eb2202e6 - the tx pubkey (32 bytes)
04 - TX_EXTRA_TAG_ADDITIONAL_PUBKEYS (1 byte)
04 - the number of tx additional pubkeys that will follow (varint)
Also take tx b43a7ac21e1b60ad748ec905d6e03cf3165e5d8c9e1c61c263d328118c42eaa6 as an example.
We calculate H( H(prefix) || H(base) || H(prunable) ) for TXID.
Actually, we can divide the transaction into 3 parts perfectly without removing any bit.
The first part prefix should be
L = "...
Where are you getting your information about the structure of a transaction?
You forgot to include the hex 0001020005, which consists of the unlock time 00, the number of real inputs in the transaction 01, the input type of the first real input 02, the input amount 00 (0 to indicate it's an encrypted amount), and 05 indicating the number of key offsets that ...
It is a 64 bit little endian unsigned integer.
If you're asking "how do I get a human amount out of an atomic unit number", divide by 1e12. cryptonote::print_money in the Monero source does this without using floating point operations (print the number, then manipulate the string).
Extract the tx public key R from the tx extra field, and for each output, it's key
K and index i, then using your private view key a and public spend key B, you own the output if:
Hs(8aR||i)G+B == K
To find out how much you received, take the encrypted amount e for that output index from the transaction's ecdhInfo field and decrypt:
If a transaction includes a key image in a ring which corresponds to one of the outputs you own, then it is a transaction you sent. If no key image in a tx corresponds, then it is not a transaction you sent. This holds regardless of whether any output is sent to your address. Usually, when you send money, there will be a change output back to you, but not ...
The daemon (monerod) has no wallet functionality, it's for working with the blockchain. To determine incoming transactions for a given wallet (e.g. viewable and spendable using your wallet keys), you would need to scan the blockchain for outputs owned by your wallet and check their spent status.
A full scan (in pseudo code) looks something like follows (...
How do I view only these transactions that were sent to this subaddress?
[wallet]: help incoming_transfers
incoming_transfers [available|unavailable] [verbose] [uses] [index=<N1>[,<N2>[,...]]]
Show the incoming transfers, all or filtered by availability and address index.
Firstly, the market price of Monero in EUR has little bearing on any of this.
Secondly, mined or transferred? The question is not clear. Regardless...
There is no cap on the value amount you can transfer (so long as you obviously own that amount) and the amount of Monero that can be mined is dictated by the emission schedule.
However, when considering ...
Beyond the somewhat dated CN doc you referenced, and if you need more specifics, the best resource is really the code. For example, you can see that the tx prefix is serialized (src):
if(version == 0 || CURRENT_TRANSACTION_VERSION < version) return false;
What is the max no of input for Monero tx?
The only restriction affecting the quantity of inputs a tx can include is the overall tx size maximum, 149.4kB [src].
How does it affect the no of decoys?
Each input has its own ring. Thus for each input being spent there is the input itself, 10 decoys and 1 key image.
Does it mean that if the number of ...
The encrypted/masked amounts are stored in the tx ecdhInfo field.
If you want to view these masked amounts on an explorer:
Scroll to the bottom and click "Show JSON representation of tx".
If you want to view in a daemon:
You will need the address/subaddress and private view key to decode the amounts.
Go to xmrchain.net and fill in the missing address and viewkey.
Edit: Here's some light reading for deeper knowledge of Monero.
Transaction structure is described in detail in Appendix A/B.
Consult to the Varint description and transform from decimal to variant format for key offsets and transaction fee.
[1.] What is the format of key offsets?
799048 -> c8e230
782511 -> afe12f
216704 -> 809d0d
841722 -> faaf33
So the key offsets should be c8e230afe12f958d49809d0dfaaf33
[2.] What is the format of transaction fee?
Same as [...
Using the example from this question's answer, and following jtgrassie's recommendation to use https://xmrchain.com with "More Details" -> "Show JSON representation of tx", the tx extra field can be found in here.
EDIT: better instructions
Go to https://xmrchain.com
Enter the transaction hash you want to look up, e.g. the example here
Go to bottom of page ...
Is there an example of a transaction that makes use of tx_extra field? Is this public unencrypted data?
Every transaction makes use of tx extra as it places the tx public key in there. The data is public but can be encrypted (e.g. payment IDs are encrypted in extra).
...that is viewable in the monero block explorer?
Select a transaction in https://...
So what exactly the miner_tx_hash field in the block, and what is its relation to the miner_tx and other transactions in the block?
miner_tx_hash is just that - the transaction hash of the miner transaction. The miner transaction is the transaction that pays out the reward for mining the block. The inputs to this tx are type gen as they literally generate ...
Why does Monero create two or more inputs for transactions?
This is done to try and make more transactions look the same. An attempt is made to make the transactions a 2/2 (2 input, 2 output transaction). Therefore, even if one of your inputs has enough to fund the output(s), the wallet will attempt to add another input as well.