search

stratum-mining / stratum

stratum
https://stratumprotocol.org
Other
224 stars 130 forks source link

Workshop: BTC Prague dev/hack/day #946

Closed plebhash closed 5 months ago

plebhash commented 6 months ago

image

BTC Prague dev/hack/day is around the corner. This issue is intended to keep track of our progress in preparing an amazing workshop.

plebhash commented 6 months ago

Currently, I'm working on two repositories:

github.com/plebhash/sv2-workshop

Contents:

The flake.nix is responsible for:

We expect to get volunteers in the audience. At least one to run a pool, and at least one to be a miner/hasher. We provide a WiFi hotspot environment for networking.

The slides have the necessary steps for both pools and miners to follow.

By following the slides, each audience hasher/miner deploys, on this specific order:

By following the slides, each audience pool deploys, on this specific order:

System Requirements for the audience:

Note: flake.nix is only executed by the Workshop team, not by the audience. There is no requirement for the audience to have nix on their system.

ToDos:

github.com/stratum-mining/stratum, workshop branch

the workshop branch is based on dev and adds:

ToDos:

plebhash commented 6 months ago

I'm also seeking feedback on the slides, which can be visualized on this link

cc @pavlenex @Fi3 @lorbax @GitGab19

plebhash commented 6 months ago

bringing over @Fi3 comments:

it work but need a patch on SRI old bug I tested it lorban will open a PR this is the library https://github.com/demand-open-source/demand-easy-sv2 still unstable I will certanly cange something in the future is for that that is undocumented I want to use it before for something and see where need to be changed this is the proxy that print in json any message that see:

https://github.com/demand-open-source/demand-test-data-collector/blob/master/src/main.rs ProxyBuilder from the library have several method that allow to change upstrea auth key or proiixy pub and priv key ecc ecc that are not used here and as already said the serde serialization have issue with ceratin data structure but they will be fixed very soon this instead can be linked to a TP and act as a client (it use the ClientBuilder) (I still have to add the ServerBuilder to complete the library)

https://github.com/demand-open-source/coinbase-monitor/blob/master/src/main.rs it the print some stats on the received template it say: total coinbase value fee + reward how many tx in the template sum of total value of the tx as you can see from the loc of these 2 examples

build a simple proxy or whatever with the lib is very easy for that my idea is to levarage it to build something nice at prague and then let the people play with it but not sure what if you have some idea

plebhash commented 6 months ago

By following the slides, each audience hasher/miner deploys, on this specific order:

By following the slides, each audience pool deploys, on this specific order:

@Fi3 based on the setup described above, how could we integrate the new Demand tooling into it?

GitGab19 commented 6 months ago

I really like the idea of pushing people that will attend our workshop to behave like a pool or miner! 👍 Ideally we should have like 2/3 pools and many miners, so that it would be pretty engaging for everyone. Great work @plebhash

GitGab19 commented 6 months ago

I just have some questions:

plebhash commented 6 months ago
  • What's the purpose of instructions under "Wanna CPUmine testnet4 tBTC on the SRI community Pool?"

This was an intro for the btc++. I thought it would be a good way to get people interested before the talk started, but the truth is that nobody cared 🙈

I will remove this slide.

plebhash commented 6 months ago

SRI config name are not placed correctly (we changed them some months ago on stratumprotocol.org)

I'm intentionally adding new *-config-workshop.toml files to the root of each role crate.

They are customized with some pointers to guide the audience, and the slides give instructions that are matching these customizations.

They're still on the btcpp-workshop branch, I will port them to workshop branch.

Here's the files on the btcpp-workshop branch:

plebhash commented 6 months ago

Ideally we should have like 2/3 pools and many miners, so that it would be pretty engaging for everyone.

That is a great suggestion, but there is also a very real possibility that we will have very few people engaged through the course of the entire workshop.

I'm not saying that will happen, but on btc++ I had only 1 pool + 2 miners. It was still amazing, since one of the miners was a core dev who got really engaged (@stratospher), so it was still a successful outcome.

My point is that 2/3 pools and many miners is maybe too optimistic (but it is still a good suggestion).

lorbax commented 6 months ago

Ideally we should have like 2/3 pools and many miners, so that it would be pretty engaging for everyone.

That is a great suggestion, but there is also a very real possibility that we will have very few people engaged through the course of the entire workshop.

I'm not saying that will happen, but on btc++ I had only 1 pool + 2 miners. It was still amazing, since one of the miners was a core dev who got really engaged (@stratospher), so it was still a successful outcome.

My point is that 2/3 pools and many miners is maybe too optimistic (but it is still a good suggestion).

Having 2-3 pool would be nice to test the fallback procedure, but for that would be enough to have a MG test doing exactly that. We can deploy multiple miners by ourself if there is no participation.

Fi3 commented 6 months ago

do pool fallback works? if yes and we can use the easy sv2 lib to create a proxy that stand in front of a jds and randomly refuse some declared job so the people would fallback to another pool and eventually will fall back to solo mine. If is not working we can instead create an ad ok jds that we will use for the workshop, that will randomly refuse some declared mining job; and use the easy sv2 lib to create a proxy that connect the client and the pool and switch pool when the jds refuse a share.

Fi3 commented 6 months ago

last year several people at various workshop coded in rust so I guess that someone will engage in creating the proxy, ofc following ours lead.

lorbax commented 6 months ago

do pool fallback works? if yes and we can use the easy sv2 lib to create a proxy that stand in front of a jds and randomly refuse some declared job so the people would fallback to another pool and eventually will fall back to solo mine. If is not working we can instead create an ad ok jds that we will use for the workshop, that will randomly refuse some declared mining job; and use the easy sv2 lib to create a proxy that connect the client and the pool and switch pool when the jds refuse a share.

why do you have suspects that might not be working?

GitGab19 commented 6 months ago

SRI config name are not placed correctly (we changed them some months ago on stratumprotocol.org)

I'm intentionally adding new *-config-workshop.toml files to the root of each role crate.

They are customized with some pointers to guide the audience, and the slides give instructions that are matching these customizations.

They're still on the btcpp-workshop branch, I will port them to workshop branch.

Here's the files on the btcpp-workshop branch:

* https://github.com/stratum-mining/stratum/blob/btcpp-workshop/roles/pool/pool-config-btcpp-workshop.toml

* https://github.com/stratum-mining/stratum/blob/btcpp-workshop/roles/jd-server/jds-config-btcpp-workshop.toml

* https://github.com/stratum-mining/stratum/blob/btcpp-workshop/roles/jd-client/jdc-config-btcpp-workshop.toml

* https://github.com/stratum-mining/stratum/blob/btcpp-workshop/roles/translator/tproxy-config-btcpp-workshop.toml

I meant the name of SRI configs like Config A, B, C and D. They are different from what we have on stratumprotocol.org

GitGab19 commented 6 months ago

Ideally we should have like 2/3 pools and many miners, so that it would be pretty engaging for everyone.

That is a great suggestion, but there is also a very real possibility that we will have very few people engaged through the course of the entire workshop.

I'm not saying that will happen, but on btc++ I had only 1 pool + 2 miners. It was still amazing, since one of the miners was a core dev who got really engaged (@stratospher), so it was still a successful outcome.

My point is that 2/3 pools and many miners is maybe too optimistic (but it is still a good suggestion).

Yeah let's see. Maybe we can tell the person who will guide the workshops in our room to communicate that laptops will be needed so that people can be prepared to follow us

GitGab19 commented 6 months ago

Ideally we should have like 2/3 pools and many miners, so that it would be pretty engaging for everyone.

That is a great suggestion, but there is also a very real possibility that we will have very few people engaged through the course of the entire workshop. I'm not saying that will happen, but on btc++ I had only 1 pool + 2 miners. It was still amazing, since one of the miners was a core dev who got really engaged (@stratospher), so it was still a successful outcome. My point is that 2/3 pools and many miners is maybe too optimistic (but it is still a good suggestion).

Having 2-3 pool would be nice to test the fallback procedure, but for that would be enough to have a MG test doing exactly that. We can deploy multiple miners by ourself if there is no participation.

I think that we can try to do that (actually fallback issue is not fixed yet, see #844) if we have time. According to the schedule, we will have 45 minutes more or less

Fi3 commented 6 months ago

according to my previous message proposal 1 will take max 10 minute to code + 10 minute for explanations of sv2 related thing is very very easy. Solution 2 will be more difficult to implement I guess 20 minute to code or going fast we can do in 10 minute but people will not follow

plebhash commented 5 months ago

according to my previous message proposal 1 will take max 10 minute to code + 10 minute for explanations of sv2 related thing is very very easy. Solution 2 will be more difficult to implement I guess 20 minute to code or going fast we can do in 10 minute but people will not follow

@Fi3 do you want to add slides with instructions for that?

Fi3 commented 5 months ago

no we need to do it live imo

GitGab19 commented 5 months ago

Currently, I'm working on two repositories:

* [github.com/plebhash/sv2-workshop](https://github.com/plebhash/sv2-workshop)

* [github.com/stratum-mining/stratum, `workshop` branch](https://github.com/stratum-mining/stratum)

github.com/plebhash/sv2-workshop

Contents:

* [`marp`](https://marp.app/)-based slides (compiled from `md` to `html` via `marp.sh`)

* a [nix flake](https://nixos.wiki/wiki/Flakes) that automates the deployment of the workshop environment.

The flake.nix is responsible for:

* Serve the slides.

* Deploy a local signet.

* Mine 16 blocks as bootstrapping for the SRI pool.

* Deploy a local `electrs` + `mempool` so the audience can explore the blockchain.

We expect to get volunteers in the audience. At least one to run a pool, and at least one to be a miner/hasher. We provide a WiFi hotspot environment for networking.

The slides have the necessary steps for both pools and miners to follow.

By following the slides, each audience hasher/miner deploys, on this specific order:

* TP synced with our local signet via WiFI

* JDC

* translator proxy

* CPU Miner

By following the slides, each audience pool deploys, on this specific order:

* TP synced with our local signet via WiFI

* JDS

* pool

System Requirements for the audience:

* Linux, MacOS or WSL

* Rust

Note: flake.nix is only executed by the Workshop team, not by the audience. There is no requirement for the audience to have nix on their system.

ToDos:

* [ ]  integrate @Fi3 ideas with DEMAND crates to the workshop instructions on `md/sv2-workshop.md`

* [ ]  finish writing and testing of `flake.nix`

github.com/stratum-mining/stratum, workshop branch

the workshop branch is based on dev and adds:

* `shell.nix`: creates a shell environment that allows for CPU mining on our `testnet4` SRI pool. Intended to be a fun informal way to get people interested in our workshop. Optional.

* `roles/jd-client/jdc-config-workshop.toml`: JDC config for workshop audience. Required for workshop steps.

* `roles/jd-server/jds-config-workshop.toml`: JDS config for workshop audience. Required for workshop steps.

* `roles/pool/pool-config-workshop.toml`: Pool config for workshop audience. Required for workshop steps.

* `roles/translator/tproxy-config-workshop.toml`: tProxy config for workshop audience. Required for workshop steps.

ToDos:

* [x]  add `shell.nix`

* [x]  add config files

Just pushed config files for the workshop: e26b8bf1c0977b7ca84889e426a69d24de395335

Sjors commented 5 months ago

The tproxy command doesn't work for me: https://github.com/plebhash/sv2-workshop/pull/2#issuecomment-2157853465

Sjors commented 5 months ago

On the "known issue on macOS" slide, maybe just spell out the solutions:

On Intel macOS: right click and open (do this once, then close it again)

On native macOS: manually code sign (point to instruction)

Note that the macOS binaries only include the GUI. If you downloaded it using Safari, it's probably going to be here:

~/Downloads/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt

Sjors commented 5 months ago

Maybe also add -sv2port=8442 to the config, so you just need -sv2 in the command.

Additionally, I always encourage people to add maximum logging when getting started:

debug=rpc
debug=sv2
loglevel=sv2:debug

And for macOS, since you're running QT (harmless on other OS):

printtoconsole=1

macOS users won't have bitcoin-cli installed by default. They'll have to use the GUI console (to create the wallet, etc).