nostr:nprofile1qqsvnvvlln2ru6jlyweayugxecv7ftfdlzd6zqca63sh7x6ercggjegpp3mhxue69uhkyunz9e5k7qg4waehxw309ajkgetw9ehx7um5wghxcctwvszvprka nostr:nprofile1qqs0m40g76hqmwqhhc9hrk3qfxxpsp5k3k9xgk24nsjf7v305u6xffcppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0d2j30f nostr:nprofile1qqs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4spz9mhxue69uhkummnw3ezuamfdejj7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0ege3s8 nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagppemhxue69uhkummn9ekx7mp0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshsud80st nostr:nprofile1qqs8k0mcqd6sw3h524qn5gslszt9am9knmes3uh268dgnnpv3yfwj6qpr9mhxue69uhhqun9d45h2mfwwpexjmtpdshxuet59uq3camnwvaz7tmjv4kxz7fwdp5kw6rvd9nksar9wghxxmmd9u5jtddh and others.
What about solving op_return with nested PoW? In this case all tx would be mini blocks, with difficulty scaled down from the network difficulty and then multiplied by the bytes in op_return. It should effectively scale the cost of larger arbitrary data in op_return by making miners have to choose if the fee is worth the PoW for the tx and scale the cost of larger blobs.
seems like your goal is to make op_returns cost extra for their creators, and I suspect there's a simpler way to do that: create a rule that says transactions containing op_returns must have a feerate X% larger than the average in that block
the great thing about app-layer development in bitcoin is, you don't have to reinvent the wheel
you *get* to
Does "measure twice, cut once" have an equivalent in software design?
Something like "Spec it out twice, code it once"
This an excellent facts-first reply to nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dswvjvel and other people advocating for spam-friendly mempool policies https://x.com/cguida6/status/1973826768084914238
Why use L1 addresses as the identity? Why not use nostr keys as the identity? It seems like "identity" is what nostr keys are supposed to be, and bitcoin addresses are definitively not supposed to be that
in my experience, nostr users are almost all bitcoin maxis, and almost all bitcoin maxis have a self custodial lightning wallet. Therefore, I expect almost all nostr users to have a self custodial lightning wallet. And, as everyone in this thread is a nostr users, QED.
I suspect every person in this thread has a self custodial wallet
> Seems like the bigger nodes get the more funds are controlled to me
Not to me
I do not know which wallets have more capital in them, custodial ones or self-custodial ones
but even the largest possible routing node is not centralized because it does not control user funds
in other words "lightning is maximally decentralized"
what feature of bitcoin would an ERP system use? if the idea is just "Oracle NetSuite, but denominated in bitcoin," I think Netsuite already has you covered: bitcoin is supported as a foreign currency option, and it will handle all the currency conversions for you.
hmm...so a webstore, but where you can say: 10% sats off if you (1) follow me on nostr (2) I follow you back (3) we've interacted more than 5 times there
if you think Lightning relies too much on hubs, I don't think you will like Ark
personally I don't mind the hubs as long as they don't control user funds
> If you send, they need to trust you, if you receive, you need to trust their mint
I think you misidentified where the trust assumptions enter in. It's not related to whether the button you pressed is the Send button or the Receive button, what matters is whose mint holds the money. If your own mint holds all of the money, you don't need to trust anyone, regardless of whether the button pressed is "send" or "receive." I think it gets interesting when each counterparty holds their own money, and interactions happen via atomic swaps.
You might say this is "essentially no better than if you used lightning," but if you think that's a put down I disagree. Lightning is very powerful but hard to work with, partly because different backends have different APIs. Cashu unifies everything: regardless of what backend it runs on, it bolts a unified scripting interface on top, and thanks to this interface, I think it's easier for coders to programmatically authorize payments from a user's node, process refunds in the event of a protocol failure, and perform swaps.
Also, it's very useful for prototyping. Perhaps some of the things I mentioned can't be done on cashu without introducing trust assumptions. But since cashu's scripting language is similar to bitcoin script, that means if you can build a prototype on cashu, then even if it's partially or fully custodial in that environment, you can then copy the design directly into bitcoin script and make a self-custodial version. After that, it's probably wise to lift it onto layer two, but cashu gives you a taste of that in the meantime, which is very meaningful for early adopters, testers, and scientifically minded folks.
I do not fully understand what you're asking but if you're thinking about brainstorming an idea in a kind of stream of consciousness style post, I'm all for it