changed requirement of TX to point to all prevs

[woutslakhorst]

See appendix A.2 of rfc004 for rationale

[reinkrul]

Just thought of additional issues:

I see potential issues when nobody tries to merge unmerged heads:

• There's no incentive to limit the number of branches. While a single branch, or a bunch of them are harmless, 1000 branches with a TX with the same LC is not (due to page size). Now the number of branches can be every-increasing, while previously it would attempt to return to 1 branch
• There are dependencies between TXs not modelled in the prevs: VC subjects (maybe others as well?). A VC TX does not refer to the TX which created/last updated the subject's DID document, so it might be in a different branch. Given that TX are casually ordered, a TX (e.g. a VC) that refers to something that happened in another TX (a DID) must refer to that earlier TX, either directly (prev) or indirect (some 'prevs ago'). Previously this wasn't a problem, because you referred to all heads. That automatically included a potential branch which contains the dependent TX (e.g. the DID).

[woutslakhorst]

There's no incentive to limit the number of branches. While a single branch, or a bunch of them are harmless, 1000 branches with a TX with the same LC is not (due to page size). Now the number of branches can be every-increasing, while previously it would attempt to return to 1 branch

When branches are merged, there's also no limit on the number of branches.

A VC TX does not refer to the TX which created/last updated the subject's DID document, so it might be in a different branch

Yes it does: network_publisher#88 All dependencies on earlier transactions must be solved by prevs, ordering of transactions can never be used because that would be an attack vector.