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 5 commits behind head on v0.11.1.

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.1    #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.

[zoedberg]

I don't think the anchor type is broken, there are 2 different anchors so it's correct to have 2 different types, could you clarify your statement? Rust compile-time guarantees are there just as before, since we only removed the dichotomy, which was the reason why we chose seal unification in the first place.

[dr-orlovsky]

Seal unification means single type of anchor. Anchor dichotomy results in a lot of code complexity and makes audit much harder; it also significantly decreases ability to do formal verification of how single-seals are working.

I have a strong opinion about the importance of anchor unification for the security of the system.

If you want I can do it myself as a PR against this PR; but I won't ACK seal unification into the release without anchor unification.

[zoedberg]

It seems to me there’s still some misunderstanding, anchor dichotomy has been removed, therefore code became much simpler and easier to audit.

I acknowledge the fact that your opinion on the subject is strong, but it’s still unclear what’s the rationale behind it. Do you mind explaining it so the understanding can be shared and we can better cooperate on this rather important matter?

As for doing it, it’s not a matter of who does it, it’s just that it doesn’t seem the way to go, unless you have reasons to do this but unfortunately those are not clear at the moment.

[dr-orlovsky]

As was discussed on the call, I still think this introduces inconsistency into the consensus layer, and doesn't perform anchor unification. I will work on a PR adding that.

For now, we intoduce v0.11.1 branch, which will be considered experimental for now (I already changed the base for this PR) and will merge it there to let your work on further experiments as a separate PRs.