Making well-known pre-approved transactions useful about stellar-protocol

[MonsieurNicolas]

Yes we're working on making this better.

In the meanwhile, I think that for this particular case you can achieve what you want by taking advantage of an escrow account where you set its master weight to 0.

The property that you want to use is that updating the signers should be done with the last operations within your transaction (to enable/disable the next edges in the graph), not as a way to modify the current transaction; you also need to make sure that the order of those operations are always valid from a signature point of view (see example below for transaction ID #2).
Basically at the end of each "state transition", you want to update the signers (edges) of the graph that make valid transitions.

Also, something to note is that if a transaction is submitted to the network with a sequence number that doesn't match the current account's counter, it will be rejected without consuming the sequence number.

I used sequence number 1 as the sequence number for the escrow account, but of course you'd need to adjust it to be whatever the escrow account has.

I also added an extra step, I think you were missing a transition that lets the consumer acknowledge receipt of the goods.

Also, I use Cleanup here as shorthand for the following operations: { delete trustline(s), merge account -> consumer } or { restore master weight to 10 }

Transactions should only be signed before submitting to the network in this particular case.

Tx #1 Signature: (setup by Consumer)

seq=1 Escrow account setup with escrow amount.

   Update signers to:
        1. h(#4) @ 10
        2. h(#2) @ 8
        3. Merchant @ 2
        4. Consumer @ 1
        5. Resolver @ 1

   Update weights to:
        1. Master = 0
        2. Low=Med=High=10

Tx #2 Signature: Merchant

seq=2 Updated - Merchant said they shipped (no-op= send 1 XLM to self).

Update signers to:
        1. Delete h(#4) (deletes not strictly required but help with cleanup)
        2. Set h(#5) @ 8
        3. Set h(#6) @ 8
        4. Set h(#7) @ 8
        5. Set Consumer @2
        6. Set Resolver @ 1
        7. Set Merchant @10 <<< this is important as the remaining weights would not work out
        8. Delete h(#2)
        9. Set Merchant @1

Tx #3 Signature: Merchant

seq=2 Merchant refunds consumer & account cleanup

Tx #4 Signature: None

seq=2 Valid after T+30days: "UnlockExpiredEscrow" refund & cleanup

Tx #5 Signature: Consumer

seq=3 New: Consumer acks receipt, release amount from escrow, cleanup

Tx #6 Signature: Merchant

seq=3 Valid after T+5 days: Merchant - starts dispute "consumer didn't ack/release funds"

Update signers to:
        1. Delete h(#5)
        2. Delete h(#6)
        3. Delete h(#7)
        4. h(#8) @ 8
        5. h(#9) @ 8
        6. Merchant @ 1
        7. Consumer @ 1
        8. Resolver @ 2

Tx #7 Signature: Consumer

seq=3 Updated - Consumer starts dispute: "not received"/"not what I wanted" (follows #2)

Update signers to:
        1. Delete h(#5)
        2. Delete h(#6)
        3. Delete h(#7)
        4. h(#8) @ 8
        5. h(#9) @ 8
        6. Merchant @ 1
        7. Consumer @ 1
        8. Resolver @ 2

Tx #8 Signature: Resolver, Merchant

seq=4 completeDisputedEscrow: send funds to merchant, fee to Resolver & cleanup

Tx #9 Signature: Resolver, Consumer

seq=4 refundDisputedEscrow: send funds back to consumer, fee to resolver & cleanup

[roosmaa]

In Tx#2:

7. Set Merchant @10 <<< this is important as the remaining weights would not work out
8. Delete h(#2)
9. Set Merchant @1

Including the tx hash of itself is kind of difficult. I recall the documentation saying that the hash of the signed contract would be removed automatically.

Tho it does bring up another idea - maybe in the future, the transaction seq number could be included besides the hash, so once it becomes impossible to execute that tx it would be automatically removed? It would also help with long chain of transactions that are dependent on oneanother which makes removing their hashes difficult and freeying up the 20 available signer slots is sometimes needed for large graph.

[MonsieurNicolas]

Ah yes, sorry the delete h(#2) in Tx #2 is implicit and not required like you said; you should still be able to implement the workflow.

I agree, I think we need to make those one time signatures easier to manage. I don't know what should be enabled just yet at the protocol layer though (a condition on sequence number is just one of the conditions that people may want).

One of the steps here that is not easy to do is "cleanup" that cannot be a mergeaccount operation if the tx was authorized by a one time hash so the only way right now it seems is to restore the master weight to something sane and let the person with the secret key do the cleanup.

[MonsieurNicolas]

btw, I opened #53 that should help reduce the need to rely on h(transaction) (and instead just use sequence numbers when possible).

[theaeolianmachine]

@roosmaa, do you feel a core enhancement (CAP) or ecosystem proposal (SEP) is needed, or can we close this out?

[roosmaa]

@theaeolianmachine it's been so long since I created this issue that I cannot really answer that question. So let's close this.