Colored coins are the most misunderstood upcoming feature of the IOTA protocol.
A lot of people see them just as a competitor to ERC-20 tokens on ETH and therefore a way of tokenizing things on IOTA, but they are much more important because they enable "consensus on data".
By creating a single uniquely colored coin that you can spend over and over to yourself, you can create a chain of spends that is secured by consensus.
By submitting data with these spends, everybody in the network will not only agree on the order of the published data but ...
... would even agree on which data to use if conflicting information where published. This is incredibly important for several use cases beyond tokenization.
In fact, IOTAs upcoming smart contracts will heavily use this new ability to build "private unforkable blockchains" ...
... that can only be updated by the owner of the colored coin.
But smart contracts are just one example for such a use case that requires consensus on data and its order and there are many more (i.e. oracles, digital twins and the DID protocol).
• • •
Missing some Tweet in this thread? You can try to
force a refresh
So it's finally time for part 2 of the update, in which I will explain how the reactive package allows us to merge metadata and logic to eliminate the problems discussed in the previous thread by getting rid of our 'external propagation logic'.
I will split the thread into several different segments to make it easier to associate the attached pictures with their respective text.
Since we plan to create blocks that act like 'interacting cells', we first need to create a mechanism that allows them to communicate.
For this purpose, we mimic the function of a 'receptor', which is a chemical structure on the membrane of cells that can bind to so-called 'ligands' to release a 'messenger'.
@Plinz I personally think that modeling multiway systems as rewrite systems that operate on a global continuous vector of data is a bit non-intuitive (and also pretty inefficient in code as you have to essentially duplicate the entire vector for each branch that you spawn).
In the ...
@Plinz ... context of Wolframs work, I even think that it leads to questionable conclusions like the proposal to explain the wave function collapse as a Knuth–Bendix completion of the multiway graph, which fails to explain things like Schrödingers Cat where different quantum states ...
@Plinz ... can lead to vastly different macroscopic outcomes.
A slightly different take on causal multiway systems that is also closer to the way we perceive the world is to model them as an evolution of "interacting substates / particles", rather than a continuous sequence of symbols.
I have lately received a number of messages, asking about the security of IOTA's new consensus mechanism in situations like network splits.
Since these questions seem to originate in factually wrong statements of a critic, I want to answer this question publicly.
(1/20)🧵👇
To understand how IOTA handles this type of situation, we first need to understand what a network split is.
It is a situation where the network is split into two (or more) disconnected partitions where each partition can only see their respective set of issued messages.
(2/20)
Most splits are the result of faulty network infrastructure causing temporary interruptions of connectivity.
Redundant hardware and connections have made large-scale network splits increasingly rare but smaller, locally confined partitions are still relatively common.
Apart from a lot of references to other papers, it contains only very hand wavy statements. I don't think they name a single concrete algorithm in the entire document.
@durerus@Conste11ation@Vrom14286662 It was promised that they would release updated papers and information, that would answer some of the questions I had, but I think this was delayed.
I wouldn't rule out that they work on something legit and I would give them the benefit of the doubt but everything that I ...
I think it's time for a short update around our progress on coordicide:
A few weeks ago we merged the refactored consensus code base and we have been running it in an internal testnet since then.
After fixing a lot of bugs, the node looks increasingly stable (we also found ...
... the memory leak that we were fighting with for almost 2 weeks - people who closely follow the development process on github will know what I mean).
The only remaining thing for the prototype to be feature complete in a first MVP version (apart from getting rid of ...
... possible remaining bugs) is the chain switching, which allows nodes to automatically recover after i.e. having being eclipsed / in a minority partition.
Me and Andrea started working on this 2 weeks ago but we had to pause and first change the way we manage state to ...
@DesheShai I would argue that the 50% attack resilience you mentioned is not the result of PoW but the result of how Satoshis voting mechanism does not operate in rounds where you have to "prematurely" finalize decisions. This allows actors to continuously adjust their opinion and ...
@DesheShai ... ultimately converge to all add weight to the same winning outcome.
If you operate in rounds (like all contemporary BFT style consensus mechanisms) and declare a decision to be final once you have reached 67% of the weight (to move on to the next round), then an attacker ...
@DesheShai ... that controls >1/3rd (i.e 34%) could switch the outcome of the voting which leads to the lowered security threshold in each round (waiting for more weight would challenge liveness).
If you do however never finalize decisions and allow actors to converge post-reaching a ...