Use environment variable STELLAR_ACCOUNT to specify the default public account

MikeFair commented 6 years ago

Rather than have to specify source_account or account of interest on every call, let the environment variable STELLAR_ACCOUNT supply a default for all cases where it's needed.

This is especially useful for load-account, set-options, change-trust, fund, send-payment, and stream

tolitius commented 6 years ago

since it would need to be a seed rather than a public key in order to sign transactions, I think it would be best not to store this seed there in the ENV variable directly, but rather have this variable point to a file:

export STELLAR_ACCOUNT=~/.stellar/foo

BB-8 would just read this file in a "$(cat foo) style" with "io/ioutil"

tolitius commented 6 years ago

or we can have STELLAR_ACCOUNT to be a public key and then only provide the seed on signing:

$ cat manage-data.json
{
    "source_account": "GBDGNIE6H7RSFIXLID6XO3GHUPPCX5BBJ7JJBRXKB6DBS5B2VSEUWOG6",
    "name": "answer to the ultimate question",
    "value": "42"
}

$ cat manage-data.json | xargs -0
  bb manage-data | xargs
  bb sign '["'$(cat seed)'"]' | xargs
  bb submit

this works too, and also later on could be sent over to a remote source (such as the hardware wallet for the signature).

MikeFair commented 6 years ago

This latter version is what I was thinking; just the public key --- then the signing key only when necessary to/from whatever the signing app is.

tolitius commented 6 years ago

STELLAR_ACCOUNT_ADDRESS and STELLAR_ACCOUNT_SEED are now in place.

the address env can be exported directly, whereas the seed env will be set to a file not to leave a shell history trail.

sign command was also updated to resolve seed from STELLAR_ACCOUNT_SEED if no signers are provided.

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'
2018/02/22 11:18:52 can't resolve Stellar account address (a.k.a. source account). you can set it via STELLAR_ACCOUNT_ADDRESS environment variable or provide it as a "source_account" field of the transaction

$ export STELLAR_ACCOUNT_ADDRESS=$(cat distributor.pub)

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'
2018/02/22 11:19:35 could not submit transaction: can't find the account seed. you can either provide it explicitely in the transaction or set "STELLAR_ACCOUNT_SEED" environment variable that points to a file with a seed

$ export STELLAR_ACCOUNT_SEED=~/.stellar/distributor

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'
## great success

sign will resolve the seed from the file:

$ bb manage-data '{"name": "answer to the ultimate question", "value": "42"}' | xargs
  bb sign

AAAAAEZmoJ4/4yKi60D9d2zHo94r9CFP0pDG6g+GGXQ6rIlLAAAAZABt1SYAAAAMAAAAAAAAAAAAAAABAAAAAAAAAAoAAAAfYW5zd2VyIHRvIHRoZSB1bHRpbWF0ZSBxdWVzdGlvbgAAAAABAAAAAjQyAAAAAAAAAAAAATqsiUsAAABA4R8YMtT8FeV4zCHUGqK0wOYyAK7CAtQfima8Ym90tg49cXkjMWXfyzeghbLE8gPum0AkQG9faz0l8uU/G7RLCQ==

or signers can be provided explicitly:

$ bb manage-data '{"name": "answer to the ultimate question", "value": "42"}' | xargs
  bb sign '["'$(cat distributor)'"]'

AAAAAEZmoJ4/4yKi60D9d2zHo94r9CFP0pDG6g+GGXQ6rIlLAAAAZABt1SYAAAANAAAAAAAAAAAAAAABAAAAAAAAAAoAAAAfYW5zd2VyIHRvIHRoZSB1bHRpbWF0ZSBxdWVzdGlvbgAAAAABAAAAAjQyAAAAAAAAAAAAATqsiUsAAABAcXDv/QoDC52wqimZtm1bGNaRbiIbKC0wzYZvWUZ+YzMeym+JKWgkvAmqzOcDH0PjGmE4KbHmO0xDx5HKJPBXAA==

all other commands are updated to resolve address/seed when not explicitly provided:

$ bb send-payment '{"to": "'$(cat issuer.pub)'", "amount": "42.0"}' | xargs
  bb sign | xargs
  bb submit
2018/02/22 11:56:21 sending 42.0 XLM from GBDGNIE6H7RSFIXLID6XO3GHUPPCX5BBJ7JJBRXKB6DBS5B2VSEUWOG6 to GDQM2SJ2HSFPNPS2EQC6V3OF3RBJHX3WMFC2CWVIFJH6MGIWZG4DNMJK

$ bb set-options -s '{"home_domain": "stellar.org", "max_weight": 1}'

$ bb change-trust '{"code": "COMP",
                    "issuer_address": "'$(cat issuer.pub)'"}' | xargs \
  bb sign | xargs \
  bb submit

$ bb change-trust '{"code": "XYZ",
                    "issuer_address": "'$(cat issuer.pub)'"}' | xargs \
bb set-options  '{"home_domain": "dotkam.com",
                  "max_weight": 1}' | xargs \
bb sign | xargs \
bb submit

MikeFair commented 6 years ago

Looking at your examples made me want to rename STELLAR_ACCOUNT_SEED to just STELLAR_ACCOUNT and if STELLAR_ACCOUNT_ADDRESS is not set, it then uses the seed data in the file pointed at by STELLAR_ACCOUNT to create the public key.

On Thu, Feb 22, 2018 at 9:29 AM, Anatoly notifications@github.com wrote:

STELLAR_ACCOUNT_ADDRESS and STELLAR_ACCOUNT_SEED are now in place.

the address env can be exported directly, whereas the seed env will be set to a file not to leave a shell history trail.

sign command was also updated to resolve seed from STELLAR_ACCOUNT_SEED if no signers are provided.

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}' 2018/02/22 11:18:52 can't resolve Stellar account address (a.k.a. source account). you can set it via STELLAR_ACCOUNT_ADDRESS environment variable or provide it as a "source_account" field of the transaction$ export STELLAR_ACCOUNT_ADDRESS=$(cat distributor.pub)$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'2018/02/22 11:19:35 could not submit transaction: can't find the account seed. you can either provide it explicitely in the transaction or set "STELLAR_ACCOUNT_SEED" environment variable that points to a file with a seed

$ export STELLAR_ACCOUNT_SEED=~/.stellar/distributor

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'## great success

sign will resolve the seed from the file:

$ bb manage-data '{"name": "answer to the ultimate question", "value": "42"}' | xargs bb sign

AAAAAEZmoJ4/4yKi60D9d2zHo94r9CFP0pDG6g+GGXQ6rIlLAAAAZABt1SYAAAAMAAAAAAAAAAAAAAABAAAAAAAAAAoAAAAfYW5zd2VyIHRvIHRoZSB1bHRpbWF0ZSBxdWVzdGlvbgAAAAABAAAAAjQyAAAAAAAAAAAAATqsiUsAAABA4R8YMtT8FeV4zCHUGqK0wOYyAK7CAtQfima8Ym90tg49cXkjMWXfyzeghbLE8gPum0AkQG9faz0l8uU/G7RLCQ==

or signers can be provided explicitly:

$ bb manage-data '{"name": "answer to the ultimate question", "value": "42"}' | xargs bb sign '["'$(cat distributor)'"]'

AAAAAEZmoJ4/4yKi60D9d2zHo94r9CFP0pDG6g+GGXQ6rIlLAAAAZABt1SYAAAANAAAAAAAAAAAAAAABAAAAAAAAAAoAAAAfYW5zd2VyIHRvIHRoZSB1bHRpbWF0ZSBxdWVzdGlvbgAAAAABAAAAAjQyAAAAAAAAAAAAATqsiUsAAABAcXDv/QoDC52wqimZtm1bGNaRbiIbKC0wzYZvWUZ+YzMeym+JKWgkvAmqzOcDH0PjGmE4KbHmO0xDx5HKJPBXAA==

all other commands are updated to resolve address/seed when not explicitly provided:

$ bb send-payment '{"to": "'$(cat issuer.pub)'", "amount": "42.0"}' | xargs bb sign | xargs bb submit 2018/02/22 11:56:21 sending 42.0 XLM from GBDGNIE6H7RSFIXLID6XO3GHUPPCX5BBJ7JJBRXKB6DBS5B2VSEUWOG6 to GDQM2SJ2HSFPNPS2EQC6V3OF3RBJHX3WMFC2CWVIFJH6MGIWZG4DNMJK

$ bb set-options -s '{"home_domain": "stellar.org", "max_weight": 1}'

$ bb change-trust '{"code": "COMP", "issuer_address": "'$(cat issuer.pub)'"}' | xargs \ bb sign | xargs \ bb submit

$ bb change-trust '{"code": "XYZ", "issuer_address": "'$(cat issuer.pub)'"}' | xargs \ bb set-options '{"home_domain": "dotkam.com", "max_weight": 1}' | xargs \ bb sign | xargs \ bb submit

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tolitius/bb8/issues/2#issuecomment-367757185, or mute the thread https://github.com/notifications/unsubscribe-auth/ACMqLcs2HSSE3bS3vfuatrfh8IjTSxduks5tXaPlgaJpZM4SOpoV .

MikeFair commented 6 years ago

This also brings up some ambiguity regarding the transaction's source account, and the operations source_account.

The transaction's source account pays the fees and "fills in" on operations where an overriding source account wasn't provided. When it's adding an operation to an existing transaction the case is clear, the source_account provided is "op_level"; but when it's a brand new transaction it's much more ambiguous.

How does bb-8 express: Have account 'channel_account' submit a txn with one operation to pay 10 XLM from 'sender_account' to 'receiver_account'?

On Thu, Feb 22, 2018 at 12:14 PM, Michael Fair michael@daclubhouse.net wrote:

Looking at your examples made me want to rename STELLAR_ACCOUNT_SEED to just STELLAR_ACCOUNT and if STELLAR_ACCOUNT_ADDRESS is not set, it then uses the seed data in the file pointed at by STELLAR_ACCOUNT to create the public key.

On Thu, Feb 22, 2018 at 9:29 AM, Anatoly notifications@github.com wrote:

STELLAR_ACCOUNT_ADDRESS and STELLAR_ACCOUNT_SEED are now in place.

the address env can be exported directly, whereas the seed env will be set to a file not to leave a shell history trail.

sign command was also updated to resolve seed from STELLAR_ACCOUNT_SEED if no signers are provided.

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}' 2018/02/22 11:18:52 can't resolve Stellar account address (a.k.a. source account). you can set it via STELLAR_ACCOUNT_ADDRESS environment variable or provide it as a "source_account" field of the transaction$ export STELLAR_ACCOUNT_ADDRESS=$(cat distributor.pub)$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'2018/02/22 11:19:35 could not submit transaction: can't find the account seed. you can either provide it explicitely in the transaction or set "STELLAR_ACCOUNT_SEED" environment variable that points to a file with a seed

$ export STELLAR_ACCOUNT_SEED=~/.stellar/distributor

$ bb manage-data -s '{"name": "answer to the ultimate question", "value": "42"}'## great success

sign will resolve the seed from the file:

$ bb manage-data '{"name": "answer to the ultimate question", "value": "42"}' | xargs bb sign

AAAAAEZmoJ4/4yKi60D9d2zHo94r9CFP0pDG6g+GGXQ6rIlLAAAAZABt1SYAAAAMAAAAAAAAAAAAAAABAAAAAAAAAAoAAAAfYW5zd2VyIHRvIHRoZSB1bHRpbWF0ZSBxdWVzdGlvbgAAAAABAAAAAjQyAAAAAAAAAAAAATqsiUsAAABA4R8YMtT8FeV4zCHUGqK0wOYyAK7CAtQfima8Ym90tg49cXkjMWXfyzeghbLE8gPum0AkQG9faz0l8uU/G7RLCQ==

or signers can be provided explicitly:

$ bb manage-data '{"name": "answer to the ultimate question", "value": "42"}' | xargs bb sign '["'$(cat distributor)'"]'

AAAAAEZmoJ4/4yKi60D9d2zHo94r9CFP0pDG6g+GGXQ6rIlLAAAAZABt1SYAAAANAAAAAAAAAAAAAAABAAAAAAAAAAoAAAAfYW5zd2VyIHRvIHRoZSB1bHRpbWF0ZSBxdWVzdGlvbgAAAAABAAAAAjQyAAAAAAAAAAAAATqsiUsAAABAcXDv/QoDC52wqimZtm1bGNaRbiIbKC0wzYZvWUZ+YzMeym+JKWgkvAmqzOcDH0PjGmE4KbHmO0xDx5HKJPBXAA==

all other commands are updated to resolve address/seed when not explicitly provided:

$ bb send-payment '{"to": "'$(cat issuer.pub)'", "amount": "42.0"}' | xargs bb sign | xargs bb submit 2018/02/22 11:56:21 sending 42.0 XLM from GBDGNIE6H7RSFIXLID6XO3GHUPPCX5BBJ7JJBRXKB6DBS5B2VSEUWOG6 to GDQM2SJ2HSFPNPS2EQC6V3OF3RBJHX3WMFC2CWVIFJH6MGIWZG4DNMJK

$ bb set-options -s '{"home_domain": "stellar.org", "max_weight": 1}'

$ bb change-trust '{"code": "COMP", "issuer_address": "'$(cat issuer.pub)'"}' | xargs \ bb sign | xargs \ bb submit

$ bb change-trust '{"code": "XYZ", "issuer_address": "'$(cat issuer.pub)'"}' | xargs \ bb set-options '{"home_domain": "dotkam.com", "max_weight": 1}' | xargs \ bb sign | xargs \ bb submit

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tolitius/bb8/issues/2#issuecomment-367757185, or mute the thread https://github.com/notifications/unsubscribe-auth/ACMqLcs2HSSE3bS3vfuatrfh8IjTSxduks5tXaPlgaJpZM4SOpoV .

tolitius commented 6 years ago

Looking at your examples made me want to rename STELLAR_ACCOUNT_SEED to just STELLAR_ACCOUNT and if STELLAR_ACCOUNT_ADDRESS is not set, it then uses the seed data in the file pointed at by STELLAR_ACCOUNT to create the public key

Agree, this approach makes sense, however I would probably like to keep the STELLAR_ACCOUNT_SEED variable only. Here is my reasoning:

STELLAR_ACCOUNT_SEED: the name has no confusion whether it is an address or a seed
if STELLAR_ACCOUNT_SEED is set, there is really no need to set STELLAR_ACCOUNT_ADDRESS
allowing to set both could lead to confusion when STELLAR_ACCOUNT_SEED and STELLAR_ACCOUNT_ADDRESS are set for different accounts

as to:

Have account 'channel_account' submit a txn with one operation to pay 10 XLM from 'sender_account' to 'receiver_account'

All the operations have an optional "source_account" field, and it will be used for that operation. In case of channels, transaction will need to be signed by at least two keys: channel seed and an account operation seed which will be provided into the bb sign '["SDOTALI...", "SRBEIUR.."]'.

There is no "exposed" way to express it in BB-8 yet, however all the APIs are there. For example every operation creates a transaction header with a source account, sequence, network, etc.. So if a new command such as new-tx or tx-header is added it may be composed with any other operation:

$ bb new-tx '{"source_account": "foo"}' | xargs \ 
  bb send-payment '{"to": "receiver-address",
                    "amount": "42.0"}' | xargs \
  bb sign '[foo, bar]' | xargs \
  bb submit

a "source_account" for a payment operation in this case above will be set by the STELLAR_ACCOUNT_SEED. In case its a channel account, it would look like:

$ bb new-tx | xargs \ 
  bb send-payment '{"source_account": "bar",
                    "to": "receiver-address",
                    "amount": "42.0"}' | xargs \
  bb sign '[foo, bar]' | xargs \
  bb submit

in this case foo will be used from STELLAR_ACCOUNT_SEED as a channel account seed.

(Or maybe wrap-tx would be a better name)

MikeFair commented 6 years ago

My $0.02

new-tx is a great name for creating a new transaction header with sequence number and source_account coming from the data supplied. Other things like paying more in fees (for priority processing), and any other transaction level options being supplied at this point.

For all other operations, they should assume they are appending operations to an existing transaction and if source_account for their operation does not match the source_account for the parent transaction they are modifying, then they should explicitly set the source_account value on their operation.

If there is no preexisting transaction to append to (i.e. starting from scratch directly with an operation), then it sets the source_account and sequence number of the transaction (instead of the operation), but doesn't allow changing all the options that new-tx would (if you want access to those options, then use new-tx first). Future operations then append as operations and follow the logic above.

Lastly, if you really want to be lazy about it, always set source_account on the operation and if it happens to match the source_account for the transaction itself then what a coincidence. Though I really prefer the "if it matches; suppress it" logic more.

MikeFair commented 6 years ago

Agree, this approach makes sense, however I would probably like to keep the STELLAR_ACCOUNT_SEED variable only.

I'd like to keep the option of both but always have ADDRESS, if set, take precedence for source_account and SEED obviously for signing.

I'm someone who would likely always want to specify the signer key files on the CLI and not put it in a variable and can even see using hardware wallets to keep the SEEDs off the machine entirely. So I'm someone who would likely only use ADDRESS, or would only provide a public address "by default".

Having _ADDRESS to directly specify a public address and _SEED to specify a file (STELLAR_SEED_FILE?), with _ADDRESS taking priority gives me all the options I could envision myself wanting.

Why do I think ADDRESS has priority? Directly specifying the address versus indirectly through a file is more specific. And yes, I could specify the two variables differently because I'm scripting commands to work on several different accounts over the set of transaction operations. And prefer setting the env var in my "loop over each account" script.

For instance, env vars are sometimes inline, up front of a shell command: STELLAR_ADDRESS=GADDR; bb8 do-something

I think that should make STELLAR_ADDRESS precede STELLAR_SEED for determining the source account. The primary exception being for signing purposes where I agree with you, that we do not want to encourage specifying seeds where they can be seen in CLI history.

I really think a main use case for bb-8 is building up script files for processing transactions. Which I think has me looking at these things slightly differently from the "personal use only" case. ??

tolitius commented 6 years ago

Transaction Header

ok, new-tx it is. I started going with new-tx three weeks ago but back then API I had in mind wasn't something I would like today, so I removed it in order to think more about it and add it later in the future once I have a better idea that I like.

For all other operations, they should assume they are appending operations to an existing transaction and if source_account for their operation does not match the source_account for the parent transaction they are modifying, then they should explicitly set the source_account value on their operation.

Yes, that is what I mean by "all the operations have an optional "source_account" field, and it will be used for that operation", so we are in sync.

And I agree to avoid always setting a "source_account" on operations unless it needs to be overriden or there is no ENV that specifies it.

Also the work on the new-tx should be done separately, in a different issue. You can create it with details that you think are important, or let me know, I'll create one.

Address or Seed

Ok, I see where you are coming from, and I would really like to be able to not deal with seeds at all, and send XDR "somewhere" to sign. And only deal with seeds where absolutely needed: i.e. multi sign.

STELLAR_SEED_FILE is a small but great correction since I like names with clear intentions.

The way it is currently implemented, transaction header will always look at the ADDRESS rather than a SEED when transaction is composed, and it would look at the SEED when a stand alone transaction is being built, since it gets signed and submitted in one go.

I think STELLAR_SEED_FILE, if set, should only be used for signing transactions: i.e. it would be really ambiguous to create a public address from it in case STELLAR_ACCOUNT_ADDRESS is not set. In other words, you would most of the time have STELLAR_ACCOUNT_ADDRESS set, and would only set STELLAR_SEED_FILE if you need to implicitly sign a transaction.

BB-8 Use Case

I really think a main use case for bb-8 is building up script files for processing transactions

I would not really try to define all or main use cases for BB-8. But I agree "building up script files for processing transactions" was my initial goal. Also, coming from the Unix and LISP culture, I like the immediate feedback when working with systems: LISP REPLs, Unix shells are great examples of that. Hence I think Stellar should not be any different. Another good side effect is on boarding new people. Stellar Labs is great, but to me command line is a lot more visible, touchable, auditable, etc.

tolitius commented 6 years ago

this is in. added docs, created #6 to track adding "new-tx" separately

tolitius / bb8