Transferring IOTAs from one address to another requires several different transactions:
An output transaction that increments the recipient's balance by the desired amount.
(usually) 1-3 inputs that authorise the spending of the IOTAs from the sender's address(es)1.
(if necessary) a change transaction that sends any remaining amount to a new address owned ...
This cheat sheet present a bundle with :
2 outputs: 100 iotas to address B and 202 iotas to address C.
the remainder : 49 iotas
The inputs are comming from 3 addresses: A1, A2 and A3.
In the example, all signatures expand on 2 blocks - except the output1 on 3 blocks -
credit to @abmushi (on slack) for the bundle cheat sheet :)
It's important to understand that IOTA use UTXO scheme (like bitcoin and probably many other cryptocurrencies).
UTXO means Unspent Transaction Output.
To understand from where the UTXO concept comes from I will first describe it "in theory" and in the end I describe how it is really implemented in IOTA.
How it works ?
Assume that Alice owns an address ...
There was a bug in the wallet software related to absence of https://github.com/Come-from-Beyond/ISS/commit/de1a279450558848a81858fd57b023719eb9a0d3. "M" should be avoided to prevent leakage of the corresponding (and following) private key fragments.
The two numbers are the
the latest solid subtangle milestone index
The "latest solidsubtangle milstone" is used for sending transactions. For a milestone to become solid your local node (or whatever node your lightwallet is connected to) must basically approve the subtangle of coordinator-approved transactions, and have a consistent view of all referenced ...
When you apply naïve Winternitz signature scheme on a (non-normalized) hash, the amount of private key data you leak is not uniform - a hash of e. g. 999⋯9 would result in all (or none, depending on how you implement it) of the key being leaked. As a consequence, even after one signature there is a varying chance that brute forcing another hash (that leaks ...
A user will usually broadcast a collection of multiple transactions (also called a bundle) when interacting with the network. One bundle could consist of
Withdrawal transaction (acquire funds to be spent from some address)
Payment transactions (pay some other address a sub or total amount of the funds withdrawn)
Change transaction (deposit unspent funds ...
A bundle can also have only 1 transaction (zero value tx), 3 transactions (if there is no remainder, therefore no change address) or more transactions (if there is a remainder and/or there are multiple output addresses).
The transactions in a bundle are always linked via trunk transaction hash (so trunk transaction hash of the first transaction in a bundle ...
Short answer: it is not.
Long answer: Signatures are not supposed to protect anything else than the iota values and (obsolete)tag fields. Therefore, as long as your transaction is not confirmed, anybody could replay/reattach it with a different content in the message field of the receiving transaction and the luckiest transaction would win.
Therefore, you ...
The current transaction structure is not the final variant. Later extraDataDigest field will be added, that field will be a part of the bundle essence (signed part). Setting the field value to the hash of signatureMessageFragment would allow to detect cases of changed content.
You could use obsoleteTag now (store the hash fragment into the last 27-N trytes, ...
A signature may even need more than two transactions, e. g. if it is a multisig signature.
Yes, the reason is that Winternitz signatures are large (for every tryte you are signing and each key that is part of the multisig you need a full hash length, i. e. 81 trytes in case of KERL, of signature data).
All spending transactions of a bundle sign the same ...
obsoleteTag will be removed soon. The preliminary final design of the bundle essence fragment is:
extraDataDigest [243 trits]
address [243 trits]
value [81 trits]
issuanceTimestamp [27 trits]
timelockLowerBound [27 trits]
timelockUpperBound [27 trits]
bundleNonce [81 trits]
Now that part contains obsoleteTag.
A bundle consisting of N transactions can reference 2*N completely different transactions (almost half of them will belong to the bundle). The chain of trunkTransaction references must form the correct bundle, branchTransaction fields can reference tails (transactions with currentIndex = 0) of any other bundles.
Current implementation of the tip selection ...
Winternitz signature scheme requires to have the checksum for the signature to be secure. Bundle normalization is an alternative way of keeping the signature secure while reducing its "strength" a little. Usage of the checksum was impossible because the final structure of the transactions wasn't supposed to contain it. In the final design the normalization ...
The bundle hash is calculated from the "essence" parts (address, (obsolete)tag, timestamp, value, bundle index) of all transactions.
Then the bundle hash is inserted into all transactions of the bundle.
For all transactions that have a negative value, i. e. they spend IOTA, a signature of the bundle hash is added to the transaction, too.
Then, starting ...
iri accepts and broadcasts single transactions, not whole bundles. Therefore when iri receives the first transaction of a bundle, it not necessarily can see already that this transaction is part of a broken bundle (as probably some more transactions are still missing at that point). So it will accept it in the hope that the rest of the bundle will arrive ...
It's not included in the bundle hash, but it is included in the transaction hash. If you look into how MAM does it, the message fragment contains the message, signature, and sibling hashes( for merkle root calculation ), all encoded into the message field.
The message is not 'validated' because any tx with positive value needs no signature, but the tx hash ...
I found the cheat sheet to be somewhat misleading as it assumes, that one tip to be confirmed is the latest solid milestone. You'll find a precise answer here. I had the exact same conceptual question. Make sure you read all comments!
Strictly speaking : branch and trunk transaction can be the same. Let's think about transaction validating the genesis: there was only only one transaction on the tangle... so impossible to pick 2 distinct tips. (same reflection is also valid for a tangle with very low load: in this situation, there is almost always no more than one single tip on the tangle.....
You have a balance not in an account, but on an address. Due to the fact that IOTA uses one-time signatures, you are advised to create transactions that empty an address fully.
So, if you have 10 Mi on address X, you(r wallet) will actually create a transaction that takes 10 Mi from address X, sends 1 Mi to address Y and sends the remaining 9 Mi to a new ...
The message is stored in the space where the signature normally would be. In the signatureMessageFragment of the first transaction in the bundle, there is GACDZCTCEAADTCGDGDPCVCTCGA and a whole lot of 9's. These trytes translate to "oke message" as you can see on the ASCII Message to Trytes converter here.
I checked the code (in the Java library) and here is how it creates a bundle.
Let's say that tip0 and tip1 are the 2 tips to approve.
The last transaction in the bundle (transaction with highest bundle index) will use
tip0 as trunk-transaction
tip1 as branch-transaction
All other transactions in bundle will use
the next transaction in bundle as trunk-...
Your seed is never compromised by address reuse. The only thing that is compromised is the private key of one of your addresses. That's why the wallet moves remaining funds to a different/new address when sending from an address.
Sending the same bundle multiple times (over testnet and mainnet or when reattaching) does not compromise the address. It is only ...
The Java library is quite picky about length of fields you set. In particular, the address has to be 81 trytes and both tag and obsoleteTag need to have 27 trytes. If the lengths are different (or these fields are empty), you get weird signing errors.
Changing the address to "999999999999999999999999999999999999999999999999999999999999999999999999999999999" ...
Yes, you are right.
In case of security = 1 and you are spending all the funds on one address (with no change needed), you can even get away with only 2 transactions (one with the input and sig, and one with the output).
As I'm new to Iota development I can not tell, if this is really the correct way to do it but I found the following works for me and the result looks correct and like what I expected it to look like:
After requesting all transactionObjects from the confirmed Tips (like I discribed in my question) I go ahead and get the bundle for each transaction:
Although the construction seems a bit odd, now I understand this specific setup was just temporary. In a new release (current v22.214.171.124) the new bundle structure will adhere to the "each tx confirms 2 others"-philosophy. So if a bundle consists of N tx it will confirm 2*N other tx. (N-1) of these point to internal tx (to chain the tx together) and (N+1) point ...
Nonces are being added to transactions, not to bundles. So for each transaction in the bundle the user
have to do a small Proof-of-Work: to find such nonce that will result in the hash of the transaction
with a certain number of trailing zero-trits.
So the POW required for a bundle increases linearly with the number of transactions in that bundle.
The C# port is not up to date as it (still) uses the old CURL hashing function (used until beginning of August 2017).