createMintFsTx command submits complete transaction if submitter key isn't renamed

ross-spencer commented 1 year ago

What do you see?

The tutorial describes the renaming of the submitter key. If the key isn't renamed then the following command will finalize and complete the transaction, submitting it to chain, for the authenticator wallet and submitter wallet.

RESP=$(echo $REQ | grpcurl -insecure -import-path $COOP_PROTO \
 -proto $COOP_PROTO/publisher-service.proto -d @ \
 localhost:5080 coop.publisher.Publisher/createMintFsTx)

i.e. if the submitter wallet key is prefixed with signing-key- then the publisher command can use that key to submit the transaction.

From the publisher gRPC service:

  signatures:
    10ba52b098c08ea6258a17790029cf4e8a98ef4c5e0595362b6b524986912345
    cd89eecf56484ca39c3606b1ae73ec733f791fda0e2a20bd8fb516c42eb12345
  validity range: Interval {ivFrom = LowerBound (Finite (Slot {getSlot = 28657719})) False, ivTo = UpperBound (Finite (Slot {getSlot = 28658319})) False}
  attached scripts:
    (1f7fbe0426b3b7ea946abb4c2f1ec20c3a04da1846f1494553212345, Plutus V2)
    (e56881fb51143b103b547379d58f27233549a6c6ba001f117d812345, Plutus V2)}
[BPI] [DEBUG [ PABLog ]] [10ba52b098c08ea6258a17790029cf4e8a98ef4c5e0595362b6b524986912345,cd89eecf56484ca39c3606b1ae73ec733f791fda0e2a20bd8fb516c42eb12345]
[BPI] [DEBUG [PABLog]] []
[BPI] [DEBUG [ PABLog ]] [10ba52b098c08ea6258a17790029cf4e8a98ef4c5e0595362b6b524986912345,cd89eecf56484ca39c3606b1ae73ec733f791fda0e2a20bd8fb516c42eb12345]
[BPI] [DEBUG [ PABLog ]] Write balanced tx: WriteBalancedTxSuccess: 6a8a5ccf8ac46dd09ec04b3dcc406ce3c462f735edc5e8541407506b0d912345

Follow through with submit step users may see an error that looks as follows:

[coop-env ~ coop.0] $ cardano-cli transaction submit \
 --tx-file transaction-to-submit.json  --testnet-magic 1 
Command failed: transaction submit  Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraBabbage (ApplyTxError [UtxowFailure (UtxoFailure (FromAlonzoUtxoFail (UtxosFailure (CollectErrors [BadTranslation (TranslationLogicMissingInput (TxIn (TxId {_unTxId = SafeHash "413cccb91b7ff75b5f5d29e3ede69bf1c071b5fc864c55f3b2676da1dc412345"}) (TxIx 1)))])))),UtxowFailure (UtxoFailure (FromAlonzoUtxoFail (ValueNotConservedUTxO (Value 0 (fromList [(PolicyID {policyID = ScriptHash "1f7fbe0426b3b7ea946abb4c2f1ec20c3a04da1846f1494553212345"},fromList [(44a13dd0b875e7149d1c59693b00b225207b33fe7fe7a720a5d4176663a12345,1)]),(PolicyID {policyID = ScriptHash "e56881fb51143b103b547379d58f27233549a6c6ba001f117d812345"},fromList [(6751fb74bb8bd2c6b6bc1c77ead2f92eab24b2cb591f79be937f49c348a12345,-1)])])) (Value 13651090 (fromList [(PolicyID {policyID = ScriptHash "1f7fbe0426b3b7ea946abb4c2f1ec20c3a04da1846f1494553212345"},fromList [(44a13dd0b875e7149d1c59693b00b225207b33fe7fe7a720a5d4176663a12345,1)]),(PolicyID {policyID = ScriptHash "e56881fb51143b103b547379d58f27233549a6c6ba001f117d812345"},fromList [(6751fb74bb8bd2c6b6bc1c77ead2f92eab24b2cb591f79be937f49c348a12345,98)])]))))),UtxowFailure (UtxoFailure (FromAlonzoUtxoFail (BadInputsUTxO (fromList [TxIn (TxId {_unTxId = SafeHash "413cccb91b7ff75b5f5d29e3ede69bf1c071b5fc864c55f3b2676da1dc412345"}) (TxIx 1),TxIn (TxId {_unTxId = SafeHash "413cccb91b7ff75b5f5d29e3ede69bf1c071b5fc864c55f3b2676da1dc412345"}) (TxIx 3)]))))])

The tutorial requires renaming this wallet:

https://github.com/mlabs-haskell/cardano-open-oracle-protocol/blob/60bd6bd2f3ef2bad2c1a25c55272d2fe0424316e/README.md?plain=1#L303

The SUBMITTER_PKH is the only wallet not used by the COOP Publisher that belongs to the user. In fact, we need to hide this wallet from the local-cluster to emulate a real scenario:

What do you expect?

If we follow the guide correctly we see:

Expected:

[BPI] [DEBUG [ PABLog ]] [10ba52b098c08ea6258a17790029cf4e8a98ef4c5e0595362b6b5249869512345]
[BPI] [DEBUG [ PABLog ]] [bedfff1b6762f7a95437ab8ca30b3244dfe44029125d236560612345]
[BPI] [DEBUG [ PABLog ]] [10ba52b098c08ea6258a17790029cf4e8a98ef4c5e0595362b6b52498695e879,bedfff1b6762f7a95437ab8ca30b3244dfe44029125d236560612345]
[BPI] [WARNING [ PABLog ]] Not all required signatures have signing key files. Please sign and submit the tx manually:
Unsigned tx file: .local-cluster/txs/tx-6e6dafd5a78454c5d156b24e6f8c534d186988433c4bb9c3dd753895d3a0d74f.raw
Some signatures were able to sign, partially signed tx available here:
Partially signed tx file: .local-cluster/txs/tx-413cccb91b7ff75b5f5d29e3ede69bf1c071b5fc864c55f3b2676da1dc4a5534.signed
[BPI] [DEBUG [ PABLog ]] Write balanced tx: WriteBalancedTxSuccess: 413cccb91b7ff75b5f5d29e3ede69bf1c071b5fc864c55f3b2676da1dc412345

And the transaction can be submitted manually.

What's the problem?

It isn't clear in the guide's steps what the implications are for not renaming the wallet. It is also not clear if this is functionality that should be included in the publishing service.

I suspect it is enough to document the behavior around #L303 if other's agree? - I can follow up with a PR. The documentation might also suggest that it's a valid approach to not rename the submitter signing key, and then revisit this point at step 8 submitting a fact statement manually vs. automatically.

bladyjoker commented 1 year ago

Hey @ross-spencer I think what you're seeing here is https://github.com/mlabs-haskell/cardano-open-oracle-protocol/issues/53. It's just how the tutorial wallet environment is setup. Feel free to document and further clarify this situation

ross-spencer commented 1 year ago

Hi @bladyjoker can you clarify the mechanics here some more? It's not clear to me how the wallet config here impacts the garbage collection? For example, I am not able to garbage collect POS_INF statements because this is prevented somewhere in the stack. But then I'm not sure where that's enforced.

Further clarity on my side - parsing coop-state.json I retrieve all fact statements and timestamps:

3-08-14 12:15:00 INFO :: py_publish.py:135:_process_state_json() :: fact statement ids on-chain: ['04CA000ACC65CA96', '04CA007078C406D0', '04CA00AD7FACF73C']
local datum ids on chain:
{
  "ids": [
    [
      "04CA000ACC65CA96",
      "PosInf",
      null
    ],
    [
      "04CA007078C406D0",
      "NegInf",
      null
    ],
    [
      "04CA00AD7FACF73C",
      "Finite",
      1692616138
    ]
  ],
  "total": 3
}

The publisher GRPC service happily accepts all of these (including the one set to never expire):

2023-08-14 12:15:26 INFO :: py_publish.py:135:_process_state_json() :: fact statement ids on-chain: ['04CA000ACC65CA96', '04CA007078C406D0', '04CA00AD7FACF73C']       
2023-08-14 12:15:26 INFO :: py_publish.py:327:batch_gc() :: Collecting IDs: [b'04CA000ACC65CA96', b'04CA007078C406D0', b'04CA00AD7FACF73C']                            
2023-08-14 12:15:26 INFO :: py_publish.py:362:gc_txs() :: certificate file location: /home/orcfax/git/mlabs/coop.0/.coop-publisher-cli/certificate.pem                 
2023-08-14 12:15:26 INFO :: py_publish.py:103:tls_credentials() :: certificate file location: /home/orcfax/git/mlabs/coop.0/.coop-publisher-cli/certificate.pem        
2023-08-14 12:15:26 INFO :: py_publish.py:115:submitter() :: submitting Tx as: bedfff1b6762f7a95437ab8ca30b3244dfe44029125d23656062a8b6

And returns the statements that became obsolete, and reminds us that the one set to never expire is still valid:

}
info {
  tx_builder_info {
    obsolete_fs_ids: "04CA007078C406D0"
    obsolete_fs_ids: "04CA00AD7FACF73C"
    valid_fs_ids: "04CA000ACC65CA96"
  }
}

Further from the publisher grpc:

"Got from user: {fs_ids: \"04CA000ACC65CA96\" fs_ids: \"04CA007078C406D0\" fs_ids: \"04CA00AD7FACF73C\" submitter { base16: \"bedfff1b6762f7a95437ab8ca30b3244dfe440291
25d23656062a8b6\" }}"                                                                                                                                                  
"Sending CreateGcFsTxRequest to TxBuilder: {fs_ids: \"04CA000ACC65CA96\" fs_ids: \"04CA007078C406D0\" fs_ids: \"04CA00AD7FACF73C\" submitter { base16: \"bedfff1b6762f7
a95437ab8ca30b3244dfe44029125d23656062a8b6\" }}"

If the wallet configuration was impacting this, I would anticipate the POS_INF statement to be collected as well because I would have the authority to do so. Instead something prevents that, but doesn't prevent the "Finite"/"Timestamped" fact from being collected. Note this one was scheduled for 21 August.

So, my questions are:

What part of the process prevents POS_INF from being collected?
What exactly is meant that the wallet configuration is allowing future timestamped statements from being collected?
If the wallets are configured more optimally, what is the process that you're expecting that would prevent this from happening anyway? It looks like COOPs gc_txs (CreateGcFsTxRequest) function will simply go ahead and collect NEG_INF and finite anyway?

bladyjoker commented 1 year ago

@ross-spencer this is a different issue, check the title :D Sorry about that!

ross-spencer commented 1 year ago

this is a different issue, check the title :D Sorry about that!

Ah, sorry @bladyjoker forgot about this one! Will find time to document.

ross-spencer commented 11 months ago

This has been documented in the PR associated with this issue.

mlabs-haskell / cardano-open-oracle-protocol