Uploaded June 2018 | Updated September 2026, 2 weeks ago
If you like this video and want to support me, go this page for my donation crypto addresses:
youtube.com/c/mobilefish/about
This is part 27 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.
In this video I will explain why a bundleHash is normalized and why you should not reuse an address for outgoing transactions.
The normalizedBundleHash is created by extracting the bundleHash from the transactionObject and the bundleHash is then normalized.
The normalizedBundleHash contains no tryte value M and the "weights" of the trytes are evenly distributed.
You can think of normalizing the bundleHash as balancing a seesaw, by manipulating its "weight" (=trytes) to reach a more equilibrium state.
I have created a simple value transaction: I have used security level 1 and transferred 1 IOTA from address A to B and there is no remainder.
See the corresponding transaction bundle:
mobilefish.com/download/iota/transactions_in_bundle_security_level1.txt
The transaction bundle has two transactionObjects.
A transactionObject containing recipient data and the other containing sender data.
The senders signatureMessageFragment is "KVSA...HMKW" and the senders address is "VXO...LTKA".
By distributing these values evenly the Koriginal values are "spread".
You will have low values: 1-13 and high values 14-26.
You can not have only Koriginal values between 14 and 26, the normalizedBundleHash prevents this.
Eve has found these two transaction bundles using the same address A for outgoing transactions.
A few days later, Eve noticed 500 MIOTA were send to address A.
Eve tries a hack attempt, she takes the 2nd transaction bundle:
From the receiver tx object, she change the recipient's address with her own address and change the recipient's value to 500 MIOTA.
From the sender tx object, she change the spending value to 500 MIOTA.
By doing so the bundleHash, normalizedBundleHash and the K values are changed.
If you reuse an address for outgoing addresses you provide a hacker more possibilities to successfully create a modified transaction bundle sending IOTAs from the victim’s address to the hackers address.
Reusing an address for outgoing transactions does not mean the hacker will immediately succeed in its hack attempt, but it will definitely increase its chances.
Check out all my other IOTA tutorial videos:
youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza
Subscribe to my YouTube channel:
youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
mobilefish.com/developer/iota/iota_quickguide_tutorial.html
#mobilefish #howto #iota
If you like this video and want to support me, go this page for my donation crypto addresses:
youtube.com/c/mobilefish/about
This is part 27 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.
In this video I will explain why a bundleHash is normalized and why you should not reuse an address for outgoing transactions.
The normalizedBundleHash is created by extracting the bundleHash from the transactionObject and the bundleHash is then normalized.
The normalizedBundleHash contains no tryte value M and the "weights" of the trytes are evenly distributed.
You can think of normalizing the bundleHash as balancing a seesaw, by manipulating its "weight" (=trytes) to reach a more equilibrium state.
I have created a simple value transaction: I have used security level 1 and transferred 1 IOTA from address A to B and there is no remainder.
See the corresponding transaction bundle:
mobilefish.com/download/iota/transactions_in_bundle_security_level1.txt
The transaction bundle has two transactionObjects.
A transactionObject containing recipient data and the other containing sender data.
The senders signatureMessageFragment is "KVSA...HMKW" and the senders address is "VXO...LTKA".
By distributing these values evenly the Koriginal values are "spread".
You will have low values: 1-13 and high values 14-26.
You can not have only Koriginal values between 14 and 26, the normalizedBundleHash prevents this.
Eve has found these two transaction bundles using the same address A for outgoing transactions.
A few days later, Eve noticed 500 MIOTA were send to address A.
Eve tries a hack attempt, she takes the 2nd transaction bundle:
From the receiver tx object, she change the recipient's address with her own address and change the recipient's value to 500 MIOTA.
From the sender tx object, she change the spending value to 500 MIOTA.
By doing so the bundleHash, normalizedBundleHash and the K values are changed.
If you reuse an address for outgoing addresses you provide a hacker more possibilities to successfully create a modified transaction bundle sending IOTAs from the victim’s address to the hackers address.
Reusing an address for outgoing transactions does not mean the hacker will immediately succeed in its hack attempt, but it will definitely increase its chances.
Check out all my other IOTA tutorial videos:
youtube.com/playlist?list=PLmL13yqb6OxdIf6CQMHf7hUcDZBbxHyza
Subscribe to my YouTube channel:
youtube.com/channel/UCG5_CT_KjexxjbgNE4lVGkg?sub_confirmation=1
The presentation used in this video tutorial can be found at:
mobilefish.com/developer/iota/iota_quickguide_tutorial.html
#mobilefish #howto #iota
