CIP-0167? | Remove isValid from transactions

[teodanciu]

Omit isValid flag from the standalone transaction encoding (not affecting the block serialization)

---

(rendered latest proposal version)

[rphair]

thanks again @teodanciu @lehins - tagging Triage for introduction at next meeting (https://hackmd.io/@cip-editors/120).

@lehins @WhatisRT I think we're now seeing a greater bandwidth of Ledger CIPs for atomic changes as I think was requested in some statements I attempted to summarise in Ledger participation and bandwidth.

• Assuming we stay with the usual (and originally recommended) process of CIPs for all Ledger changes, is there a standard list of people we can tag to confirm these PRs before what will usually be, if no objection, a summary process for candidacy & merge?
• @Crypto2099 @Ryun1 @perturbing we should also collect names into this list with other node Ledger implementors to be sure it's evenly distributed across all node projects.

@teodanciu I've suggested a rephrase of the CIP title to:

• use the briefest possible phrasing of the change, as appearing at the beginning of the Rationale;
• since this CIP represents a change, like Update CIPs it's more clear to express it as an action (i.e. a verb phrase: whereas proposed standards for new objects & features are generally noun phrases).

[lehins]

is there a standard list of people we can tag to confirm these PRs

I think the list of people should be decided on CIP by CIP basis, because not everyone is affected equally. For example, this CIP could use input from the Consensus team, while other ledger related CIP might need input from the Plutus team instead.
That being said, as you know always feel free to ping me for any CIP that is Ledger related. @teodanciu also expressed interest in participating in Ledger related CIPs too.

[lehins]

Love it. Hopefully community will see it as a nice simplification.

[rphair]

@lehins #1089 (comment): this CIP could use input from the Consensus team

Apologies I don't have a complete list: I'll do my best to tag Consensus authors & reviewers here; from memory plus those in this thread:

• DONOTMERGE a place to discuss my draft enrollment CIP IntersectMBO/ouroboros-consensus#1559

@bwbush @dnadales @nhenin @nfrisby @jasagredo @amesgen @fraser-iohk @geo2a @abailly

[dnadales]

@rphair, thank you for the ping. @amesgen is part of the Consensus team :) I'll ask the rest of the team if there are any other remarks besides what Alex already mentioned 👍

[WhatisRT]

The reasoning of this CIP seems sensible and it doesn't affect any specifications that we currently have, so I thumbs up from me.

[rphair]

@teodanciu @WhatisRT we had a shift in meeting focus in favour of Leios CIP review, and also due to not having a quorum of editors present we'll have to try confirming this as Candidate again at the next meeting: https://hackmd.io/@cip-editors/121

[rphair]

@teodanciu the CIP meeting today was an additional confirmation that this proposal is generally well-liked all around. I believe it should proceed quickly enough toward merge but the normal process is to confirm this as a candidate before promotion to Last Check which I think will happen quickly enough (so approving as soon as CIP number is applied; I personally wouldn't be able to find any fault with this & see no expert objection).

Please also update the directory name to CIP-0167 and update your OP's "rendered latest proposal version" link accordingly 🎉

[rphair]

As per #1089 (review).

[rphair]

@teodanciu somehow an incidental discussion got this off track (my mistake I think). I don't see any obstacle to what would be a relatively simple, universally agreed-upon change: so am marking Last Check which would be at our next CIP meeting in 4 weeks (since the next biweekly interval would be at the Cardano Summit). @Crypto2099 @Ryun1 @perturbing if there is consensus to merge this in the meantime I will handle the extra paperwork. 😎 cc @lehins

[colll78]

This must be done very carefully because it has the potential to break a lot of bridges and light client protocols. A mithril bridge proves inclusion of a transaction in a block, if the transaction body as present in the block does not include the validity flag, then there is no way for such a bridge to determine whether the transaction succeeded or if the collateral was taken.

[rphair]

@colll78 the editors will definitely ensure #1089 (comment) is addressed before merging this & take any response from @lehins @teodanciu into account about how we might define "carefully" in the CIP itself.

[lehins]

This must be done very carefully because it has the potential to break a lot of bridges and light client protocols. A mithril bridge proves inclusion of a transaction in a block, if the transaction body as present in the block does not include the validity flag, then there is no way for such a bridge to determine whether the transaction succeeded or if the collateral was taken.

isValid flag will still be present in the block. It is very important that it is retained, precisely because the block producer that includes transactions in the block sets that flag. This CIP is about removing isValid flag for transactions that are being submitted into the mempool. It is totally sound to do that because today that flag is completely ignored by the node.

[lehins]

@colll78 the editors will definitely ensure #1089 (comment)

@colll78 Does my explanation above clarifies your concern? Please let me know if it doesn't and I'll be happy to discuss it more. We have this statement in the CIP, please let me know how we can make it clearer:

This would not affect the serialization of the transactions within blocks, since isValid flag is already stored separately from the transaction

[colll78]

@colll78 the editors will definitely ensure #1089 (comment)

@colll78 Does my explanation above clarifies your concern? Please let me know if it doesn't and I'll be happy to discuss it more. We have this statement in the CIP, please let me know how we can make it clearer:

This would not affect the serialization of the transactions within blocks, since isValid flag is already stored separately from the transaction

Okay so it does not impact how bridges validate whether a transaction in a block succeeded or failed? If so then yes it addresses this concern.

[lehins]

Okay so it does not impact how bridges validate whether a transaction in a block succeeded or failed?

Yes, that is correct. This CIP only affects mempool submission, not block validation

[rphair]

@teodanciu @lehins at Last Check review at the CIP meeting today all present editors were in favour, so we're just waiting for 1 or more additional editors to sign off on it before it can be merged anytime. cc @Crypto2099 @Ryun1

[Ryun1]

approving

assuming that directory rename will be done by @rphair 🙌