v0.11 fixes

[zoedberg]

This PR is part of a v0.11 fixes epic, see RGB-WG/rgb-tests#30 for an overview.

[dr-orlovsky]

Concept and approach ACK.

Left few comments and thoughts

[dr-orlovsky]

This type becomes strictly equal to Outpoint. I do not think we need it anymore

[zoedberg]

I think we do need it because ExplicitSeal can be ExplicitSeal<Txid> or ExplicitSeal<TxPtr>. Or do you think we could drop the generic from ExplicitSeal?

[dr-orlovsky]

I think we can drop generic form and just implement the trait we need (something like TxoSeal... there were some traits for explicit seals) and have ExplicitSeal<TxPtr> renamed into GraphSeal (which is a type alias to it anyway, so we do not need both) - and ExplicitSeal<Txid> (with its alias GenesisSeal) removed, and Outpoint uses instead of them.

We can make things even more simple: in v0.12 I got rid of TxPtr taking convention that Txid of zeros means witness output-based seal. This reduces a lot of code here, at no risk cost (from my experience, each time you have an enum in core, add 1000 lines at least where you deal with it's matches....)

So, if you follow v0.12 approach, you will end up with having just Outpoint as a seal definition - and that's it.

(To be fully frank, in v0.12 we do have just one seal type, TxoSeal, but not Outpoint, since there we support failback seal definition. Not sure we need that in v0.11, which is temporary anyway).

[zoedberg]

I think here I can say the same I said in RGB-WG/rgb-core#285 (comment): since this is just refactor I'll do this in another set of PRs after these ones are ACKed

[dr-orlovsky]

I am taking my suggestion back: single type of seals doesn't work and I had to differentiate two seal types it in v0.12: #112

[codecov]

Codecov Report

Attention: Patch coverage is 62.96296% with 30 lines in your changes missing coverage. Please review.

Project coverage is 41.2%. Comparing base (a928721) to head (2180f54).
Report is 1 commits behind head on v0.11.

Files with missing lines	Patch %	Lines
seals/src/txout/blind.rs	73.4%	17 Missing ⚠️
seals/src/txout/explicit.rs	0.0%	10 Missing ⚠️
src/bin/bpcore-stl.rs	0.0%	2 Missing ⚠️
seals/src/txout/witness.rs	0.0%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           v0.11    #111     +/-   ##
=======================================
- Coverage   42.1%   41.2%   -0.9%     
=======================================
  Files         35      34      -1     
  Lines       3521    3428     -93     
=======================================
- Hits        1483    1414     -69     
+ Misses      2038    2014     -24     

Flag	Coverage Δ
rust	41.2% <63.0%> (-0.9%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dr-orlovsky]

Seal unification is still pending in this PR, or you like to do a separate one with unification?

[zoedberg]

Seal unification is still pending in this PR, or you like to do a separate one with unification?

There is no commit for seal unification in this PR because when we did "make contract commit to a close method" we already removed the close method from the seal.

[dr-orlovsky]

Seal unification still requires implementation of DBC verification which should happen in BP DBC crate. You also need to introduce a unified proof type. Pls check how I did that in v0.12

[zoedberg]

Seal unification still requires implementation of DBC verification which should happen in BP DBC crate. You also need to introduce a unified proof type. Pls check how I did that in v0.12

DBC verification was already and still is in BP DBC crate.
First rgb-core validation code checks that the proof provided in the consignment is of the correct type, depending on the expected closing method, which is derived from the first DBC-compatible output (first op_return/pt2r). Then bp-core, based on the proof type (opret or tapret), checks that the first output of that type contains a valid MPC.
I think we can implement seals unification without a unified proof type, why do you think we need that?

[dr-orlovsky]

Well, without seal unification in DBC you just have a broken anchor type system with two different anchors, and you do not use rust compile-time guarantees for the consensus security. Basically, this is not a completed seal unification.