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

[Thomas Hardjono <[e-mail]>]

This is what we have so far in SATP Core (Section 8.3), where the "client" is G1 and the "server" is G2:

{
   message_type REQUIRED urn:ietf:satp:msgtype:lock-assert-msg.
   session_id REQUIRED: 128-bit value identifying the current transfer-session.
   client_identity_pubkey REQUIRED.  The client who sent this message.
   server_identity_pubkey REQUIRED.  The server for whom this message is intended.
   lock_assertion_claims REQUIRED.  The lock assertion claim or statement by the client.   <--------
   lock_assertion_format OPTIONAL.  The format of the assertion.
   lock_assertion_expiration REQUIRED.  Duration of validity of assertion.
   hash_prev_message REQUIRED.  The hash of the previous message.
   client_transfer_number OPTIONAL.  This number is meaningful only to the client.
   client_signature REQUIRED.  The digital signature of the client.
}


So the "lock_assertion_claims" will carry the following info:

{
"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]] on behalf of Thomas Hardjono [[e-mail]]
Sent: Tuesday, March 21, 2023 2:03 PM
To: Venkatraman Ramakrishna; Denis Avrilionis
Cc: [e-mail]
Subject: Re: [Sat] Burn-Assertion and Mint-Assertion messages

Thanks Rama,

>>> 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).

I agree actually (i.e. including the assetId and assetProfileId in the assertions).  I think it will help with bookkeeping.


Best

--thomas


________________________________________
From: Venkatraman Ramakrishna [[e-mail]]
Sent: Tuesday, March 21, 2023 1:59 PM
To: Thomas Hardjono; Denis Avrilionis
Cc: [e-mail]
Subject: RE: [Sat] Burn-Assertion and Mint-Assertion messages

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

--
sat mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sat