SRI Translator Proxy compatibility matrix #1186
Comments
plebhash
added
translator proxy
|
We did have a matrix with our early release (way pre 1.0.0), but a lot has changed, and I am unable to locate that doc in our drive. I am not sure if battle testing is a proper term here, but having a compatibility matrix would help. I think the end-goal here is to test on as many miners as you have and also set up a system where any community member can contribute to. An easy way to keep a track of compatibility could be a GitHub issue which has an owner that maintains, and testers could simply leave a comment once they test with a particular device/firmware. One example of how we conducted tests with uppercase Bech32 on BTCPay. btcpayserver/btcpayserver#2110 Having a tracker issue would not only help with an easy way to provide feedback, but also help with cross-posting in manufacturers repos and advocate for compatibility. |
plebhash
changed the title
that's a better path indeed we should just keep editing this issue description as we make progress on this effort this dynamic approach is probably easier than having to approve and merge multiple PRs that are modifying |
plebhash
changed the title
plebhash
changed the title
|
in June 2024 I rented a it did not work with tProxy right away, which was reported on #964 and fixed on #965 as a patch to the parsing logic converting stratum/protocols/v1/src/methods/client_to_server.rs Lines 311 to 340 in d0970a8 as we work on the compatibility matrix, we should pay special attention to how each machine is sending the |
|
While you're at it, can you test the machines with ( |
yea we deployed a dedicated signet for this, more details here: #1274 (comment) |
|
I was able to see #1173 on System Logs of WhatsMiners while mining on |
this is however non-blocking, meaning that despite these error logs on the device firmware, it can still mine with tProxy on mainnet |
|
the only firmware that really caused trouble was BraiinsOS (BOS) the tProxy logs had some error messages that deserve more investigation this is however low priority, since (assuming noise incompatibility with SRI gets solved) BOS is perfectly capable of doing Sv2, and therefore connecting it to a tProxy is not a hard requirement |
this is not an issue with the translator but with the miner. That send non stratum messages trying to contact the pool I guess. |
@jakubtrnka do you have some insights on this issue here? I remember the first time we noticed that was about 1 year ago |
SRI Provides a Translator Proxy (tProxy). It translates SV1 traffic into SV2. It is a key component for SV2 adoption in the Mining Industry.
Different SV1 firmware flavors can result in different edge cases. It is strategically important for SRI tProxy to cover the most popular SV1 firmwares in the industry.
@GitGab19 and I will spend 3 weeks in Thailand for a Residency in BOB Space (Dec 1-20)
we will have access to a wide range of SV1 Mining Devices there
we should take that opportunity to battle test SRI tProxy
as an outcome of this effort, I propose that we add a matrix of device support to
roles/translator/README.mdsomething like this:
if the number of compatibility bugs is too big for us to be able to fix everything during the time we spend there, we will need to make compromises, which will mostly consist of:
The text was updated successfully, but these errors were encountered: