Here are some complications with the current TSA in Chrysalis.
- Computing OTSRI and YTSRI is hard.
- Laziness is inherited. Thus, promotions are almost impossible, because an old transaction will never be approved by something which will be other nodes’ eligible tip list. Thus, in order to promote something, a node must issue a transaction which gets directly referenced by a milestone, which is rather unlikely.
- Is the distinction between lazy and semi-lazy strictly necessary?
Here is an alternative which is simple. We define the YRM (Youngest Referenced Milestone) of a transaction to be index of the most recent milestone in the past cone. For example, a transaction directly referencing Milestones #50 and #48 will have YRM 50. Something referencing this transaction and an older transaction should have YRM 50 too. If a new milestone arrives, noone’s YRM changes.
The TSA then uniformly picks a tip satisfying the following:
- YRM was greater than
current milestone index-2(or some other number than 2) at the time of arrival. - It is not below max depth.
When a new transaction arrives
- The YRM is the max of its parents
- If the YRM is within 2 of the current milestone index, the transaction is added to the tip list.
Pros of this approach.
- The YRM can be recursively calculated, and does not change with incoming milestones.
- The tip list can be recursively maintained, and it does not need to be scrubbed when a milestone arrives (with the exception of the below max depth).
- Promotions are super easy.
- A transaction is only eligible for TSA if it has at least one “good” parent and is thus helping the network.
Cons:
- We still need an easy way to compute which things are below max depth.
- A lazy node could always just select the last miestone as for their two tips. But this behavior is a problem with most TSAs I think.
- Suppose N is the current milestone index. A malicious actor could issue transactions X with one parent milestone N, and the other milestone N-15 (or whatever the below max depth parameter). Unless the next milestone indirectly references it, X will violate below max depth when milestone N+1 is issued. Any transactions which reference X will then also become invalid too, thus an attacker can use X to try to orphan other incoming transactions.
A variant of this last attack however can essentially be perpetrated in the original TSA: an attacker issues a transaction X that is almost lazy, and then when after the next milestone, X will be become lazy. Thus any transaction referencing X will need promoting, which is close to impossible. It seems to me that any variant of this attack is possible as long as we have a hereditary, temporal condition.