IOTA tutorial 10: Transaction and Bundle
HTML-код
- Опубликовано: 24 июл 2024
- If you like this video and want to support me, go this page for my donation crypto addresses:
/ mobilefish
This is part 10 of the IOTA tutorial.
In this video series different topics will be explained which will help you to understand IOTA.
It is recommended to watch each video sequentially as I may refer to certain IOTA topics explained earlier.
The squares in the Tangle represents transactions and each NEW transaction should reference transactions which have no other transactions referencing them.
These non referenced transactions are called tips (tip 0 and tip 1).
Each transaction consists of a bundle of transactions.
An example of an IOTA transaction where 3 IOTA’s are transferred from Alice's address to Bob's address:
www.mobilefish.com/download/i...
A transaction consists of a bundle of transactions: currentIndex 0 refers to transaction 0, currentIndex 1 refers to transaction 1, etc..
All these transactions have the same bundle hash.
All transactions in the same bundle should be treated as an atomic unit.
It means that either all transactions of a bundle are confirmed, or none of them are confirmed.
Every transaction in the bundle requires it own PoW, see the different nonces in the transactions.
There can be 3 different types of transactions inside a bundle:
- Output transactions
Transactions where IOTA’s are send to one or multiple addresses.
The IOTA light wallet can only send to one address. These transactions are easily recognised because the transaction value is always greater than 0 and the address does not belong the sender.
- Input transactions
There are two types of input transactions:
* Input transactions where the value is negative.
These are the transactions where the complete balance from that address is spent.
* Input transactions where the value is greater than 0.
These are the transactions where unspent/not used IOTA’s are send to a new change address in the senders wallet.
- Meta transactions
Zero value transactions are meta transactions. The signatureMessageFragment of these transactions could either hold a signature or a message fragment.
Transaction examples:
www.mobilefish.com/download/i...
www.mobilefish.com/download/i...
www.mobilefish.com/download/i...
www.mobilefish.com/download/i...
By increasing the security level you increase the key size, meaning you increase the private key size.
Depending on the key size, this signature is fragmented and stored in 1, 2 or 3 transactions.
Wallet 1, using security level 1, the signature is stored in 1 transaction:
www.mobilefish.com/download/i...
Wallet 2, using security level 2, the signature is fragmented and stored in 2 transactions:
www.mobilefish.com/download/i...
Wallet 3, using security level 3, the signature is fragmented and stored in 3 transactions:
www.mobilefish.com/download/i...
By increasing the security level you increase the signature size and thus the number of transactions needed to store the signature.
IOTA signatures are larger than Bitcoin signatures due to IOTA's use of Winternitz one-time signatures to gain quantum resistance.
Each single transaction inside a bundle consists of 2673 trytes and much of it is taken by the signatureMessageFragment which has a size of 2187 trytes (approx 82%).
A single transaction inside a bundle requires 2673 trytes or ~1.55 kBytes.
A bundle can have one transaction, for example when you attach an address to the Tangle.
A bundle can have an X number of transactions.
For example: Alice has a wallet (using security level 2) with address 0 to address 99 with each address having one IOTA.
When Alice transfers her complete wallet balance to Bob, she creates a transaction bundle containing 201 transactions: 1 transaction to Bob, 100 transactions withdrawing 1 IOTA from each address and 100 meta transactions to store the second signature fragment.
Each transaction inside the bundle requires a PoW.
Let assume a PoW takes 20 seconds per transaction.
Please note: This 20 sec is arbitrary chosen!
In this example the total time to create the bundle, takes:
201 transactions x 20 sec / tx = 67 minutes.
You can easily create a transaction bundle containing lots of transactions.
However watch out for the Proof of Work.
Check out all my other IOTA tutorial videos:
goo.gl/aNHf1y
Subscribe to my RUclips channel:
goo.gl/61NFzK
The presentation used in this video tutorial can be found at:
www.mobilefish.com/developer/...
#mobilefish #howto #iota 
Наука
Really good explanation! Thank you very much! It helps me much to handle the iota libraries
Wow, this reminds me of school. Like, I really need to learn this but gosh its a lot to take in sometimes. :) Well done as usual, Mobilefish.
Great video, thank you.
Thank you!
I cannot find a better adjective to describe how great your videos are. Fantastic job!
Meanwhile I see a mix use of the term "transaction". For example, in page 3, this quote "Each transaction consists of a bundle of transactions" cause the confusion. The former "transaction" points to the bundle, the green box in page 4, the square in Tangle, while the latter "transaction" is more a part or a sub component inside the former "transaction". I think a better word for the "latter transaction" may be items or entries, or anything. No idea if they are the formal use of transactions in IOTA document (not yet read through).
Thanks again.
Aha, you noticed! That was also my problem when making this video.
In IOTA documentation, there is no special word to name transactions inside a bundle. They ARE transactions, but entries might be a good alternative.
And if you look at the Tangle image a square is called a "transaction" (in IOTA documentation) but in fact it is a BUNDLE of transactions.
In the future, for simplicity sake, I will be using the word "transaction" instead of "a bundle of transactions".
How many times the "system" checks the adresses looking for founds?
After many transaction you'll have found in addreses with hugh indexnumber. When to stop?
Dear Professor, My question is: Can I traceback or find any transaction in the tangle? for example, based on some transaction ID value or any other parameter?
How do i create automated transaction from 1 transaction to 2 deifferent wallets. One of the wallets takes some % (lets say 5%) from value of the transaction and displays confirmation of transaction on website. Other wallet takes the rest. What would be the best way to do it? Do i need smart contracts or something?
How're the private key and the signatueMessageFragment connected? Please explain us what a theft is doing when he found a double-use address. Thanks for your videos, you're great
A great question, however I have not yet investigated how the signature is created..
Thank you for the great videos!
is there any method for merging balances each address ?
If you use the api call:
github.com/iotaledger/iota.lib.js#getaccountdata
you can get the latest confirmed balance (= balance of ALL addresses together)
Thanks for the rapid reply. :)
If wallet has 3 address
address 0 : 1
address 1 : 1
address 2 : 1
In this case, can I send 3 IOTAs by 1 transaction ?
Thank you again! :)
Yes. If you use iota.api.sendTransfer it is automatically done. You only need to specify the receive address and the amount. The api automatically starts with address 0...N until the required amount is found. In your example it will use address 0, 1 and 2.
Is there a particular (programming) reason for the construct of the last tx N in the bundle @0:35: branchtx->tip1 and trunktx->tip0. Why not the other way around? Love your vids!
branch tx must refer to tip (does NOT matter which one)
tip tx must refer to the other tip
but is there any reason why the branch references do not all point to the same tip?
Sorry, I do not know the answer.
You can try: iota.org/IOTA_Whitepaper.pdf
Or iota.stackexchange.com/
Hi. Thank you for your video. In Transaction Example 2 (8:44), is it still safe to send 3 IOTAs to Alice's address 2 instead of address 3? I know it's best practice to send IOTAs to an unattached address (Alice's address 3 in this case), but in Transaction Example 3 when Alice sends 3 IOTAs to Bob, she needs to do PoW 6 times. With the 3 IOTAs sent to her address 2 instead, the number of times PoW is done would be only 4. What risk would be incurred then?
You are risking your IOTAs to be 'stolen' (because of address reuse for 'future' outgoing tx) vs some 'faster' pow.
Since address 2 has never been used for outgoing tx before (because if it had, it wouldn't have had any funds), how is the prospective 'future' outgoing tx from it going to be an address reuse?
Nguyen, sorry I have made a mistake. Ignore my previous answer.
1) Question: "In Transaction Example 2 (8:44), is it still safe to send 3 IOTAs to Alice's address 2 instead of address 3"
Answer: Yes
2) I do not understand the second question. The part "..With the 3 IOTAs sent to her address 2 instead, the number of times PoW is done would be only 4.." is confusing.
Hi. Thank you for the answer. The second part of my question was actually just elaboration on the first. What I meant is maybe it would be less expensive computationally for the 3 IOTAs in Example 3 to be transacted had the 3 IOTAs in Example 2 been sent to Alice's address 2 instead of address 3. You backing the point I raised have satisfied me. A change in the wallet implementation owing to that would be a good idea maybe?
Ah, I now understand your question. You can create a stateful wallet which can store any relevant information to avoid address re-use. Of course you can make this wallet "smart" to make it less expensive computationally by choosing specific addresses which fulfill the transaction.
Hi, i think that have a tiny mistake, exactly in 15:52 minute you have with branchTransaction, you said that if it is not the head transaction, it will be hold to tip 0 but i think that you want to refer to tail transaction which won't be holded to tip 0. Thanks for spent your time with us, that was very useful.
I have rewatched my video, but it is correct what a said in the video.
My observation is that what you said is matching the video and the slide. However it seems on the branchTransaction, the last condition should be "If this transaction is the *head* transaction" instead of "tail transaction". Only the head transaction is different from others (see the diagram in pg 4)
Again, great videos as usual. Great job!
I don't understand why there are transactions which are referenced by more than 1 transaction when a NEW transaction only references tips (non-referenced transactions). Can anyone explain this to me?
Let's assume:
- The Tangle has a transactionZ (tip) with no transactions referencing it.
- Node A receives a transactionA
- Node B receives a transactionB
The nodes find tips using the Monte Carlo Random Walk algorithm.
Lets assume Node A and B find the same tip (=transactionZ) at exactly the SAME time.
Now transactionA is referencing transactionZ and transactionB is referencing transactionZ.
In this example transactionZ is referenced by 2 transactions.
But it is possible it can be referenced by more transactions (3, 4,...)
Thank you for the example. I get it now!
ruclips.net/video/M9dwwgtbbOU/видео.html - what is you have 10 addresses and 0 in the first 9, does this mean it always goes through all of them before reaching address 10, where there might be some funds, so that the transaction is successful? Am I missing something? Isn't this slowing down the transaction time?
You are correct! This is how the IOTA Light wallet (desktop) works. This wallet is stateless which means it does NOT store any information. All information is retrieved from the tangle. That is why it take times to display balance information. The current Trinity wallet (mobile) is NOT stateless, it stores information. I assume (not know for sure because the code is not public) all used addresses are stored.