cannot distinguish allocations coming from unsafe history

[zoedberg]

As shown in RGB-WG/rgb-tests#22 a wallet is unable to distinguish an allocation coming from an "unsafe" history (i.e. a history containing unbroadcasted/unmined TXs) from allocations coming from a "safe" history. I think either these kind of allocations should be distinguished or the wallet should not be able to accept a transfer with unsafe history when using a "normal" resolver (i.e. one using an indexer).

[dr-orlovsky]

This happens due to a fact that we allow unmined last transaction (so we can validate consignment before the sender publishes it).

The question here is how to distinguish that last "terminal" transaction from the rest, buried more deeply in the history. Before we were relying on "terminals" information in the consignment, but it also may be faked.

The very simple fix is to reject any unpublished transactions - this is the fix I propose in #283

In v0.12 we will be able to fix this by verifying that the transnaction is the last one (since we force witness ordering as proposed in RGB-WG/RFC#15) - but it can't be done in v0.11 since the consensus doesn't know anything about the state transition graph structure and can't reason which is the terminal one and which is not

[zoedberg]

This happens due to a fact that we allow unmined last transaction (so we can validate consignment before the sender publishes it).

It's not the last transaction which is unmined but the previous one.

The very simple fix is to reject any unpublished transactions - this is the fix I propose in #283

I agree with the fix. It will break the LN channel opening but for that I guess we can use a custom resolver

In v0.12 we will be able to fix this by verifying that the transnaction is the last one (since we force witness ordering as proposed in RGB-WG/RFC#15) - but it can't be done in v0.11 since the consensus doesn't know anything about the state transition graph structure and can't reason which is the terminal one and which is not

As just said it's not the last transaction which is unmined so I guess this will not be possible in v0.12 either

[dr-orlovsky]

It will break the LN channel opening but for that I guess we can use a custom resolver

Yeah, seems there is no other option than using a custom resolver

As just said it's not the last transaction which is unmined so I guess this will not be possible in v0.12 eithe

I mean the last transaction can be unmined, but not the others (like the previous before last, which we have in the test) - thus, we need to differentiate the last tx from others. This will be possible in v0.12 in automatic fashion