-
Notifications
You must be signed in to change notification settings - Fork 7
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 Mock option to Tx Building #11
Conversation
…pture the --mock-witness-count value.
Working on this update (c89b2ae) I realized we should come up with a standard on how we manipulate transactions and how we expect further transaction updates to occur. Version 2.10.1 of CardanoSharp.Wallet introduced a new Both of these functions are useful, but not together. Now I'm not sure if we should just pick a stance on how transactions should be built, or if we should always add functionality that achieves the same goal but can be used regardless if you use builders or not. Example: I could added an extension for |
@@ -90,6 +103,17 @@ public async ValueTask<CommandResult> ExecuteAsync(CancellationToken ct) | |||
// Fee Calculation | |||
var fee = tx.CalculateAndSetFee(protocolParams.MinFeeA, protocolParams.MinFeeB); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I suggest a mock witness count parameter in CalculateFee and CalculateAndSetFee (with a default value of 0) again? Transactions will more likely be built in a separate environment to where the signing/witnessing will happen so it makes sense for CardanoSharp.Wallet to cater for this scenario instead of having all consumers replicate this code?
My simple view is that since the transaction body and metadata is generally finalised by one party, the only part of a transaction that should be manipulated is the witness set. Changing anything else will change the signature payload which invalidates the previous witnesses. Given the the typical transaction life cycle:
Steps 1 and 2 would happen in the same context in the majority of cases, but steps 3 and 4 can cross process/network boundaries and switch hands with some level of coordination. However that coordination should entirely be an application layer concern or handled manually out-of-band (e.g. a manual process in discord, a Orleans-based app which orchestrates signatures, etc.). So with that in mind I'm definitely leaning towards the cardano-cli approach of finalising the body+metadata, calculating the fees based on the expected number of witnesses but leaving the witnesses empty, and leaving it to the layers above to coordinate the signatures and append their witnesses one by one. |
Ok yeah that definitely makes sense for general flow. Do you think we should empty out the Mock Witnesses after calculating the fee (maybe inside the new Calculate method) or should i just create an extension specifically to remove the mocks? |
The first option makes sense to me, unless you can think of a scenario where consumers might want to do explicitly create/remove them? |
This PR: CardanoSharp/cardanosharp-wallet#88 is in response to this comment: #11 (comment) |
LGTM |
No description provided.