vnprc's avatar
vnprc vnprc@trianglebitdevs.org 3 months ago
I published my first rust library yesterday:
crates.io: Rust Package Registry
 You can test it out in this playground environment:
GitHub
GitHub - vnprc/tx-relay-playground: devenv for tx-relay development and testing
devenv for tx-relay development and testing. Contribute to vnprc/tx-relay-playground development by creating an account on GitHub.
 I think this approach solves the filter debate by dismantling the bitcoin core architecture into separate components. Bitcoin core should be used only for blocks and blockchain consensus. It is bad architecture to combine TX relay and block relay into a single binary with a single peer-to-peer network. It opens the node to many DOS attack vectors. It open the developers to social attack vectors. And it forces unnecessary constraints on bitcoin transactions (mempool policy) that severely limit what developers can accomplish with off-chain protocols like lightning. Why continue down this path when alternatives are available? I intend to continue developing permissionless software solutions to enable sovereign pool operators to meet and exceed the capabilities of large, closed source pool operators.

Replies (3)

waxwing's avatar
waxwing 3 months ago
How does tx relay over nostr help with censorship resistance? Genuine Q, I'm curious.
1 replies ↓
Printer's avatar
Printer GoBrrr@printer.gobrrr.me 3 months ago
Interesting 👀
vnprc's avatar vnprc
I published my first rust library yesterday:
crates.io: Rust Package Registry
 You can test it out in this playground environment:
GitHub
GitHub - vnprc/tx-relay-playground: devenv for tx-relay development and testing
devenv for tx-relay development and testing. Contribute to vnprc/tx-relay-playground development by creating an account on GitHub.
 I think this approach solves the filter debate by dismantling the bitcoin core architecture into separate components. Bitcoin core should be used only for blocks and blockchain consensus. It is bad architecture to combine TX relay and block relay into a single binary with a single peer-to-peer network. It opens the node to many DOS attack vectors. It open the developers to social attack vectors. And it forces unnecessary constraints on bitcoin transactions (mempool policy) that severely limit what developers can accomplish with off-chain protocols like lightning. Why continue down this path when alternatives are available? I intend to continue developing permissionless software solutions to enable sovereign pool operators to meet and exceed the capabilities of large, closed source pool operators.
View quoted note →
vnprc's avatar
vnprc vnprc@trianglebitdevs.org 3 months ago
The llm put that part in. I don't think we have a problem with transaction censorship as it's commonly understood. You can take the view that mempool filters are a form of censorship. I just look at it as flawed design. I intend to use this library and additional tools to enable open source transaction acceleration APIs for open mining pools. With exogenous ecash transaction fees and enough block producers offering this functionality we can do away with on-chain tx fees. It has long been a dream of bitcoin protocol devs to enable anyone to fee bump any bitcoin transaction permissionlessly. I have a plan to accomplish this. This will significantly boost the capabilities of off chain protocols. This could also be a useful tool for pools to apply filters to their mempools to prevent e.g. coinjoins, "spam", blacklisted addresses, etc.
↑