CIP-0148? | Tag / Redeemer field in TxOut

[colll78]

We propose to allow the attachment of arbitrary, temporary data to transaction outputs within the script context. This data, akin to redeemers in their operational context, is intended to be used exclusively during the execution of Plutus scripts and thus are not recorded by the ledger. This will facilitate a wide variety of smart contract design patterns, one of which can be used as a general solution for double satisfaction without sacrificing script composability.

---

(proposal rendered from branch)

[rphair]

@colll78 we're not adding this for discussion in today's CIP meeting, where new proposals are normally introduced in Triage, because of the Draft status (as also with #749). Please feel free to leave it in this state as long as you need... then we will proceed to meeting discussion as well as more rigorous community review (though leaving it here for public comment now is also welcome).

[colll78]

@colll78 we're not adding this for discussion in today's CIP meeting, where new proposals are normally introduced in Triage, because of the Draft status (as also with #749). Please feel free to leave it in this state as long as you need... then we will proceed to meeting discussion as well as more rigorous community review (though leaving it here for public comment now is also welcome).

Whoops, I didn't mean to set this as a draft.

[rphair]

@colll78 Due to last minute status change this has been added to Triage (not time for full technical review; just an introduction) at today's meeting: https://hackmd.io/@cip-editors/80

[Ryun1]

Input from the IOG Plutus and Ledger teams would be appreciated here 🙏
@michaelpj @lehins

[michele-nuzzi]

Including this information in the witness set might be an attack vector.

The user signs the transaction body, not the witness set.

That means that once transaction is signed the witness set might still change, and the signature would be correct.

That implies the user agreed to sign something that is later modified.

This is not a problem for redeemers because usually the information present on redeemers is validated in the contract, so if an attacker modifies it, a carefully designed contract will fail.

In the example use case of the "TxOutRef in output datum" that information is indeed in the datum, which is part of the tx body, which is signed and hence immutable once signed (or else the signature is invalid).

if we move this info outside the body the TxOutRef can be modified after signing, leaving the contract vulnerable to double satisfaction.

[michele-nuzzi]

also modifying the redeemer indirectly causes the body to be invalid, because redeemers and datums in the witness set are used to calculate the scriptDataHash

modifying these will result in a different scriptDataHash, hence the body is invalid

[lehins]

The user signs the transaction body, not the witness set.

The user does sign some parts of the witness set (redeemers and datums) indirectly through the script hash integrity check.

[michele-nuzzi]

Yes that is correct I corrected myself in the coment

[colll78]

Right the idea would be for the user to sign this information the exact same way they sign redeemers and datums (ie adjust script hash integrity check accordingly). I will update this CIP to reflect that.

[HeptaSean]

Maybe also move the redeemer in the body in the process?

[colll78]

I agree that it would be best if redeemers were directly in the transaction body and I would fully support a separate CIP to that end, however, given that currently they are signed via scriptDataHash I don't want to introduce inconsistency by moving these into the body in which case tooling would have to accommodate them differently than they do normal redeemers. The idea is to keep them as close from an implementation perspective to transaction redeemers to lower the implementation burden.

[michele-nuzzi]

@colll78 trust me, scriptDataHash is much worse than a small inconsistency

[colll78]

Should we not then create a CIP to move redeemers into the tx body?

[lehins]

Maybe also move the redeemer in the body in the process?

Should we not then create a CIP to move redeemers into the tx body?

I've discussed this very same idea on multiple occasions.
I am not sure if we need a CIP about it, since it shouldn't be that complicated to implement and I suspect everyone would be in favor. But, it might be a good idea to create a CIP for visibility. So, if you still think we need a CIP for it, then I can create one or maybe someone from the community would be willing to step in.

[michaelpj]

I don't like it: it adds a kind of weird dangling feature that is useful in this one specific case, and otherwise doesn't mean anything. But I acknowledge that it's a reification of the pattern people currently use.

What I would like is some more principled solution to the double satisfaction problem, which we don't have.

So I guess it's a -0 from me: I would prefer not to do this but if there's lots of support and no alternative I wouldn't block something like this.

[michaelpj]

This made me wonder why you can't in fact use redeemers.

If a particular script execution needs to know which transaction output is "it's" output for some purpose, then you can put the index of that output into the redeemer.

The answer (I think) is that for double-satisfaction you need exclusivity: with the redeemer solution each redeemer has its own mapping and nothing ensures they don't overlap. With output tags you have (I assume) a single tag.

That does sit a little awkwardly, however. Why shouldn't you have multiple tags? What if you do want to use a single output for two purposes in a legitimate way? e.g. "this is the payout address for the Ada" and "the permission token goes here".

[colll78]

The type of output_tag is data, so you can have any arbitrary information you want in the output so you can store whatever you want there.

What if you do want to use a single output for two purposes in a legitimate way? e.g. "this is the payout address for the Ada" and "the permission token goes here".

That is two outputs though right? IE 1 output is "payout for ada" and 1 is "permission token output", in which case you tag each output accordingly.

The issue is that matching the redeemers to the outputs is very expensive and they aren't really designed to facilitate this time data association with outputs so the interface would be awkward.

[lehins]

Could you please elaborate on why using redeemers for this purpose would be awkward?
We can always work on improving the interface, but I want to know why conceptually redeemers can't be used for this purpose?

[michaelpj]

I think I would prefer this approach, and for us to just solve the lookup time problem properly.

[lehins]

Solving lookup problem would be a good thing to do. It has been a year since that comment was made, anyone knows if there any progress in that direction?
CC @zliu41

[zliu41]

Yes - builtin arrays with constant time lookup is coming at the next HF.

[colll78]

AFAIK, these BuiltinArrays will not be added directly to the script context right? The script context fields will still be BuiltinList and you will have to use a builtin to convert them to BuiltinArray or has this changed?

[lehins]

We could look into switching to arrays for some parts of the context that today uses lists. Naturally, we can evaluate this when we get to defining PlutusV4 in Ledger, which is not going to happen for quite some time.

[michaelpj]

I'm not sure the bloat complain quite lands:

1. Anything included in transactions goes in the history of the chain forever, so that would apply to tags as well
2. But: information in datums does bloat the UTXO set, which can be a problem

That is, I would say it's not so much the permanency that's a problem (that happens anyway), so much as the (temporary, but ongoing) UTXO set bloat.

[colll78]

Yes, I did not make it clear I was referring to the UTxO set size which is often what is most impactful on the efficiency of indexers for dApps.

[gitmachtl]

just wanna ask if this affects in any way also hardware wallets? because of the memory constrains, hardwarewallets cannot look at whole utxo sets while performing the signing action.

[rphair]

@colll78 this is lagging in progress a bit and there was a question in the CIP meeting today over some resolutions that weren't recorded. A couple editors including @Ryun1 & @Crypto2099 (I was just taking some notes) + @michaelpj and @fallen-icarus as I remember made the following points:

• This is relevant to a "composability" problem of transaction outputs from one dApp to be applied as inputs to a potentially different dApp.
• Within the CIP process there hasn't yet been any other way of dealing with this composability problem other than the one suggested here.
• However, people are able to deal with composability issues in other ways that don't require the proposed changes... and therefore this solution might only be applicable to the author's own / preferred implementations.

Assuming the above reservations are valid, both @Ryun1 and I (and maybe others) thought this might then be better off as a CPS dealing with composability (and peripherally the "double satisfaction problem"), and suggesting this tagging approach as one means of dealing with it.

[colll78]

@colll78 this is lagging in progress a bit and there was a question in the CIP meeting today over some resolutions that weren't recorded. A couple editors including @Ryun1 & @Crypto2099 (I was just taking some notes) + @michaelpj and @fallen-icarus as I remember made the following points:

• This is relevant to a "composability" problem of transaction outputs from one dApp to be applied as inputs to a potentially different dApp.
• Within the CIP process there hasn't yet been any other way of dealing with this composability problem other than the one suggested here.
• However, people are able to deal with composability issues in other ways that don't require the proposed changes... and therefore this solution might only be applicable to the author's own / preferred implementations.

Assuming the above reservations are valid, both @Ryun1 and I (and maybe others) thought this might then be better off as a CPS dealing with composability (and peripherally the "double satisfaction problem"), and suggesting this tagging approach as one means of dealing with it.

I would like to clarify that this CIP is not designed specifically as a solution to the double satisfaction problem / dApp composability problem. This is a general improvement to the smart contract platform on Cardano that enables a huge range of use-cases that are currently in-feasible. The core value add is the ability to associate arbitrary data with outputs without permanently writing that data to the UTxO set. Sure, it can be used to solve double satisfaction without sacrificing dApp composability (a property that is currently unique to this solution to DS); however, more generally it can be used to do things like tag specific outputs with the USD price of the multi-asset value they contain via a signed oracle message which is associated to the output via this output_tag field. It also could be used to index the location of relevant tokens within the output value map to make onchain token lookups ~O(1); currently searching values is a very expensive and common operation, for instance if you need to find the total number of pool_asset_a in a DEX pool utxo, or if you need to check for the presence of a some state_thread_token (pretty much every dApp on Cardano). This is possible because the location of all tokens in the value of all outputs is known during transaction construction (nice property of deterministic transactions on Cardano), so you don't need to ever perform search on-chain (i.e. valueOf) instead we can just index the location of these tokens via this output_tag field. So, when a contract comes across a TxOut with an output_tag = 6 (idx of state token) it could simply verify that the head of the 6th entry of the value map contains the state token (or provide 2 indices if it isn't the first token with that currency symbol in the value).

It also enables things such as dependent transaction chaining which is a pre-requisite for babel fees. To achieve this, you could use this field to store a TxIn of an input that must be included as a resolving input (see validation zones) for this transaction to be considered valid by the CHAIN level rules for this tx to be included in the block. Since this would be available in the witness set, it would be available during chain level validation without bloating the UTxO set (probably not an exact fit because the update rules and structure needs to be specific for chain level validation).

Likewise this CIP is of critical importance to intent-based operations / smart contract account abstraction. Both of these involve expressing intent offchain which reduces the number of transactions required to execute a user action. For instance, right now when a user wants to interact with a DEX / orderbook they first must create their order (which conveys their intent i.e. to swap X asset A to Y asset B in DEX pool P, or to sell asset A for asset B at exchange rate of E on an orderbook) in a preliminary transaction, and then a second transaction is required to actually fulfil their request (i.e. batch process orders against the pool on an AMM DEX or match orders on an orderbook DEX), furthermore if you want to update your intent (ie. you want to swap your asset A for asset C instead of asset B or you want to increase slippage or update your sell price or even change the asset you are selling) all of these things will require an additional transaction (perhaps multiple). With this CIP, you can provide your intent as a signed message which in turns allows all aforementioned user operations to be fulfilled in a single transaction. The user doesn't need to submit and pay for a transaction to create a swap request / limit order, the instead they can just publicize a signed message that describes their intent (i.e. swap order with XYZ constraints) which can be consumed by dApps directly to allow them to spend funds from the account as long as they do so exactly as intended by the user (as described by the user's signed message). The user can then update their intent without performing a transaction by producing a new signed message that can then (with this CIP) be associated with the relevant input / outputs.

[rphair]

My reading of @colll78's #735 (comment) is that this proposal is still interesting to the community. However, I still have no idea how this would be validated as a candidate.

Since all the prior response was from the Plutus team I'm tagging this as Plutus category even though it looks like it could be applicable to the Ledger. @zliu41 (@lehins WhatisRT) could you confirm (or change) that category and indicate that this proposal might be admissible?

In the meantime marking this as Unconfirmed since it's been triaged already but not validated as a CIP candidate. @michele-nuzzi @MicroProofs if you see any advantage to bringing it into the CIP meeting for discussion again please make a comment here & we'll put it on the schedule.

[colll78]

Can we have a re-review on this please? Intent systems are an extremely hot topic right now, and this CIP would provide huge value for all such applications.

[lehins]

@colll78 Thank you for your response. Your comment definitely made it clearer for me why spending datums are not a suitable solution to the problem. It is still unclear to me why redeemers can't be used to solve this problem.

It might be a very naive question, but please bare with me. As a thought experiment, in order for me to understand the problem better, here is how I could envision redeemer being used for attacking this problem. Note, I am not trying to argue that this is a better approach to what is being suggested in the CIP. I just want to see if my understanding is sound through checking with you whether such a solution could work at all.

Imagine this transaction with UTxO, where 1 Foo == 10 ADA and 1 Bar == 50ADA

utxo = UTxO
  [ (in0, fooScript: 10 Foo)
  , (in1, fooScript: 5 Foo)
  , (in2, barScript: 20 Bar)
  , (in3, 50 ADA)
  , (in4, 100 ADA)
  , (in5, 1000 ADA)
  ...
  ]
Tx
  { body = TxBody
    { inputs = [in0, in1, in2, in3, in4, in5]
    , outputs = [out0: 50 ADA, out1: 100 ADA, out2: 1000 ADA, out3: 15 Foo, out4: 20 Bar]
    }
  , wits = TxWits 
    { redeemers =
       [ (Redeemer (Spending 0), (Data [arg0, "Foo", in4, out1], exUnits0)
       , (Redeemer (Spending 1), (Data [arg1, "Foo", in3, out0], exUnits1)
       , (Redeemer (Spending 2), (Data [arg2, "Bar", in5, out2], exUnits2)
       ]
    }
  }

So, in such a transaction both fooScript and barScript will see all of the redeemers. My question is that why can't those scripts inspect the data passed in those redeemers in order to ensure that they verify double satisfaction? Is it because DApp writers would have to agree on predefined format for the redeemer data? Or is this approach has some sort of vulnerability that can be exploited to bypass double satisfaction verification? Or is it an issue of efficiency?

I can see how this Tag solution is a more "type safe" and more efficient approach to dealing with problem, when comparing to the one that uses redeemers. But, it doesn't really feel to me versatile enough. For example:

• ADA could be coming from many different places (certificate refunds, reward account withdrawals)
• Ada could be going to many different places (paying deposits, fees, donating to treasury, etc.)
• NFTs can be minted
• inputs and outputs are unlikely to contain exact amounts to satisfy those kind of trades precisely, so it is unlikely that there will be a perfect match between ADA and NFT swaps like that. So even with Tags you'd have to have some sort of agreed upon format for the data that is being placed in those Tags.

It feels to me like this problem is a more fundamental one that could use a more versatile and standardized solution. I am not going to pretend like I have a better solution at this moment, but I have never thought about this problem until now.

[lehins]

An idea just popped into my mind. I haven't thought it through very well yet, but, I think it sounds sensible. What if we add a concept of a "Claim". Every script would have a capability to claim parts of the transaction and no two scripts could claim the same part of the transaction. Here is a sample data type:

data Claim = 
  = ClaimInput TxIn Value
  -- ^ Specifies which input to claim and which portion of it will be claimed by the script
  | ClaimWithdrawal RewardAccount Coin
  -- ^ Claim ADA that is coming out of a withdrawal
  | ClaimRefund CertIx Coin
  -- ^ Claim ADA that was refunded in one of the unregistration certificates (either DRep or Staking Credential)
  | ClaimMint Value
  -- ^ Claim a positive value that was minted in this transaction

Then we'd add this claim to a redeemer:

data Redeemer = Redeemers
  { unRedeemers :: Map (PlutusPurpose AsIx era) (Data era, ExUnits, [Claim])}

This would allow for a whole lot more flexibility:

• Multiple scripts would be able to claim parts of the same input.
• Scripts could claim parts of the transaction that would be otherwise inaccessible. Eg. you'd be able to buy NFTs with rewards.
• You could mint multi-assets and other scripts could claim those mints.
• You could burn your multi-assets that you've claimed in the same transaction.

Ledger rules would then verify that there are no overlaps between any two claims:

1. No two scripts try to claim same parts of the resource in the transaction.
2. Total claims do not exceed resources that are available in the transaction.

Two things that I like about this solution is that it would be standardized and there would be no extra logic required from the DApp writers (thus practically free from the perspective of execution units). It would be up to transaction builder to specify which part of the transaction maps to which validator. Naturally, those claims would be available to the script, so if desired those scripts would be able to confirm that enough resources were claimed to satisfy the validator, but at least they wouldn't need to worry about any other script claiming the same resources.

I also believe that those claims could be specified for all plutus versions, with one limitation that only PlutusV4 would be able to see those claims in their context.

FYI, current CIP is quite a bit easier to implement from the Ledger perspective, so in a sense I am piling up more work on our shoulders, but I believe that it would be totally worth it. What I am suggesting above would be a much safer solution IMHO, since there would be no ambiguities on how this feature suppose to be used, which is not the case with Tags.

This approach as I described does not provide a mechanism to check where the money is going (i.e. ADA went to Alice that spend her NFTs), but I don't think it should even matter. In other words checking that no resource is used for two different purposes, sounds to me like a well defined solution to the double satisfaction problem.

@colll78 Thoughts?

CC @WhatisRT What's your opinion on this suggestion.

If this solution sounds sensible to you guys I could write up a more detailed CIP.

[colll78]

this Tag solution is a more "type safe" and more efficient approach to dealing with problem, when comparing to the one that uses redeemers. But, it doesn't really feel to me versatile enough. For example:

• ADA could be coming from many different places (certificate refunds, reward account withdrawals)
• Ada could be going to many different places (paying deposits, fees, donating to treasury, etc.)
• NFTs can be minted

@colll78 Thank you for your response. Your comment definitely made it clearer for me why spending datums are not a suitable solution to the problem. It is still unclear to me why redeemers can't be used to solve this problem.

It might be a very naive question, but please bare with me. As a thought experiment, in order for me to understand the problem better, here is how I could envision redeemer being used for attacking this problem. Note, I am not trying to argue that this is a better approach to what is being suggested in the CIP. I just want to see if my understanding is sound through checking with you whether such a solution could work at all.

Imagine this transaction with UTxO, where 1 Foo == 10 ADA and 1 Bar == 50ADA

utxo = UTxO
  [ (in0, fooScript: 10 Foo)
  , (in1, fooScript: 5 Foo)
  , (in2, barScript: 20 Bar)
  , (in3, 50 ADA)
  , (in4, 100 ADA)
  , (in5, 1000 ADA)
  ...
  ]
Tx
  { body = TxBody
    { inputs = [in0, in1, in2, in3, in4, in5]
    , outputs = [out0: 50 ADA, out1: 100 ADA, out2: 1000 ADA, out3: 15 Foo, out4: 20 Bar]
    }
  , wits = TxWits 
    { redeemers =
       [ (Redeemer (Spending 0), (Data [arg0, "Foo", in4, out1], exUnits0)
       , (Redeemer (Spending 1), (Data [arg1, "Foo", in3, out0], exUnits1)
       , (Redeemer (Spending 2), (Data [arg2, "Bar", in5, out2], exUnits2)
       ]
    }
  }

So, in such a transaction both fooScript and barScript will see all of the redeemers. My question is that why can't those scripts inspect the data passed in those redeemers in order to ensure that they verify double satisfaction? Is it because DApp writers would have to agree on predefined format for the redeemer data? Or is this approach has some sort of vulnerability that can be exploited to bypass double satisfaction verification? Or is it an issue of efficiency?

The redeemer exists to provide information relevant to the execution of a specific script, as such it, it contains a format that is only comprehensible to the script itself. In the above example, fooScript can barScript can indeed view the redeemers list, but for fooScript to understand the redeemer of barScript it will need specific knowledge about the construction of that script, if the redeemer of a script is BuiltinData encoded in constructor format (ie. Constr Index [BuiltinData]) then the fooScript will need to know what field the fields in barScript mean to meaningfully interact with them (say it just searches for a TxOutRef, how can it know that the purpose of that TxOutRef is to uniquely identify the inputs? What if there are multiple input sources? What if a script uses BuiltinData encoded as BuiltinList [BuiltinData] instead of the constructor format?

Even in an ideal world, where we get every single script author to follow a standard that enforces the redeemer is encoded in constructor format, and that the first field in the constructor of any spending redeemer should be a BuiltinList [BuiltinData] that identifies all the outputs that satisfy the spending conditions for that input, this solution is simply impractical. Imagine we have 40 inputs, from 40 different scripts, for fooScript to know that some arbitrary TxOutRef, txOutA, is used exclusively to satisfy the spending conditions for inputA, it will need to traverse every spending redeemer in the transaction (40) and check that txOutA is not identified as the satisfying output for the redeemer of any other script execution. Then all 39 other scripts in the transaction need to do the same, now we have traversed and decoded a list of 40 redeemers in 40 different script executions in the transaction, this would be impossible. With tagging, you don't need to traverse anything, the information you need is directly in the outputs, so the execution of 40 scripts is feasible without blowing up budget.

Again, I would like to explicitly clarify that the purpose of tags is not exclusively as a solution to double-satisfaction, this is just a single example in which the ability to provide information relevant to TxOuts directly is powerful. The alternative that you are proposing cannot address the other use-cases I mentioned (intent-based operations, account-abstraction, etc).

[rphair]

@colll78 as per Tuesday's CIP meeting this was acknowledged as ready for merge as soon as the formalities like CIP number & directory renaming (to CIP-0148) are in place. 🎉

@lehins our understanding of your latest comments is that these are an exploration of this issue with an eye for best practice that @colll78 and colleagues have worked out through engineering trial & error over 3 years or so. So we're assuming that you have no real objections to this unless stated explicitly.

I'm tagging Last Check which puts it on the next meeting agenda (https://hackmd.io/@cip-editors/108) as a failsafe, but @Crypto2099 @Ryun1 as you recall from the meeting (cc @perturbing) this was declared ready to merge before then if there's full editor support & no last-minute objections.

[lehins]

@colll78, sorry I got distracted by other things and forgot to respond. Thank you for your explanation, it does make it clear to me why existing solutions are unsuitable. I figured that the problem with redeemers would be the fact that data supplied is weekly typed and it would be very hard to have all script writers to agree on a common format. With that in mind, can you please explain to me how is this also not a problem for Tags proposed in this CIP. Tags are expected to be a weekly typed Data as well as redeemers are:

if the redeemer of a script is BuiltinData encoded in constructor format (ie. Constr Index [BuiltinData]) then the fooScript will need to know what field the fields in barScript mean to meaningfully interact with them

What if other scripts try to use tags for something else which would conflict with the solution for double satisfaction that your script is relying on? In other words, from my understanding of this CIP, it also suffers from the exact same problem as redeemers do.

@rphair I understand that @colll78 and other have a lot of experience with this problem and with DApp writing in general, but I am still not yet convinced that this is the best approach possible.

Last thing I want is to implement a feature that we have to support forever, which we end up replacing with something different in a feature era, because this approach turned out to be suboptimal.

What I would like to see is the list of all problems that this approach solves. Cause I was under impression from reading this CIP that the sole reason why it is needed was to solve double satisfaction problem, which turns out is not the case: "The alternative that you are proposing cannot address the other use-cases I mentioned (intent-based operations, account-abstraction, etc)." @colll78 Please forgive me, but I can't find any mention of "account-abstraction" in this CIP.

For example, unless we are talking about something else, intents as I know them, will be solved by a CIP that is already planned to be implemented CIP-118, so this CIP no longer needs to solve it and I am not even sure how it would solve it, to be honest with you.

"account-abstraction" - what is this and how this Tag approach solves it and why is it a problem that we need to solve to begin with?

@rphair In other words, I do object this CIP as it stands right now, because in my opinion it does not have enough information on how it solves the problems it claims to be solving. It does not compare to any other approach that we can take that would solve those problems in alternative ways. For example, what the alternative approach that I suggested that would solve double satisfaction problem has not been considered so far or properly compared to. Are there other solutions that are known to solve the same problem(s).
If this CIP is not clear to me, as a ledger expert, I am sure it will be unclear to many others. So at the very least I would expect some better explanations of the problems and the solution with some examples. In particular:

• how solving double satisfaction plays together with other purposes Tags will be used for?
• how this feature works for solving double satisfaction when partial matches of many TxOuts to many TxIns are desired?
• why we only want to solve these problems for TxOuts and not other sources of value: withdrawals, deposits/refunds, minting?

Keep in mind, that I am not trying to push back on the feature, I am asking for this CIP to be improved, with proper comparison to alternative approaches that we can take (i.e. not the ones that are already available today).

[lehins]

"recorded by the ledger" is an incorrect statement. Every bit from every transaction is recorded by the ledger in the blockchain. Instead, it should state: "not recorded in the ledger state".

[lehins]

This will facilitate a wide variety of smart contract design patterns

This statement is way too ambiguous. It is unclear what those use cases are. If they are unknown, then we should be stating it clearly. If they are known then then they must be listed here. Most importantly I would like ta have clarity how this Tag will be used for those multiple problems in the same transaction at the same time.

[lehins]

Maybe also move the redeemer in the body in the process?

Should we not then create a CIP to move redeemers into the tx body?

I've discussed this very same idea on multiple occasions.
I am not sure if we need a CIP about it, since it shouldn't be that complicated to implement and I suspect everyone would be in favor. But, it might be a good idea to create a CIP for visibility. So, if you still think we need a CIP for it, then I can create one or maybe someone from the community would be willing to step in.

[lehins]

Solving lookup problem would be a good thing to do. It has been a year since that comment was made, anyone knows if there any progress in that direction?
CC @zliu41

[rphair]

thanks @lehins for clarifying the position we had assumed in #735 (review). We will consider your latest round of review a checklist for things that need to be agreed upon before moving forward. - cc @WhatisRT (and @polinavino if you want to jump into the discussion about how this might affect the development of "intents" & #862)

@colll78 I'll dial this back from Last Check but editors will keep an eye on the discussion of these review points to see when your two positions start coming together... if & when that happens we will put this on the track to merging it again. If either of you think a CIP meeting discussion would help, just say so and the time will be yours on the next meeting's agenda. - cc @Ryun1 @Crypto2099 @perturbing

[colll78]

Updated readme with respect to the discussion I had in the ledger working group.

[rphair]

thanks @colll78 for the comprehensive update & the notification about the working group.

@lehins I think the editors (I can't be at the next meeting https://hackmd.io/@cip-editors/109) would prefer to merge this if possible... so based on your agreement at the working group, can you please note whether the points in your last #735 (review) were resolved?

Without a point-by-point confirmation it would be hard for us to be sure that this is ready to merge. Alternatively I think you could submit another review — noting that it supersedes the previous one — and present either a full endorsement or any remaining issues & whether you think these need to be resolved before accepting this as Proposed.

@Ryun1 @Crypto2099 @perturbing to ensure this is on the agenda in the appropriate light I'm re-tagging this Last Check even though all review points might not be resolved at this time.

[Ryun1]

Reviewed within CIP Editors Call # 109
Although tagged Last Check, there is still quite a few open questions/discussion points
So leaving as Last Check

[rphair]

@colll78 2 notes from the CIP meeting today:

1 - You still have to rename the containing directory to CIP-0148.

2 - As we said already in #735 (comment) somebody will need to do either of these things before editors can progress this any further (since nobody would know after a commit like 04ccb1f whether any individual review point was resolved or not):

• declare in a sincere comment, either from author or Ledger side, that all prior issues are resolved & we're starting with a new review slate;
• go up to all the points above & "resolve" the ones that have been resolved & leave the unresolved ones open.

[rphair]

@colll78 I'm marking this Waiting for Author until the review feedback can be addressed as per #735 (comment).

Also, very important since this detail will be difficult to catch later & would mess up the front page of the repository if merged this way... the directory needs to be renamed again (from CIP-148 to CIP-0148). 🙏

[zliu41]

Looks reasonable, but perhaps it's also useful to attach tags to transaction inputs? See comment below.

[zliu41]

This covers double satisfaction in the sense of multiple inputs being satisfied by one output. There is a dual problem - multiple outputs being satisfied by one input. To handle this, perhaps we should allow tags in transaction inputs, which can be checked by the guard scripts proposed in #1063?