Bundles in Tangle


Author
Message
Enis Olgac
E
IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)
Group: Forum Members
Posts: 40, Visits: 1.7K
I was wondering how a bundle in tangle would look like, and draw this figure. It is showing “Genesis” and five transfers, each of them a bundle, a set of four transactions.

*** Missing Image due to upload error ***

In a dag vertices are supposed to be of same kind. Therefore, it is preferable to redefine the entities of tangle as bundles, each being an ordered-list of 1 to n transactions. If done so, a genuine bundle just attached to tangle will:
  • be a tip
  • have 1 + (n - 1) branchBundle
  • n - 1 internal trunkBundle
  • 1 external trunkBundle
The additional branchBundles can be used to provide more approvals. Or, they can be used to maintain a total-order on tangle, and not a partial-order as indicated in the whitepaper. Also, every legitimate ledger must have a total-order. The missing total-order (being temporally sorted) on tangle implies credit accounts on IOTA, where their absence may be the cause of unbalanced and/or zero balanced accounts reported in different posts. After all, it is imperative that all sites on tangle must be in total-order. Total-order means that the reduced tangle is an ordered-list:

*** Missing Image due to upload error ***



Edited 10 Months Ago by Enis Olgac
Enis Olgac
E
IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)
Group: Forum Members
Posts: 40, Visits: 1.7K
With uploaded Figures

I was wondering how a bundle in tangle would look like, and draw this figure. It is showing “Genesis” and five transfers, each of them a bundle, a set of four transactions.

In a dag vertices are supposed to be of same kind. Therefore, it is preferable to redefine the entities of tangle as bundles, each being an ordered-list of 1 to n transactions. If done so, a genuine bundle just attached to tangle will:
be a tip
have 1 + (n - 1) branchBundle
n - 1 internal trunkBundle
1 external trunkBundle
The additional branchBundles can be used to provide more approvals. Or, they can be used to maintain a total-order on tangle, and not a partial-order as indicated in the whitepaper. Also, every legitimate ledger must have a total-order. The missing total-order (being temporally sorted) on tangle implies credit accounts on IOTA, where their absence may be the cause of unbalanced and/or zero balanced accounts reported in different posts. After all, it is imperative that all sites on tangle must be in total-order. Total-order means that the reduced tangle is an ordered-list:


Edited 3 days ago @ 1:23 by Enis Olgac

Enis Olgac
E
IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)
Group: Forum Members
Posts: 40, Visits: 1.7K
I was following the discussion in #tanglemath. Here is how I understand the role of bundles in tangle:

  • A bundle is a linked-list of transactions. Each transaction refers to the next one via trunkTransaction, except the head (C4).
  • It is not clearly specified in Bundles, but I assume that branchTransaction of every transaction in the bundle refers to one and the same tip.
  • trunkTransaction of the head refers to another tip.
  • According to whitepaper, tip A and tip E are not necessarily distinct.

Please note that upon attachment to the tangle, all transactions except C1 are sites according to whitepaper. It is also crucial that a bundle must be attached to tangle as a bundle, and not one transaction after the other.
As soon as a "tip selection" is required, the procedure traverses tangle backwards (or its reciprocal forwards) starting at some site, e.g. G (this can be a tedious and error-prone task, if you are not using directed graphs as your data-structure). The process continues until it discovers a tip. Assume that during traversal "tip selection" hits C3. Because C3 is a site, the process will continue with C2, also a site, and then with C1. C1 is a tip, so it will be returned as selected. If the process returns anything else than C1, then it is a bug.

Enis Olgac
E
IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)
Group: Forum Members
Posts: 40, Visits: 1.7K
Bundles; An Alternative Implementation

Whitepaper states that sites in tangle are linked in the opposite direction of increasing time, i.e. towards Genesis. Transactions in a bundle though are linked in the direction of increasing time, i.e. away from Genesis. This is neither necessary nor useful.
As an alternative one could reverse the linkage of transactions in a bundle. The first transaction of the bundle would then link to the last transaction of the last bundle of the same account. Where account should be understood as equivalent to seed from which the private keys are generated. Every other transaction would link to the previous transaction of the same bundle. The bundle would look like as illustrated:
 
This implementation would have the following advantages:
  • All bundles, i.e. transactions, would comply the same definition
  • The last transaction of a bundle, therefore the bundle, will be by definition a tip
  • Once a tip is confirmed, all transactions of a bundle can be executed as a single unit (all or none execution)
  • The first, and possibly the only, transaction of a bundle can be linked to any number of tips as required
  • All bundles, therefore all transactions of an account would be linked as a list, i.e. a sequence. Because transactions are temporally ordered, tangle would comply with the definition of a legitimate ledger
Considering bundles as illustrated would ease the implementation of tangle as a genuine directed graph, which is currently not the case.


Enis Olgac
E
IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)IOTAn Pending (1.2K reputation)
Group: Forum Members
Posts: 40, Visits: 1.7K
Tangle, free of Conflicting Transactions?

Why not. Here is the explanation.
Premises we build on:
  1. Private part of a key identifies an account owner
  2. Public part of the same key can be used as a generally available id for the account
  3. Only the owner of the key can issue a valid spending notice
  4. A valid spending notice is the only source to change the balance of an account
  5. Just before a spending notice is issued, the node operating the account has a particular (definite) view of tangle
  6. The description of the view in (5) is part of the notice
  7. Descriptions of two specific views of tangle are comparable to be equivalent or not
Building on these premises, a spending notice can only be in one of the following states when it arrives a node:
  1. Pending; it cannot be asserted whether the issuing and receiving views are equivalent, or not. Processing of notice will be delayed.
  2. Valid; issuing and receiving views are equivalent, and the spending notice is valid. Tangle will be updated accordingly.
  3. Invalid; issuing and receiving views are equivalent, and the spending notice is invalid. Notice will be rejected, and tangle remains as is.
There will be no transaction which is valid, but in conflict with the tangle history. For a simple reason. If the issuing and receiving views are equivalent, they refer to views with the same tangle history. A particular notice which is valid in one view, cannot be invalid in an equivalent view, or vice versa.
In a tangle with no conflicting transactions, there is no need for consensus building. Accordingly, processing of issuing notices will be deterministic, in order and in value.

How views can be described in such a way that they are comparable, is beyond the scope of this post.

Edited 9 Months Ago by Enis Olgac
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search