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 online, 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!
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.
Does this require that all 12 months are funded, not spent, but funded?
so bitflix can't use them anymore either
Ok. either implies that the funds will be tied up, which now that I think about it, must be the case.
So this is more like a fully pre-funded but cancellable subscription use case. Part of the appeal of a traditional subscription is lost with money time-locked, but I am thinking about incentives where this might work...
Here is one: if Bitflix offers a diminishing monthly fee for the duration of the subscription, this might compel subscribers to hang on and lock their funds. If they cancel, and later want to subscribe again, the monthly fee restarts at the higher rate further incentivizing the monthly subscription model. Exciting stuff!
Does this require that all 12 months are funded, not spent, but funded?
Yes. The money is "sent" into multisig addresses, which means they are prefunded, but I put the word sent in quotes because this happens off chain. The money hasn't actually moved, or at least that move isn't "final" yet -- the sender can overwrite it if the bridge server cosigns to overwrite it. I can automate the bridge server so that it signs whatever the sender wants if a virtual channel is marked as a bill payment, thus allowing the sender to freely overwrite one or more of their prefunded billpay channels if (for example) they have a sudden expense. Then later they can replace the overwritten ones with new ones of the same value when e.g. their next paycheck comes. Effectively borrowing money from "piles" that they previously earmarked for future bills. Which is pretty similar to what people often do in real life.
100 sats \ 2 replies \ @OT 12 Jun
This sounds like some much needed functionality to LN.
So why called them hedgehog channels? Wouldn’t it be better to frame it as an extension to lightning?
why called them hedgehog channels?
It would be wrong to call them lightning channels because they violate the lightning specifications. I like to use different names for different things so that people can have clarity about which is which.
Wouldn’t it be better to frame it as an extension to lightning?
I think you can do both: hedgehog channels are like an extension that you can attach to a lightning node (e.g. via a bridge server) to gain additional features
Fair enough
Interested in trying it out when it’s ready.
Can I get your opinion on this silly little thing I came up with kinda as a joke lmao: #560629
I think it's a very good idea. It reminds me of joinpools: https://bitcoinops.org/en/topics/joinpools/
been following this one since you dropped it. really interesting work and it is amazing because it works now! people really sleep on the works now part.
keep it up.
Can't wait now!! Please double your efforts. Getting more and more interested now.
I will definitely continue to work on it!
Cool features! :)
You're doing some real pleb work. Keep it up. Best wishes!
The future of finance is right here, lets get after it!
We are waiting for it.