3

One of the features of IOTA is that sub-tangles can be constructed and then attached to to the main tangle in the future.

With IRI version 1.5.2, how does the prevention of lazy tip selection change the tangle's partition tolerance?

For Further Reference, please see these resources below

Original IOTA features list on BitcoinTalk

[IOTA solves] Partition Intolerance

Blockchain-based currencies are unable to survive long-sustained partitioning of the network because this may lead to reversal of a large number of transactions. It is also impossible to initiate an intentional partitioning in cases when it is required.

A quick-easy reference to it by @zauz here on iota.stackexchange:

When would it be required to intentionally partition the Iota transaction graph?

A @medium article on it called Sharding the IOTA Tangle Effectively.

Indeed, this is even covered in an AMA here:

enter image description here

Improve this question
5
  • 1
    "sub-tangles can be constructed and then attached to to the main tangle in the future" can you add the link to sources please ?
    – ben75
    Commented Jul 23, 2018 at 11:38
  • 2
    The linked source is a theoretical approach of tangle partitioning, and don't reflect the strategy of the IF regarding tangle partition. AFAIK, the only official publication briefly presenting partition in the tangle is this one about economic clustering.
    – ben75
    Commented Jul 23, 2018 at 23:01
  • I think it's better to add your own answer (referring to the github issue) instead of editing the question. Just to keep things in a clean structure. (The question remains perfectly valid as it was)
    – ben75
    Commented Jul 26, 2018 at 13:53
  • Yes, but the original question is not about "IF core strategy". It's about problems raised with 1.5.2. The github issue can be interpreted as "the IF answer to those problems", so IMO it make more sense to include it in an answer instead of in the question. (just for readability)
    – ben75
    Commented Jul 26, 2018 at 14:15
  • Yes, and the github issue describes in details the impacts of 1.5.2 regarding partition tolerance---> it's an answer.
    – ben75
    Commented Jul 26, 2018 at 14:18

1 Answer 1

Reset to default
2

IMO, a distinction should be made between different partitioning scenario.

  1. Accidental/occasional partitioning

It's the situation where a portion of the network is temporary disconnected for a relatively short period of time. Participant can still submit transactions to the disconnected tangle and when the disconnected tangle is back online, transactions will simply be included in the main tangle.

Changes in IRI 1.5.2 will impact the acceptable offline period (previously it was limited only by snapshot time). i.e. an "accidental partitioning" cannot last for a too long period of time, otherwise a re-attachment of all transactions of the disconnected tangle is required. (i.e. if the accidental partioning last for too long, IRI 1.5.2 will interpret this situation as a side-chain stiching (see point 3 below) ). (see also the related issue on github)

  1. Intentional partitionning

This is economic clustering . The details are still unknown at the moment.

  1. Side-chain stiching

An actor use a customized tip selection algorithm to build a side chain and try to include it in the main tangle later. We saw that this massive sudden appearance of transactions build on top of a very old milestone was causing problems for all participants using a fair-tip-sel.

IRI 1.5.2 should fix this kind situation.

Improve this answer
1
  • Well, you quote David Sonstebo in your question, and he just explain that "Not everything is OK". I'm not a specialist of the Flash Channels, but I don't see how the changes in IRI 1.5.2 may have an impact on this. (Flash channel start with a transaction to a multisig, ends with a transaction from a multisig. Last transaction don't need to approve the first one)
    – ben75
    Commented Jul 24, 2018 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.