Post
Topic
Board Announcements (Altcoins)
Re: IOTA
by
tonych
on 22/10/2015, 16:04:15 UTC
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?