-
Notifications
You must be signed in to change notification settings - Fork 503
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
txnbuild: build transactions using xdr string #1329
Comments
I looked into exactly what's involved in this. TLDR: we should just do it now. The old Go The new I originally thought we should defer this until we start using This mapping is handled in the JS SDK for Transactions here. It delegates to the appropriate mappings for each XDR-sub-object. The majority of the work is to handle each kind of Operation (see here). The code is a little tedious, but straightforward. We should just implement the equivalent thing for
The goal is that after calling one of these methods the object should be able to be used normally, e.g. to have signers added, timebounds tweaked etc, and then built when ready. This work adds full support for building from XDR strings, which is a significant feature improvement. It will make implementation of #1530 much simpler, and makes #1540 unnecessary. |
A slightly related question: The txnbuild.Transaction struct holds the network string. When this get's built into the xdr.TransactionEnvelope this seems to be dropped so that when we decode the envelope we have to re-add the network string before signing. What's the rationale behind this? As it stands this means a signing service needs to know which network the transaction is destined for to add a signature. Should adding a signature require knowledge of the network passphrase? |
@ire-and-curses thanks for looking into this. I think we should be able to include this in the next release. I agree with most of what you have outlined, my only concern is the following:
I don't think we should be encouraging users to modify transactions(except adding signers) that has already been built. The output of In any case, a transaction that is modified after it has been signed, will fail when submitted to the network. I guess modification of an XDR string is only useful if the transaction has not been signed. @OwenJacob the network passphrase is used to generate the hash of the transaction. The hash is what is signed. This is why it is required for the signing process. |
Agree that if the incoming serialised TX is signed we should prevent For the case of an unsigned incoming serialised TX, we should allow tweaking and building as usual. This handles the use cases of third party signing, and also users storing a TX in serialised form for reference or transport. |
The JS SDK enables users to intialise a transaction object using the base64 transaction envelope.
It will be good to have something similar for the Go sdk.
The text was updated successfully, but these errors were encountered: