Topic: IOTA - page 758. (Read 1471689 times)

Min transaction PoW will naturally increase over time mimicking Moore's law when more powerful hardware appears. Multiply this by TPS increase caused by increased popularity.

ASICs indeed will be created.

Satoshi's assumption was shown to be incorrect - http://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf.

Necessity to absorb surplus hashpower is not obvious, also what numbers do you have in mind (1% of not used hashpower, 10%, 99%)?

There is no such thing as rewriting of envelopes, you can only add new ones unless you conducted a global eclipse attack.

No. The cap is related to another issue.

Looks good, it's just unclear why you picked Bitcoin hashrate which is generated by ASICs working a million times faster than a computer.

While it is true that Bitcoin has constant PoW during two weeks, it is adjusted every two weeks in response to changes in the total hash power available. It is able to adapt. There is no reason to assume that the flow of transactions in Iota will increase in response to more hash power being available.

Will anyone create ASICs or build botnets specifically to attack Iota users? If Iota token becomes valuable enough, why not?

It is not just an assumption, it is carefully designed incentives that drive people to behave honestly rather than try to attack other users. Satoshi writes this in section 6 of Bitcoin whitepaper:
Why? I'm guessing after I rewrite envelopes of E and B, I have to also rewrite all envelopes that reference them (A and C), then the envelopes that reference those who reference, and so on until the tips, correct?

Not even when the weight cap is reached ? (The paper mentions the cap but I'm not sure it ever states if the cap will actually be applied)

Never, look at formula #14 in http://188.138.57.93/tangle.pdf. Just like in Bitcoin there is always a chance of doublespending.

OK, guess the transactions will get entangled fast enough. Let's and do a quick calc considering they do:

• Let J be the average Joe hash rate
• You cannot ask Joe to wait more than 60 sec to issue a single transaction, so the minimal PoW cannot be more than 60 * J
• Let E be the attacker's hash rate

The minimal number of transactions per second that you need in order to keep the system secure is N = E / (60 * J)

So for SHA-256 (in fact, what hashing do you consider?):

• Let's take the Core 2 Duo hash rate for Joe
  J = 2.5 MH/s
  
• Today's hash rate of the Bitcoin network is around 430 PH/s. It is plausible to assume that a single entity owns 1% of that hash power
  E = 4.3 PH/s = 4 300 000 000 MH/s

 => The minimal number of transactions per second is the astonishing N = 28 666 666

Did I misunderstand something?

So when can a tx be considered unreversable ?

There will be a crowdsale, yes.

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.

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

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

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

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

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.

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.

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?

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.



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

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.

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?