From fa3382c8c07aa772b44cba881990a778a7afef8b Mon Sep 17 00:00:00 2001
From: Micah Kendall <micahk.accounts@icloud.com>
Date: Sat, 27 Jan 2024 21:53:25 +1100
Subject: [PATCH 1/3] init

---
 cip-augment-spend-purpose/README.md | 57 +++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 cip-augment-spend-purpose/README.md

diff --git a/cip-augment-spend-purpose/README.md b/cip-augment-spend-purpose/README.md
new file mode 100644
index 000000000..63a701e20
--- /dev/null
+++ b/cip-augment-spend-purpose/README.md
@@ -0,0 +1,57 @@
+---
+CIP: ?
+Title: ?
+Category: ?
+Status: Proposed
+Authors:
+    - Micah Kendall <micah@mcomp.tech>
+Implementors: []
+Discussions:
+    - https://github.com/cardano-foundation/CIPs/pull/?
+Created: YYYY-MM-DD
+License: CC-BY-4.0
+---
+
+<!-- Existing categories:
+
+- Meta     | For meta-CIPs which typically serves another category or group of categories.
+- Wallets  | For standardisation across wallets (hardware, full-node or light).
+- Tokens   | About tokens (fungible or non-fungible) and minting policies in general.
+- Metadata | For proposals around metadata (on-chain or off-chain).
+- Tools    | A broad category for ecosystem tools not falling into any other category.
+- Plutus   | Changes or additions to Plutus
+- Ledger   | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)
+- Catalyst | For proposals affecting Project Catalyst / the Jörmungandr project
+
+-->
+
+## Abstract
+<!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->
+
+## Motivation: why is this CIP necessary?
+<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->
+
+## Specification
+<!-- The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely on the basis of the design in the CIP. This is necessary to facilitate multiple, interoperable implementations. This must include how the CIP should be versioned, if not covered under an optional Versioning main heading. If a proposal defines structure of on-chain data it must include a CDDL schema in its specification.-->
+
+## Rationale: how does this CIP achieve its goals?
+<!-- The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.
+
+It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS, and answer any questions that the CPS poses for potential solutions.
+-->
+
+## Path to Active
+
+### Acceptance Criteria
+<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' -->
+
+### Implementation Plan
+<!-- A plan to meet those criteria or `N/A` if an implementation plan is not applicable. -->
+
+<!-- OPTIONAL SECTIONS: see CIP-0001 > Document > Structure table -->
+
+## Copyright
+<!-- The CIP must be explicitly licensed under acceptable copyright terms.  Uncomment the one you wish to use (delete the other one) and ensure it matches the License field in the header:
+
+<!-- This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). -->
+<!-- This CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->
\ No newline at end of file

From cf427f6071dee3cdde46050a1b282f1ef1ec1f33 Mon Sep 17 00:00:00 2001
From: Micah Kendall <micahk.accounts@icloud.com>
Date: Sat, 27 Jan 2024 22:04:56 +1100
Subject: [PATCH 2/3] finished outline

---
 cip-augment-spend-purpose/README.md | 40 ++++++++---------------------
 1 file changed, 11 insertions(+), 29 deletions(-)

diff --git a/cip-augment-spend-purpose/README.md b/cip-augment-spend-purpose/README.md
index 63a701e20..1bb71e97b 100644
--- a/cip-augment-spend-purpose/README.md
+++ b/cip-augment-spend-purpose/README.md
@@ -1,7 +1,7 @@
 ---
-CIP: ?
-Title: ?
-Category: ?
+CIP: ????
+Title: Augment Spend Purpose
+Category: Plutus
 Status: Proposed
 Authors:
     - Micah Kendall <micah@mcomp.tech>
@@ -12,46 +12,28 @@ Created: YYYY-MM-DD
 License: CC-BY-4.0
 ---
 
-<!-- Existing categories:
-
-- Meta     | For meta-CIPs which typically serves another category or group of categories.
-- Wallets  | For standardisation across wallets (hardware, full-node or light).
-- Tokens   | About tokens (fungible or non-fungible) and minting policies in general.
-- Metadata | For proposals around metadata (on-chain or off-chain).
-- Tools    | A broad category for ecosystem tools not falling into any other category.
-- Plutus   | Changes or additions to Plutus
-- Ledger   | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)
-- Catalyst | For proposals affecting Project Catalyst / the Jörmungandr project
-
--->
-
 ## Abstract
 <!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->
 
+We should change the purpose Spend(OutputReference) to instead be Spend(OutputReference, ScriptHash), where ScriptHash is a bytearray / bytestring of the script hash.
+
 ## Motivation: why is this CIP necessary?
-<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->
+This makes common patterns in contract development much cheaper, but also more ergonomic.
 
 ## Specification
-<!-- The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely on the basis of the design in the CIP. This is necessary to facilitate multiple, interoperable implementations. This must include how the CIP should be versioned, if not covered under an optional Versioning main heading. If a proposal defines structure of on-chain data it must include a CDDL schema in its specification.-->
+There should be a 2nd value in the Spend constructor for the script purpose, which is the script hash of the spending script.
 
 ## Rationale: how does this CIP achieve its goals?
-<!-- The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.
-
-It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a CPS, the 'Rationale' section should explain how it addresses the CPS, and answer any questions that the CPS poses for potential solutions.
--->
+We would have the script hash available as a constant-time lookup, instead of linear-time.
 
 ## Path to Active
 
 ### Acceptance Criteria
-<!-- Describes what are the acceptance criteria whereby a proposal becomes 'Active' -->
+The plutus ledger team add the script hash as a second value inside the spend constructor.
 
 ### Implementation Plan
-<!-- A plan to meet those criteria or `N/A` if an implementation plan is not applicable. -->
-
-<!-- OPTIONAL SECTIONS: see CIP-0001 > Document > Structure table -->
+N/A as it is a very simple change
 
 ## Copyright
-<!-- The CIP must be explicitly licensed under acceptable copyright terms.  Uncomment the one you wish to use (delete the other one) and ensure it matches the License field in the header:
 
-<!-- This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). -->
-<!-- This CIP is licensed under [Apache-2.0](http://www.apache.org/licenses/LICENSE-2.0). -->
\ No newline at end of file
+This CIP is free and unencumbered, released by it's author into the public domain.
\ No newline at end of file

From 1340b204d5461535801a730bdd50ade8b19e7059 Mon Sep 17 00:00:00 2001
From: Micah Kendall <micahk.accounts@icloud.com>
Date: Sat, 27 Jan 2024 22:05:15 +1100
Subject: [PATCH 3/3] more fields filled

---
 cip-augment-spend-purpose/README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cip-augment-spend-purpose/README.md b/cip-augment-spend-purpose/README.md
index 1bb71e97b..b7bced425 100644
--- a/cip-augment-spend-purpose/README.md
+++ b/cip-augment-spend-purpose/README.md
@@ -7,8 +7,8 @@ Authors:
     - Micah Kendall <micah@mcomp.tech>
 Implementors: []
 Discussions:
-    - https://github.com/cardano-foundation/CIPs/pull/?
-Created: YYYY-MM-DD
+    - https://github.com/cardano-foundation/CIPs/pull/754
+Created: 2024-01-27
 License: CC-BY-4.0
 ---