mirror of
https://github.com/bitcoin/bips.git
synced 2025-05-12 12:03:29 +00:00
[BIP-119] Rename Channel Factories / Clarify Malleability
This commit is contained in:
parent
3693cdfd19
commit
099694efd3
@ -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.
|
||||
@ -262,8 +262,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=====
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user