Hey,
3 questions please: -How does the Lightning part works (fully custodial, via a LSP like Phoenix, non custodial possible ?) -The platform to trade Digital things require an account, isn't it possible to login by signing something from our BitMask extension ? -Is Carbonado an IPFS like storage system to store the data from NFT or whatever its called on RGB ?
Thanks
  1. We run our own LNDHubX server in the cloud, though we're working to add Fedimint support to BitMask Core, and RGB support for Fedimint.
  2. Yes. We're working on a NIP for Passwordless Authentication, and plan to transition the marketplace to using Nostr.
  3. Carbonado is structured more similarly to the Nostr relay system, but essentially, yes, the intent is to store RGB21 content there. We're finishing up the Carbonado Node now. Currently Carbonado is only used for E2EE of RGB contracts kept within the wallet, since the actual contract data is kept offchain, the only thing onchain is the cryptographic commitment needed to anchor mutable contract data against a single UTXO.
Does that answer your questions? Do you have any suggestions or value judgements from what you've seen so far?
reply
Thanks for your answers.
First of all I'm not a big fan of all of this, I left the eth ecosystem a long time ago cause I was not convinced by the utility of what was built in this ecosystem compared to Bitcoin. But I'm still curious when new things are developed using Bitcoin, and RGB could bring features that even if not as important for mankind as Bitcoin, answer to a certain demand from some people.
  • For the Lightning part, I think it is crucial that people can at least have their own keys through a LSP service that you could run or using a partnership Idk. We are constantly shitting on ETH for their wallets and smart contracts execution depending on Consensys but at least they have their own keys....
  • Nice for the passwordless thing and the nostr move.
  • Ok thanks for the Carbonado explanation. I'm a total noob technically speaking but wasn't there a way to leverage directly nostr to store what you have to store off-chain ? It has already a bit of traction so I guess it's much more decentralized and resilient than Carbonado right now.
reply
  1. That's a good point, and we're also very excited about LDK. When they release PTLCs and async payments, hopefully later this year, we can finally have the technology to go down that road. And maybe Ark can help scale that.
  2. ty, if you want to provide feedback, here's the issue (NIP soon): https://github.com/nostr-protocol/nips/issues/558
  3. And yes, kind of, but that's just for metadata, not the data itself: https://github.com/nostr-protocol/nips/blob/master/94.md
I think there's other NIPs in the process of sorting out storage payments and such, but as far as I know, they're not trustless. Carbonado is probabilistically trustless, and it can do this without a blockchain. It uses stream verification encoding to periodically ask for short pieces of a file, 1KB each, in multiple random places that can't be known in advance. I can then verify that along with a checksum against a 32 byte Blake3 merklehash. If we chunk data into 32MB segments, only 1MB of hashes are needed to secure 1TB of storage. Also, the Nostr devs seem pretty adamant about sticking to SHA-256, which is pretty slow these days without hardware acceleration. And finally, the storage providers are paid in sats for the value they provide, and there's even geocoding metadata added as well for georedundancy: https://github.com/diba-io/carbonado/issues/13
As for your original point, you might appreciate some of what I said in this response: #190465
Maybe it sounds farfetched, but it's good to at least build the technology. Who knows if it will catch on or be successful, but it might be useful to be prepared just in case... Bitcoiners are like the doomsday preppers and gun nuts of economics.
And regardless, in the very least, it's good to satisfy the demand for shenanigans without having to tell people to buy something other than Bitcoin. Ideally it wouldn't be through some wasteful, naive, and risky implementation like BRC-20, either.
reply