IOTA

[superresistant]

Privacy level of Iota is not Bitcoin's nor Monero's. Transactions can be done off-tangle being seen only by few nodes, off-tangle transactions are not stored on the tangle.

What do you call a "transaction" here if it is not stored on the tangle ?
How is it off-tangle if few nodes are aware of the transaction ?

EDIT: I think I get it, off-transactions must be done by 2 nodes that doesn't broadcast the transaction.

[1714047560]

1714047560

[1714047560]

1714047560

[1714047560]

1714047560

[jcksteve]

What this... 50 billion TOKEN..??

Where have you seen "50 billion"?

ouchh..i'm wrong..??

[Come-from-Beyond]

EDIT: I think I get it, off-transactions must be done by 2 nodes that doesn't broadcast the transaction.

Yes.

[Ratatosk]

EDIT: I think I get it, off-transactions must be done by 2 nodes that doesn't broadcast the transaction.

Yes.

OK, thanks to you 2.

So, basically, IOTA "universe" doesn't offer more privacy or anonymity than Bitcoin by default, but if the users decide or ask for, some operations will not be "shared and recorded" excepted by some few specific nodes, interresting.

[Come-from-Beyond]

So, basically, IOTA "universe" doesn't offer more privacy or anonymity than Bitcoin by default, but if the users decide or ask for, some operations will not be "shared and recorded" excepted by some few specific nodes, interresting.

Frankly saying, this feature is not unique to Iota. It's based on the idea of payment channels (http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf) invented for Bitcoin. When Bitcoin adopts the changes required for payment channel realization is another question.

[50cent_rapper]

Will there be a software client/wallet for this, so people can send and receive tokens ? Or we must wait for IoT-devices to spend tokens ?

[Come-from-Beyond]

Will there be a software client/wallet for this, so people can send and receive tokens ? Or we must wait for IoT-devices to spend tokens ?

We will provide software written in Java, its source code and executables for several popular OSes generated with http://www.jwrapper.com.

[tonych]

Minimal PoW is enough, we assume that there exist a constant flow of new transactions which is a pretty reasonable assumption.

Got it. But I still doubt it is secure. With roughly constant flow of transactions, we have roughly constant PoW generated on the legit branch.
In Bitcoin, we always have better, more power efficient ASICs. The miner who is first to install a new ASIC, obtains temporary advantage over other miners (assuming all other variables equal). A new ASIC basically redistributes the constant flow of wealth (25BTC/block) among miners, ordinary users don't care. And it was one of design goals of Bitcoin that mining is more profitable than attacking.
In Iota, I'm afraid, it'll be profitable to use ASICs against users. If minimal PoW per transaction is small enough then a small battery of ASICs might be enough to outPoW the whole legitimate network armed with CPU PoW.

Several copies of a transaction increase security of the network, not decrease it. I think there is a confusion caused by different terminology. Let's call data required to be signed (amount, beneficiary, etc.) a transaction and the part that contains references and the transaction an envelope. Envelopes reference each other, their sole purpose is to help to achieve consensus, transactions do reference each other indirectly by using outputs of parent transactions as inputs of child transactions. An adversary can't change references inside transactions, anyone can change references inside envelopes but this will only create the 2nd envelope. To be able to censor transactions you need to conduct a successful global eclipse attack, if you only change envelope then you contribute to network security increase. Note, that references inside envelopes are secured by PoW. If you spend electricity on PoW you just make tangle more tangled, which is good.

Thanks, terminology definitely helped.
So you allow to duplicate a transaction as long as PoW is also duplicated.
What about attempts to rewrite history by rewriting the envelopes?



In this example from the whitepaper, if I wanted to censor envelope F and the corresponding transaction (because e.g. it contained a spend that I want to roll back), could I "route around" it by spending some electricity and rewriting references in envelopes of E and B so that they no longer point to F but somewhere else? Then there are no references to F in the graph any more, I can safely delete it and share my version of the history with other nodes. How will they know which history is right?

[Come-from-Beyond]

Got it. But I still doubt it is secure. With roughly constant flow of transactions, we have roughly constant PoW generated on the legit branch.
In Bitcoin, we always have better, more power efficient ASICs. The miner who is first to install a new ASIC, obtains temporary advantage over other miners (assuming all other variables equal). A new ASIC basically redistributes the constant flow of wealth (25BTC/block) among miners, ordinary users don't care.
In Iota, I'm afraid, it'll be profitable to use ASICs against users. If minimal PoW per transaction is small enough then a small battery of ASICs might be enough to outPoW the whole legitimate network armed with CPU PoW.

Bitcoin has constant PoW during a week too, I don't see how constant PoW leads to an insecure state. Would anyone create ASICs for Bitcoin mining if there was no subsidy (25 BTC) nor transaction fees?
Security of Iota relies on assumption that an adversary controls less than 50% of hashing power. This is a standard assumption in cryptoindustry. Bootstrapping period will be protected by checkpoints.

Thanks, terminology definitely helped.
So you allow to duplicate a transaction as long as PoW is also duplicated.
What about attempts to rewrite history by rewriting the envelopes?



In this example from the whitepaper, if I wanted to censor envelope F and the corresponding transaction (because e.g. it contained a spend that I want to roll back), could I "route around" it by spending some electricity and rewriting references in envelopes of E and B so that they no longer point to F but somewhere else? Then there are no references to F in the graph any more, I can safely delete it and share my version of the history with other nodes. How will they know which history is right?

The history with the heaviest tangle is right. To rewrite the history you need to control most of the hashing power.

[rlh]

Ok, I just skimmed the white paper (a little better than reading just the conclusions, but not fully digesting the formulas.)

I have a question about a type of attack.  Since this is an IoT coin, it is my understanding that in order to fully confirm a transaction, you should validate the full chain from the TX to the genesis transaction correct?  Over time this shouldn't be a problem because a node should only have to download transactions that are missing from any tip.  For example, if I get a Transaction F, and I already have transactions A->B->C in the F's chain, I only need to download transactions D->E, and validate the associated signatures for these transactions, in order to fully validate F.  Once F is fully validated in this manner, I can validate/sign F to post with my transaction G.

Now, what's to prevent someone from accepting a payment and creating a massive, off-chain tangle?  Maybe I spend 1-2 days, generating really long, off-net tangles.

I then submit a single transaction that relies on gigabytes of transnational details that only my Sybil nodes hold.  Wouldn't the network flood with requests for information on these transactions?  This may not seem like a big deal, but if IOTA is to be used with small(ish) IoT devices that can benefit from micro-payments, can't such information requests overload such devices?

Solution: When confirming a transaction, if you have to back-search a constant number of transactions, toss out the transaction.  In other words, if I have to request 5 transaction generations and I'm still not on the main-chain, I can toss out the transaction.

Is my scenario even a problem?

[Come-from-Beyond]

Ok, I just skimmed the white paper (a little better than reading just the conclusions, but not fully digesting the formulas.)

I have a question about a type of attack.  Since this is an IoT coin, it is my understanding that in order to fully confirm a transaction, you should validate the full chain from the TX to the genesis transaction correct?  Over time this shouldn't be a problem because a node should only have to download transactions that are missing from any tip.  For example, if I get a Transaction F, and I already have transactions A->B->C in the F's chain, I only need to download transactions D->E, and validate the associated signatures for these transactions, in order to fully validate F.  Once F is fully validated in this manner, I can validate/sign F to post with my transaction G.

Now, what's to prevent someone from accepting a payment and creating a massive, off-chain tangle?  Maybe I spend 1-2 days, generating really long, off-net tangles.

I then submit a single transaction that relies on gigabytes of transnational details that only my Sybil nodes hold.  Wouldn't the network flood with requests for information on these transactions?  This may not seem like a big deal, but if IOTA is to be used with small(ish) IoT devices that can benefit from micro-payments, can't such information requests overload such devices?

Solution: When confirming a transaction, if you have to back-search a constant number of transactions, toss out the transaction.  In other words, if I have to request 5 transaction generations and I'm still not on the main-chain, I can toss out the transaction.

Is my scenario even a problem?

A low-end device may be unable to process gigabytes of data within a short period of time, but it can cooperate with other low-end devices and split the burden by using techniques like https://en.wikipedia.org/wiki/MapReduce. A M-of-N multisignature with virtually unlimited M and N will make elements of such swarms to behave honestly (otherwise they will lose money or won't get their transactions accepted). Luckily for devices which don't have "friends", it's not necessary to "see" the whole tangle if they spend money, they can reference old transactions and wait a little longer. If they accept money then they can explicitly warn their customers that a payment may take very long time for verification. On the other hand, if they provide a service they may spend a lot of time and create off-tangle payment channels (or even ask their owner to do it for them by using his computer) and then accept payments without worrying about the size of the tangle.

[rlh]

Using MapReduce is an interesting approach and would certainly make sense.  However, if it's not implemented (say, in a tech product by a company that didn't think to integrate it) this is a viable form of a spam attack.

I certainly understand that IOTA will initially be what the initial client software provides, but if you are planning on a robust IoT use-case, there should be a standardized communications protocol so that people companies can roll their client-code for their hardware. 

Providing pre-existing implementations of MapReduce logic could help encourage responsible development.  Otherwise, it might not be even an after-thought and once products and nodes exist, this type of attack would be considerably easy to implement.

These are just some additional thoughts on the matter.

[Come-from-Beyond]

Using MapReduce is an interesting approach and would certainly make sense.  However, if it's not implemented (say, in a tech product by a company that didn't think to integrate it) this is a viable form of a spam attack.

I certainly understand that IOTA will initially be what the initial client software provides, but if you are planning on a robust IoT use-case, there should be a standardized communications protocol so that people companies can roll their client-code for their hardware. 

Providing pre-existing implementations of MapReduce logic could help encourage responsible development.  Otherwise, it might not be even an after-thought and once products and nodes exist, this type of attack would be considerably easy to implement.

These are just some additional thoughts on the matter.

Valid point, we just need to make sure that we won't fit too much into the standard making Iota lose its lightweightness.

[petko]

Minimal PoW is enough, we assume that there exist a constant flow of new transactions which is a pretty reasonable assumption.

Security of Iota relies on assumption that an adversary controls less than 50% of hashing power. This is a standard assumption in cryptoindustry. Bootstrapping period will be protected by checkpoints.

So for a transaction to be considered confirmed, the number of approving transactions multiplied by the minimal PoW must exceed the maximal possible adversary's PoW?

[Come-from-Beyond]

So for a transaction to be considered confirmed, the number of approving transactions multiplied by the minimal PoW must exceed the maximal possible adversary's PoW?

No, it's not that easy, if transaction flow drops then an adversary can catch up and double-spend. It's a never ending race.

[tobeaj2mer01]

How can we get IOTA? Can we mine it or buy it?

[petko]

No, it's not that easy, if transaction flow drops then an adversary can catch up and double-spend. It's a never ending race.

Indeed, right. Another try:

To consider the system secure, the average number of transactions per second, multiplied by the minimal PoW, must exceed the maximal hash power per second of a probable attacker

[Come-from-Beyond]

Indeed, right. Another try:

To consider the system secure, the average number of transactions per second, multiplied by the minimal PoW, must exceed the maximal hash power per second of a probable attacker

This looks good for the edge case of a tangle degenerated to a chain. It should be the same for a tangle with arbitrary topology for transactions that have already been considered confirmed, but intuition says that it's incorrect for transactions that haven't passed their adaptation period (i.e. there are a lot of tips not referencing them) yet.

[iotatoken]

How can we get IOTA? Can we mine it or buy it?

There will be a crowdsale, yes.

[patmast3r]

So for a transaction to be considered confirmed, the number of approving transactions multiplied by the minimal PoW must exceed the maximal possible adversary's PoW?

No, it's not that easy, if transaction flow drops then an adversary can catch up and double-spend. It's a never ending race.

So when can a tx be considered unreversable ?