Re: [Sat] Burn-Assertion and Mint-Assertion messages

[Denis Avrilionis <[e-mail]>]

I suggest we add a sessionID (or more generally a transferContext ) in all assertions otherwise we will have problems associating the change of state with the specific transfer instance

--
Denis

> On 21 Mar 2023, at 19:59, Venkatraman Ramakrishna <[e-mail]> wrote:
> 
> Thomas,
> 
> So a function will be evaluated in Stage 1 that looks something like this, right: f([<assetId>, <assetProfileId>]) = <Session-ID>
> 
> If this is a one-way function, one can't recover the inputs given just the output. Then I think we will need to keep those fields in the Burn-assertion JSON as the receiving network (behind G2) may very well need to do some bookkeeping in its ledger based on those asset attributes (the same logic holds for other assertions). But if those values can be unambiguously extracted from <Session-ID>, then they don't need to be explicitly added to the JSON, strictly speaking.
> 
> Rama
> 
> -----Original Message-----
> From: Thomas Hardjono <[e-mail]> 
> Sent: 21 March 2023 20:23
> To: Denis Avrilionis <[e-mail]>; Venkatraman Ramakrishna <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] RE: [Sat] Burn-Assertion and Mint-Assertion messages
> 
> 
> Folks,
> 
> Just revisiting this in preparation for IETF116 next week.
> 
> Burn-assertion (lock-assertion):
> 
> {
> "gatewayId": "did:gateway:tz:tz1aaYoabvj2DQtpHz74Z83fSNjY29asdBfZ",
> "networkId": "tezos:NetXdQprcVkpaWU",
> "assets": [{
> "assetId": "tezos:NetXdQprcVkpaWU/tzip16:tz1YWK1gDPQx9N1Jh4JnmVre7xN6xhGGM4uC/1",
> "assetData": {},
> "assetProfileId": "tezos:NetXdQprcVkpaWU/tzip16:tz1CAK1gDPQx9N1Jh4JnmVre7xN6xhGGM433/1",
> "assetState": "Burned",
> "assetStateTimestamp": "2023-02-22T20:20:39+00:00"
> }]
> 
> 
> Question:  should the Burn-Assertion message (msg 2.6) and the Commit-Ready (that carries the Mint-Assertion) indicate a Session-ID?
> 
> Sorry if its unclear, let me rephrase:  if G1 and G2 already agreed on the assetId and assetProfileId early in Stage-1 (before Transfer-Commence msg 2.1) and that this agreement results in a jointly-derived Session-ID value, should these assertions be less verbose and simply mention Session-ID?
> 
> Or do we need to actually carry assetId and assetProfileId values in these assertions? 
> 
> 
> SAT-Core (draft-hargreaves) currently has this payload for the Transfer-Commence (Section 81. in the text):
> 
>          {
>          "message_type": "urn:ietf:satp:msgtype:transfer-commence-msg",
>          "session_id":"9097hkstgkjvVbNH",
>          "originator_pubkey":"zGy89097hkbfgkjvVbNH",
>          "beneficiary_pubkey": "mBGHJjjuijh67yghb",
>          "sender_net_system": "originNETsystem",
>          "recipient_net_system":"recipientNETsystem",
>          "client_identity_pubkey":"fgH654tgeryuryuy",
>          "server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334",
>          "hash_asset_profile":"nbvcwertyhgfdsertyhgf2h3v4bd3v21",
>          "asset_unit": "ghytredcfvbhfr",
>          "hash_prev_message":"DRvfrb654vgreDerverv654nhRbvder4",
>          "client_transfer_number":"ji9876543ewdfgh",
>          "client_signature":"fdw34567uyhgfer45"
>          }
> 
> 
> 
> 
> Thoughts?
> 
> 
> best
> 
> 
> --thomas
> 
> 
> 
> 
> 
> 
> ________________________________________
> From: sat [[e-mail]] on behalf of Thomas Hardjono [[e-mail]]
> Sent: Tuesday, February 28, 2023 2:24 PM
> To: Denis Avrilionis; Venkatraman Ramakrishna
> Cc: [e-mail]
> Subject: Re: [Sat] Burn-Assertion and Mint-Assertion messages
> 
> Hi Denis,
> 
>>>> Maybe we shall keep the network assertions messages (related to the 
>>>> Gateway <-> Network communication) decoupled from the messages 
>>>> exchanged between gateways. However, messages between gateways may 
>>>> include references to network assertions. For example, the 
>>>> "Burn-Assertion" message below could be included as a reference in message 3.6 from G1 to G2. (That way, all network <-> gateway messages remain unchanged if for any reason we modify the sequence of messages between gateways).
> 
> Yes ideally all signed assertions (e.g. in JSON) must be standalone in the sense that the signed-assertion blob can be: (i) included in the message (e.g. part of HTTP body), or (ii) be storable elsewhere with a hash/reference of the blob included in the actual message.
> 
> 
> --thomas
> 
> 
> 
> 
> 
> ________________________________________
> From: Denis Avrilionis [[e-mail]]
> Sent: Tuesday, February 28, 2023 2:02 PM
> To: Thomas Hardjono; Venkatraman Ramakrishna
> Cc: [e-mail]
> Subject: Re: [Sat] Burn-Assertion and Mint-Assertion messages
> 
> Dear Thomas, Rama, Alex,
> 
> Regarding including hashes of messages / nonces, I understand this is to create an order in the sequence of exchange between gateways.
> 
> Maybe we shall keep the network assertions messages (related to the Gateway <-> Network communication) decoupled from the messages exchanged between gateways. However, messages between gateways may include references to network assertions. For example, the "Burn-Assertion" message below could be included as a reference in message 3.6 from G1 to G2. (That way, all network <-> gateway messages remain unchanged if for any reason we modify the sequence of messages between gateways).
> 
> Regarding the sequence of messages, all messages between Gateways can be defined with explicit numbers (as shown in the message flow diagram). Given that we also have a SATP instance ID that defines a specific exchange between two gateways, the couple [<SATP Instance ID>, <message flow number>] is equivalent to a nonce. (note: we should make sure all possible messages between gateways are defined and numbered, including all rollback cases too).
> 
> Denis
> 
> 
> On 28 Feb 2023, at 17:09, Thomas Hardjono <[e-mail]<mailto:[e-mail]>> wrote:
> 
> 
> 
> Following Denis' model for the Lock-Assertion, for the Burn-Assertion do we need only to change the assetState to become "Burned" and include the timestamp:
> 
> {
> "gatewayId": "did:gateway:tz:tz1aaYoabvj2DQtpHz74Z83fSNjY29asdBfZ",
> "networkId": "tezos:NetXdQprcVkpaWU",
> "assets": [{
> "assetId": "tezos:NetXdQprcVkpaWU/tzip16:tz1YWK1gDPQx9N1Jh4JnmVre7xN6xhGGM4uC/1",
> "assetData": {},
> "assetProfileId": "tezos:NetXdQprcVkpaWU/tzip16:tz1CAK1gDPQx9N1Jh4JnmVre7xN6xhGGM433/1",
> "assetState": "Burned",
> "assetStateTimestamp": "2023-02-22T20:20:39+00:00"
> }]
> }
> 
> 
> 
> --thomas
> 
> 
> 
> ________________________________________
> From: sat [[e-mail]<mailto:[e-mail]>] on behalf of Thomas Hardjono [[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, February 28, 2023 9:45 AM
> To: Venkatraman Ramakrishna; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Sat] Burn-Assertion and Mint-Assertion messages
> 
> Hi Rama,
> 
> Would the hashes be there in addition to signatures and session IDs (or nonces) or in place of them?
> 
> Yes, in addition to signatures and the session-ID carried in each message.
> 
> The bigger question is that there are pairs of messages (e.g. messages 2.5 and 2.6, and msgs 3.6 and 3.8) that are loaded with implications, as compared to other pairs (e.g. messages 2.1 and 2.2).
> 
> So, should we require an explicitly inclusion of a hash for those pairs of important messages?
> 
> (The goal is to reduce cheating opportunities by G1 and G2, since the channel is already TLS protected).
> 
> 
> 
> Are there examples of other protocol sequences where successive messages include hashes of the previous ones?
> 
> Right now I can't think of any (I think SAML2.0 permits this for the Request/Response pairs).
> 
> But also, we are dealing with value-transfer (economic value), not just communications of bits/bytes.
> 
> 
> 
> --thomas
> 
> 
> 
> ________________________________________
> From: Venkatraman Ramakrishna [[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, February 28, 2023 9:30 AM
> To: Thomas Hardjono; [e-mail]<mailto:[e-mail]>
> Subject: RE: Burn-Assertion and Mint-Assertion messages
> 
> Would the hashes be there in addition to signatures and session IDs (or nonces) or in place of them? Are there examples of other protocol sequences where successive messages include hashes of the previous ones?
> 
> Rama
> 
> -----Original Message-----
> From: Thomas Hardjono <[e-mail]<mailto:[e-mail]>>
> Sent: 28 February 2023 19:44
> To: Venkatraman Ramakrishna <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] RE: Burn-Assertion and Mint-Assertion messages
> 
> 
> 
> Regarding the ACK-Final, as you say, it is critical for the conclusion of asset transfer.
> Does 3.10 serve as a sort of an ACK for the ACK-Final then?
> 
> That is, should it be incumbent upon G2 to attempt retransmission of an ACK-Final until it receives a conclusive "Transfer-Completed"?
> 
> Yes, I think G2 has to keep trying until it gets a Transfer-Completed message.
> 
> Also, the Transfer-Completed message 3.10 from G1 needs to carry a hash of the ACK-Final (msg 3.8) as a means to implicitly state that G1 has received & accepted the Mint-Assertion from G2.
> 
> 
> On a separate but related question, does it make sense for us require each message to include a hash of the previous message (for the same transfer session)?
> 
> 
> 
> --thomas
> 
> 
> 
> 
> ________________________________________
> From: Venkatraman Ramakrishna [[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, February 28, 2023 7:45 AM
> To: Thomas Hardjono; [e-mail]<mailto:[e-mail]>
> Subject: RE: Burn-Assertion and Mint-Assertion messages
> 
> "Burn-Assertion" and "Mint-Assertion" sound fine from a terminology perspective. Should we say "Assertion" or "Confirmation"? Does it matter? I think "Assertion" de-links the gateway from its network, which is OK.
> 
> Regarding the ACK-Final, as you say, it is critical for the conclusion of asset transfer. Does 3.10 serve as a sort of an ACK for the ACK-Final then? That is, should it be incumbent upon G2 to attempt retransmission of an ACK-Final until it receives a conclusive "Transfer-Completed"?
> 
> Rama
> 
> PS: Still recovering from illness and injury, so will try to participate in brainstorming to the best of my ability.
> 
> -----Original Message-----
> From: sat <[e-mail]<mailto:[e-mail]>> On Behalf Of Thomas Hardjono
> Sent: 28 February 2023 17:56
> To: [e-mail]<mailto:[e-mail]>
> Subject: [EXTERNAL] [Sat] Burn-Assertion and Mint-Assertion messages
> 
> 
> Hi folks,
> 
> Seeing that we are discussing the Lock-Assertion format, I think we also need two (2) more assertion message types related to the extinguishment (burning) of the asset in NW1 and the re-generation (minting) in NW2.
> 
> 
> Looking at our message flow diagram (version 16):
> 
> (a) In Step 3.5A the gateway G1 is "extinguishing" (i.e. "burning" or permanently disabling) the asset from NW1.
> 
> Then in Message 3.6 we said that the Commit-Final message would also carry a signed assertion stating that G1 has completed the burning of the asset in NW1.
> 
> Could we call this assertion something like:  "Burn-Assertion" ?  (using the terms "burn" and "mint" that is popular today).
> 
> 
> (b) In Step 3.7A the gateway G2 completes the minting process by way of assigning newly-created asset to the beneficiary (e.g. Bob's address on NW2).
> 
> This is then reported to G1 in a signed assertion from G2 carried within message 3.8 (the ACK-Final message).
> 
> Could we call this assertion something like:  "Mint-Assertion" ?
> 
> 
> Its probably worth highlighting that message 3.8 is an important one (far more relevant here than in the classic 2PC usage).
> 
> In the traditional usage of the 2PC/3PC commitment protocol (e.g. distributed databases), the ACK-Final message is simply an acknowledgement message that could be lost (i.e. loss can be tolerated).
> 
> In our case, the signed Mint-Assertion blob carried within message 3.8 legally binds G2 in the sense that G2-owner is now liable if it lies or makes an error.
> 
> That is, the ACK-Final message must not be lost.  If G2 never receives message 3.10, then G2 may need to retransmit message 3.8.
> 
> 
> 
> Thoughts?
> 
> 
> 
> --thomas
> 
> --
> sat mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sat 
> 
> --
> sat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sat 
> 
> --
> sat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sat 
> 
> --
> sat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sat