After playing with this new option, I think we should change the design.

The new option is not really usable where it is in a meaningful way without being coupled with --build-only. The reason being is that any use where the tx will be sent immediately really just needs to use the current sequence number plus one. The only need for setting a different sequence number occurs when building and later sending.

Since the option is only usable in that advanced build-only case, I think we should make this something they can do with the stellar tx ... commands. It will keep the options advertised smaller for each of the subcommands being changed here, and keeps the advanced functionality for tx modifications in the same place. Maybe as a way to simply change a sequence number stellar tx set seq, where those commands could grow to support others like stellar tx set source-account. Or maybe by using the stellar tx edit.

Originally posted by @leighmcculloch in #1702 (comment)

Maybe as a way to simply change a sequence number stellar tx set seq, where those commands could grow to support others like stellar tx set source-account.

Fleshing out the idea I alluded to above here's one idea to start the design process. I think given the tx structure is a tree of related fields and sub-fields, we could organise this transaction command the same.

stellar tx set source-account <SOURCE_ACCOUNT>
stellar tx set sequence-number <SEQUENCE_NUMBER>
stellar tx set fee <FEE>

stellar tx set memo none
stellar tx set memo text <MEMO_TEXT>
stellar tx set memo id <MEMO_ID>
stellar tx set memo hash <MEMO_HASH>
stellar tx set memo return <MEMO_RETURN>

stellar tx set preconditions none

stellar tx set preconditions time-bound none
stellar tx set preconditions time-bound max <MAX_TIME_BOUND>
stellar tx set preconditions time-bound min <MIN_TIME_BOUND>

stellar tx set preconditions ledger-bound none
stellar tx set preconditions ledger-bound min <MIN_LEDGER>
stellar tx set preconditions ledger-bound max <MAX_LEDGER>

stellar tx set preconditions min-seq-num none
stellar tx set preconditions min-seq-num <MIN_SEQ_NUM>
stellar tx set preconditions min-seq-age none
stellar tx set preconditions min-seq-age <MIN_SEQ_AGE>
stellar tx set preconditions min-seq-ledger-gap none
stellar tx set preconditions min-seq-ledger-gap <MIN_SEQ_LEDGER_GAP>

stellar tx set preconditions extra-signers none
stellar tx set preconditions extra-signers add <EXTRA_SIGNERS>

Some of these subcommands are pretty long, e.g. preconditions, and I think we should enable the "match abbreviated" command option that clap-rs supports. We already have it enabled in the stellar-xdr that is embedded under the 'stellar xdr' command, and it means you can type stellar xdr d, or stellar xdr dec, for stellar xdr decode. For the above commands it would allow for some abbreviation such as stellar tx set precond ... for frequent users while remaining unambiguous and self describing in their full form.

Preconditions actually have multiple ways to be constructed when there are no preconditions, and when there are only time bounds, and I think the CLI can just optimise around that, the UI doesn't need to expose those differences. The CLI can upgrade and downgrade the conditions as necessary to keep the tx as small as possible.

Thoughts? cc @sagpatil @fnando @willemneal

Is it necessary to follow the commands from a tree of related fields or could we drop words like preconditions as the developers don't necessarily need to know it is a precondition, only that they can set the field based on a known field name.

@janewang Nothing is set in stone, we could drop the tree structure, which is similar to what @willemneal did in his PR, although the PR is options oriented rather than sub-commands. The challenge with dropping no hierarchy is that some modifications of the tx have ambiguous scope. If we get rid of the stellar tx set preconditions none command, then we probably don't need the hierarchy.

@janewang are you suggesting something such as:

stellar tx set source-account <SOURCE_ACCOUNT>
stellar tx set sequence-number <SEQUENCE_NUMBER>
stellar tx set fee <FEE>

stellar tx set memo none
stellar tx set memo text <MEMO_TEXT>
stellar tx set memo id <MEMO_ID>
stellar tx set memo hash <MEMO_HASH>
stellar tx set memo return <MEMO_RETURN>

stellar tx set time-bound max none
stellar tx set time-bound max <MAX_TIME_BOUND>
stellar tx set time-bound min none
stellar tx set time-bound min <MIN_TIME_BOUND>

stellar tx set ledger-bound min none
stellar tx set ledger-bound min <MIN_LEDGER>
stellar tx set ledger-bound max none
stellar tx set ledger-bound max <MAX_LEDGER>

stellar tx set min-seq-num none
stellar tx set min-seq-num <MIN_SEQ_NUM>
stellar tx set min-seq-age none
stellar tx set min-seq-age <MIN_SEQ_AGE>
stellar tx set min-seq-ledger-gap none
stellar tx set min-seq-ledger-gap <MIN_SEQ_LEDGER_GAP>

stellar tx set extra-signers none
stellar tx set extra-signers add <EXTRA_SIGNERS>

Or something such as:

stellar tx set --source-account <SOURCE_ACCOUNT>
stellar tx set --sequence-number <SEQUENCE_NUMBER>
stellar tx set --fee <FEE>

stellar tx set --memo-none
stellar tx set --memo-text <MEMO_TEXT>
stellar tx set --memo-id <MEMO_ID>
stellar tx set --memo-hash <MEMO_HASH>
stellar tx set --memo-return <MEMO_RETURN>

stellar tx set --time-bound-max-none
stellar tx set --time-bound-max <MAX_TIME_BOUND>
stellar tx set --time-bound-min-none
stellar tx set --time-bound-min <MIN_TIME_BOUND>

stellar tx set --ledger-bound-min-none
stellar tx set --ledger-bound-min <MIN_LEDGER>
stellar tx set --ledger-bound-max-none
stellar tx set --ledger-bound-max <MAX_LEDGER>

stellar tx set --min-seq-num-none
stellar tx set --min-seq-num <MIN_SEQ_NUM>
stellar tx set --min-seq-age-none
stellar tx set --min-seq-age <MIN_SEQ_AGE>
stellar tx set --min-seq-ledger-gap-none
stellar tx set --min-seq-ledger-gap <MIN_SEQ_LEDGER_GAP>

stellar tx set --extra-signers-none
stellar tx set --extra-signers-add <EXTRA_SIGNERS>

@willemneal If we ignore the "preconditions none" / "--no-preconditions" case, it does seem much less ambiguous. The only option that seems a little odd at that point is the extra signers one.

My 2 cents: it'd be easier to chain tx edit with flags, and I think it's a very common use case to setup multiple things at once. (--memo-text <..> --fee <...> --sequence number <...>
On the extra-signers: I agree, I think it could be confusing for people who are not very familiar with preconditions (what's the difference between --extra-signers and signing with one more key?) not sure how we can combine working easily with flags and clarity on preconditions.

For input to whether we need flags for some of the advanced options, according to the stellar hubble bigquery dataset there is some usage of min-account-sequence, and rare usage of others.

SELECT
  EXTRACT(YEAR from created_at),
  COUNTIF(min_account_sequence IS NOT NULL AND min_account_sequence != 0) as min_account_sequence,
  COUNTIF(min_account_sequence_age IS NOT NULL AND min_account_sequence_age != 0) as min_account_sequence_age,
  COUNTIF(min_account_sequence_ledger_gap IS NOT NULL AND min_account_sequence_ledger_gap != 0) as min_account_sequence_ledger_gap,
  COUNTIF(extra_signers IS NOT NULL AND ARRAY_LENGTH(extra_signers) != 0) as extra_signers
FROM `crypto-stellar.crypto_stellar.history_transactions`
GROUP BY 1
ORDER BY 1 DESC
LIMIT 1000

For the extra-signers functionality, I think it's worth keeping that outside the tx set command. Extra-signers is a list, similar to how operations are a list in the tx. The operations @willemneal is adding as a separate command in the form stellar tx op add ... (#1663), and extra-signers could follow suit: stellar tx extra-signers add ....

But it's also such a low used feature, it could be argued not worth adding the command for. But if it's easy enough may as well.

🤔 I have another idea for us to consider: flip the tx set command too so it is modelled like the tx op command.

stellar tx source-account set <SOURCE_ACCOUNT>
stellar tx sequence-number set <SEQUENCE_NUMBER>
stellar tx fee set <FEE>

stellar tx memo clear
stellar tx memo set text <MEMO_TEXT>
stellar tx memo set id <MEMO_ID>
stellar tx memo set hash <MEMO_HASH>
stellar tx memo set return <MEMO_RETURN>

stellar tx time-bound clear
stellar tx time-bound max clear
stellar tx time-bound max set <MAX_TIME_BOUND>
stellar tx time-bound min clear
stellar tx time-bound min set <MIN_TIME_BOUND>

stellar tx ledger-bound clear
stellar tx ledger-bound min clear
stellar tx ledger-bound min set <MIN_LEDGER>
stellar tx ledger-bound max clear
stellar tx ledger-bound max set <MAX_LEDGER>

stellar tx min-seq-num clear
stellar tx min-seq-num set <MIN_SEQ_NUM>
stellar tx min-seq-age clear
stellar tx min-seq-age set <MIN_SEQ_AGE>
stellar tx min-seq-ledger-gap clear
stellar tx min-seq-ledger-gap set <MIN_SEQ_LEDGER_GAP>

stellar tx extra-signers clear
stellar tx extra-signers add <EXTRA_SIGNER>

The above would pave the way for a rich set of future commands:

stellar tx source-account get
stellar tx sequence-number get

stellar tx op list
stellar tx extra-signers list

Automatically resets it based on the source account, setting it to the next valid value.

stellar tx sequence-number next

Auto set seq num based on 5 more than the source account currently has:

stellar tx sequence-number set +5

Auto set time bounds based on 5 mins from now:

stellar tx time-bounds max set +5min

Using this model loses the convenience @Ifropc mentioned about being able to combine multiple together, but it paves the way for a rich set of commands for getting at fields, not just setting them.

If we did the above, I think we'd need to move the subcommand under stellar tx edit, so that the namespace wasn't a mix of the existing tx commands along with the above.

While I was happy for the solution with minimal changes, I think the second one is must cleaner and will make it clearer to new devs. This does come at the cost of terseness as @Ifropc, points out will make setting multiple fields more verbose.

There is a solution for example tx set --time-bounds-max-set ... --sequnce-number next. Which would share the same naming. But as usually it's probably better to have a single way to do something.

@Ifropc @janewang If there is agreement I can start on @leighmcculloch's last suggestion, tx edit time-bounds set max +5min, etc.

Perhaps we could add a tx update, which would then resolve all of the accounts and also maybe update the seq_num and fees?

-- @willemneal #1785 (comment)

This would be really convenient.

I think we could in addition provide the same functionality in a way that is composable. For example:

• stellar tx edit sequence-number next and stellar tx sequence-number set +1 from How to set fields on Transactions #1643 (comment)

• stellar tx resolve-addresses to do as you say and resolve all aliases used anywhere that will map to an AccountId, MuxedAccount, or ScAddress