@@ -73,9 +73,9 @@ is provided in this BIP's subdirectory.
73
73
74
74
There are numerous payment channel related uses.
75
75
76
- ====Channel Factories ====
76
+ ====Batched Channel Creation ====
77
77
78
- Using CHECKTEMPLATEVERIFY for Channel Factories is similar to the use for Congestion Control,
78
+ Using CHECKTEMPLATEVERIFY for Batched Channel Creation is similar to the use for Congestion Control,
79
79
except the leaf node transactions are channels instead of plain payments. The channel can be between
80
80
the sender and recipient or a target of recipient's choice. Using an CHECKTEMPLATEVERIFY, the
81
81
recipient may give the sender an address which makes a tree of channels unbeknownst to them.
@@ -262,8 +262,11 @@ Below we'll discuss the rules one-by-one:
262
262
263
263
The set of data committed to is a superset of data which can impact the TXID of the transaction,
264
264
other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead
265
- of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Channel Factory type constructions
266
- as the redemption TXID could be malleated and pre-signed transactions invalidated.
265
+ of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
266
+ as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels
267
+ are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that
268
+ may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more
269
+ composable with arbitrary sub-protocols.
267
270
268
271
=====Committing to the version and locktime =====
269
272
0 commit comments