Transaction fees

[adambor]

9th Proof of Folding outlines a performant single-use-seal commitment layer, abstract from any token on the base layer, as such the problem of how to pay fees to the miner was pushed to the client-side-validated layer above (e.g. RGB). A different approach would be to keep bitcoin as a token on the base layer (this wouldn't even lead to more complexity on the base layer), and this could then be used to pay for the fees. Below is comparison table of pros/cons for both solutions.

	Client-side-validation	Bitcoin as base layer token
Use any token to pay for fee*	Yes	No
Need to pass consignment to miners**	Yes	No
BTC programmability	Yes	No (limited to schnorr signatures)

---

Use any token to pay for fee*
Using any token to pay for a fee sounds like a big advantage, providing a tremendous UX improvement for the users. On the other hand one must also consider that requiring a fee to be paid in bitcoin provides additional demand and utility to bitcoin.

Need to pass consignment to miners**
This is a big issue with client-side-validated fee paying, the consignment (containing the CSV asset history) can easily become several tens/hundreds of MB. This consignment needs to be passed along with every transaction, this means:

• miner ingress in terabytes per block
• possible overloading of the whole p2p network
• massive CSV history entanglement (miners spending their fee would entangle pretty much whole asset history).

The only solution for this would be to utilize CSV history compression using SNARK/STARK proofs, SNARKs would be able to compress the history to constant 1-2kB but do require a trusted setup. On the other hand STARKs do not require any trusted setup but their size is polylogarithmic to the length of the history, resulting in ~500kB at the tail end.

	Size	Required bandwidth for 2^20 txns (whole block)
Bitcoin on base layer: Transaction	1 kB	1 GB
Full CSV: Transaction + raw consignment	100 MB	100 TB
Full CSV: Transaction + SNARK proof	2-3 kB	2-3 GB
Full CSV: Transaction + STARK proof	500 kB	500 GB

[cryptoquick]

Very good summary.

A couple comments:

• 0.5 TB is still a huge improvement over 100 TB
• I think we should do both and let miners set fees and let the market decide. This makes sense if we launch with the capability to shard.

[adambor]

Indeed it is, but still means at least 72 TB ingress per day for miners, not even talking about the strain on the whole p2p network, because as Maxim pointed out you don't necessarily want to have public repository of the miners, you want them to be anonymous, therefore transactions have to be relayed through the p2p network. Heck I am even worried that 1GB bandwidth per block (just for txns) is too much for the p2p network.

It also is a good question if the loss of programmability for BTC is such a big deal, as we realized already that RGB in its current state purely depends on bitcoin locking script for spending conditions. But then we need a bitcoin 2wp from the get-go to get that bitcoin on the base layer ( or issue our own AbraxasCoin to be used for fees :) )

[cryptoquick]

Miners won't be running their servers on services where bandwidth is metered. Usually on services like AWS, bandwidth is constrained by the NIC, which usually ranges from 1gbps-8gbps for their more affordable instances. 0.5TB per block works out to be nearly 7gbps, which is just barely under that limit. But this won't work on a P2P network, since the traffic will need to go at least 2:1 upload:download. I think Bitcoin defaults to 8 peers.

There is another option, which is to limit the defaults of a CSV fee chain by 10x, so instead of a million tx per block, 100,000. This will likely lead to a premium paid by those who wish to pay fees in anything other than ABTC. Also, the 2WP doesn't have to be trustless to begin with if we build on Liquid... But that introduces another complication, of 1 minute block times, and so we'd need another default limit of 10x if running on Liquid.

[josediegorobles]

We can have BTC on both sides, isn't it? A native 2WP between BTC on base layer and on client-side validation, so we don't have to worry about the 2WP between Bitcoin blockchain and Prime/9th Proof of Folding. We can do trustless swaps from BTC in bitcoin blockchain to prime/9th base layer and to prime/9th client side BTC tokenM from prime/9th base layer to prime/9th client side BTC token and from client side to bitcoin blockchain and prime/9th base layer. And then the miners can receive fees directly on base layer (in bitcoin) or a (most probably) bigger fee in whatever token in base layer (and maybe a fee directly from client side to base layer too).
And yeah btc on base layer won't have programmability but you can transfer to client-side for that.

[adambor]

Miners won't be running their servers on services where bandwidth is metered. Usually on services like AWS, bandwidth is constrained by the NIC, which usually ranges from 1gbps-8gbps for their more affordable instances. 0.5TB per block works out to be nearly 7gbps, which is just barely under that limit. But this won't work on a P2P network, since the traffic will need to go at least 2:1 upload:download. I think Bitcoin defaults to 8 peers.

You lose out on decentralization big time if it is impossible for regular miners to run their own node for block construction.

There is another option, which is to limit the defaults of a CSV fee chain by 10x, so instead of a million tx per block, 100,000. This will likely lead to a premium paid by those who wish to pay fees in anything other than ABTC. Also, the 2WP doesn't have to be trustless to begin with if we build on Liquid... But that introduces another complication, of 1 minute block times, and so we'd need another default limit of 10x if running on Liquid.

Yep, you are right, we can start with federated peg, you think we can re-use liquid for that? Is it possible to build trustless (as in only trusting Liquid) 2WP on top of liquid? 1 minute block time is not an issue, you don't necessarily need to commit a new Abraxas block to every Liquid block, can be done every 10 blocks, etc.

[cryptoquick]

You lose out on decentralization big time if it is impossible for regular miners to run their own node for block construction.

Agreed. It would seem the CSV approach to fees is not the way to go. However, does Prime have the same problem?

Yep, you are right, we can start with federated peg, you think we can re-use liquid for that? Is it possible to build trustless (as in only trusting Liquid) 2WP on top of liquid? 1 minute block time is not an issue, you don't necessarily need to commit a new Abraxas block to every Liquid block, can be done every 10 blocks, etc.

I'd prefer to have a system of intermediate finality, where there can sometimes be more than 100,000 txs per Liquid block if there is a tx deficit prior, which resets when checked into the Bitcoin blockchain.

As for whether Liquid can intermediate an RGB 2WP, that's a good question, but that's the sense I'm getting.

[adambor]

We can have BTC on both sides, isn't it? A native 2WP between BTC on base layer and on client-side validation, so we don't have to worry about the 2WP between Bitcoin blockchain and Prime/9th Proof of Folding. We can do trustless swaps from BTC in bitcoin blockchain to prime/9th base layer and to prime/9th client side BTC tokenM from prime/9th base layer to prime/9th client side BTC token and from client side to bitcoin blockchain and prime/9th base layer. And then the miners can receive fees directly on base layer (in bitcoin) or a (most probably) bigger fee in whatever token in base layer (and maybe a fee directly from client side to base layer too). And yeah btc on base layer won't have programmability but you can transfer to client-side for that.

We've started to call 9th Proof Abraxas, so I will refer to solution described in 9th Proof of Folding as Abraxas.

I was thinking about this as well. That there could be a native 2WP mechanism allowing you to swap between CSV BTC (client side validated BTC) and BASE BTC (base layer BTC) - both on top of Abraxas. This can and should be limited to just some small number of peg-out txns (like 100) per block (as every peg-out would require sending at least a STARK proof of the consignment - ~500kB) - this is fine as most people can probably just do an atomic swap between CSV BTC and BASE BTC, not initiating any peg out.

Another I think even better approach is to consider the fact that if we can create a 2WP between Bitcoin blockchain and BASE BTC, we can also create a 2WP between Bitcoin blockchain and CSV BTC using the very same principle. Therefore people could bridge BTC -> BASE BTC (that will stay on the Abraxas base layer), and BTC -> CSV BTC (on top of Abraxas). You can then do atomic swaps on top of Abraxas between BASE BTC <> CSV BTC. This way we don't need any additional functionality for 2WP on top of Abraxas, users can pay fees in BASE BTC and atomic swap into CSV BTC if they want more programmability.

[cryptoquick]

That's perfect! I like how this design is shaping up. That way Bitcoin miners can then be incentivized to run Abraxas miners because they'll be able to earn more bitcoins. We'll make a proper bitcoiner out of you yet, @adambor 😸

One question:

There's essentially three forms of Bitcoin in this design, correct?

BTC - Coins on the Bitcoin blockchain (I would actually call this base layer)
BASE BTC - Coins used to pay for fees on the Abraxas chain, backed by BTC held in (maybe Liquid?) 2WP (I would recommend we call this ABTC, for Abraxas BTC)
CSV BTC - An RGB20 for BTC backed by ABTC (I've been calling this RGBTC)

[adambor]

Yep, almost, so we have:

BTC - coins on the bitcoin blockchain, so like you said - base layer
ABTC - coins on Abraxas chain, backed by BTC in some 2WP (liquid, prometheus, spiderchain, bitvm, whatever...)
RGBTC - RGB20 BTC token on Abraxas, backed by BTC in a 2WP (liquid, prometheus, spiderchain, bitvm, whatever...)

So both ABTC and RGBTC are backed directly by BTC on bitcoin blockchain held in some 2WP construction. So to swap ABTC to RGBTC one needs to peg-out ABTC -> BTC, and then peg-in BTC -> RGBTC. This of course doesn't scale, so I believe most people will just do atomic swaps between ABTC <> RGBTC on top of Abraxas, with the relatively expensive peg-out & peg-in process done from time to time by market makers to rebalance their liquidity pols.

[cryptoquick]

That all makes sense.

BTW, you never answered this question:

It would seem the CSV approach to fees is not the way to go. However, does Prime have the same problem?

[adambor]

Yes, Prime indeed has the very same problem, even worse because the seal proofs are much larger - so consignments are also much larger. Prime also has no way of having a base layer asset like Abraxas, so for Prime this is an unsolvable issue.

[adambor]

So I was thinking about it and turns out we can still have a very good UX of users paying the fee in any token, even with limiting the fee payments to ABTC.

The trick is to do a scriptless atomic swap inside transactions. So you have a liquidity provider that will pay for your fee by his input seal which contains some ABTC, and for this you give him your RGB asset on the client-side.

Here is an example of such transaction, with A sending 10 tokens to B, and using a liquidity provider C to pay the 0.000001 ABTC on-chain tx fee, C gets 2 tokens as a reward for this.

Same could be applied for the case when you have RGBTC and want to send a transaction. So for a user there is actually no point in having any ABTC, as he can just use this system to send RGBTC to a liquidity provider who then pays for his transaction fee.

I imagine in the future there will be many liquidity provider, basically anyone with a lightning network node can become one, so centralization and transaction censorship will not be an issue, off-chain privacy is handled on RGB by blinded amounts.

[cryptoquick]

Nice! That could work. So long as miners get their ABTC.