Interactive Transaction Construction (InteractiveTxConstructor, splicing, dual-funding)
Host: dunxen -
The interactive transaction construction protocol, outlined in lightning/bolts#851, allows parties to collaboratively construct a bitcoin transaction by exchanging inputs and outputs for that transaction. It finds its first practical use in the dual-funding protocol where both parties A and B can contribute to the value of the channel during establishment. An example interactive transaction construction session (from the spec) could look like the following:
+-------+ +-------+ | |--(1)- tx_add_input ---->| | | |<-(2)- tx_complete ------| | | |--(3)- tx_add_output --->| | | |<-(4)- tx_complete ------| | | |--(5)- tx_add_input ---->| | | A |<-(6)- tx_add_input -----| B | | |--(7)- tx_remove_output >| | | |<-(8)- tx_add_output ----| | | |--(9)- tx_complete ----->| | | |<-(10) tx_complete ------| | +-------+ +-------+
- Splicing also makes use of the interactive transaction construction protocol for constructing splice-in and splice-out transactions.
- This PR implements the interactive transaction construction protocol as a type-safe state machine.
- Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
- What is the
SerialIdof an input or output and how is it chosen in this implementation? What is the
SerialIdparity constraint and why is it used?
- Why are the number of inputs and outputs for the constructed transaction limited to 252 each?
- If we already have the limit for inputs and outputs above, why do we place a limit of 4096 on received
- How are the state transitions defined using the
define_state_transitionsmacro and what is the purpose of doing so in this way? How does it help holders of an
- What transaction fees are paid by the non-initiator of the interactive construction protocol?