Template Providers and regulatory capture

[plebhash]

We recently merged #54, where we imbue braidpool-node with the ability to listen for new blocks via ZMQ and fetch new templates via getblocktemplate RPC.

This design is taking Braidpool's architecture in a direction where braidpool-node is essentially a separate entity to bitcoind and relies on it as a Template Provider. Before braidpool-node is ossified with this design, it's important to discuss its potentially negative consequences.

As it was discussed by @mcelrath and @TheBlueMatt on the #template-distribution channel of SV2 Discord (perhaps not 100%, but with some degree of agreement), Template Providers are inevitably bound to become a target for legal attack vectors coming from Nation-States trying to impose censorship and compliance (e.g.: OFAC).

One alternative could be to design braidpool-node such that it taps into the mempool itself. It would require braidpool-node to join the p2p communication with other bitcoind nodes and participate in the tx gossip like a regular node.

(to clarify: I'm not arguing to literally re-write braidpool-node as C++ code, I'm sure this could be achieved with Rust crates)

In practice, it would be the same as if braidpool-node and bitcoind were always running on the same localhost. But there wouldn't be any option to do this differently (e.g.: braidpool-node and bitcoind on separate machines), because the code simply wouldn't allow for that configuration. The only way for a pure/unmodified braidpool-node to create a template would be to pick transactions straight from the mempool, without any middleman whatsoever.

I do wonder if this design wouldn't make whoever is running braidpool-node vulnerable to regulatory capture, but I'm not a lawyer so I'm not equipped to answer this question.

[mcelrath]

FWIW I don't think that discussion has all that much relevance for Braidpool though people may find it interesting. Using a local getblocktemplate (on localhost) and not providing the ability to filter ordinals/inscriptions/addresses) is the answer to avoiding regulatory capture and censorship. It's the SV2 plan to outsource templates that could lead to regulatory capture by having "compliant" template providers external to the miner. This will result in less decentralization and I don't think their argument about there being lots of template providers to choose from works. No one wants this legally risky responsibility and it's likely to collapse into only one global template provider IMHO.

I have never proposed that Braidpool should outsource templates in this way. The template will be constructed locally by each miner either by braidpool-node or bitcoind. If we do that this isn't a concern.

One implication though is that I don't think the Braidpool UI should offer any kind of tx filtering at all. If we make filtering an option, everyone will do it out of an abundance of legal caution, to the detriment of the network.

[plebhash]

One implication though is that I don't think the Braidpool UI should offer any kind of tx filtering at all.

Sure, I'm not advocating for that.

The template will be constructed locally by each miner either by braidpool-node or bitcoind.

The second option on this phrase is the main issue I'm trying to point out. By having braidpool-node to rely on bitcoind for templates via getblocktemplate RPC, we are already creating the option to outsource templates.

Sure, we could simply assume the miner would run both braidpool-node and bitcoind locally. But SV2 design takes a similar assumption, and if I understood your argument correctly, that should not be considered a safe assumption: the simple fact that the miner has the OPTION of fetching templates from a 3rd party bitcoind creates the slippery slope that would inevitably end up in regulatory capture.

Perhaps the wording on my original message was a bit confusing. In summary, what I'm saying is: each braidpool-node should not receive templates from one specific (aka centralized) bitcoind node via RPC. Rather, braidpool-node should receive txs from random peers via p2p gossip with bitcoind nodes, and then build the template on its own (without filters, as you pointed out).

[mcelrath]

In my opinion we will have to do what you describe out of necessity (because getblocktemplate will be too slow). That is, have braidpool-node keep its own mempool (whether by pulling from bitcoind or using or own faster p2p relay) and build its own block template.

A simple way to do this is to mine individual bitcoin txs in beads. The set of selectable txs are those that have already been mined in an ancestor bead. This has a knock-on effect of providing "weak confirmation" of txs to the sender.

Now because all txs are known and already agreed upon by DAG consensus, before a bitcoin block is mined, we can do fancy things like fast set intersection and differences just using txids, thereby validating blocks very very quickly and constructing new blocks very quickly. We can use libbitcoinconsensus instead of bitcoin's RPC.

[mcelrath]

By not relying on getblocktemplate we also kill the attack vector of outsourcing the bitcoind instance to some "compliant" node that is censoring. It's all in braidpool-node and if you don't like the policy there you'll have to modify braidpool-node.

In the long run, if braidpool-node subsumes all functionality in bitcoind it could become the de-facto definition of bitcoin. (This is called a "feather fork")

[pcfreak30]

I wanted to comment on this in hopes that this is kept in mind while designing this project.

1st, my high-level view is this software would replace P2Pool. To that end, I expect this will get forked for child UXTO chains. I'm personally involved in 2 UXTO networks in Golang and JS atm.

I would like to see the software have design choices to adapt to other UXTO/BTC-sibling chains easily. Many have a BTC-compact RPC API. But some also don't. This effort is a possible solution to a broader problem with UXTO mining centralization.

If there is 0 interest in enabling this to be adaptable (including different hash algo's), then it will just mean intentionally making it harder for the wider community.

I just thought I would bring this up, given some of the technical discussion around P2P networks and mempools.

Kudos.

@mcelrath