The problem comes down to this; at the current stage, an attacker could very easily amass 33% of the hashpower of the network, because hashing only happens at the instants when new transactions are being added to the tree, and is completed in a second using a normal laptop.
I was unable to find any information on how IOTA resolves this seemingly disturbing security issue on their website or in their whitepaper, but I did find the following information in two non-affiliated blogs (1, 2) after a lot of searching:
> Milestones: Milestone is a special transaction issued by a special node called Coordinator. The Coordinator is run by Iota Foundation, its main purpose is to protect the network until it grows strong enough to sustain against a large scale attack from those who own GPUs. Milestones set general direction for the tangle growth and do some kind of checkpointing. Transactions (in)directly referenced by milestones are considered as confirmed.
This means that IOTA in its current form does not provide any censorship resistance, since the path of the tree is centrally directed through a Coordinator node run by the IOTA Foundation. As such, IOTA is no more decentralized than an Apache Kafka cluster, or Ripple and their Unique Node List.
I would argue that this is crucial information a user needs to know, yet I have no idea how the average person is intended to learn about this, since it’s nowhere to be found in the IOTA whitepaper or on their website. (EDIT: Since this article was written, IOTA published a post regarding this matter https://blog.iota.org/the-transparency-compendium-26aa5bb8e2.... I responded to their post https://medium.com/@ercwl/hello-david-b77bbc62c457 )
They seem to have developed their own hashing function, of the sponge family, called Curl - and are actually using the Westernelitz (oh jesus spelling, more space-efficient Lamport) signature scheme - it is a method of constructing a digital signature only from hash functions. Cool.
Not to argue semantics but its isn't a chain. It may have blocks (containing one transfer) but it is by no means linear. This lets the tangle achieve verification parallelization. Which is in contrast to blockchain’s strictly sequential, synchronous ledger.
Stellar has nice properties, like a decentralised exchange built into the platform and native integration with existing financial institutions/other cryptocurrencies through anchors.
But I would not say it's blockchain-free. They close a "block" every 5 seconds. Depends on what you consider a block. They use boring stuff like PostgreSQL to store the data instead of reinventing everything.
The innovation of blockchains is not on the how-to-store-things side, but how to keep a state of things every nodes agree with.
Stellar can store data on Postgres because it is just a small database of how much money each account has at each ledger. Past ledgers can be erased from the database (which makes it not a blockchain in any sense anymore).
Bitcoin has a history of all transactions organized in blocks not because it's a fancy new database technology, but because that way is the way it worked out better to keep a synced state between nodes, kind of an append-only log.
You could, if you wanted that, read the Bitcoin database and translate it into a set of rows of a who-has-how-much Postgres table.
Or, better, you could implement a Bitcoin client that stored its blocks as rows in a Postgres table, but I think it would be much more resource-intensive than the databases the Bitcoin clients are using today.
The Bitcoin blockchain is a compact serialization format used as the input to the proof-of-work function. The proof-of-work is the important part, and for that we need a centrally, agreed-upon serialization format where the latter blocks inherit PoW from earlier blocks.
A Bitcoin node can store blocks/transactions in whatever way it wishes -- Postgres, Dropbox, SQLite DB on a floppy disk -- as long as it's able to deliver to nodes in the canonical serialization format, because it's needed to verify proof-of-work (and signatures for the transactions).
They have "ledgers". Each ledger is based on the previous ledger, but the previous ones are discarded as soon as the next reaches a state of consensus.
