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. 
-No evidence is provided that the specific contexts which cannot be supported are critical,
-nor is there an attempt to quantify the claimed performance improvements.
-Accepting CIP 118 will not only add to ledger complexity, 
-it is an open invitation for a series of subsequent ledger changes, 
-both tweaks and fixes of missteps, and as more of the inexhaustible list of intents 
-gets shoe horned in. 
-Efforts and energies would be much better spent making accessible and utilizing what we already have.
+The use cases CIP 118 cites can already be supported. No evidence is provided
+that the specific contexts which cannot be supported are critical, nor is there
+an attempt to quantify the claimed performance improvements. Accepting CIP 118
+will not only add to ledger complexity, it is an open invitation for a series of
+subsequent ledger changes, both tweaks and fixes of missteps, and as more of the
+inexhaustible list of intents gets shoe horned in. Efforts and energies would be
+much better spent making accessible and utilizing what we already have.
 
 ## Context
 
@@ -190,26 +189,23 @@ 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". 
-I find this argument incredibly weak. To create a transaction, a user already
-needs access to the chain via functions `getUtxosAtTip` and `submitTx`. Having
-another `getDatumByHash` is not a big deal - it is just a tooling issue. 
-A more compelling case is that it reduces the size of transactions. 
-Prior to the change and in normal application an output datum hash 
-would need to be validated, 
-and so the datum would be present in the witness set, adding to the 
-transaction size. 
-The consuming transaction would then need to include the same data.
-There are some contexts where this can be improved upon, 
-but CIP 32 essentially halves this problem by paying for the data just once.
-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.
+spending party, who must watch the whole chain to spot it". I find this argument
+incredibly weak. To create a transaction, a user already needs access to the
+chain via functions `getUtxosAtTip` and `submitTx`. Having another
+`getDatumByHash` is not a big deal - it is just a tooling issue. A more
+compelling case is that it reduces the size of transactions. Prior to the change
+and in normal application an output datum hash would need to be validated, and
+so the datum would be present in the witness set, adding to the transaction
+size. The consuming transaction would then need to include the same data. There
+are some contexts where this can be improved upon, but CIP 32 essentially halves
+this problem by paying for the data just once. 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
 transaction size limit. Referencing scripts dramatically reduces the size of
-script heavy transactions. Generally speaking, of the three CIPs, this was the 
+script heavy transactions. Generally speaking, of the three CIPs, this was the
 most significant.
 
 The ledger changes in Vasil were a small perturbation of what had come before.