6

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 ...


6

A full node has a local database of current IOTA balances (which gets initialized from the latest Snapshot and then updated by confirmed transactions). When the full node performs its validation of a transaction bundle, it will verify that the balances of the spending transactions do not exceed the amounts stored in its database. This is done sequentially so ...


4

You can generate your address with the option checksum: true . It will give you a 90 characters address where last 9 chars are the checksum. Before attaching this address to the tangle you can use the function Utils.isValidChecksum(<90 chars address>) to check that your address is valid. source


4

Thanks for including the additional info in your question! I was about to write the answer to update to the newest PyOTA version, but you were faster with your comment. So yes, PyOTA 2.3.0b1 should solve the issue! :)


3

Welcome to the IOTA StackExchange! I'm sorry (and a tad embarrassed 😅) to hear that you encountered an error during the tutorials! Hopefully we can get you back on track quickly! The error message indicates two things: Request failed validation ({'transaction': ['wrong_type']}) PyOTA attempted to craft a request to fetch information about the bundle, ...


3

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 ...


3

It seems like what you want to avoid is the risk that your funds will "end up somewhere which isn't in my control." In that case, you should use the IOTA API to double-check that your seed produces your address. This will ensure that you indeed have access to funds at that address. This can be done entirely offline, using the IOTA JavaScript API and the ...


2

send only a small amount of IOTA or even a zero value transaction of the address check if you see the transaction in your wallet send the rest of your IOTA Although this would work, it shouldn't really be an issue, if you generated the address with a tool that works like the official IOTA light wallet or any of the official IOTA libraries from iotaledger ...


2

If I'm not remembering wrong, when a discrepancy is detected the node runs again the MCMC algorithm and chooses two other tips. The inconsistent tips will remain on the tangle. The growth of the tangle will (hopefully) confirm only one of the two tips, the other will be on an orphaned branch and will never be confirmed.


2

The problem here is, we can't prove, if the timestamp is correct or not. Setting the timestamp back to 01.01.1900: Case 1: The node is honest and rejects the transaction, because the timestamp is not correctly dated -> everything is good Case 2: The node is NOT honest and distributes the transaction further. Now other nodes have no way of knowing, if the ...


1

First, pay attention that with Chrysalis iota fundamentally changes. It will change farther with coordicide, which is nothing like the original white-paper. White paper ideas will never come to fruition it seems... However, I'll answer your question in the context of the old whitepaper (because this is what you are asking about :-) ). A transaction (...


1

This blog explains exactly the main concern here reported: http://www.tangleblog.com/2017/07/10/is-double-spending-possible-with-iota/ Section: "Doublespending in IOTA" Basically, the increasing number of hosts also increase the difficulty to perform such attack, due to you need to get "an “omnipresence in the tangle with “bad” nodes, formed as a sub ...


1

By verifying a transaction that is invalid, a transaction itself becomes invalid and will never be verified by other honest transactions (i.e. the transaction is on an "invalid path" that others do not recognize so its X Iotas are worthless). So: What happens next? Nothing. The transaction that happens to verify an invalid one will never be confirmed. ...


1

There are two ways I can think of to verify a (the orange) transaction. 1. With the Coordinator If you don't know how IOTA transactions are confirmed by the coordinator, check out How exactly are transactions verified and confirmed in IOTA first. Preconditions: You get all information about the old Tangle through thetangle.org (or any other provider) ...


1

The Java port is up to date - it is used in the Android wallet. Also, obviously the JavaScript port is up to date - it is used in the official desktop wallet. The C# port is not up to date as it (still) uses the old CURL hashing function (used until beginning of August 2017).


Only top voted, non community-wiki answers of a minimum length are eligible