Buck is also on nostr đ. Looking forward to the new year chat! nostr:note1zhx7c933vhcqvwzs7f3sx5v7aphpsnnaq6l46tdyhnldjfd2wggq2yp0dy
Are there any relay implementations that have NIP-44 support? The NIP04 standard says it's been deprecated in favor of 44 but there don't seem to be any relays that support the favored one.
He is the psyop manifest
If you're in Austin TX this week for SXSW or the Bitcoin Takeover, join us at the Bitcoin Commons this Thursday for Austin Bitdevs!
We're breaking our long running streak of the third Thursday of the month to take advantage of a busy week of Bitcoin events here in the Bitcoin capital of the world in the Lone Star state! https://www.meetup.com/austin-bitcoin-developers/events/296945954/
It could be but BIPs are a lot of work, more political than technical and it doesnât need a BIP to work. Just broader understanding and adoption.
The protocol for blinded xpubs is actually pretty straightforward and easily done today (higher risk of losing funds though if you donât know what youâre doing).
Hereâs the original proposal and recovery examples using even something like caravan today: https://github.com/mflaxman/blind-xpub
Thatâs whatâs important about having a good domain model- it makes it easier to reason about code paths that should already be available to you.
Our current, rigid BIP32 path standards and the way many signers implement them are the real limiting factor to broader blinded xpub adoption.
The protocol for blinded xpubs is actually pretty straightforward and easily done today (higher risk of losing funds though if you donât know what youâre doing).
Hereâs the original proposal and recovery examples using even something like caravan today: https://github.com/mflaxman/blind-xpub
fun fact: looks like npm utilizes 402 status codes in responses if you try and publish to a private package!
(no lightning/L402 support though đ)
Ok, so I wasnât the only person in the world that saw and recognized nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m wearing a satoshi shirt. nostr:note1fsdgkvx30gm98q7p0h7p0dc79ufz2ts453ns00ct6k88xe8zhdzqvtarkk
Unless Iâm missing something, you canât just âallowâ sign events with the key offline. Maybe thereâs some delegation protocol, but you need access to the nsec to sign every message. Signing canât happen without access to the private key.
The closest we have is something like the VLS (validating lightning signer), which is a dedicated, internet enabled signing device that supports encoding permissions about limits on what the device will sign. Unfortunately it still falls victim to the problem that your private keys are still exposed to the internet.
Every message you send in nostr is signed with a private key. Iâm assuming youâre not signing that much with your bitcoin seed.
Lightning keys are hot which is why you should only keep as much as youâre willing to lose in lightning.
Another reason is privacy. You donât really want to associate your life savings with your social identity.
this piece is kinda focused on NFTs, but i think it poses an interesting question
https://niftys.substack.com/p/is-it-ingroup-or-is-it-dynasty
Nice. I also like the somewhat related concepts of Veblen goods and shibboleths. Both hard to acquire signals that you are part of a group (the former through cost and latter through language, originally literally unable to pronounce a word).
Good walk-thru as well of how we as a community that are custodians of an open, decentralized, and immensely valuable protocol need to have reasonable expectations. Lightning didnât fix all of bitcoinâs problems, but it also was necessary to get the MVP out, in no small part b/c deploying proof of concept is how we learn.
We should look towards the future with the same clear-eyed practicality. nostr:note1nqrjka082g9fdheazxt225lza222v74z6dvhg9e7hpppj5slj9lqjm2hjg
Yeah and honestly if it hold for too long that basically means bitcoin has failed since the majority of people still have zero familiarity with it still and those are the ones that still need to be onboarded for it to be worth it.
I really like this heuristic for evaluating bitcoin upgrades by Erik Aronesty from the mailing list:
> "Best tool for the job" is not the bar. "Safe for all" and "useful for
some" is the bar.
Wen nostr:npub1mutnyacc9uc4t5mmxvpprwsauj5p2qxq95v4a9j0jxl8wnkfvuyque23vg integration carman?
Question was my comparison to stacker news so makes sense. Nice thing about nostr is you donât have to use the custodial options. Problem with nostr is the complexity and âanalysis paralysisâ that comes from too much choice.
Nope. There will always be new bugs, new attack vectors, and new optimizations. Not to mention human inclinations.
Definitely not my word!
Plenty of custodians are voluntarily chosen. Most ppl voluntarily choose Coinbase. Thatâs more of a concern if youâre choosing a custodian/federation because you have no choice.
The more important thing is if you can leave the federation in a censorship resistant way. If you canât leave when you need/want, then the voluntary nature in which you entered is irrelevant
A bunch of people have been shilling [Liquid](https://liquid.net/) has a scaling solution with on-chain fees on the rise. I wanted to take the time to breakdown why this is a fool's errand and there are better ways to go about this.
Liquid is based on [Elements](https://github.com/ElementsProject/elements) which as they claim in their README is `a collection of feature experiments and extensions to the Bitcoin protocol`. Liquid is just another blockchain. It is a fork of bitcoin with a few fancy things added (Tokens, CT, covenants) and bundled together with a 1 minute block time, federated custody, and some blockstream branding.
Blockchains do _not_ scale. As we are seeing today, the bitcoin blockchain does not have enough throughput for everyone's transactions. This is for good reason, keeping the cost of running a full node low is a priority, this was one of the main reasons the blocksize wars were fought.
So why does Liquid exist? People lately have been touting it as a way to ease fee pressure but in my opinion this is a fool's errand, no different than people back in 2017 saying to use litecoin because fees on bitcoin were too high. Liquid is just a fork of bitcoin, it has the exact same scaling problems and the only reason it has smaller fees is because it is never really been used. For now, it can work as a temporary stop-gap (essentially finding arbitrage for fees), but building actual infrastructure on top of liquid will run into the _exact_ same problems as on-chain bitcoin.
The problem is that Liquid is trying to use [trust as a scaling solution](https://trustisascalingsolution.com/) but did it in a completely inefficient way. When you are trusting the 11-of-15 multisig, you don't need all the benefits that a blockchain gives you, everything is dictated by the functionaries anyways. The problem is if liquid gets any meaningful amount of users it will also end up with huge fees and we'll be back to square one because Liquid's architecture didn't actually leverage any of the trust tradeoffs it took and just inherited all the same problems of on-chain bitcoin.
There are real solutions available. Lightning is the obvious alternative but it does have it's own problems, I think a lot of people have been seeing the problems with small scale self-custodial lightning, it is extremely hard to scale. This is why I am extremely excited about [fedimint](https://fedimint.org/). Fedimint has almost the exact same trust model of Liquid (a federated multisig) but is built on a much better architecture that actually allows for scaling. Fedimints don't have a blockchain but instead operate as a chaumian ecash mint. This allows for them to do actually innovative things instead of just being bitcoin plus a couple features. There isn't a block size, instead the transaction throughput is just gated by the processing power of the guardians. Smart contracts are limited by having to do everything on-chain with bitcoin script, they are pure rust code and allows for all sorts of crazy things. And it all still interoperates with Lightning, essentially giving a Wallet of Satoshi with way less rug-pull risk, tons of new features, and is extremely private.
All this said, it is sad we aren't talking about self-custodial scaling solutions. Today the only real one is Lightning and with current fees, it isn't reasonable unless you have a few million sats. The problem is that this is just inherently a limitation with Lightning. Lightning is excellent when you have high value channels and can make payments across the network, but it does excel at "pleb nodes" where one guy puts 100k sats to try it out, this comes with too many limitations with paying on-chain fees and needing to have reserves to pay future on-chain fees. However, this is potentially solvable. Lightning has solved the problem of scaling payments, where if you have channels, one on-chain transaction can represent many actual payments. What lightning did not solve is that one utxo still represents one user, and this is the limitation we are running into today. Currently the only way we solve this is using a multisig sig (Liquid and Fedimint), but we can solve this in a self-custodial way if we activated covenants. Covenants essentially let us give fine grained control of what is going to be spent from a UTXO before the UTXO even exists. Currently, there are a few proposals (CTV, APO, TXHASH) all with varying ways to do it and different tradeoffs, but imo something like this is desperately needed if we want any chance to scale bitcoin in a self-custodial way.
Bitdevs should be fun this month đ