Author: Eugene Siegel 2022-08-10 15:34:44
Published on: 2022-08-10T15:34:44+00:00
The discussion revolves around the ancestor bulking variant of pinning and its relevance in certain situations. The primary scenario where this variant matters is when adding a new descendant is not possible due to the limitations of ancestor/descendant. In the given example, as all outputs are locked with `1 OP_CSV`, adding a descendant to the splice tx is not feasible. It is also noted that the ancestor bulking does not hold significance for RBF as it only replaces the splice tx, not the ancestors. However, it may matter if the new funding output is not encumbered.The new funding output cannot have `1 OP_CSV` unless there is a modification in the commit tx format, which might be a complicated process. Since the commit tx has the disable bit set in nSequence, it is not compatible with the sequence lock. Enabling the bit can be challenging as the time-based or block-based locktime based on the lower bits of the obscured commitment number should be block-based (and non-zero) for the sequence lock to work. If the new funding output is not encumbered, pinning exists as an attacker can create a junk tree using the anchor output. However, it is replaceable through RBF as one can broadcast their own commit tx (with anchor).Overall, the discussion provides insights into the technicalities involved in the ancestor bulking variant of pinning and its applicability in specific scenarios related to Bitcoin transactions.
Updated on: 2023-06-03T09:37:24.709261+00:00