Allow for the bridging of custom messages/payloads or 0 BTC/sBTC deposit and withdrawals

[MarvinJanssen]

Related: #3961

At Clarity WG we started building generalised commit-reveal contracts to allow any kind of data to be submitted on Bitcoin and revealed on Stacks. See here: https://github.com/MarvinJanssen/clarity-commit-reveal.

A multitude of applications could then be built on top, of which sBTC would be one. By removing sBTC specific logic from commit-reveal it would become easier to build different things that did not perfectly align with sBTC paradigms. After we shifted direction the codebase was abandoned and the idea not developed further.

I am posting this to open a discussion to see if there is still room for a generalised commit-reveal now that the node will take care of most of the work. It is conceivable that other dapps can benefit from being able to bridge messages between Stacks and Bitcoin with custom payloads. Looking at what ALEX has been building for example, in a Nakamoto/sBTC world, their bridge would always be more expensive to run because they have to do the work purely in Clarity and cannot leverage the node mechanism directly. It puts all applications that cannot (effectively) build their transport on top of sBTC at a disadvantage.

cc @setzeus @fiftyeightandeight

[setzeus]

I strongly agree that supporting protocol mechanisms that enable further BTC <> STX communication with custom sBTC payloads is in general a worthy endeavor & vouch for building it into a version of Clarity-Bitcoin even if it's less effective than the protocol bridge.

What options do you see here? From my understanding it's:

A. Extract The Work Back From Node To Contract
This would mean that the protocol & all dapps built on top are exposed to the same network conditions; however, this would re-introduce the massive economic incentive problem (ie - forcing signers to have varying amount of transaction fees).

B. Update The Node / Protocol To Process Defined Commit-Reveal Messages
In order to provide any dapp with the existing sBTC bridge advantages the node would also need to process these additional commit-reveal messages. I'm not sure on what that works entails nor what security implications (if any) this causes? My guess is we'd have to strictly define what's an acceptable commit-reveal payload.

[MarvinJanssen]

To be honest, I am not exactly sure what the exact format should be. I think when it comes to point A, either is fine (although I prefer to do all I can in Clarity personally). The real question is how the network is incentivised to process custom Bitcoin messages and bring them into Stacks. For Nakamoto/sBTC, it is part of consensus so there is "no way around it" as a miner/signer. For custom messages, you want to prevent spam from hitting the network—although the bottleneck will conceivably the Bitcoin side. In any case, the miner has to do the work so who pays them for it? Perhaps attaching some Bitcoin to those messages is enough for miners to bring them in but the only way to do that is to bridge it into sBTC. If it is not on the Bitcoin side, then it needs to be paid for with STX or another token. It could invite a new type of transaction or a contract that will pay the miner fees if it reveals a custom message to it. (The latter likely give the greatest flexibility.) If the miner includes it in the block themselves then they can do it zero-fee.

[fiftyeightandeight]

Looking forward to working together to improve BTC <> STX integration!

[will-corcoran]

In support of this. Very cool idea. It could be interesting to reference this messaging related BIP for structuring message standards. Also, LayerZero.