Hi, Thank you for the amazing series of IOTA tutorial. I have one question. In the previous tutorial, we need to calculate the normalized bundle hash to prevent from releasing the key digest. But why in the MAM scheme (in the slide) I can see the number of hash for some fragment being zero? That's because the information has been masked so it doesn't matter ??
Great video! Question: as I understand, 'count', 'next_count', and 'start' are not published to the tangle (or are they?), so what are these parameters good for?
Yeah I know the meanings of these parameters; they are part of a MAM object. That's clear to me; maybe the broadcaster needs them, but the thing I'm wondering about is whether they are needed by the receiver, because I don't see them being published to the tangle. So if I'm the receiver, do I need the 'count', 'next_count', and 'start' parameters?
These parameters are only used by the publisher to create the MAM stream. The receiver only need the root and side_key (when channel mode=restricted). 1) With the root the receiver can calculate the address. 2) From this address the transaction bundle is retrieved. 3) The signatureMessageFragment fields in the transaction bundle together is the masked payload. 4) The masked payload contains the message (eg sensor data) and the next root. 5) With the next root repeat step 1.
Theoretical you can store any information size, but it makes NO sense to do that! The bigger the payload, the payload is broken up in smaller pieces. More pieces means more time is needed for the PoW.
The receiver does not need to know the index. The masked payload contains the index. See sheet 4: www.mobilefish.com/download/iota/masked_payload_part20.pdf
Hi, Thank you for the amazing series of IOTA tutorial. I have one question. In the previous tutorial, we need to calculate the normalized bundle hash to prevent from releasing the key digest. But why in the MAM scheme (in the slide) I can see the number of hash for some fragment being zero? That's because the information has been masked so it doesn't matter ??
I do not understand your question.
Can you tell me which slide number you are referring?
www.mobilefish.com/download/iota/masked_payload_part20.pdf
Great video!
Question: as I understand, 'count', 'next_count', and 'start' are not published to the tangle (or are they?), so what are these parameters good for?
See: www.mobilefish.com/download/iota/mam_part19.pdf
Explained in page 21 (See also: IOTA Tutorial 21)
Yeah I know the meanings of these parameters; they are part of a MAM object. That's clear to me; maybe the broadcaster needs them, but the thing I'm wondering about is whether they are needed by the receiver, because I don't see them being published to the tangle. So if I'm the receiver, do I need the 'count', 'next_count', and 'start' parameters?
These parameters are only used by the publisher to create the MAM stream.
The receiver only need the root and side_key (when channel mode=restricted).
1) With the root the receiver can calculate the address.
2) From this address the transaction bundle is retrieved.
3) The signatureMessageFragment fields in the transaction bundle together is the masked payload.
4) The masked payload contains the message (eg sensor data) and the next root.
5) With the next root repeat step 1.
Great video!
Challenge for next episode - MAM practical example.
Working on it....
Hi love the content, Question: How many sensor data can i store per payload ?
Theoretical you can store any information size, but it makes NO sense to do that!
The bigger the payload, the payload is broken up in smaller pieces.
More pieces means more time is needed for the PoW.
How should the receiver knows the index?
The receiver does not need to know the index.
The masked payload contains the index.
See sheet 4: www.mobilefish.com/download/iota/masked_payload_part20.pdf
thank you!! i didn't notice it
thanks