Accounts that must authorize incoming transactions about stellar-protocol

[jedmccaleb]

An implementation issue here is that we can either

1. do this check before txs are flooded
2. do the check when txs are applied to the ledger.

---

1. this would mean that the destination account of payments would need to be loaded during checkValid. seems bad.

2. this would mean that these txs would fail the check to make sure there aren't superfluous signatures on the envelope during check valid. So we would have to remove this check for at least txs with payment operations. seems bad.

@MonsieurNicolas any thought on this?

[MonsieurNicolas]

I think one way to approach this is to decouple things so that we favor a flow similar to multi sig where signatures are added by different parties by adding a "claims" operation that is a noop from the ledger point of view, but that allows to express claims about various aspects of the transaction (participants in a n-way payment, limits, etc)

For example, let's say you want A to pay X to B, where B requires some verification to be done (and can be done by T that can be different from B).

A would craft a tx that looks like this:
tx source: A
op: claims { tier1 verified } . source: T
op2 : payment, source: null (A), send X to dest=B
then get "T" to sign the transaction and submit it to the network.

account B would be setup with something like:
operation O1 requires claims C1 at threshold TT1 (we could instead of doing this do it with categories, like "Payments" to avoid situations where a "Payment2" allows to get around this)
then there is a list of signers for claims, with weights
before processing the payment, we would check if op2 meets the claim requirements.

As far as validation goes:
checkValid (used during flooding etc) would not check for claim requirements
BUT
we would perform the additional checks on the tx endpoint

Going with a solution like this makes this viable with the order book as well (as many banks would most likely share who they trust for claims).

[jedmccaleb]

Hmm interesting, what types of things could you use this for beyond this new option 3 below?

Another option:
3) add a new operation called "ApproveTransfer" that must be in the tx to allow any account that has the mustApprove flag set. Downside is that it seems a more heavy weight. Txs to these guys will now have to be crafted in a certain way.

[codeck]

Another option: an account with mustApprove only accept operations where peer account has overlapped signer.
it's a mimic of social contract of partial handover of control in regulated finance system.

[MikeFair]

I'm not sure how multi-sig handles it; but I see three things.

I generally like the ability for an account to mark itself as "require my signature" and even "refuse all transactions". Any transaction where this account is a Destination could be put into a "Pending" status and be found in the "held" transactions on the account object. I build on this idea a bit in 3.

I also don't see the need for requiring the txn to go back to A for final approval. A already sent it out the door; B has an added condition that it wants to review the final form before accepting the transaction; the txn's fate is entirely in B's hands at that point.

It's quite common for things to get into "Pending Approval" or "Needs More Information" state.

It's a great idea to support a transaction having a potentially long lived "pending" state when other parties can add comments; sign for approval/cancellation; or transfer the transaction to another party.

While "pending" a transaction is "held" by an owning account, kind of like an asset actually; the ball is in this account's court.

An Account here has three buckets for "pending" transactions; "incoming", "outgoing", and "held". "incoming" and "outgoing" return all "pending" transactions where the account is a direct source or destination. "held" is for txns where this Account is the current owner (may not be Source/Destination).

I don't know what's already supported, but the operations I see on held txns are "cancel" and "transfer" (with memo fields; and signers approving the "cancel" or "transfer" transaction).

The "transfer" transaction moves a transaction to the "held" bucket of another account. A transaction can die in transit if it doesn't reach its final destination in time.

If a transaction is "held" by the destination account; executing a "transfer" to itself applies the transaction and the transaction comes out of "pending" status.

It would be ideal if the signing requirements for a transfer were on a "per destination account" basis. That way an automated system could sign for its own transfers on transactions it hadn't yet processed; transferring a transaction to itself (the final approval step) can have different requirements; and transferring to some random unapproved account where the transaction could get lost can't happen.

Automated processes could use these accounts and transfer operations to implement workflows for compliance and other rules based systems; or even for simple reporting purposes on current flows.

Lastly, there's two new boolean properties for an account; "hold incoming transactions" and "hold outgoing transactions". These settings cause a transaction to go "pending" and get "held" by the account where it requires a "transfer" to move on.

Using this, to implement the above; the receiving bank would turn on "hold incoming transactions"; it would then execute a transfer to itself to "approve" the incoming transactions; "cancel" to reject them; or "transfer" to another account if more processing is required before making a decision.

---

I can see several use cases for this feature.
Aside from the obvious workflow approvals;

1. When receiving an Asset, the receiving system needs to ensure it knows what asset it's receiving. The Asset might have an identifier, but that doesn't mean the internal system has a means by which to work with the asset (what kind of asset is it? Currency? Equity? Forward Contract? Bond? Can I get pricing for it? Does it trigger any regulatory or filing requirements? Who did it come from?). This gives the system an automated means to ensure the internal systems have the asset set up before accepting it.

2. Matching; this is more of a "preapproval" process; but it's important that an asset trader and a broker agree on the details before sending their respective settlement instructions to a bank. It's common to email spreadsheets back and forth, or better yet, use more sophisticated matching systems like "Omgeo", where the traders and brokers first put their transactions into a common space where they can digitally agree on the details before sending the transaction out the door. Matching is one market where Stellar could improve things for financial services. It would be a new type of thing for Stellar, but the basic process is each party's system places its prospective block/allocation trade levels into the Stellar network where only the respective counter party could see the trade. An automated comparison system usually does most of the heavy lifting and eventually marks the trades as "Matched" when all the various fields agree. Once the matching system has approved the match on the trade details, the internal system at each respective party then sends those instructions to the bank. (Then bank then having received two sets of authorized, matching instructions completes the transaction with the broker.)

One thing that's different is that while a transaction hasn't been matched it's still very fluid. All of the transaction details can be easily amended. This would be the equivalent of each counter party building a pending transaction in the network where both the "Accounts" involved can see it while it's still fluid. They can't directly change the other Account's version of the trade, but they can compare them.

3. Think "son/daughter" has an account, maybe a credit card like account, but all transactions incoming and outgoing need to be approved "mod/dad" first.

4. Making M of N signatures easier. Each signer has their own "home account" in addition to their shared "M of N" account. By placing the transaction into the "held" bucket of all N "home accounts" all of the users can see it in their supporting wallet app. Once they sign the txn as "approve" or "cancel" the txn disappears from the "held" bucket on their wallet app. This implies that a transfer operation can send a pending transaction to multiple accounts. The original creator of the transaction would execute the initial "transfer" to "home account" of each of the signers.

For signers that don't have a "home account" the transaction also goes into the "held" bucket on the source account. Perhaps, since these transactions are "pre-approval", a "prelim" status bucket is better...

5. It's flexible enough that many folks could create all kinds of other workflows.