I would say money because it influence all other things. The good news is we can have all three.

I have a thread here where I outline why I think this is so cool. Here I've copy pasted it with slight modifications:

At its core it's "just" escrow software. It helps you create a 2 of 3 multisig where the escrow agent has 1 of the keys and the buyer and seller have the other two. But it's particularly cool because it takes that to the next level: it supports frost multisig, which makes it one of the first bitcoin apps to actually use taproot for what it was meant for, and it's also designed so that users can reuse their bitcoin as collateral in multiple contracts without actually moving it. So you can use this as the basis for bitcoin layer twos.

I also love what they do with their integrated signing device. There's this separate little module that holds your keys and does all of the signing, so the website never has your keys, it just asks this module if you want to sign the contracts, and the module asks you.

I would love to see that piece in particular spun off into its own little app. Too few bitcoin apps do this "separation of concerns" thing where your signing device is separate from the apps you interact with. The signing module could change all that and is worth a lot on its own.

Sovereign Origin asked me the following question on twitter
"This one [the part about using bitcoin as collateral] is not clear. They can do what now? This sounds very interesting!!"

I'm probably butchering this but I think it works like this. There are four people involved in every contract:

Alice = buyer
Bob = seller
Carol = agent
Bitescrow = coordinator

Alice's funds go into a 2 of 2 multisig with bitescrow and she gets a presigned "backout transaction" so that bitescrow never has custody of her funds. Suppose Alice wants to buy a car from Bob for $60k. Alice and Bob must first agree on who Carol should be (their agent, separate from bitescrow), then Alice gets bitescrow to cosign a transaction that would, if broadcast, move Alice's funds (1 btc) from the 2 of 2 multisig into a 2 of 3 multisig, where Alice, Bob, and Carol have the keys.

Now Alice sends Bob $60k "real" dollars (USD, not bitcoin). In the "happy path" Bob sends her the car and everyone is happy so Alice and Bob just cooperatively tell the escrow "nevermind, don't actually broadcast anything." And Alice's money thus stays in the 2 of 2 multisig with the escrow. If there's a dispute, bitescrow broadcasts the transaction putting the money into the 2 of 3 multisig whereupon what happens next is up to Carol, the agent: if she sides with Alice, that means Carol thinks Alice got jipped, so Alice gets her bitcoin back. If Carol sides with Bob, she thinks Alice never sent the USD, so Bob gets Alice's money.

But in the "happy path" Alice's money never moved! It still remains in her original 2 of 2 multisig with bitescrow, so she can reuse it in another contract. Your bitcoin is used as collateral for contracts where you actually send something else (not bitcoin) and only use bitcoin as a fallback in case there is a dispute. This should scale really well, and it's also neat that bitescrow never custodies any user funds. They do have to be trusted not to collude with Alice though.

I think that's the basic model but @BlueSlime or @Tristan can correct my errors.

SRI stands for Stratum Reference Implementation, and is meant to act as the building blocks for the Bitcoin mining infrastructure.

Now imagine someone wants to write a sv2-enabled pool based on SRI. There are infinite different directions they could go, which I will try to summarize in two main ones:

leveraging low-level APIs

Right now, SRI has implementation for roles crates, which do include a "demo" pool. But this is just a dummy project which only exists for the purpose of showcasing how to wire the low-level libraries together (e.g.: crates under protocols, commons and utils). This pool implementation is somewhat opinionated in regards to multiple factors, namely:

• threading model
• error handling
• socket handling
• coinbase management (very simplistic)
• share accounting (basically non-existent)

If someone wants to leverage the low-level libs while writing a production-ready pool from scratch under a different architecture, that is already doable. We believe these low-level crate libs are relatively mature, which is why they are all set as v1.0.0.

This is also likely a path to most pools that already have some codebase, but only wish to integrate SV2 in a modular way. While SRI is a Rust codebase, it provides FFIs to enable integration with other programing languages (e.g.: C, C++, Python).

leveraging high-level APIs

Putting low-level libraries together implies heavy-lifting. That could be time-consuming and somewhat prohibitive to small teams. That is why it is also desirable that SRI provides high-level libraries with building blocks for roles implementations.

That way, if some small team wishes to implement a pool in a specific way, SRI would already provide some building blocks for that. These building blocks would be opinionated with regards to threading model, error handling, socket handling and any other general aspects of the software. The pool team could then implement their own opinionated strategiesfor coinbase management and share accounting, without necessarilty spending thousands of man-hours on wiring together the low-level APIs.

Good question!

The motivation behind it is to get our feet wet with people building on top of our API. It was already possible if you knew how^[1] but not many people used it because it was too annoying (as one @anon kept pointing out) or not obvious that it was possible (?).

Now with this official API key support, more people might be interested in building bots like @hn or @nitter but we don't want to drown in support requests or deal with API abuse (too many expensive requests etc).

This formal API key request is intended to act as a rate limiter: With it, we know who wants to do what and can be more prepared for what's to come. It also limits the access to people who can come up with ideas that make sense from our perspective. So less "opportunistic abusers".

Also keep in mind that there are no guarantees that the API is stable. That's also a reason to limit it since else people might see this as a lot more stable than it really is, build on it without our knowledge and then get disappointed if their code breaks because we changed something on our side.

With this request, we can also establish a direct communication channel for such things or feedback and support.

If you use ~meta to request API access, others can also chime in on the ideas. But you don't have to use ~meta, you can also reach out to us privately via email, Telegram or SimpleX as mentioned in the info message:

https://m.stacker.news/22004

1. copy session cookie from network tab and look up the GraphQL schema in the code or here ↩

As a result, my dad always felt insecure about money, no matter how wealthy he grew.

Sounds familiar. My folks both grew up poor, but my dad was comically poor, rural-living-in-a-shack-and-hungry poor. He has never, ever kicked it, and that mindset has caused a lot of angst, though, ironically, my siblings and I openly discuss how his pathology has also probably been the reason why my folks are relatively comfortable now.

And so, a pattern: the problem giving rise to its own solution, which the problem prevents you from adopting. Kind of lovely, actually, like a big cat that's about to kill you.

I always thought that the role of btc is the same as the role of anything, which is to help you to live a good life. I'm walking the same road with bitcoiners for like half the way, bc there is something important in asking what it means to live a good life, and digging into the defaults society wants to give you. Many of them do not hold up under scrutiny.

But two road diverge half-way through the wood, and I part ways at that point bc btc is not a fetish for me. Stacking is a tool. If my stash ever becomes life-changing in size, I'll treat it the same way I treat my table saw. I get that this will be easier said than done, for some, but I'm sure of my conclusion.

I don't want to miss the starting gun. It only goes off once.