RFC: Weighted Uniform Random Tip-Selection

[luca-moser]

Rendered

[gjeee]

The concept (to me at least) of "confirmed root transactions" is a bit unclear (yellow boxes in the pic). But what are the green ones then? I would think they are as well.

Here again...what are the green ones then?

[gjeee]

Also I think TSI is not exactly defined:

Transaction Snapshot Index (TSI) defines the index of the milestone which confirmed a given transaction.

Shouldn't it be: ......the index of the oldest milestone......?

[luca-moser]

@gjeee First thanks for your comments, please use the review feature next time as the way you wrote your comments they don't target specific lines (even though they should/do)

Regarding your first comment:

The concept (to me at least) of "confirmed root transactions" is a bit unclear (yellow boxes in the pic). But what are the green ones then? I would think they are as well.

The text from the RFC says:

Confirmed Root Transactions defines the set of first seen transactions which are confirmed by a previous milestone when we walk the past cone of a given transaction. The walk stops on confirmed transactions.

The green transactions are not Confirmed Root Transactions because if you would walk as described in the text from the PoV transaction, you wouldn't reach them as you stop walking as soon as you reach an already confirmed Confirmed Root Transaction. Those "stopping points" are the yellow transactions as described in the RFC.

Regarding your second comment:

Also I think TSI is not exactly defined:

Transaction Snapshot Index (TSI) defines the index of the milestone which confirmed a given transaction.

Shouldn't it be: ......the index of the oldest milestone......?

Only ever one milestone does confirm a given transaction, there's no need to say oldest in this context. Of course newer milestone still reference previous transactions but in this context it is clear that we're talking about the milestone which confirms a transaction.

[GalRogozinski]

As per discord discussion the following points should be emphasized clearly:

1. A tip is eligible for selection only if it is solid
2. An invalid tip (doesn't pass bundle validation) should be given a score 0. As already defined, this score will propagate upwards

[thibault-martinez]

Tiny nit but the README says the path should be text/0000-my-feature/0000-my-feature.md otherwise everything is on the root.

[muXxer]

A tip should stay in the tip pool for some time, even if it got referenced by other transactions.
Otherwise the tangle would become really slim and it would be much harder to sync, because we have to request tx by tx.

Maybe have two criteria at the same time? A minimum time after first reference by another tx or a maximum amount of references. If one of the two criteria is reached, the tip is removed from the pool.

[luca-moser]

I've added a paragraph for those rules, please verify whether they are ok @muXxer.

[GalRogozinski]

2 points we need to agree on:

1. Only bundles with valid signatures should be legible for tip selection

currently we think yes

2. Do we need to add a delay before tip before removing from tip pool?

[hmoog]

LGTM