i have been in tech for over a decade, and i have watched the “cool new thing” ecosystems struggle with purpose and then devolve into weird political drama again and again and again
sometimes it’s like “nifty why aren’t you into the cool new thing” and it’s like hello have you not been paying attention?? ive made not being into the new tech thing a personality trait
my blog is called basicbitch.software for a reaaaason
in theory paying with promises is less data than paying to pubkeys, so it costs less to transact
the protocol for doing this hasn’t been fully built + proposed yet; Ark is probably the thing closest to existing
no it’s a reduction in the amount of data you need to write to chain; instead of writing in a pubkey you write in the promise to pay a bunch of pubkeys at some point, in the future
and in fact that bitcoin cant be used for anything else
then you have a promise and not a utxo, which is pretty worthless if you want to use that promise to pay someone else
so people are trying to design ways to pay each other with promises instead
i thought the whole point of using btcpay server was self sovereignty
For all the merchants looking to accept Lightning in their nostr:npub155m2k8ml8sqn8w4dhh689vdv0t2twa8dgvkpnzfggxf4wfughjsq2cdcvg stores, I highly recommend checking out this newly launched plugin from nostr:npub13ljnkd633c7maxatymv3y2fqq8vt3qk7j3tt0vytv90eztwgha9qmfcfhw!
This is a HUGE deal - once you have Blink account and tie it through Lightning connection, not only can you seamlessly accept payments without worrying about channel management and liquidity, but you also have the option to hedge in StableSats USD.
Here's a trailer showcasing the plugin in action:
And then blog post on Blink's website explains all the details of setup and vision behind plugin: https://www.blink.sv/blog/introducing-the-blink-plugin-for-btcpay-server
So far in my own testing everything is working very smoothly; I'll continue to explore and play with the tech, as this has absolute potential for use in all my merchant setups and workshops at the conferences.
Finally - h/t to nostr:npub1y24gz5gwucl79vtv4ctwpysl0r5m4xyzu2rgulnr44ks3t5mt92q4nz2ad who is the coding powerhouse behind the plugin. It's all FOSS, so check out git repo on: https://github.com/Kukks/BTCPayServerPlugins/tree/master/Plugins/BTCPayServer.Plugins.Blink
it says it’s custodial. is that the innovation? 
(anchor outputs changed this; onchain fees for force closes are now optionally held by each node in a separate account. it’s fully possible to be transacting with coins you cant recover if they go onchain due to lack of sats in your “anchor tank”)
lightning protocol devs are again at a pretty prime spot wrt understanding these challenges and trade offs, as theyve been actively building systems with these constraints for the past number of years
The LN network is a very rudimentary covenants system, no body likes it when they have to pay to resolve those covenants onchain (force closes)
and LN has a pretty easy setup for funding that onchain unrolling, given that there’s only two parties and the “liability” of going to chain is (or at least historically was) fully funded
covenants scale bitcoin by making promises to pay you. typically these promises are ones that you can verify because they’re written into the chain
those promises risk becoming “unenforceable” where youve been promised bitcoin that is forever uneconomical to ever claim outright. It’s worth paying attention to the talk about how easy it is to add fees later to different covenants designs, etc. who pays the fees to make good on that “promise” of the bitcoin belonging to you is generally an open question, and the ability to do so (and how) is under active research/exploration right now (imo)
an old theme of layer-2 design is “whos permission do you need to exit”; covenants add the additional question of “how much does it cost to exit”
a lot of the L2 protocols that “use” covenant primitives (in whatever form) rely on the idea of swapping ownership of those promises. how you update the underlying contracts to reflect that changed ownership is where the protocol design comes in
maybe something worth using as a lens when comparing different protocols that rely on covenants “to scale”
vgr wrote an incredible piece about internets and beefs; i fully believe the way out of mooking is learning the primitives a la a Base58 class or something else that gives you hands on experience with the raw stuff
https://www.ribbonfarm.com/2020/01/16/the-internet-of-beefs/
this is why i started nostr:npub1vmpf90hq56wzyxht6teg3llpa74rzcepw9suj5unxl3tph24zd4qgtxhm7
you follow the chain of the mightiest; the contribution of their might to the cause is what makes the chain great, it is what lets it stand the test of time
bitcoin is not a democracy: might makes right.
in technical realms we rely on expertise as might, not debate or public opinion
Dunxen really throwing down “consensus is not democracy” on the TL; I needed this reminder re: expert opinions in the consensus process
quantum computers are clever because in the material world you have to physically explore every path of a problem; the quantum realm of branches moves at a tremendously faster rate comparatively (in path exploration) than materially needing to calculate every state
being able to frame questions such that you can access the branching process of particles is an enormous speed up for searching a problem space
it sounds more complex than it is. general idea is that everything is a state machine, and the quantum realm is where the set of “allowed” state transitions are explored (hence the name branch-ial, they branch furiously)
where the branches actually move is what “matters” (get it? matter/material world)
time is the weird moment of collapse of the branchial to the material (i think, kinda guesstimating)
bitcoin layer twos about to mf-ing thrive ⚡️⚡️