lint

content/posts/cip-118.md

@@ -6,14 +6,13 @@ date: 2025-07-21
 ## Abstract
 
 CIP 118 fails to demonstrate sufficient need for the ledger changes it proposes.
-The use cases CIP 118 cites can already be supported. 
+The use cases CIP 118 cites can already be supported. No evidence is provided
-No evidence is provided that the specific contexts which cannot be supported are critical,
+that the specific contexts which cannot be supported are critical, nor is there
-nor is there an attempt to quantify the claimed performance improvements.
+an attempt to quantify the claimed performance improvements. Accepting CIP 118
-Accepting CIP 118 will not only add to ledger complexity, 
+will not only add to ledger complexity, it is an open invitation for a series of
-it is an open invitation for a series of subsequent ledger changes, 
+subsequent ledger changes, both tweaks and fixes of missteps, and as more of the
-both tweaks and fixes of missteps, and as more of the inexhaustible list of intents 
+inexhaustible list of intents gets shoe horned in. Efforts and energies would be
-gets shoe horned in. 
+much better spent making accessible and utilizing what we already have.
-Efforts and energies would be much better spent making accessible and utilizing what we already have.
 
 ## Context
 
@@ -190,21 +189,18 @@ it would otherwise cost, particularly with CIP 32.
 
 CIP 32 purports to address an inconvenience caused by the former design's
 support only of datum hashes at tip. Quote: "This is also inconvenient for the
-spending party, who must watch the whole chain to spot it". 
+spending party, who must watch the whole chain to spot it". I find this argument
-I find this argument incredibly weak. To create a transaction, a user already
+incredibly weak. To create a transaction, a user already needs access to the
-needs access to the chain via functions `getUtxosAtTip` and `submitTx`. Having
+chain via functions `getUtxosAtTip` and `submitTx`. Having another
-another `getDatumByHash` is not a big deal - it is just a tooling issue. 
+`getDatumByHash` is not a big deal - it is just a tooling issue. A more
-A more compelling case is that it reduces the size of transactions. 
+compelling case is that it reduces the size of transactions. Prior to the change
-Prior to the change and in normal application an output datum hash 
+and in normal application an output datum hash would need to be validated, and
-would need to be validated, 
+so the datum would be present in the witness set, adding to the transaction
-and so the datum would be present in the witness set, adding to the 
+size. The consuming transaction would then need to include the same data. There
-transaction size. 
+are some contexts where this can be improved upon, but CIP 32 essentially halves
-The consuming transaction would then need to include the same data.
+this problem by paying for the data just once. The impact of CIP 32 is
-There are some contexts where this can be improved upon, 
+compounded when used with CIP 31. With both CIP 31 and 32, any referencing
-but CIP 32 essentially halves this problem by paying for the data just once.
+transaction does not pay in fees nor bytes for the inclusion of the datum.
-The impact of CIP 32 is compounded when used with CIP 31.
-With both CIP 31 and 32, any referencing transaction
-does not pay in fees nor bytes for the inclusion of the datum.
 
 CIP 33 allowed scripts to be referenced, rather than having to be included in
 the transaction. As mentioned, scripts can easily exhaust most if not all the