In this post I’ll summarize the proposed changes to be able to integrate split ticket purchasing ability to LN, which has several benefits such as decreasing the on-chain footprint and possibly providing improving privacy to purchasers.

I’ll also outline a general strategy for implementing those over the course of the next months.

Changes and Rationale

To enable construction of the MRTTREE Smart Contract which allows non-custodial control of group funds (part 1 - MRTTREE construction):

• Add OP_PUBSECP256K1FROMPRIV to be able to create the correct conditional test to bind redeemability of the tree of transactions.

To enable redeeming funds from tickets after a vote or revocation and in case of non-cooperation of the group of users:

• Add the SIGHASH_NOINPUT signature hash type, so users can rebind the tree of transactions previously built to the new transaction.

To reduce the cooperation needed to redeem funds with the stake base reward after a vote (part 2 - LN & Split Tickets):

• Add the SIGHASH_NOTOUTPUTVALUE signature hash type, so that the output amounts in the tree of transactions are malleable;
• Add the OP_CHECKOUTPUTPERCENTAGE opcode so that the outputs are still restricted to not drop below a certain percentage.

Finally, to improve the layout of ticket transactions (part 3 - Ticket Layout Changes):

• Drop the need for the number of inputs to be equal to half the number of outputs;
• Add OP_SSTXCOMMITMENT so commitment addresses are uniquely identified by content (versus index);
• Add OP_SSTXPROPVOTEADDR so the Politeia voting rights is uniquely identified.

Implementation Strategy

Assuming all changes are to be made, they can be worked somewhat concurrently.

The new signature hash types can be implemented along with the already proposed reformulation of the signature hash algorithm.

The new opcodes for operations are largely self-contained and wouldn’t currently interact with any other major ecosystem component. Their semantics can be defined and they can be implemented largely independently of any other work (and might even turn out to be useful in other contexts).

The new stake opcodes and the changes to the layout of ticket transactions however represent a significant departure from how staking currently works and would require rewriting several different components. At the very least, this is a big impact to the node, wallet and VSP software stacks.

Do note that work is not absolutely required for LN funded tickets, so it can be done over a longer time frame. This can bring benefits to LN split tickets in the form of added privacy and reduced blockchain footprint (which has network-wide repercussion) but that can be achieved in small increments.

If this discussion doesn’t garner enough technical criticism to be considered completely unworthy of further work then the next steps involve writing the proposal and specs for the relevant consensus changes.

Conclusion

While surpassing 8k written lines to present only a rough, high level outline of the changes required to “merge Lightning Network to Decred Staking in some way” might seem just a tad verbose, hopefully it serves as an illustration of how these kinds of changes cannot simply be done by armchair strategizing and require actual fingers-on-the-keyboard work to be thought out.

Some of this work has been reviewed at various points by a few developers and contributors so I’d like to thank them for their input during these past few months.