pull down to refresh
0 sats \ 1 reply \ @ursuscamp 28 Oct \ on: DNN: Decentralized Naming Network nostr
If I am understanding this correctly, it is similar to a “phone number” or human-readable bitcoin transaction ID that also has associated metadata? Interesting idea if that’s true.
So the Bitcoin event is connected to the Nostr event because the Nostr events public key is encoded as a bitcoin address right? In essence, while this “adds no burden to bitcoin” in a practical sense it requires multiple transactions for a name since no one uses their Nostr pub key as a bitcoin address. So it would involve:
- a transaction to send bitcoin to the address for their Nostr pub key
- a second transaction to send bitcoin from the key to itself as the “marker” transaction
- a third transaction to send their remaining bitcoin not spent in fees back to their actual main wallet (optional but likely to occur)
When I was originally working on Nomen I also considered using a scheme that involved using a Nostr pub key as a bitcoin address/pub key as well, but I kept hitting this same wall. I ended deciding it was both less costly to Bitcoin and overall less tiresome to the user to just allow them to use any Bitcoin transaction from any address with just an attached OP_RETURN as the anchor. This is actually even easier now since core v30 relaxed op return restrictions, giving more room to create a sane protocol (I originally made some discouraging mistakes in Nomen due to having to work within the 83 byte limit).
Bitcoin has already been invaded by normies and taken over by NGU-obsessed fiat apologists and ossificationists excited about trading nation state shitcoins on a permissioned Lightning network.
The restrictions is what makes them powerful. Those restrictions allow you to remove trust. There are already many types of spend restrictions in Bitcoin, such as multisig or OP_CSV or OP_CLTV.
100 sats \ 1 reply \ @ursuscamp 21 Feb 2024 \ parent \ on: The ICANN Problem, Solved With Bitcoin bitcoin
There is no plan to allow multiple names to "share" a UTXO via a merkle root, nor should there be, IMO. I thought about it, but there are issues with this:
-
There must be scarcity of names. If the goal is human-meaningful names, then there must be some limit on "scaling" them, or someone could just claim every useful name in human speech inside a single Merkle root.
-
Data availability. All ownership data is "on chain" and thus always available. The record associated with a name have more flexible data availability requirements (like DNS records) and are thus available on nostr relays. However, the most important part, ownership, is always available on chain. Unless you wanted to use something like an inscription envelope, fitting a lot of data on chain is not possible. If you store all the names in a merkle root, then the data must be stored SOMEWHERE off chain.
That doesn't mean scaling is impossible, there are multiple ways I envisioned scaling.
The first is via "custodial" sub-domains where someone just issues new custodial names via nostr events associated with your key and you can then issue records against that. That would have a trust model similar to modern DNS.
The next way to scale is via sidechains. Something like Liquid, for instance, has an identical UTXO model to Bitcoin and you could easily issue names on Liquid. However, because of the different block cadence, you can't have the names occupying the same namespace.
So, while "ursuscamp" might be a name on the base layer (Bitcoin), the equivalent name on Liquid would be "ursuscamp.lq" or something like that.
So "mom.ursuscamp.lq" would be at the custodial sub-domain "mom" assigned to the name "ursuscamp.lq" where the ownership information is on the Liquid sidechain.
So it's really quite scalable as is.
I have been in love with the idea of Lightning-specific sidechains for a while. Are there any validia rollups (on Bitcoin or otherwise) which could be a model to look at?
I don't think a good definition of custodian is "can steal your money". Trust and custodianship are not the same thing. Trust is a superset of custodianship.
Imagine you have your gold bullion in your house. Your neighbors know. They COULD shoot you and take your gold. You're trusting them not to. That does not mean your gold is custodial, IMO.
I would be careful to ascribe too much competence to the governments in question. I don't think anyone is looking to use it to distract us for some bigger purpose. These are self-serving parasites, and their biggest concern is to make sure their skins are preserved after the decades of crimes they committed.
This has been building over decades of leaks and small disclosures. It only seems sudden because it finally reached a melting point where it boiled over into the mainstream.
We've exhausted so many options we're beginning to suspect some browsers (mainly safari) just clears some of our state which can cause the error.
It's always Safari...
This reminds me a bit of statechains, just eliminating the third party. That in and of itself is fairly cool.
I am not sure cold channels offer a huge benefit over current Lightning channels. They can be used cold, which is certainly neat. But in return an uncooperative close could be massive and there is a time limit.
30 sats \ 1 reply \ @ursuscamp 28 Sep 2023 \ parent \ on: 📢 AMA with gandlaf: Unveiling PROXNUT! bitcoin
Presumably each API call also needs to make a round-trip to the mint, right? This extra latency could be considered a disadvantage.
Fungibility is subjective. Some things have characteristics that make it harder to tell individual units apart, and thus people will be more likely to treat them as fungible.
Just so everyone is aware, he's not advocating for fungible tokens. He's opposed to fungible tokens.
He's trying to propose a fungible token standard that's better than BRC-20. BRC-20 transactions leave little dust UTXOs littering the chain, and it's a major reason for the UTXO bloat since Ordinals came out. He's merely trying to propose a system that he hopes is better and will overtake it, for the sake of the UTXO set.
Regarding UX, it can definitely be improved. I want to implement a Nostr bot and/or website that can accept a Lightning or ecash payment and make the onchain tx for you. Then you just need to sign a Nostr even to publish records.
There is a transfer mechanism described in the spec. No tooling currently exists to create them and I wouldn’t suggest constructing them manually if you’re technically inclined.
I think they’re likely to change to something described in issue 6 above. The currently envisioned transfer is brittle and necessitates users keep events signed by previous owners. But we can fix that.