The governance module is key to this discussion. The Taproot Bridge team wants to start this month and that adds a critical time element to the governance module. I think there is a good argument for testing the governance module on Hyperqube_Z, but a key point of discussion is the potential opportunity loss of delaying the governance module, and therefore missing the window of opportunity for this team to move forward with the Taproot Bridge.
Nobody likes feeling rushed. We have to try to be as objective as possible from a number of perspectives. I look forward to learning more points of view.
We are not going to rush the implementation of the governance module. It will be tested and reviewed extensively before being considered for go-zenon. I am confident it will take more than 30 days.
Can you please explain how this work is consistent with Mr. Kaine’s vision for BTC integration? In the past he mentioned xClaim as a basis for BTC interoperability.
Why are you making this proposal and not the developers who are behind this work? Something this expansive and important should be proposed by the people doing the work.
How does this work integrate with Sentinels and the work of the professor?
My general reaction is this implementation is not consistent with Kaine’s limited explanations of how he envisioned the BTC integration and if these devs are serious they need to make a very comprehensive proposal and have an active discussion with the developers here.
Thank you for furthering the discussion. My goal is to move several presently ongoing issues in the NoM, forward. Whether they are approved or not is not my primary concern, but we need to come to some kind of resolution on several matters, rather than wasting away.
Disclosure: I do not have any investment in these proposals.
This is a complementary interoperability solution. It builds on the TSS approach using Schnorr. It’s needed to create vaults on Bitcoin for different purposes: bridging, merge-mining, etc. It’s a proven method to control BTC, Ordinals and Runes on Bitcoin.
I’m going to take the lead in this direction because they prefer to code and not bother with anything else (that’s how we worked for Bitcoin Account Abstraction on Supernova too).
The Bitcoin full nodes bitcoind can run on Sentinels. We need reliable RPC connections to Bitcoin full nodes and Sentinels are already incentivized by the protocol.
who signs messages? Pillars? How do you deal with a changing signature set?
Does this mean you propose the work will include the deployment of sentinels? How do you coordinate this with Prof’s work on UnikernelZ which is intended to run on sentinels also (as outlined in the WP)? And will the sentinel design take into account PoW links?
I think the deployment of sentinels needs to be coordinated with the core developers of the project. Sentinels encompass PoW links, N&T potentially, and UnikernelZ.
How do you bring all these ideas together so the deployment of a sentinel meets the intended design objective?
The team will work on @sumamu’s orchestrator and integrate Bitcoin Taproot support for it. The only thing to add is that we’ll need more than 1/3 of Pillars to secure the Bitcoin TSS vault(s). We can add a few cool things to the orchestrator, too.
I don’t know. We can integrate bitcoind into Sentinels, but we need to figure out how to do that.
N&T is at the consensus layer (Pillars). UnikernelZ is complementary.
A Sentinel specific implementation is currently out of scope for the Bitcoin Taproot bridge.
Thank you for that clarification. My recommendation is that before we add any functionality to the bridge, we improve the existing UI / UX experience. Every new user that joins the project experiences an issue with bridging assets and they each require help in Telegram.
I also experience issues and have reported them in Github.
From my research of N&T it separates transaction dissemination from consensus ordering. Being that Sentinels are the networking layer of the project I assumed they would be involved with transaction dissemination (the Narwhal portion of N&T). But that is a guess at this point.
I think we need to have a deep understanding of how sentinels will work before we assume they take on new network rolls.
This is out of scope for the Bitcoin Taproot bridge project. They can deliver the bridge integration, and they can also cover the frontend required for the bridge interface, so we can parallelize work.
I agree, but again, it’s out of scope for the Bitcoin Taproot bridge proposal. We need a separate discussion to find ways to improve the current bridge UX.
Every NoM node is part of the peer-to-peer layer. Sentinels are just a special type of node.
For the purpose of this integration, they can host bitcoind full nodes. But other than that, the Sentinel implementation is out of scope for this discussion
