CTO/Co-Founder for Bitcoin sidechain project using Elements \ stacker news ~jobs

We are looking for someone to lead the development of a Bitcoin sidechain project using Elements.

This project is named "Sequentia", and it has been described at a fairly high level with a whitepaper as well as a slightly more technical "theoretical paper"; both of which can be found here. That being said, we are still very much open to input on a conceptual level, and development has not yet formally started.

In a nutshell, the core idea behind Sequentia is a Bitcoin sidechain that is optimized for seamless cross-chain atomic and Lightning swaps with Bitcoin. Our motivation comes from the belief that:

The tokenization of financial assets is an important use-case that will indeed require sidechains, because implementations of tokenization protocols that rely on writing inside of (and therefore "tainting") Bitcoin transactions will not ultimately scale for this particular use-case.
However, everyday Bitcoin payments will eventually be best served by non-blockchain L2 protocols, such as the Lightning Network (especially with large channel factories or other solutions to the inbound liquidity problem), and sidechains will consequently become obsolete for the use-case of transferring money (BTC).

The intended result is therefore a UX that’s centered around a standard Bitcoin/LN wallet which can be expanded to include tokens issued on the sidechain, and facilitate peer-to-peer swaps between these and BTC by using DEX protocols and platforms; therefore never requiring a ‘representation’ (pegged derivative) of Bitcoin on the sidechain, but also never polluting the main timechain with data related to the transfer of non-monetary financial assets.

To achieve this, there are (broadly speaking) two important changes that need to be made to Elements compared to its implementation in Liquid:

Anchoring. A consensus rule requiring every sidechain block to contain a reference to a Bitcoin block at an equal or greater height than the Bitcoin block referenced by the previous sidechain block. This means that a reorg on Bitcoin would also cause a reorg on the sidechain, as sidechain blocks would be discarded whenever they contain a reference to an orphaned Bitcoin block.
No Coin. There should be no specific transaction fee currency on the sidechain. Thus, users would be able to propose sidechain transactions to Block Signers with the fee expressed as any amount of any token issued on the sidechain. In the most common expected use cases, transaction fees on the sidechain would ideally be paid as a fraction of the same asset(s) being transferred on the sidechain. For example, one could have a Sequentia wallet containing only USDT, and use it to perform a p2p swap to acquire BTC. Only in the case of more volatile or less liquid assets (for which Block Signers might have no/insufficient demand), would a user possibly need a second sidechain asset in their wallet in order to pay fees.

In addition to the aforementioned optimization for cross-chain swaps between BTC and the sidechain, one of our longer-term goals is to switch out of the Strong Federation consensus model entirely and replace it with a more open consensus mechanism with market-driven incentives. The approach we currently describe in our whitepaper is a type of modified proof-of-stake mechanism, which we call an “open federation”. This mechanism would also further make use of Bitcoin's consensus to ensure sidechain persistence/transaction finality (other than in the case of Bitcoin reorgs). Although such an "Open Federation" would use what could be called a “governance token” to distribute membership in the Block Signing federation, this token would nevertheless not be a “coin” in that users of Sequentia would never need it (unless they want to join the Federation).

While there are important reasons why we currently feel that this is the best way to create the most robust sidechain possible (more on this here), we also recognise that it isn’t required for our Minimum Viable Product, as we believe Sequentia would still be of immense value even using a Strong Federation for block creation. Thus, we're perfectly happy with leaving the "opening of the federation" as a potential future "post-mainnet" upgrade, especially if we can convince members of Liquid's blocksigning federation to also initially serve as Sequentia's blocksigning federation. This results in a shorter time to market, and gives us more time to consider different alternatives that wouldn't involve us issuing a token.

We do not currently have any funding. But we can offer generous equity compensation to anyone able to contribute their time to the project, up to consideration for a position equal to the two current co-founders.

0 sats \ 0 replies \ @aejkohl OP 28 Jan

Update: we are now funded, and in a position to financially reward contributions to the project!

0 sats \ 1 reply \ @anon 3 Jan

I believe what you are proposing can be done already on liquid using some PSET-s (partially signed elements transactions), you just need one more party in the transaction providing the swap service from the asset you hold into L-BTC.

This would work as following:

Pick a swap service provider
Cooperatively construct a PSET as such:

input from the user containing asset A
input from the swap provider containing L-BTC
output to the recipient in asset A
output to the swap provider in asset A
change output of the user in asset A
change output of the swap provider in L-BTC
transaction fee in L-BTC

Both parties verify and sign the transaction

What this achieves is that, a user can send a transaction in asset A to a recipient without holding any L-BTC. The swap provider pays the transaction fee in L-BTC and gets asset A for it in the same transaction.

This can be further decentralized by having multiple parties providing such a service competing on pricing (same as block producers would in your proposed sidechain).

0 sats \ 0 replies \ @aejkohl OP 4 Jan

It is also currently possible to pay transaction fees off-chain on virtually any blockchain using fiat via SWIFT transfers or Western Union payments (as tongue-in-cheek examples) to prospective blocksigners in exchange for them to include your 0-fee transactions in their blocks.

But this is obviously not practical/efficient for large-scale implementation, and especially not as the default/intended user behaviour on a network; the model you propose is only marginally better in this sense (and is worse than the aforedescribed off-chain method in terms of blockspace efficiency)

Furthermore, I think you missed the central part of our proposal, and what makes the "No Coin" principle we described so important in the first place:

We want to optimize the sidechain for cross-chain swaps with on-chain/Lightning BTC. This is achieved mainly through the "Anchoring" consensus rule I described in OP, which is arguably the most important difference that we're proposing over the current version of Liquid.

In other words, the "No coin" principle is necessary mainly because we want no part of the sidechain protocol to be technically dependent on the existence of pegged Bitcoin, so that the sidechain can outlive the usefulness of pegged Bitcoin; but the Anchoring rule is the primary innovation that makes this possible (creating cross-chain consistency between the Bitcoin timechain and the Sequentia sidechain so that swaps and other HTLC don't require burdensome timelocks to plan for edge cases like Bitcoin chain reorgs).