Workshop: BTC Prague dev/hack/day

[plebhash]

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]

Currently, I'm working on two repositories:

• github.com/plebhash/sv2-workshop
• github.com/stratum-mining/stratum, workshop branch

---

github.com/plebhash/sv2-workshop

Contents:

• marp-based slides (compiled from md to html via marp.sh)
• a nix flake 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:

• add shell.nix
• add config files

[plebhash]

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

cc @pavlenex @Fi3 @lorbax @GitGab19

[plebhash]

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]

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

• TP synced with our local signet via WiFI
• JDC + coinbase monitor
• 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

---

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

[GitGab19]

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]

I just have some questions:

• What's the purpose of instructions under "Wanna CPUmine testnet4 tBTC on the SRI community Pool?"
• SRI config name are not placed correctly (we changed them some months ago on stratumprotocol.org)

[plebhash]

• 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]

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

[plebhash]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

no we need to do it live imo

[GitGab19]

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: e26b8bf

[Sjors]

The tproxy command doesn't work for me: stratum-mining/sv2-workshop#2 (comment)

[Sjors]

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]

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).