Skip to content
This repository has been archived by the owner on Dec 9, 2023. It is now read-only.

Asset transfer validation is ineffective #130

Closed
claudiosdc opened this issue Jan 26, 2021 · 7 comments
Closed

Asset transfer validation is ineffective #130

claudiosdc opened this issue Jan 26, 2021 · 7 comments
Assignees

Comments

@claudiosdc
Copy link
Contributor

I have noticed that the fungible validate command is not validating the witness transaction produced by an asset transfer operation (and referenced in the respective consignment data structure).

For instance, if one issues the fungible validate command right after the fungible transfer command, even before the witness PSBT is finalized and sent to the Bitcoin blockchain, the response will always be Asset transfer successfully validated.

This misbehavior has been verified in version 0.2.1 of RGB node.

@dr-orlovsky
Copy link
Member

This is correct, it should not validate it. The task of witness transaction validation lies on the wallet. The reason is the simple fact that this transaction is probably not yet mined when the consignment arrives and wallet needs to wait for it.

@claudiosdc
Copy link
Contributor Author

After some debugging, I have realized that the consignment validation procedure (validate method of the Consignment structure of the Stash daemon) was actually returning an EndpointTransitionNotFound warning, which means that the procedure was not finding the endpoint node ID (in my test, the consignment had a single endpoint) in the state transitions of the consignment data structure.

After further investigation, I have found out that the cause of this problem is in the procedure that generates the consignment for an asset transfer operation. More specifically, in the consign method of the Stash trait implementation for the Runtime structure of the Stash daemon.

What happens is that the consign method is passed the transition node via its node input parameter, whose ID is then used to produce the endpoints entry of the Consignment structure (see code snippet).

However, that same method, prior to adding the received transition node to the state transitions vector, modifies it to conceal its asset change assignment (see code snippet). Once the transition is modified, its node ID also changes, thus causing the mismatch with the node ID in the endpoints entry.

@claudiosdc
Copy link
Contributor Author

This is correct, it should not validate it. The task of witness transaction validation lies on the wallet. The reason is the simple fact that this transaction is probably not yet mined when the consignment arrives and wallet needs to wait for it.

@dr-orlovsky, then I am really confused because, reviewing the code that is executed when processing the fungible validate command, it is clear that a Spectrum server is queried to make sure that the witness transaction (whose txid is found in the consignment produced by the asset transfer) exists, and that it spends the UTXO that holds the single-use seal associated with the asset allocation that is used as the source for the asset transfer.

If you look at my previous comment, you will see an explanation of why this not happening as it should.

@dr-orlovsky
Copy link
Member

Thank you for all the details. Will review the process how it happens in the code and what can/should be fixed and report back.

@claudiosdc
Copy link
Contributor Author

claudiosdc commented Jan 27, 2021

@dr-orlovsky, in an intention to contribute a bit more with your effort, I was looking at a way to fix this issue. However, the solution seems to be more complex than I have anticipated.

I thought that it would be just a matter of replacing the node ID in the consignment's endpoints to match the node ID of the transitions in the consignment's state transitions. That is, the consignment's endpoints would include the node ID of the concealed transitions (I mean, the transition after its assignments are concealed as required), in the same way that the consignment's state transactions include the concealed transitions.

When that is done, the fungible validate command does not return the EndpointTransitionNotFound warning any more. However, this triggers another error condition, and the fungible validate command now returns the TransitionNotInAnchor failure.

The TransitionNotInAnchor failure is due to the fact that now the node ID (of the concealed transition) in the consignment's endpoints does not match the node ID of the transitions that were used to generate the anchor. In fact, reviewing the procedure that is used to generate the anchors, it is passed the node ID of the "plain" transitions. By "plain" I mean before any of its assignments are concealed as required.

One possible solution would require to change the way the anchors are generated so that they use the node ID of the concealed transitions instead.

@dr-orlovsky
Copy link
Member

The conceal operation must not modify the transition node id. Transition node id, when computed, conceals all data anyway and uses the concealed version for the hashing. If the id is modified after any of concealements applied that means that the id computing is broken. I will investigate that part of the story separately.

As for the reason why the transition is not found during the validation, it the node id computing works correctly, there should be a different cause of the bug.

@dr-orlovsky dr-orlovsky moved this from Discovered issues to Under investigation in Quality Assesment Feb 10, 2021
@dr-orlovsky dr-orlovsky self-assigned this Feb 10, 2021
@dr-orlovsky dr-orlovsky linked a pull request Feb 10, 2021 that will close this issue
UkolovaOlga added a commit to LNP-BP/devcalls that referenced this issue Feb 15, 2021
10.02.2021 Agenda:
RGB QA

Issues from https://github.com/orgs/rgb-org/projects/11:

1. Properly handle result from 'validate' request to Stash daemon - RGB-WG/rgb-node#132
2. Asset state transition node ID mutability
    - https://github.com/rgb-org/rgb-node/issues/133
    - RGB-WG/rgb-node#131
    - Asset transfer validation is ineffective: RGB-WG/rgb-node#130
3. Question about fungible asset known allocations semantics - RGB-WG/rgb-node#134
4. Transfer change allocation not being registered - RGB-WG/rgb-node#129
5. Transaction output duplicated by 'fungible transfer' - RGB-WG/rgb-node#127
@dr-orlovsky dr-orlovsky moved this from Under investigation to Solutions in review in Quality Assesment Feb 24, 2021
@dr-orlovsky
Copy link
Member

Solved with RGB-WG/rgb-core#8

Quality Assesment automation moved this from Solutions in review to Done Mar 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants