Skip to content

Conversation

@joemphilips
Copy link
Contributor

depends on #694 , previous attempt is #684

Currently it is independent from #695 , and it follows bitcoin core's spec.

@joemphilips joemphilips changed the title Support output descriptor WIP: Support output descriptor May 22, 2019
@joemphilips joemphilips changed the title WIP: Support output descriptor Support output descriptor May 23, 2019
@joemphilips joemphilips force-pushed the OutputDescriptor branch 3 times, most recently from ef4f091 to e5bbb1a Compare May 27, 2019 09:55
@NicolasDorier NicolasDorier mentioned this pull request Aug 24, 2020
* Before this commit, Parser did not allow whitespace around
  '(', ')' and ','. By removing all whitespace as a preprocess
  for parsing, it is now rebust against user inputs.
  Also it is now bit faster because we don't have to call `.Token`
  combinator anymore.
* Remove useless `Tag` field from OutputDescriptor and PubKeyProvider
* Refactor pattern match for `Equals` method.

Both for the sake of consiceness.
... for `OutputDescriptor`, `PubKeyProvider`, `OutputDescriptorParser`
and `ISiginingRepository`
...for OutputDescriptor and PubKeyProvider
Since user must always access these types through
parent type, there are no point for repeating the
prefix twice. Thus we can simplify by dropping the
its prefix (in this case `Descriptor` and `PubKeyProvider`)
Copy link
Contributor

@lontivero lontivero left a comment

Choose a reason for hiding this comment

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

Some comments for your consideration.

* Add null check to everywhere public
* Add check for user-provided enum value.
* Make an indentation for switch expression a bit more natual.
@NicolasDorier
Copy link
Collaborator

I want implementation of the OutputDescriptor to be "closed" inside this library. i.e. user's should not create the new type by overriding OutputDescriptor, So I did not want to use virtual or abstract methods.

When you want to do this, you can just declare the abstract/virtual methods internal.

@joemphilips
Copy link
Contributor Author

When you want to do this, you can just declare the abstract/virtual methods internal.

But doesn't it make it impossible for user to use the method?

@NicolasDorier
Copy link
Collaborator

NicolasDorier commented Sep 18, 2020

@joemphilips yes, one thing often used also is have a method "BlahBlah" public and another one "BlahBlahCore" internal/protected.
With BlahBlah which don't have to do much... That's ugly if you have too many methods that need that, but if it is a one or two, I think that;s fine. (that said, I am not advocating for changing your code for using that, I did not reviewed enough your code yet to know if it indeed simplify things)

@NicolasDorier
Copy link
Collaborator

@lontivero you plan to still review some stuff or should I start review as well?

@lontivero
Copy link
Contributor

I will not review it more.

@NicolasDorier
Copy link
Collaborator

@joemphilips I think I will merge that soon. One question: About KeyId and WitScriptId. Do you really need it in say FlatSigningRepository?
As time pass, I get more and more convinced that KeyId/ScriptId/WitScriptId are classes that should never have existed in the first place, so I am curious why you need it.

@joemphilips
Copy link
Contributor Author

I can try using uint160/uint250 instead if you want, I've just used it because I like using different types for those cases. (It makes hard to misuse the API.)
Let me check if that works or not.

@joemphilips
Copy link
Contributor Author

After testing a bit, I think it is possible to use uint160/uint256 for ISigningRepository but It requires substantial refactoring.

e.g. I want to use the api like pk.WitHash.ScriptPubKey.Hash.ScriptPubKey or PayToPubkeyHashTemplate.ExtractScriptPubKeyParameters() which uses KeyId or ScriptIdso I first have to add a new methods/properties to PubKey , ScriptTemplate , that will be huge change on the existing code.

I suppose it is out of the scope for this PR, if you really want to make KeyId/ScriptId obsolete, first we’d better make those types obsolete in existing code.

(which I don’t think is necessary though btw, having wrapper types like WitScriptId and ScriptId is a nice way to specify the intention.)

@NicolasDorier
Copy link
Collaborator

@joemphilips don't refactor to use uint160/uint256 instead I just want to know, why you need those Ids classes rather than just ScriptPubKey

@joemphilips
Copy link
Contributor Author

  1. It is done in that way in original implementation
  2. It is a bit smaller
  3. It is more easy to understand the intention (e.g. for TryGetPubKey(KeyId keyId, out PubKey pubkey) , if the first argument is Script, reader might get confused whether that is ScriptPubKey for the p2pk, or ScriptPubKey for the p2pkh)

@joemphilips
Copy link
Contributor Author

joemphilips commented Oct 27, 2020

Would you consider merging this? I have a plan to use it. @NicolasDorier

* Implement `OutputDescriptorJsonConverter`.
@NicolasDorier NicolasDorier merged commit 825f265 into MetacoSA:master Oct 29, 2020
@NicolasDorier
Copy link
Collaborator

NicolasDorier commented Oct 29, 2020

Released a new version. (.62)

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.

3 participants