Packaging witness files

[andrew-fleming]

Should witness files be packaged? And if so, what should they look like exactly?

The options as I see them:

1. Package interface and a default impl
2. Package only the interface
3. Package neither

[andrew-fleming]

If witnesses are fully inlined into the testing simulator, as #381 seems to do, this would suggest that @0xisk proposes #3. I know it's a draft (as of this writing). Is this accurate?

I imagine that the most helpful approach would be #1. The idea is users won't have to create their own witnesses from scratch if they so choose (witness logic should also be tested independently). And if the default witnesses don't work for them, there's at least an interface ready to go. Note that #389 proposes to remove the ledger import from the witness file, if that was a concern

cc @emnul

[0xisk]

@andrew-fleming thanks for starting this conversation here.

as #381 seems to do, this would suggest that @0xisk proposes #3. I know it's a draft (as of this writing). Is this accurate?

As it seems that it supports option 3 it actually is not, as I'm following the same way in midnight-apps and there it is more of option 1. The reason it looks like option 3 atm is that because there is not really an interface that needs a function implementation to be exported from us, all of the witnesses so far are purely private input from the user so I don't see any additional value to be added from us here Unless we are thinking to propose a safe nonce generation witness and this has some strength validation. But up till now, all the witnesses can be just in-lined in the simulators. The reason I think option 1 would be good here is by looking at this witnesses/ example in the midnight-apps as here I think it brings useful usage by simply importing the necessary impl in their witness interface. That's why the scripts are called by the name of the witness function in the contract as wit_divUint128.ts, and the implementation is pure without any relation to the MN tx context. Then in building the Simulator for testing or the contract provider for intergration the user could simply import our impl as here for example. Wdyt?