Yes, you can upload images or any files or other data to the tangle.
As long as their size is less than 2187 trytes you can put them into one tx (=transaction). If they are bigger (=more trytes) than that, you can still send them by just putting them into multiple txs that reference each other (similar to a bundles for value txs).
So for example if you ...
I think this copy/paste from Reddit explains it perfectly:
What is the Coordinator and what does it do?
Every minute [now 35 seconds] the Coordinator makes a normal transaction with its signature on it, and we call these Milestones. Every transaction (including Milestones) verifies two other transactions. When you want to know if a transaction is verified,...
IOTA uses Proof-of-Work as an anti-Sybil measure. Every transaction has some PoW tied to it, the transactions reference other transactions which the transaction issuer treats as valid, so a transaction is like a vote for all the transactions it references directly or indirectly.
Among conflicting transactions the one with the highest number of votes is ...
putting luggage in an empty train and someone in the next station opens the door and gets the bags out
is actually quite accurate because that's basically whats happening. Except that nobody gets the bags out. Somebody just takes a look at the content of the bags. The bags stay in the train forever. Until a snapshot. Where everything in ...
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 ...
As of the current implementation state, every node will have to receive every confirmed transaction eventually (so that the solid subtangle milestone can increase and the node can calculate all balances if asked for them). There are plans for "sharding" so that nodes only care about certain transactions (e. g. based on first letter of address), but there is ...
What PoW means in practice is that cost spent on mining = security. Ie. $100 fees per hour? Spend >$100 (in energy used for mining) to rewind these transactions. It's better with asics as that adds 'has access to asics'.
To buy Security with huge costs of transactions is not reasonable anymore. Fiat Cash or anything else is cheaper. This would be dump ...
"Hype aside it's a minor change that's equivalent to transaction chains in Lightning Network or Raiden, offering exactly the same advantages (asynchronous) and disadvantages (lower security)." - this is a https://en.wikipedia.org/wiki/Straw_man argument. All the rest is based on this fallacious foundation, no surprise the resume is fallacious too.
The biggest perceived "downside" of Tangle as opposed to Blockchain is that the cost of decentralization requires PoW in every transaction as opposed to centralizing it with miners.
Blockchain may be compromised by centralized mining activity as we've seen it be manipulated by forks and price pumps based on profitability. IOTA doesn't have this issue, but ...
In short: double spending is incredibly unlikely in IOTA.
In IOTA, majority hashpower is insufficient for a double-spend attack. IOTA is unlike proof-of-work based blockchains in this regard. You also need enough neighbors to get your transactions confirmed. IOTA calls this concept omnipresence.
IOTA nodes use mutual tethering rather than automatic peer ...
I did a crude test based on the Tangle data available here http://store.alon-e.com/IOTA_DBs and then fitted a projection function to it.
So the whole size of the Tangle (counted from December 2016) could easily go up to 100 GB by mid 2018.
What is the current size of the IOTA chain data?
Right now the whole IRI directory on my Ubuntu server is 5.2gb. The current database is 4.9gb and is likely due for a pruning (snapshot in IOTA terms).
What is the expected rate of growth, given current rates of adoption?
Very difficult to answer this question given how early it is in the IOTA ...
A transaction is only an envelope for the signed bundle that details the exact transaction of funds between addresses. The transaction gets attached to the Tangle by doing the Proof of Work and validating two tips. Once it is linked to the Tangle that way, it cannot move any more. It therefore has become part of the permanent history of the Tangle. It can ...
I can't answer how it will behave in case the coordinator is shut down and the network is actually decentralized as described in the whitepaper.
Right now, the branch that gets confirmed by the coordinator, a special central node run by the Iota Foundation, is the one that gets accepted as valid by every conforming full node.
Basic recursion for every open tip should do it. Just follow everything back to the origin or until you hit something you mapped already. I know that those object notations are very pseudo ;)
if(root OR (x already_mapped))break;
Here's my takeaway, and technical people please feel free to correct me:
This blog post is about how every node can pick their own tip selection algorithm, which is the method by which they decide which two transactions to attach a new transaction to (as each time you send a transaction to a node, you confirm two previous ones). As nodes can do whatever ...
Basically there are three ways to get to the data (depending on what you want):
Query the API of your node to find transactions and walk along them. This might be slow (depending on what you are looking for), but the API is well-documented and you can walk the tangle quite easily.
Directly query the node's database (which is a RocksDB instance) for what you ...
I think you got something wrong there: 1-2 transactions per second is not the max amount of transactions possible, it's the amount of transactions people make.
On the live tangle, we have seen transaction speeds as high as 50 transactions per second or more.
Here are possible considerations:
1) Load balance on full nodes:
1a) are there enough full nodes ...
When you re-attach a transaction you don't take the old one out. You basically issue a copy of the same transaction.
So if the yellow transaction is already approved/referenced by the black ones, then when you re-issue the yellow transaction nothing will really happen. You just have two yellow transactions: one that's already been approved and one that's ...
The IOTA Tangle more network-bound than hash-power-bound because in order to perform an attack, you need to meet three conditions:
X [any number] percentage of network hash rate (depending on Y 34% may not be enough)
You have to know how a big section of the network topology (know which nodes are neighbours of which nodes)
Y percentage of ...
Short answer it depends.
A little longer answer, the needed time for the proof of work depends on:
the device that calculates the hash.
the load of this device (with other stuff).
the minWeightMagnitude (here you can read more about it).
Furthermore the IOTA Foundation is planing/working on a external CPU called Jinn. Jinn is a ternary CPU so more ...
All individual transactions that make up the complete transaction share the same bundle hash. That bundle hash is unique to them. It is not an address hash or a transaction hash of another transaction. It is an ID that uniquely identifies the entire transaction.
Transactions can be replayed in order to position them at another point in the tangle ...
The blowball problem is this phenomena where a huge quantity of new transactions select more or less at the same time the exact same transaction (most of the time the latest milestone) as branch and trunk transaction.
On a tangle vizualizer this phenomena is visible in the form of "balls" where the center of the ball is a milestone, and the ball consist of ...
Let x denote our transaction.
The score is backward-looking = weight of x + sum of weights of all transactions approved by our transaction x
The cumulative weight is forward-looking = weight of x + sum of weights of all transactions that directly or indirectly approve our transaction x
This is not a complete answer, but here are a few points:
IOTA is a cryptocurrency, whereas Hashgraph is an algorithm, i.e. there is no public ledger built on Hashgraph (yet)
IOTA is open-source technology, whereas Hashgraph is patented Distributed Ledger Technology & not open-source (yet)
In IOTA there is no absolute unique order of transactions (yet), ...
After looking into code of IRI : all incoming transactions that aren't known yet (i.e. not already stored in the local tangle) are immediately stored in the local tangle and broadcasted to all neighbors.
There is a send_limit parameter that can be used to reduce the broadcast rate, but the default behavior is the broadcast every new transaction ASAP (...
All the data will remain in the Tangle.
If one could take out the dataset one could change the data and you will never know. By leaving it in the Tangle and distributing it you can always be sure you recieved the original data.
In an older blog post David Sønstebø stated:
Tangle — the permissionless distributed ledger of IOTA — solves this
In addition to miners losing their jobs?
I guess probably the higher number of transactions and full nodes you need to achieve stability in the network. Also there are different kind of gametheoretic attacks possible. This has to be further researched by running simulations.
Flash is a bi-directional off-Tangle payment channel to enable instantaneous, high-throughput transactions. In essence, they provide a way for parties to transact at high frequency without waiting for each transaction to confirm on the public IOTA network. Instead, only two transactions will ever occur on the main IOTA network: opening and ...
There is no requirement to do a protocol update when a snapshot is done, but it's a good opportunity to do it.
Remember that the tangle is still young and protocol updates are required. In the future, once tangle will be mature, I expect that snapshot will be done with no protocol update at the same time.