OP_CHECKSEPARATESIG and actuaries: reform of multichannel factories ScrgruppEn

Many people these days are finally starting to realize the shortcomings and limitations of off-chain channels limited to two participants, i.e. the accelerator network, and the need to start exploring channel designs with more than two participants for this trend to scale to work successfully in the long term. This requires accepting new trade-offs, i.e. the price of solving some of Lightning’s existing problems by packing more than two people into a shared UTXO control arrangement is creating an entirely new class of problems.

The biggest issue presented when moving from two-party to multi-party is the interaction requirements. If you have 10 people in one channel sharing control of one UTXO, you need all 10 parties to be connected at the same time to update the status of that primary channel. This presents a much worse coordination problem than the current implementation of Lightning Channels where only two people need to be online to take advantage of the channel.

The best current thinking on this issue is simply to introduce trust into the situation through what is essentially a federal union. Lightning (and future multisig systems) acts as a self-custody system because the funds held by multisig on-chain are n-of-n, requiring the registration of 100% of participants to change the state of the funds off-chain. If you as a member of such an agreement refuse to sign a new update, it is impossible to reallocate your funds in any way. Ignoring the requirements of staying online and monitoring the blockchain to handle legacy instances, this security model is equivalent to sole custody on the main chain. Control of money cannot be changed from the current state of affairs without for you Signature.

Reducing the fundamental limit from n-of-n to m-of-n completely undermines this security equivalence of sole custody on the chain. It is an effective custodial, as your key is no longer required absolutely and non-negotiably in order to transfer control of your funds. ZmnSCPxj (not Zman!) An interesting solution has been proposed to the interaction problem

OP_CHECKSEPARATESIG

This proposal will require two soft forks, SIGHASH_ANYPREVOUT and OP_CHECKSEPARATESIG. The scope of OP_CHECKSEPARATESIG is so small and so little changing, I’d be surprised if there was any serious disagreement with it, and APO has relatively high consensus in the ecosystem as a desirable change.

OP_CHECKSIG and OP_CHECKSIGVERIFY are the two main methods for verifying signatures in Bitcoin script currently. There are two parts to the signature, the S value and the r value. OP_CHECKSIG(VERIFY) takes the r and S of the signature as one complete argument, and the public key of the check as another argument, for a total of two arguments, and then checks whether the signature is valid. OP_CHECKSEPARATESIG takes the public key, r-value, and S-value all as separate arguments (for a total of three), and verifies the signature.

Yes, that is literally the entirety of the proposal. Soft fork is simpler and less complicated than CHECKTEMPLATEVERIFY (CTV). Why is this required? Well, you’ll see it here now.

Offline status updates for everyone

This is what the starting state of a basic multiparty channel would look like. A pre-signed transaction needs Alice, Bob and Charlie to sign a UTXO over which they share control with an output for each member. If Alice wants to pay Bob while Charlie is offline, her only option is to create a pre-signed transaction from her output in the channel state and split that money between herself and the payment to Bob as follows:

The problem with this arrangement is that Alice can simply sign a conflicting transaction to refund the payment to Bob at any time and use it before Charlie goes online and everyone updates the channel, and because only her key is needed to do so, Bob can do nothing to stop it. We need to have some sort of arbitrator who ensures that Alice can’t double spend Bob when making payments this way because Charlie doesn’t respond.

You could just add a condition that requires the actuary (M) to also be a keyholder for everyone’s outputs, meaning they would have to sign to approve any transactions that spend Alice, Bob, or Charlie’s outputs from the channel state. The problem with this is that Bob now has to trust the actuary instead of Alice. If the actuary cooperates with Alice, Bob can still be double-spent.

This is where OP_CHECKSEPARATESIG comes in. Here’s how: The value of r in a signature is derived from the nonce number used for the signature. One of the main risks in dealing with keyless is the risk of key leakage, and reusing the same number twice for different transactions will leak enough information for someone with both transactions to be able to recreate the private key used. This can be used to take over the role of actuary from the top and remove trust in him. Whatever key the actuary uses for this role can be loaded with a security that can be confiscated. From this point we add their key to everyone’s output as described above, except specifying in each script exactly what value of r should be used in the signature of M in advance. We also have a timed path in CSV format that only needs the owner’s key; This way users can always spend their money however they want if the channel is closed serially after a specified period of time.

Now when Alice goes to pay Bob while Charlie is offline using a pre-signed transaction that spends its output in the channel, it goes to the actuary to sign it. After the signatures are completed and Bob has a copy of the transaction, he has a much stronger assurance that this money will not be double-spent. If the actuary cooperates with Alice to double spend Bob, his key will be leaked and the money he put in the bond could be confiscated. If the channel is closed on-chain in this case, Bob will be able to confirm the signed transaction by the actuary before Alice can double spend it, because Alice has to wait for the time lock to expire before she can double spend it, Bob doesn’t because Alice and Actuary’s spending path has no time lock. This can be added as a line to each level of the multichannel if you integrate smaller channels at the top as well.

This provides a security model for Alice and Bob to update the multichannel without Charlie being online, which while strictly speaking untrustworthy, comes as close as possible without meeting that bar. Bob can have a strong guarantee that it will not be spent twice, which is almost 100% as long as the value of the bond the actuary uses is greater than the value of the payment, and Alice can make this payment with a good enough guarantee for Bob even though Charlie is offline With the Internet. This can be used in very frequent situations where not everyone is available to continue processing updates, and is explicitly broken off when everyone is online to update the base level of the channel and remove additional transactions using this scheme.

OP_CHECKSEPARATESIG and the actuarial role it enables in multilateral channels solves a major problem in making the concept of more than two people sharing a channel widely applicable. I’m sure there are plenty of other situations besides MLS where a bond is enforced such that some party only signs one copy of something. Bitcoin users should take this seriously, as it provides a great solution to a known problem without any of the complexity by changing a small aspect of how signatures are verified.

The most trusted voice in bitcoin, Bitcoin Magazine provides news, analysis, information, commentary, and price data about Bitcoin blockchain tech