Super Testnetmetric trend

Also, robosats coordinators currently publish all orders on nostr and update them when their status changes. But there is currently no way for users to signal via nostr that they accept a particular offer. It would be great if you could DM a coordinator with an offer id and say "hey, I accept this offer, send me a hodl invoice," and then take it. Nostr devs, consider making this a thing! Robosats needs more devs!

Super Testnetmetric trend

The average number of contracts processed per day on robosats, since its inception in 2022, is 15. Today they processed 137 contracts. Robosats is running hot today. robostats.supertestnet.org https://image.nostr.build/cc67545c42cc145e7af9b06b96ac85d497155f860c9886f6800995db42562c72.jpg

Super Testnetmetric trend

If you ever feel like your product or service would lose users by providing them with the truth (informed consent), stop and reflect. Honesty is only in conflict with adoption among scammers. If you ever feel that tension, sacrifice adoption, and keep being honest.

Super Testnetmetric trend

I'd love it if people started doing that and then a directory of websocket-compatible bitcoin nodes was created. Maybe they could signal on nostr. Or even signal on bitcoin's p2p layer, using service bits. It's possible to make bitcoin's p2p layer web-friendly - but it takes work

Super Testnetmetric trend

On that note, did you know the websocat tool can expose any TCP port (including bitcoin's) as if it was a websocket port? Yep! It's got a built-in converter that will do the websocket handshake and then directly pipe TCP data to the browser. Consider running it on your node!

Super Testnetmetric trend

A few services make data from bitcoin's p2p layer *available* to browsers, e.g. block explorers, some electrum servers (including esplora servers), and block-dn. But it'd be great if browsers could talk to *any* node instead of placing the load directly on those limited services.

Super Testnetmetric trend

It's annoyingly hard to use bitcoin's p2p layer from browsers. BTC nodes don't understand the handshakes browsers do when they make GET/POST requests, unless you use RPC, which is permissioned. It's cool that Webcoin found a way, but it only works if folks run the bridge software

Super Testnetmetric trend

A project in 2018 called Webcoin built a bitcoin browser wallet in SPV mode Details here: https://github.com/mappum/webcoin To talk to bitcoin nodes, it relied on a TCP->Websocket proxy called Webcoin Bridge Details here: https://github.com/mappum/webcoin-bridge Is anyone running that bridge anymore?

Super Testnetmetric trend

We just entered a new signaling window for bip110 There are zero pro-bip110 blocks in this window so far https://redblocks.supertestnet.org https://image.nostr.build/869e16f1869be735ab5f950adf96bd928fce550546adda14d29e481fa5f5f134.jpg

Super Testnetmetric trend

Connector Swaps mentioned Thanks for the graphical presentation of them, sir! nostr:naddr1qvzqqqr4gupzqnm89qsfay30eumrlfwjputmrstvktg2d4zwmgp09hnnpjg8uvz5qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qq8xy6rxd3cxycq6f6035

Super Testnetmetric trend

> They addressed it by saying that they used secure enclaves The problem with using TEEs (Trusted Execution Environments) is all the trust that's involved. Unless you inspect the hardware itself, you don't know if it's been backdoored; and there is open source software that has been used to extract private keys from "unmodified" secure enclaves. So there's just no way to know the hardware is really doing what its operators promise it's doing.

Super Testnetmetric trend

I give a more detailed comparison of Arkade and Spark here: nostr:nevent1qvzqqqqqqypzqgvra9r4sjqapufyl0vnc4kv4fz70e29em4c655y37vz206f0wt4qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyzeg8fvqtxkdnsc80x30t9s4xjuwx597mghava3yd4glqdmatrtxxs2hd9p Per that thread, it's possible to use Arkade in a manner that qualifies as a self-custodial layer two. But it's not possible to use Spark in that manner (actually, it probably could be, with some design changes; see note below). Since Arkade users have a self-custodial option, I think Arkade is superior to Spark. I also prefer Spark to Liquid for the following reasons: Spark is designed in such a way that, if the server is not malicious but merely shuts down, users all get their money back via a presigned transaction that they already have a copy of. Liquid is not designed that way. If Liquid suddenly stops working, all of its users lose their money; they do not have a presigned withdrawal transaction, not even a timelocked one, so they just have to hope Liquid starts working again or at least that enough people in the Liquid multisig can access their backup keys (if they have any) and start responding to withdrawal requests. It also doesn't help that the members of the Liquid multisig are not known. A few paragraphs ago I said Spark "probably could be [self-custodial], with some design changes." A couple of years ago I came up with a protocol called "insured statechain." This protocol allows a third party, or even a statechain server operator, to insure your ability to withdraw from a statechain, such that if you can't get your withdrawal transaction confirmed (e.g. because the statechain server became malicious and stole the utxo you're trying to spend), you can take a utxo from the insurer instead. In the insured statechain protocol, the insurer's utxo is stored in a 2 of 2 multisig, and you don't pass around the private key to it like you do with a statechain, so there's no risk of the insurer revoking the insurance contract. Spark could theoretically be modified to support this protocol, and then they themselves could sell insurance for a fee, and thus offer their users the option to use their service as a "real" second layer, i.e. in a verifiably self-custodial way. More details about my insured statechain protocol are in this video: https://www.youtube.com/watch?v=k5iT12een1Y