A way to reduce the liquidity requirement of hubs in lightning p2pool, potentially by three orders of magnitude. The first part of this post briefly summarizes the original lightning p2pool proposal in a slightly new way, the second part introduces this new idea.

The original proposal had this as the script of the coinbase output.

Code:

(1) 2of2 multisig of hub + successful hasher
OR
(2) hub pubkey + H(X)
OR
(3) successful hasher pubkey + OP_CSV 1 week

Control of the coinbase is divided, between the hub and the successful hasher, in a complicated way.

In the case where everyone cooperates, branch (1) is used to send the coinbase to the hub. (But only after the hub has sent all the hashers the correct amount of money according to the state of the sharechain)

The successful hasher could defect, either by becoming unresponsive or trying to hold the hub to ransom on a Mutually Assured Distruction (MAD) basis. To avoid that, branch (2) allows the hub to collect the money on its own. It must reveal the preimage X which allows every other hasher in p2pool to collect their rightfully-owed money.

The hub could also defect, by being unresponsive or holding the successful hasher to ransom via MAD. Branch (3) avoids this by providing a timeout (of 1 week in this example) after which the successful hasher can collect the entire coinbase. This punishes the hub, providing a disincentive to doing this.

Now, we remind ourselves of the Schnorr signature + taproot + MAST proposal, which will probably be added to bitcoin one day via a soft fork. Using Schnorr signatures it allows any N-of-N multisig to take up the same blockchain space as a single signature. MAST allows any syntax tree with N branches to be efficiently committed to, spending via one branch only requires log2(N) data to be added to the blockchain. Taproot is a way to combine Schnorr and MAST which avoids having to reveal any MAST merkle proof if it never gets used.

------

With all this mind, we propose another script of the coinbase output, this time with two hubs. The hubs have preimages X and Y. The "OR" statements are left out for readability, branches are numbered and successful hasher is abbreviated to SH. The hubs both periodically broadcast hash-locked channel updates, same as in the original proposal.

The proposed coinbase script for the situation with 2 hubs:

Code:

(1) 3of3 multisig of hubX, hubY and SH
(2) hubX pubkey + H(X) + hubY pubkey + H(Y)
(3) SH pubkey + hubY pubkey + CSV 1 week
(4) SH pubkey + hubX pubkey + CSV 1 week
(5) hubX pubkey + H(X) + CSV 2 weeks
(6) hubY pubkey + H(Y) + CSV 2 weeks
(7) SH pubkey + CSV 3 weeks

What we have is a branch covering every possible combination of cooperate and defect:

* Branch (1) is a 3-of-3 multisig for everyone cooperates, it is the most common situation.
* Branch (2) is when SH defects, it allows the two hubs to divide the money equally between them, but they must reveal the preimages so that every other hasher can get paid as well.
* Branches (3) and (4) are used when one hub defects, it allows SH and the other hub to take their money and punish the defecting hub by stealing it's money too.
* Branches (5) and (6) cover the situation where SH and one hub both defects, it allows the remaining hub to punish them the other hub and get the money (but it must reveal its preimage).
* Branch (7) covers the situation where both hubs defect, the SH punishes them both.

The most important branches are (1) and (2). In the vast majority of cases all the payment channels will be honestly updated and branch (1) will be used. All the other branches are required to make it impossible to hold anyone else to ransom via MAD. The OP_CHECKSEQUENCEVERIFY timeouts are staggered so at each step there is plenty of time to respond.

Branch (1) can be efficiently executed in a single Schnorr signature. All the other branches can be hidden in a MAST merkle tree, hidden in a taproot scheme.

This reduces the liquidity requirement because each hub only needs to own half a much bitcoins as before. Today's block reward is around 12.5 btc, under this idea each hub only needs to provide 6.125 btc. All the other incentives and procedures as the same as before.

--------

Next, let's extend the scheme to using 3 hubs. Each hub has preimages X, Y and Z. The coinbase script for that situation would be:

Code:

(1) 4of4 multisig of hubX, hubY, hubZ and SH
(2) hubX pubkey + hubY pubkey + hubZ pubkey + H(X) + H(Y) + H(Z)
(3) SH + hubY + hubZ + CSV 1 week
(4) SH + hubX + hubZ + CSV 1 week
(5) SH + hubX + hubY + CSV 1 week
(6) hubY + hubZ + H(Y) + H(Z) + CSV 2 weeks
(7) hubX + hubZ + H(X) + H(Z) + CSV 2 weeks
(8) hubX + hubY + H(X) + H(Y) + CSV 2 weeks
(9) SH + hubZ + CSV 3 weeks
(A) SH + hubY + CSV 3 weeks
(B) SH + hubX + CSV 3 weeks
(C) hubZ + H(Z) + CSV 4 weeks
(D) hubY + H(Y) + CSV 4 weeks
(E) hubX + H(X) + CSV 4 weeks
(F) SH + CSV 5 weeks

This is very similar to before. There are 15 branches now, most of which would be never executed and are hidden in MAST. Branches (1) and (2) are again the most important. As before, it's not possible for any entity or group of entities to hold anyone else to ransom via MAD. All the hubs can be punished if they misbehave. Each hub only needs to provide 3 times less liquidity as before.

If any branch but (1) is executed then the MAST proof size is only log2(15) = 4 hashes.

Left as an exercise to the reader, you can work out that with N hubs the number of branches for a similar scheme is 2^(N+1) - 1, which means the merkle proof for any branch except for (1) is of size N.

If we choose N = 10 to have 10 hubs, the most common branch (1) of the 10-of-10 multisig is still just the same size as a Schnorr single sig. For any other branch the merkle proof size is only 10 hashes. But each hub requires 10 times less liquidity.

If we choose N = 100 we have 100 hubs. As before, the branch (1) is just a single sig and each hub requires 100 times less liquidity.

We can also use the previous idea of using multiple coinbase outputs. We can have 10 coinbase outputs, each with N = 100 hubs, so that would be 1000 hubs altogether, each requiring 1000 times less liquidity than the original proposal.

1000 is more of a demonstration to show how well this scheme scales. In reality it would run up against other bottlenecks like the bandwidth requirement for all those channel updates.

belcher

Posts

Merits