diff options
| -rw-r--r-- | bip-0119.mediawiki | 11 |
1 files changed, 7 insertions, 4 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 09e8564..29f6271 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -73,9 +73,9 @@ is provided in this BIP's subdirectory. There are numerous payment channel related uses. -====Channel Factories==== +====Batched Channel Creation==== -Using CHECKTEMPLATEVERIFY for Channel Factories is similar to the use for Congestion Control, +Using CHECKTEMPLATEVERIFY for Batched Channel Creation is similar to the use for Congestion Control, except the leaf node transactions are channels instead of plain payments. The channel can be between the sender and recipient or a target of recipient's choice. Using an CHECKTEMPLATEVERIFY, the 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: The set of data committed to is a superset of data which can impact the TXID of the transaction, other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead -of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Channel Factory type constructions -as the redemption TXID could be malleated and pre-signed transactions invalidated. +of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions +as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels +are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that +may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more +composable with arbitrary sub-protocols. =====Committing to the version and locktime===== |