sBTC Disbursement process

[igorsyl]

@radicleart cross-posting from Bitcoin Builders Discord per @kantai 's suggestion

Hi! I'm beginning to digest Judes sbtc-mini contract and have a question about the disbursement process - maybe someone can shed some light ?

Could disbursements be paid in SBTC rather than BTC ?

Disbursements pay the pox rewards from the SBTC wallet (originating from miners) to the BTC address the signers registered with?

Would doing this break pox consensus or the incentive mechanism? From a user perspective don't most pool stackers already have rewards paid in STX?

Would paying the pox rewards in SBTC be equivalent to a situation where signers immediately wrap their disbursements into SBTC via a pegin request (but in the following reward cycle / SBTC wallet) ?

[igorsyl]

cc @andrerserrano @radicleart please cross-post your answers here.

[radicleart]

The thought above is really about the stackers (rather than the miners) and motivated by wondering if its possible to simplify the protocol in the area around paying pox disbursements. E.g. if all btc paid to a peg wallet (ie miner pox rewards + user peg ins) could be treated as 'pegged in' and swapped for SBTC.

Could this work if say the signers were divided randomly into 2 groups (odds and evens say) and pox rewards to odd signers were fulfilled to SBTC by even signers and vice versa.

Not expecting to change the way the protocols here. This is really about learning how mini sbtc works and thinking aloud.

[jcnelson]

It needs to be BTC, not sBTC. Per the design doc, signers must receive their PoX payouts as BTC in order give them a reason to go through the DKG process in order to handle peg-ins and peg-outs. By requiring that signers receive PoX BTC to the same wallet address as the peg wallet, we ensure that signers must cooperate from the get-go when their tenures begin, even if there are no peg-ins or peg-outs.

Allowing them to receive sBTC removes a powerful incentive for signers to act faithfully -- they'll get paid either way with sBTC.

[MarvinJanssen]

Thank you for your answers Jude!

1. Maybe it would have been more specific to say 1:! price with Bitcoin at the time the PoX reward was received.
2. I can see that as a theoretical argument, but if future Stackers "do not care" about prior Stackers—which I understand to mean is they will not honour their sBTC peg-out—then the protocol is dead. sBTC the token is valuable for as long as the promise of being able to peg it out to native Bitcoin in the future exists. Since future Stackers also receive their rewards in sBTC at the end of the cycle they participate in, if they don't honour prior Stackers' peg-outs during their cycle, then to recover PoX value they must collude to seize the peg wallet for themselves. And they must do it before the cycle ends because the next set of Stackers won't care about them. It would be an issue if the entire set of prior Stackers is replaced by a completely new set of Stackers for the next cycle.
3. Meaning, actual disbursement is paid out of the PoX reward for the particular Stacker?
4. Not useful as metrics but useful for testing purposes nonetheless.
5. This point was more aimed at the final mainnet version of sBTC.

[jcnelson]

I can see that as a theoretical argument, but if future Stackers "do not care" about prior Stackers...

What I was trying to say here is that requiring Stackers to hold sBTC exposes them to more risk without any gain (i.e. forcing Stackers to have more skin in the game by receiving sBTC is not an advantage). They're already risking their STX and PoX rewards. The additional risk of receiving sBTC is that sBTC can temporarily freeze for banal reasons in the absence of malice, preventing Stackers from receiving a payout for honest participation. Paying in BTC via the disbursement step removes this extra risk.

I would be supportive of allowing Stackers to choose to receive sBTC over BTC, but I don't think we should remove the ability for Stackers to receive BTC.

Meaning, actual disbursement is paid out of the PoX reward for the particular Stacker?

Not in the current design. The sBTC mini contract calculates the pro-rata share of BTC that each Stacker is entitled to based on the fraction of the STX they contributed. This is handled by the Stackers themselves (really, anyone can do it, but I'm assuming that no one besides the Stackers care) -- they send Stacks transactions to check the PoX payouts for each Bitcoin block in the reward cycle, and count up the amount of BTC paid to the peg wallet address. Once this sum has been calculated, Stackers proceed to send Bitcoin transactions to disburse the rewards from the peg wallet (which they necessarily are able to do, since they use the same means to process peg-outs). Once the disbursement has been made, anyone can post a proof of the disbursement transaction to the Stacks chain to prove that the Stackers paid out some of the entitled rewards (this would likely be done by the next cycle's Stackers, so the contract is able to transition to the next reward cycle). The contract then validates each disbursement transaction to verify that UTXOs created by that transaction pay exactly that pro-rata share to a given Stacker's payout address. The fee for this transaction is not checked by the contract, because there's no way to know what the fee will be when it is time to process disbursements. The unstated assumption is that Stackers would collectively work out a way to pay the fees outside of the protocol (i.e. this is something the implementation gets to decide).

What I was saying above is that paying Stackers in sBTC does not remove the need for paying (unknown-in-advance) additional STX fees, because the contract must mint sBTC to each Stacker based on their calculated pro-rata share of the BTC received. The only fair way to do this is to require each Stacker to individually pay for their sBTC to be minted.

---

In the interest of expediency, I'd be fine with simply paying sBTC to Stackers instead of BTC for sBTC mini if that gets us a testable artifact faster. But I'm not okay with doing this in the SIP-021 sBTC. The SIP-021 sBTC must pay BTC to Stackers, and moreover, we can make this happen automatically without the disbursement logic. If the economics CAB does a very rigorous review of paying sBTC instead of BTC and finds that it does not warp any of the system's incentives, then I'll reconsider.

[igorsyl]

I would be supportive of allowing Stackers to choose to receive sBTC over BTC, but I don't think we should remove the ability for Stackers to receive BTC.

👍 for choice. I imagine some stackers would want programmable sBTC rewards and avoid the wrapping process while others may want safe BTC rewards.

[MarvinJanssen]

I like the idea of having the option too. What would be interesting to me from a design standpoint is to in fact make the system always pay sBTC to all Stackers, but Stackers can submit a peg-out before the cycle ends and those peg-outs must also be fulfilled before the next cycle can start. They could then also signal to the protocol that they want their sBTC pegged out automatically.

+1 to the economics CAB researching this matter. Is that something we can already start doing? cc @Hero-Gamer

[jcnelson]

Let me reiterate: I do not support this for sBTC. I only support it for mini sBTC. I think it would be an extraordinary finding from the economics CAB that there are no incentive differences between receiving BTC and sBTC. Please do not take anything I have written above as approval. My suggestion to pay Stackers in sBTC is only for the sake of expediency in getting it out the door.

[kantai]

Would doing this break pox consensus or the incentive mechanism? From a user perspective don't most pool stackers already have rewards paid in STX?

Yes -- the sBTC design alters the current PoX protocol for stackers. Rather than today's stacking mechanism, rewards would require participation in the sBTC protocol.