Replying to Avatar vnprc

nostr:npub1x0ywjcwk9zjffndn0wt485xx68h8vykdqg9yztya7lec5an0g4lqg09t7k what is the payout scheme? I assume it would have to use pplns or similar right?

Hey! great to hear from you. I have been meaning to reach out.

The cool thing is that in this reboot, we are adding transactions with UTXOs. So each p2pool "block" encapsulates a share found by a miner. The share block, as I call it in the code, has a coinbase. This coinbase essentially has an output, which can be "spent" by the miner. The output could have any bitcoin Script in it.

Since the p2pool sharechain has exactly the same transactions as bitcoin, miners can spend their UTXOs.

One approach is to atomically swap a bunch of such outputs for bitcoin.

The buyer of the coinbase outputs is later paid for all these outputs by p2pool from the bitcoin block coinbase.

The share block coinbases are only useful for share accounting. Payouts are directly from there bitcoin block coinbases - based on the share accounting from the sharechain coinbase ownership.

I'll give you my coinbase, if you give me bitcoin now, and you'll get paid when the pool's bitcoin coinbase pays out all the buyers of such coinbases (call them market makers).

We will limit the number of outputs on the bitcoin block coinbase so we can stay within antminer limits. That will limit the number of market makers that can trade on the pool.

There is s brief introduction here https://blog.opdup.com/2025/02/04/rebooting-p2pool-for-bitcoin.html

Having said all that, I want to explore other ideas. Given the pool has transaction support, we should be able to do even cooler things - like use ecash for privacy!

Reply to this note

Please Login to reply.

Discussion

Sir, I cannot zap you. This comment is highly zap worthy.

I have also been looking for ways to swap coinbase outputs for other outputs. Apparently covenants are a no go because tx introspection across outputs not covered by the script being executed is more powerful than any proposal on offer.

Two other ideas are coinswaps or DLCs.

If we lock a coinbase output to a 2-of-2 script that would cover the initial staging tx. I think it would require one more tx after that to complete transfer of ownership. This creates a natural 100 block baking period for the contract. Maybe useful, maybe problematic. Still thinking on it.

DLCs are very intriguing because we can also lock up ecash in a DLC. I think this is the most promising idea at the moment because it blurs the line between on-chain and ecash anon sets.

Edited for clarity:

For a coinswap, if we lock a coinbase output to a 2-of-2 script that would cover the initial staging tx.

Next step is to develop a scheme to resolve a DLC when a coinbase output matching this shape is emitted within this timeframe.

I published a design a while back for using DLCs to pay miners, where the federation of mining service providers act as the oracle.

https://www.radpool.xyz/1/payout-mechanism.html

Do you have any links on how ecash is locked into a DLC? i haven't read about that.

Regarding swaps, another idea is to run these swaps on LN. I have been told boltz is doing just that.

Ecash can do lightning swaps too https://github.com/cashubtc/nuts/blob/main/14.md

Excellent. Thanks for sharing. I'll read through and come back here.

I think I'm starting to get it. It's like a P2Pool Ark Service Provider but flipped backwards. The VTXOs are funded by proof of work shares and instead of a liquidity provider funneling bitcoin into the ASP, P2Pool funnels liquidity out of the ASP via coinbase rewards.

Fucking brilliant!

You could fund the ecash mint using VTXO Spillman channels. Like this proposal but again flipped backwards.

It's more secure. You really don't want to open LN channels with pools. Spillman channels solve that.

https://gist.github.com/lukechilds/307341239beac72c9d8cfe3198f9bfff

Exactly, we can use much simpler contracts than LN to provide the trade between the shares on p2pool and BTC. We do need atomicity in the trade though. So miner's shares and buyers BTC are swapped or not, there should be no state in each either of the party is left hanging.

I wonder if we should write down the contracts in the case of doing this swap without ecash and then with ecash. The devil is always in the detail. I am curious how much extra code complexity we need to introduce to use ecash here.

Another point to keep in mind is, since p2pool is a block chain with transactions, we can provide an extra op code in the script engine. So, can we make the transactions even less expensive on the bitcoin chain by using something like CSFS on the p2pool chain? My intuition says it should be possible, but I haven't explored this yet. Still in the weeds of building the p2pool chain.

> My intuition says it should be possible, but I haven't explored this yet. Still in the weeds of building the p2pool chain.

I have the same problem. Too many ideas to follow up on. Need to focus on eHash development.

We should get together and brainstorm.