Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add tapret tweak only when necessary #158

Merged
merged 1 commit into from
Apr 19, 2024

Conversation

zoedberg
Copy link
Contributor

@zoedberg zoedberg commented Apr 3, 2024

I've found a bug while doing transfers between an opret wallet (using rgb-lib) and a tapret wallet (using rgb-wallet). In detail I've:

  1. issued a contract with the opret wallet
  2. sent some assets from the opret to the tapret wallet
    • in witness
    • the sender defined an opret seal
  3. sent some assets back from the tapret to the opret wallet
    • with a blinded UTXO
    • requesting an opret seal

The second transfer will have in input an opret seal and will define 2 seals, one opret (for the receiver) and one tapret (for the RGB change), therefore it will need to create an opret anchor.

This transfer fails (when calling the pay method) with the error Completion(TapretKey(NoCommitment)).

Investigating this, I've noticed that the call to psbt.dbc_output::<TapretProof>() returns an p2tr output and currently it's used to decide if a tapret tweak needs to be added. But when it tries to extract the tapret commitment from that output (let tapret_commitment = output.tapret_commitment()?;) it fails because it's not there (since the call to rgb_commit created just an opret commitment). I think the issue is that the call to dbc_output is not enough to decide whether there is a tapret commitment that needs a tapret tweak to be added, in this case for example the method is seeing the p2tr output for the bitcoin change.

Therefore with this fix I'm protecting that code with an extra check, inspecting the AnchorSet of the Fascia to see if there's a tapret anchor. As an alternative fix I think the rgb_commit method could return the CloseMethodSet it used and then protect the addition of the tapret tweak calling has_tapret_first.

Copy link
Member

@dr-orlovsky dr-orlovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 0aa29fd

let tapret_commitment = output.tapret_commitment()?;
self.wallet_mut()
.add_tapret_tweak(terminal, tapret_commitment)?;
if let (Some(_), _) = fascia.anchor.as_reduced_unsafe().as_split() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is dangerous way to do it - if the split method change signature and will return opret anchor first, this will be missed to be changed. Thus, the better is to

Suggested change
if let (Some(_), _) = fascia.anchor.as_reduced_unsafe().as_split() {
if let (Some(Anchor::<_, TapretProof> { .. }), _) = fascia.anchor.as_reduced_unsafe().as_split() {

... but this is too clunky and better I would modify RGB Core API

@dr-orlovsky dr-orlovsky merged commit a0c5c63 into RGB-WG:master Apr 19, 2024
15 of 20 checks passed
@dr-orlovsky
Copy link
Member

Sorry, reverted since this uses invalid base and everything in RGB Core has already changed

dr-orlovsky added a commit that referenced this pull request Apr 19, 2024
@dr-orlovsky
Copy link
Member

Ok, I did the fix in the right way in ce07eb7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants