CB-1Q23 : Decentralized Mining Pool (#790) #821
Replies: 9 comments 1 reply
-
The Gitbook with the information related to the Decentralized Mining Pool will be here: |
Beta Was this translation helpful? Give feedback.
-
Milestone 1 completed
@will-at-stacks |
Beta Was this translation helpful? Give feedback.
-
Congratulations on the well deserved grant Stacks Degens! 1 or 2 questions below 🙏 When the signature aggregator publishes the TX, it unlocks the amounts directly from all participants into where it needs to to be committed for PoX? Thank you for taking the time! Best of luck with the implementation, mining pools are eagerly anticipated by our community! |
Beta Was this translation helpful? Give feedback.
-
Milestone 2 completed
@will-at-stacks |
Beta Was this translation helpful? Give feedback.
-
Milestone 4 completed - Front End
@will-at-stacks |
Beta Was this translation helpful? Give feedback.
-
Update: We built the front-end and will place it on testnet and host it so testers can see the application live. The next major steps: We are approximately 65% done with everything. Next major step port over coordinator and signer code for miners ( M3 ) - end of next week |
Beta Was this translation helpful? Give feedback.
-
The details and references to code in order to easily specify the statusGitHub - degen-lab/stacks-pools at develop
GitHub - degen-lab/core-eng at fund-script-both-ways
IntroWe have finalized overall the transactions integration for the funding part, the communication is through the relay server at the moment. Based on the request the coordinator sends and the responses the signers send there are multiple flows created. ( good case + bad actor cases ) FROST signature problemThe p2tr signature from the FROST is signed by all participants but on broadcast it gives an error for invalid signature. (from this repo implementation https://github.com/Trust-Machines/stacks-sbtc) Is there a different one that should work? Expected flow (steps 1 to 5):Flow Details:
The transaction you should see printed (witness content might differ):
Steps to reproduceEach of these actions should be performed in different terminals as they are required to run concomitantly. They should be performed in the order listed below.
cd sbtc-ops/clarinet
clarinet integrate
cd relay-server
RUST_LOG=info cargo run --bin relay-server
cd degen-superior-signer
RUST_LOG=info cargo run run --id 1 --config conf/signer1.toml
RUST_LOG=info cargo run run --id 2 --config conf/signer2.toml
RUST_LOG=info cargo run run --id 3 --config conf/signer3.toml
go to http://localhost:8001/rpc-terminal (if you’re prompted for username and password, they are both generatetoaddress 101 bcrt1phvt5tfz4hlkth0k7ls9djweuv9rwv5a0s5sa9085umupftnyalxq0zx28d
generatetoaddress 101 bcrt1pdsavc4yrdq0sdmjcmf7967eeem2ny6vzr4f8m7dyemcvncs0xtwsc85zdq
generatetoaddress 101 bcrt1pa4w2alr6x7tuxwg7anpep90rzn09sxhwppxvq9xt99p20lwqmlcqz9q8e3
RUST_LOG=info cargo run --package degen-superior-coordinator --bin degen-superior-coordinator -- --config ./conf/coordinator.toml --signer-config ./conf/signer.toml dkg-sign Stacker DBGeneral info from presentation
How we would use itStore cryptographic data in StackerDB for communication between coordinator and signers (notifier and participants). Context and questionsI think we would need to read from and write to it in order to facilitate this between the notifier and participants. How would the participants be supposed to know how to listen to the events written by the notifier and vice versa? The notifier has to communicate in a channel where it would only receive events from the participants that are in the smart contract in order to only track their actions (and not random bad actors trying to mimmick them). How could this communication part be limited to only the smart contract participants? Are there any implementations of Stacker DB in other applications that have a similar flow? Is it integrated in the Signers in https://github.com/stacks-network/stacks-core? (extra context, the participants and notifier run their own stacks and bitcoin nodes) References |
Beta Was this translation helpful? Give feedback.
-
UpdateFor the communication and signing layer, we’ll have to wait for the Nakamoto 3.0 version of the signers’ communication and the new signature that is proposed in SIP-025 (the second iteration explained here ). As mentioned in the SIP, the first iteration adds data to block headers, which isn't viable for mining pool participants to follow. |
Beta Was this translation helpful? Give feedback.
-
@BowTiedDeployer
This discussion thread should be used for all payment requests for your grant.
Please follow these steps:
Beta Was this translation helpful? Give feedback.
All reactions