@@ -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.
@@ -303,8 +303,11 @@ Below we'll discuss the rules one-by-one:
303
303
304
304
The set of data committed to is a superset of data which can impact the TXID of the transaction,
305
305
other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead
306
- of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Channel Factory type constructions
307
- as the redemption TXID could be malleated and pre-signed transactions invalidated.
306
+ of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
307
+ as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels
308
+ are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that
309
+ may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more
310
+ composable with arbitrary sub-protocols.
308
311
309
312
=====Committing to the version and locktime =====
310
313
0 commit comments