Block Template Validation Service about bitcoin-verde HOT 7 CLOSED

great idea to introduce the "funding wanted" label.

from bitcoin-verde.

This is a great idea.

Might be hard to deduce the cause of the invalid block from error strings as I imagine they might different from each implementation and may not even remain constant over time.

Hopefully the code for this will be open source a miner that doesn't want to rely on a third party can use it themselves.

from bitcoin-verde.

Very much like this proposal.
Had a look through, and not quite clear yet, but possibly subject to Solution Milestones "1. (a) Define ..." is how to interpret Solution Overview "(5) The service then responds to the requester if any node finds the template invalid."

The phrasing in the overview suggests a response only if a validation error occurs.
Presumably this isn't really intended like that but just a simplification for proposal purposes?
As I would still expect the TVS to respond if all was good, otherwise one cannot be sure...

I'd suggest as well that there should be a setting, possibly negotiated or announced, for the TVS to return a result set within a maximum agreed amount of time.
More concretely:
The result set might contain something like a Valid//Invalid//Indeterminate for each implementation it queried.
"Invalid" being accompanied by the node's error message / code.
"Indeterminate" included because a node may return unexpected information, or deterministically or nondeterministically crash without returning a result to the TVS.
In both cases no clear implication could be made on the validation of the template.
If a node fails to respond in time before the TVS has to provide its results, then its status would also be classed as Indeterminate.

Probably "before any work is performed on the block template" could be modified to "before any significant work is performed on the block template" as miners might start to work while the result is being sought, if the time to gather it is non-negligible. (?)
Then they could just abort if it came out negative in a way that they cared about.

from bitcoin-verde.

This is a great idea.

Thanks, Chris! I hope we can get BCHD involved, and I look forward to getting to collaborate with you guys.

Might be hard to deduce the cause of the invalid block from error strings as I imagine they might different from each implementation and may not even remain constant over time.

Totally agree. I tried to describe the difficulty of essentially falling back to heuristics for this by describing the feature as "best effort". Perhaps in later iterations we can form some kind of standard procedure for communicating this across nodes.

Hopefully the code for this will be open source a miner that doesn't want to rely on a third party can use it themselves.

100% yes. The word "service" is more technical than anything else; what I mean is it's a standalone application. We want to leave the decision up to the pools/miners to run their own or if they want to rely on a service they don't control. I see benefits of both, so it's intended to be able to do either.

from bitcoin-verde.

Very much like this proposal.

Thanks, freetrader. I'm happy to have your support on this.

Had a look through, and not quite clear yet, but possibly subject to Solution Milestones "1. (a) Define ..." is how to interpret Solution Overview "(5) The service then responds to the requester if any node finds the template invalid."

The phrasing in the overview suggests a response only if a validation error occurs.
Presumably this isn't really intended like that but just a simplification for proposal purposes?
As I would still expect the TVS to respond if all was good, otherwise one cannot be sure...

It's just a simplification. Basically, the service acts as a web service with a request/response mechanism. Every request will have a response. The specifics are going to be complicated to define of course, especially since the rate in which template blocks are updated/validated can be quite frequent, and validating a block is usually nontrivial. So the service may end up having a queue/webhook callback mechanic to it instead of a serialized response. I think that's ultimately going to be a decision we make once we have idea of load and throughput.

I'd suggest as well that there should be a setting, possibly negotiated or announced, for the TVS to return a result set within a maximum agreed amount of time.
More concretely:
The result set might contain something like a Valid//Invalid//Indeterminate for each implementation it queried.
"Invalid" being accompanied by the node's error message / code.
"Indeterminate" included because a node may return unexpected information, or deterministically or nondeterministically crash without returning a result to the TVS.
In both cases no clear implication could be made on the validation of the template.
If a node fails to respond in time before the TVS has to provide its results, then its status would also be classed as Indeterminate.

This is an excellent suggestion, and it aligns itself well with the above consideration regarding the nonfunctional requirements around throughput. I'd probably presume a node crashing due a template block would be treated similarly as "invalid", but calling out more specifically (via a mechanism like the "indeterminate" idea you suggested) would be more useful.

Probably "before any work is performed on the block template" could be modified to "before any significant work is performed on the block template" as miners might start to work while the result is being sought, if the time to gather it is non-negligible. (?)
Then they could just abort if it came out negative in a way that they cared about.

Absolutely. I expect the miner/pool to make this decision ultimately. It'd be equally plausible they'd just mine an empty block or whatever previous job they were on if still valid, too. The same decision making ability is up to the miners/pool as well in regards to what they do in the case the template would be considered invalid between the network. They could switch to another node and use its template instead, or they could again mine an empty block, or they can attempt to exclude any problematic transactions, etc. Lots of options, and I expect different miners will have different opinions here, and I look forward to hearing their perspectives and thoughts.

from bitcoin-verde.

This issue was funded in our flipstarter campaign and work it has begun: https://verde.flipstarter.cash

from bitcoin-verde.

Bitbalancer code is complete and we are in conversations with mining pools to deploy the bitbalancer in a limited capacity. The code and product may be found here: https://github.com/softwareverde/bitbalancer

from bitcoin-verde.