Power outage #1 came and went. Very brief, maybe 10 seconds. But we are likely not done yet.
Potentially the show may be delayed tonight, just fair warnin.
A live battle of the bands is going down right now and the winner is determined by boost amount over Lightning:
6 bands and 4 emcees in different parts of the world, audience scattered across the globe boosting in sats.
Looks like Lightning is dead! Long live Lightning!
Bowl It Up! In which I stay fringe, nostr:npub19ha7tju4teqp3dmwv4p28wrcy9zd6h6hxkg5mwvjrlfycweazpkse2q0fa spots a Pickle Opportunity, The Rev salutes Kittie and callers rip a prank!
You make an excellent point, I also hate the term
They freed Assange I never thought it would happen but they did it
I continue to work on my hedgehog protocol and I've figured out how to add some cool features to it. I wrote a "bridge server" which helps "translate" hedgehog payments into lightning payments, and it works right now, which means a hedgehog wallet can pay regular lightning invoices. I also added support for something I call "unilateral channels."
What that means is, someone can be fully offline, not even talking to you, not even aware of you, and if you have their pubkey you can send them $100 in bitcoin (for example) in such a way that they "receive" it in a new hedgehog channel. You just use their pubkey to create a multisig and fund it with the $100, then send them a string of text containing signatures for the "force closure" transactions that they need in case they have to unilaterally exit from the multisig. Then, whenever they next get online, they can paste that string into their wallet and instantly start using the money in their (already confirmed!) new hedgehog channel to make hedgehog payments and lightning payments.
You you could also use the unilateral channel feature to "make up" a bunch of keypairs, get some business cards, print out channel opening/closing information on the business cards (using the pubkeys from each of the keypairs you made up to create the multisigs), fund the multisigs yourself, and then "gift" them to people by just handing them the business card. Each recipient gets a new, prefunded hedgehog wallet with full support for sending and receiving lightning payments, with two simple steps: (1) visit a webpage (or download an app) that runs hedgehog wallet software and (2) scan the qr code to import the channel data.
All of these features have some interesting side effects. For example, since you can receive money into a new hedgehog channel without being online, you can keep your private keys fully offline in an airgapped hardware wallet, and whenever you want to send money over hedgehog or lightning, you can just prepare the transaction in your software wallet, encode it as a series of several psbts, pass those to your hardware wallet for signing, and let your software wallet send the newly signed transactions to the bridge server.
You could also *receive* money over lightning into a separate hot wallet, and regularly withdraw it to a cold hedgehog wallet by using your hardware wallet to individually sign the various transactions that are involved in receiving lightning payments and revoking old state (but this requires implementing support for receiving lightning payments on hedgehog, which I haven't done yet -- see below).
I am currently working on a feature that I call "virtual channels" which allow you to make a unilateral channel without going on chain. This lets you cheaply give people hedgehog channels that "fully" work, with the tradeoff that you (the sender) have a copy of this virtual channel's private keys, so you have custody of the recipient's funds. But the channel works just like a regular hedgehog channel, with the same interface, its own balance, full support for sending and receiving hedgehog payments, and sending lightning payments. So it's sort of like you're hosting an lnbits wallet for someone, only with hedgehog's ability to effectively emulate asynchronous payments. Which means you don't need a server to host this software, a regular phone or even a web browser should work fine, because you don't need to be online all the time, only the bridge server does.
Once virtual channels are ready I want to add support for "receiving" lightning payments into a hedgehog channel. I wrote up a specification for it here (https://github.com/supertestnet/hedgehog-advanced) but I haven't implemented it yet. Once that is done I think hedgehog will be ready to implement in a "real" wallet. It will have so many cool features:
- keep your keys airgapped and still (a) send hedgehog payments (b) receive hedgehog payments (c) send lightning payments (d) regularly withdraw lightning payments from a "hot" wallet into .your airgapped hedgehog wallet without needing to do any base layer transactions
- if exchanges like kraken or swan add support for hedgehog, any user who has monthly or weekly autobuy enabled could receive these regular purchases of bitcoin directly into a hedgehog wallet -- hot or cold -- and be able to spend the money on lightning or hedgehog as soon as it confirms, without needing to come online til they want to actually spend the money
- if you are sending someone money and your recipient is *on*line, you can use a hedgehog wallet as a regular lightning wallet
- if your recipient is *not* online, you can pay them by making a unilateral channel for them on the base layer, and to do that you just need to be willing to pay a base layer tx fee and know one of their pubkeys (technically that part is optional, as you can just make up a keypair for them -- though I personally wouldn't trust a keypair that some rando made up for me and I would sweep all funds from such a channel whenever I next got online)
- if your recipient is not online and you don't want to incur a base layer fee, you can make a "virtual" (i.e. custodial) unilateral channel for them and deposit whatever amount you want to pay them into that. You can then send them its details and go offline, and they can sweep it whenever they next get online, without any further help from you (i.e. you don't need to be online when they sweep the funds! They just need the bridge server to be online)
- this emulates asynchronous lightning payments pretty effectively, without the need for the sender to run a server or rely on a third party custodian. But there is a "first party" custodian -- the sender retains custody of the funds in a virtual channel until the recipient sweeps them. And there is a third party bridge server, who can censor payments, though if that happens, the sender can just retry with a different bridge server and stop using the old one
- it also emulates "pull" payments, which are useful for subscriptions. If you want to subscribe to twelve months of bitflix, you can send bitflix twelve virtual channels where each one has a timelock on the virtual channel opening transaction. This effectively means that the first virtual channel cannot be used til 1 month goes by, the second one cannot be used til 2 months go by, etc. As each timelock expires once per month, a single virtual channel becomes usable each month. This allows bitflix to sweep funds from one channel per month, thus "pulling" pre-authorized funds from your wallet according to a predetermined schedule
- if you ever want to cancel such a subscription, just make a new transaction with the bridge server overwriting all the remaining virtual channels you gave to bitflix. The bridge server will then stop treating the virtual channels as valid, because they can no longer redeem the money in them even if it comes to their side of the virtual channel, so bitflix can't use them anymore either, and thus your subscription is effectively canceled
- all of this can work just fine today without waiting for bitcoin *or* lightning to upgrade -- which I think is just amazing!
Wow where can I learn more? I'm gonna need to go find some stimulants to be able to read all of this properly but it sounds like just the solve we've needed for a lot of digital value for value projects ๐
Every time you spend a dollar, you also incur an opportunity cost of not buying $1 worth of bitcoin.
The "never ever spend your corn" types spend bitcoin all the time every day, they just lack the intellect to see it.
Skinny dipped in a Ray County watering hole today, also got some ground lamb and homemade relish in a barter.
Today was a good day.
Podcasting 2.0 another crucial piece of the puzzle
Good news! Your Bowl is ahead of schedule! In which I trust my web, nostr:npub19ha7tju4teqp3dmwv4p28wrcy9zd6h6hxkg5mwvjrlfycweazpkse2q0fa avoids the line at the Trip DMV, The Rev gets shroomy with Mushroomhead and callers prefer typing!
Who could have guessed the dying gasp of BAYC would take place on the walmart clearance rack? ๐๐๐
Apple died with Steve. You know it, I know it, everyone knows it.
Works great already today in noStrudel
You should definitely keep my boy nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr in on these convos, he's the dev behind noStrudel
And of course I forgot to add the screencap
Zap Mentions / some thoughts on broadcasting zaps...
Today on nostr zaps don't provide a great discovery signal because they are fundamentally reactions which you only see if the event being zapped is in already your feed.
If you don't see the content, you won't see the zap reaction, and therefore you won't get the payment signal that indicates the content is valuable.
Zaps also can't trend on nostr because they can't be liked / reposted / zapped / quoted / replied to.
As a user there is no way for me to broadcast a zap in the same way I would broadcast a kind 1 note. I can share my thoughts on something - but there's no way for me to increase the signal of those words by including a zap alongside them. Examples where you might want to do this include:
- donating to a good cause
- sharing a long form article
- supporting a content creator
- thanking a supporter for a zap
---
Potential Solution - Zap Mentions
I think there is a solution to this that doesn't require a new nip or change to the spec. Zap events could just be embedded in kind 1 notes using the standard NIP-27 nevent1 format.
Clients could give users the option to 'broadcast' their zap within a kind 1 note in certain cases and other clients could render some additional UI to display the zap.
Below is an example zap I just sent to nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s - you will probably be reading this just as nevent1... but it would be trivial for clients to parse this and render the zap in whatever way they choose:
nostr:nevent1qvzqqqpxquqzptjz5ej5jncfssa0n2hjvr8e4jz5tlpequraz2442jekee5243qnr65tnu
Ultimately we don't want users of nostr clients to be forced into a choice between sharing content or zapping it - we want them to be able to do both in one frictionless action and this will generate the most signal and make nostr the most attractive place for content creators.
I would love to hear thoughts on this from client developers / designers - nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc
And if someone wants to try rendering this note in the way I've described please tag me!
Works great already today in noStrudel
You should definitely keep my boy nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr in on these convos, he's the dev behind noStrudel
A Bowl in under 3! In which I dodge the 33 bullet, nostr:npub19ha7tju4teqp3dmwv4p28wrcy9zd6h6hxkg5mwvjrlfycweazpkse2q0fa twists her tongue, The Rev expands the dark metal and callers hoodwink the cops.
all those big uglies seem to be consolidation txs. What is the use case there? Is it known? To me the numbers just don't jive. Why would it be worth burning that much corn to get these particular txs thru?
Not a great weekend for it, maybe next week.
I suspect fiscal quarter transition periods are gonna be rough moving forward
