-
@ optout
2023-12-28 05:47:43Some musings on how a mining pool could pay out miners trustlessly. Don't expect a conclusion at the end, this is more like me thinking out aloud.
Mining pools are a necessity for evening out the lottery effect, if you don't want to wait decades for a mining reward, you need to join a pool. However, most pools are custodial, that is, they hold your collected earning bits until it's economical to pay out.
Ocean's (nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze https://ocean.xyz) recently started pool brings the innovation of direct payout to miners: miners (with large-enough shares) get paid out directly from the coinbase transaction! So far only two such blocks were produced, but the idea is simple and great, the payout is directly from the coinbase, and is completely trustless. For smaller amounts the pool still acts as custodial pool, because of fee economics: even though the coinbase transaction itself does not have a fee, but creating small (or even dust) UTXOs for miners does not make sense.
A solution would be using Lightning for small payments.
The easy way is to pay out over Lightning in a custodial way, with payments independent from the coinbase rewards. This can produce more frequent payments, thus reducing the wait time for miners and the amount custodied by the pool. Due to the lower fee sensitivity of Lightning, reward payments could be sent out after each block. However, this is still a custodial, trust-based solution.
The two approaches could be combined: at each found block, pay out larger shares (above a threshold, e.g. 0.01 btc) directly from the coinbase transaction trustlessly, the rest to the pool, and at the same time pay all other smaller shares via lightning (note that the pool gets onchain funds and has to pay out over lightning, so it needs to manage liquidity, but this is a detail).
Is it possible to pay out over lightning in a trustless and scalable way?
One idea is that the coinbase transaction can contain a submarine swap output.
A submarine swap is a trustless, atomic swap from onchain bitcoin to lightning. The typical use case is that someone wants to pay a lightning invoice, but has no access to lightning, only has onchain bitcoin. A submarine swap provider can perform a swap: takes onchain and pays out over lightning (potentially taking a small swapping fee). This can be done trustlessly: given the existing lightning invoice, an address can be crafted with a script that allows spending only by possession of the lightning payment secret. The user can verify the script of this address, do its onchain payment to it. Then the swap provider pays the lightning invoice, finding out the payment preimage, and then can proceed to collect the onchain funds.
The pool always recomputes the current outstanding reward (share) of each miner. If the miner supplies a lightning address (e.g. LNURL), the pool can generate an invoice for the current share amount. Then it is possible to create a submarine swap address that is collectible by the pool only in the possession of the preimage of the invoice. The miner can verify that invoice it has given out, and the script in the bitcoin address, which is part of the published block template. Once the block is mined, the pool is incentivized to collect the respective output (otherwise it is lost), but it can do so only after paying the lightning invoice.
So technically it is possible to pay out trustlessly over lightning. But is this scheme practical, from fee and scalability point of view? Miners are OK, as they only get small lightning payments. The drawback is that a separate output is needed for each payout, with small amount, and with a small script. This is bloating the coinbase transaction, with possibly thousands of output (and megabytes of data). Another problem is that the pool operator must collect the locked funds for each payout separately, which takes an onchain fee. So this scheme is not practical for small amounts in a high-fee environment, in other words, not scalable.
To address the collection fee issue, payouts to multiple miners could be combined into a single output, with a script that contains all the conditions (with and clauses). This would require much less outputs, making the scheme more scalable.
However, this introduces a serious denial-of-service attack possibility: a malicious miner can provide the invoice, but refuse to accept payment (and reveal the preimage), which would block collection of the reward for all miners from the given output.
An onchain payout only requires an address from the miner, and no other action. A lightning payout, on the other hand, requires providing an invoice, and accepting a payment. This distinction is important, as it can open up denial of service, which can be an issue in case multiple payouts are combined.
Let's briefly also look at the data size issue. Whether a single output for each lightning payment, or a single output is used, at some steps all the individual payment hashes have to be included in a script. This could be reduced if one could combine the preimage hashes in one check, but I don't see that possible with hash-based payment hashes. Another idea is to have a single submarine swap for a lightning invoice that is trustlessly multiplexed to all the desired invoices, analogue to an lnproxy solution. But I see no way to solve this (in the lightning invoice it's not possible to use bitcoin script, only hashing).
So my brainstorming got me this far. I plan to explore the option to use chaumian e-cash instead of lightning, the Cashu implementation is now powerful enough to attach conditions to the ecash, such as who can redeem it. The idea is that the pool operates a mint, and when it want to pay out miners, it just creates and send them ecash, with the right denominations, and locked to their pubkeys. The miners then can immediately redeem the ecash, e.g. via lightning. This would be still a trusted setup, but only for a short period. However, this is not really an improvement over the pool paying out over lightning (custodially, as discussed above).
It could be that the mint is operated by another entity, thus the pool does not need to be trusted once it mints the ecash, but then there is the need to trust another entity as well. Or the mint can be a federation, e.g. a fedimint. This is another idea to explore.
What could work as of now is the combined approach: pay out larger shares directly from coinbase, the rest to the pool operator, and pay out smaller shares over lightning. Miners would need to supply a bitcoin address and an LNURL address.
Ideally a trustless and scalable lightning payout solution will be found eventually.