pull down to refresh
0 sats \ 0 replies \ @ursuscamp 15 May \ on: Are you ready for the normiepocalypse? meta
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 \ 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.
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.
/6: For me personally, while this solution is interesting, I wouldn't be a fan of it. I think a better solution would be to just have high-profile entities to just mention their order of claim. Ex: Someone took "Amazon" and then the actual Amazon that we know comes in and registers, they'd just market themselves as "Amazon:2" or something, and browsers/clients, over time, may suggest a "popular" domain to be pushed at the top and writing the domain and/or highlighted.
What you’re describing here sounds more like squatting prevention. 6 describes putting all of the ownership data on chain so the indexer doesn’t require data from Nostr to maintain a chain of custody.
Am I misunderstanding what you mean?
/7: This is interesting... in terms of decreasing the issue of someone not knowing if a name is shadow-claimed or not, why not, referencing the proposed solution in /6, have a list for those who haven't revealed their claimed name after X blocks (let's say 48 hours worth of blocks of 10 minutes as an example), would be put on that .shadow list (or browsers/clients would do the calc themselves to see if they unsalted their transactions within the X amount of blocks), otherwise it's a valid claim. This might be the smallest compromise to protect people from front-runners and decrease the risk of someone having already taken their name.
Interesting! We could also make it so if they don’t reveal their shadow claim in 48 hours, their claim is invalid, making it impossible to sit on any claim for a long period of time.