As an equal opportunity downer, I have to challenge Super's use of language here, this is not an asynchronous payment any more than the K1 in a LNURL-Withdraw link or trusted shitcoin swap is.
Since the receiver must come online to sweep the state, it's not asynchronous, it's a promise not unlike any centralized solution.
The internet does not work asynchronously, it works through re-attempts and re-signaling.
reply
I think it's fair to say I've paid you if I've given you everything you need to collect the payment at your leisure (but before a timelock expires). It's a bit like giving you a check. If I was at a grocery store and I gave the clerk a check, then later someone asks me "But did you pay them?" I would say yes. And instead of a bank account, these "checks" are redeemed from a multisig where the recipient is a keyholder and can enforce the redemption.
reply
Fair to say
That's my point, language matters.
Are LNURL-W's an async payment?
Does lightning have async payments already?
If the answer to either of those is no, then the same is true of Hedgehog
reply
Are LNURL-W's an async payment?
Yes, they are an async payment where you have to trust someone's word until you redeem it
Does lightning have async payments already?
Yes, through lnurlw. But they require trusting a server until you redeem them. Hedgehog fixes this.
If the answer to either of those is no, then the same is true of Hedgehog
The answer to both is yes
reply
Hedgehog doesn't obviate trust, so what does it fix exactly?
reply
It reduces the trust requirements. Basically lnurlw except you don't need to trust the sender or a third party server.
reply
But until you sweep it, you are trusting the sender not to close.
I don't see how that reduces the trust requirement, you're just using the word server instead of sender.
reply
until you sweep it, you are trusting the sender not to close
if they close, you can enforce the latest state as long as you do so within 2016 blocks
not the same with lnurlw
if an lnurlw server closes before you redeem your lnurlw, you lose everything
Hedgehog gives you a window of time to redeem it unilaterally because closing isn't done until the 2016 blocks are up
246 sats \ 1 reply \ @MadBudha 26 Mar
So does it runs off chain or across the LN?
reply
off chain
not on LN
reply
1000 sats \ 1 reply \ @conduition 27 Mar
A very clever use of connector logic.
I'm curious how you envision routed payments fitting into this paradigm. What you're describing in the Hedgehog repo is analagous to key-sending in Lightning: Paying your channel partner directly with no expectation of receiving anything in return. To make this useful, you'd need to be able to route payments over multiple hops like Lightning using HTLCs or PTLCs, or perhaps even something wilder like Blitz payments. Consideration of network-driven scaling seems to be missing.
Thus, instead of sending a revocation secret to revoke a prior state, the sender merely sends a signature authorizing their counterparty to consume the revocable connector and the rest of the funds so long as both inputs are consumed in a transaction that creates the latest state.
It's not 100% clear what you mean by 'creates the latest state'. This seems incredibly crucial to the protocol, as otherwise revealing the revocation secret is completely unsafe for the sender. Here's what i'm assuming you mean.
Say I'm Bob, at the beginning of this section (state 2). I want to send 1000 sats to Alice. Alongside my two signatures needed for Alice to be able to unilaterally close the channel with her 9000 sat balance (state 3), i would need to provide a signature which lets her fairly distribute the channel balances according to State 3 if I (bob) try to broadcast the first TX from State 2. That way, if I broadcast state 2, Alice can come online and follow up by 'correcting' me with the latest state, without actually punishing me, similar to how Eltoo Channels work.
However this seems unscaleable. By doing this, i have only revoked state 2 if Alice can reply by broadcasting state 3. To maintain the revocation of state 2, Alice would need me to sign similar 'correction' transactions every time i send her money. This quickly becomes impractical because every time I send Alice money, I will need to include such a correction TX signature for every previous state I might be able to broadcast.
The obvious fix for that is to do this:
For even better safety, the old revocation script – (counterparty && revocation_secret) – should still be kept as a third tapleaf in the new revocation taptree, so that a sender can “conditionally” revoke their most recent state using (counterparty && sender) but “absolutely” revoke the state before that using the old revocation script.
This way, Bob can reveal the revocation secret for state 2 once Alice acknowledges receipt and shares her signatures for State 3. Bob no longer needs to sign new correction transactions for State 2 because Alice can instead just sweep the whole channel balance if Bob broadcasts State 2.
But in the readme you pitch that technique as an optional safety improvement, not an essential scaling requirement. Without it, I would have to sign n transactions if there are n previous states I could have broadcast - not practical for high-frequency channels.
reply
I'm curious how you envision routed payments fitting into this paradigm
Pretty similar to how lightning does it: each hop between you and your destination forwards an htlc. Like with keysend, you send the secret to the destination out of band. Like with zaplocker, he redeems his htlc when he gets online. Liquidity is locked up along the route until then, annoying every routing node severely. (I hope they charge massive fees, and I hope there are as few routing nodes as possible -- ideally just one, see the Burrow idea at the bottom of the readme.)
in the readme you pitch that technique as an optional safety improvement, not an essential scaling requirement
It's an essential requirement
reply
274 sats \ 3 replies \ @anon 26 Mar
Very nice!
Tried running it. Changed bob key to "ababbaab".repeat( 8 ) and alice key to "baababab".repeat( 8 ) and used different amounts. However when closing the channel, the total funding amount was transfered to one address
reply
if Alice started with 10k sats, sent some money to Bob, and then closed, she tries to close with the prior state (where she still has all 10k sats), because she can't close with the latest state, due to only having 1 signature where 2 are needed. But that is why she has to wait 5 blocks (which should be more in production): during that time, Bob can set things right by running hedgehog.bob_penalize(). If Alice merely tried to finalize state X-1, nothing bad happens to her, Bob can only create the latest state (X). But if she broadcasted X-2, or any other state, Bob can take everything
reply
134 sats \ 1 reply \ @anon 26 Mar
tried it again with differet keys and amounts, and I get this error when trying to push the clsoing transaction from alice: mandatory-script-verify-flag-failed (Invalid Schnorr signature)
reply
can you be a bit more detailed about the steps you took that led to this error? I'd like to try to reproduce it and then fix it. Were the steps this?
  • Fund the multisig with 150k sats
  • Alice sends 2k sats to Bob
  • Alice closes
  • Invalid Schnorr signature
Or something else?
reply
Super causally invented the new type of channels! Great work!
Do you plan to do it on Liquid at some point? I think it’s good experimental platform and it will reduce cost of opening/closing channels. For serious stuff L1 is the way to go of course.
If I want to build a wallet using hedgehog channels can I (not company, just finding pet project for myself) do it or there is some license limitations?
reply
Super causally invented the new type of channels! Great work!
Thank you!
Do you plan to do it on Liquid at some point?
I plan to replace Liquid at some point
I think it’s good experimental platform and it will reduce cost of opening/closing channels
That is all true but testnet is even cheaper (totally free)
I do most of my testing on a local testnet I spun up in bitcoin core, then make a proof of concept webpage when I have something that works
Then I usually let someone else take it to the next level by making a production system with it
If I want to build a wallet using hedgehog channels can I (not company, just finding pet project for myself) do it or there is some license limitations?
Go to town my friend! Make whatever you like! I would love to see whatever you build
reply
Good god does this man sleep?
All I wanted was a normal boring Tuesday, and now this.
Thanks a lot supertestgoat
reply
Anybody else feel nothing anymore?
Like 2 years ago I would have been euphoric for every new idea or new cryptographic scheme planned for L2 Bitcoin layers. I'd have gone down the rabbit hole for hours.
But now it's just dread. I want new ideas, I want that the best solution mcguffin comes. But it's just not exciting anymore, even when the BTC/USD exchange rate is at all time highs. Anyone else?
reply
I still feel the thrill, friend
🫂 <-- me sharing my euphoria with you
reply
there's no such thing as "the best solution." it's "the best solution for my problem." there are always going to be people like super who are constantly thinking about the next thing and, at their core, are innovators. then there will be others who take this idea and continue to run with it, battle testing it, attacking it from many sides, trying to break it, all while improving the UX to see if it actually is a better solution than the existing state-of-the-art. one is not better than the other. both types are needed.
things got a little easier for me when i realized that i can't necessarily be both, and that's okay. choose one and strive to be damn good at it.
reply
For those interested here is the official Github repo with the protocol description.
reply
Wake up babe new layer 2 just dropped
reply
Well it is Tuesday after all
reply
31 sats \ 0 replies \ @calle 26 Mar
This one is real though!
reply
60 sats \ 0 replies \ @anon 26 Mar
Lightning is dead. Long live Lightning ⚡️
(Reply paid for by lightning ⚡️)
reply
Holy fuck, this is cool. So, does this need a sf to work since it's based on Ark?
reply
no, it works right now
It's based on connectors, not Ark
Connectors work today
reply
Mind blown! Thanks for the clarification.
reply
Dude made lightning network for DTNs :D
reply
what are dtns?
**Edit: nevermind, it apparently stands for delay-tolerant networks
Yes, I made an alternative to lightning channels that is much more delay-tolerant
But it's not a network yet
reply
Delay Tolerant Networks. My altnet post series were about them except I didn't even realize it was about them until a commenter basically told me the DTN protocol stack was useful for what I was talking about lol.
The latest one focuses on ION (which is actually HDTN now). I haven't written a new post in a while because I was learning dtn7-go, but then got distracted by nixos and now I'm on RHEL for some reason. Focus is hard.
Anyway, if you read this one it should at least explain DTNs in general well enough: #330735
reply
NixOS is great!
reply
10 sats \ 0 replies \ @o 31 Mar
a value Alice may reveal to Bob if she wants to revoke her ability to safely receive money in an address containing the top script.
I'm missing something. Can you please explain the above? I don't understand why or when Alice would want to revoke her ability to safely receive money. Folks tend to want to acquire and maintain the ability to safely receive money - the more the better.
reply
10 sats \ 0 replies \ @kevin 27 Mar
LETS GO!
PS. I think you'd have a lot more people watching your videos if you upped the audio quality, it's pretty distracting with all the random noises in the background. I'm sure lots of people would chip in (I know I would) to get you one if you don't want to spend sats on one yourself. This one is pretty good if you travel frequently: https://rode.com/en/microphones/wireless/wirelessgoii
reply
10 sats \ 1 reply \ @pakovm 27 Mar
I have a few questions:
  1. Do you even sleep?
  2. How can hedgehog become a network? How do "checks" reach people who don't have a channel with you?
  3. Did your dealing have the capability of reaching users who don't have any money before hand?
  4. Do you think that it will be possible to implement these simpler state channels into Lightning?
  5. Where do you stop?
reply
Do you even sleep?
I have not gotten sufficient sleep recently, too excited
How can hedgehog become a network? How do "checks" reach people who don't have a channel with you?
A combination of keysend and zaplocker. Nodes between you and your destination forward htlcs to one another and you send the payment secret to your destination out of band. Like with zaplocker, funds are locked up along the route until your recipient gets online and redeems his payment using the secret
Did your dealing have the capability of reaching users who don't have any money before hand?
You can sponsor the creation of a new hedgehog channel for them and dump money into it. Similar to when you send money to someone on Phoenix for the first time and Phoenix deducts enough money from the payment to do a base layer transaction. See also Burrow: https://gist.github.com/supertestnet/14addffae669058a9bb9df2e2608ff7f
Do you think that it will be possible to implement these simpler state channels into Lightning?
Yes
Where do you stop?
Can't stop won't stop
reply
in before "hedgehog on nostr" is a thing.
reply
Thanks for the demo!
A couple of questions
  1. What ensures either party know the latest balance at any given time?
  2. Are payments able to be relayed through intermediate nodes?
  3. What made you pick hedgehog for the protocol name?
reply
What ensures either party know the latest balance at any given time?
Nothing. The sender needs to tell the recipient what their state is via some communication method. The recipient needs to accept that state before a timelock expires. If they don't, the state transition never really happens.
Are payments able to be relayed through intermediate nodes?
In theory yes, similar to how lightning does it, but I haven't implemented that yet.
What made you pick hedgehog for the protocol name?
Hedgehogs are known to be rather fast and they are also cuddly and cute. There are also lots of puns you can do with it, so if people want to build stuff on top of this, there is lots of room for naming things creatively.
reply
Sonic transactions! Not sure what they’ll be but Sonic transactions belong on the hedgehog protocol
reply
Super cool. Nice work.
reply
10 sats \ 3 replies \ @joda 26 Mar
I think I found a problem:
You need to get a mouse with customizable buttons for "open in new tab," "copy," and "paste".
😁
reply
Middle click on all mice is "open in new tab"
reply
0 sats \ 1 reply \ @joda 26 Mar
Yeah I think he's on a laptop with track pad.
reply
I have a mouse but I love my trackpad
reply
Sick!!! Is hedgehog strictly better than lightning? Or is there some tradeoff?
reply
I think it is strictly better than lightning and I think there are tradeoffs. I outline some of them here:
reply
Is it trusless ? Like do you need an LSP or something or does it work really "like" LN but I can pay anyone without worrying about the payee being online or not ?
It seems just to good to be true, where are the trade offs ? :)
reply
Is it trusless ?
I don't believe in trustless. It inherits bitcoin's standard trust assumptions, including that the majority of miners are honest. Specifically, this protocol requires getting a transaction confirmed in order to enforce the latest state, and if miners censor your attempt to do so, your counterparty can steal from you. So no, it's not trustless.
do you need an LSP or something
You do not need an LSP or something. You can open a channel directly to someone and then all your payments within that channel can be done asynchronously. My proof of concept only supports payments within a channel, i.e. A->B, it does not currently support routing payments from A->B->C.
Routing can be done similar to how lightning does it (using a chain of htlcs that nodes forward to one another) but that introduces liveness assumptions about the routing nodes. A routing node N cannot forward an htlc to the next hop H if N is offline. Consequently, something like an LSP (HSP?) would be helpful, as they can be online all the time and you can thus pay someone who is offline through them.
It seems just to good to be true, where are the trade offs ? :)
  • Recipients need inbound liquidity, which costs money
  • Routed payments require routing nodes to be live (thus incentivizing the creation of LSPs, or HSPs)
  • Payments are not completed until the recipient eventually comes online to collect, and they have a limited time window to do that. So they either need trusted third party watchtowers or be watchful themselves, which is annoying
reply
It inherits bitcoin's standard trust assumptions, including that the majority of miners are honest.
Bitcoin does not require a majority of miners to be honest. It requires a large percentage¹ to be independent, and economically rational. That's a much weaker requirement than honest.
If we were happy with a majority honest assumption, we could have just increased the block size: there would be no need for others to validate the chain. The majority of miners could be trusted to do that for us.
  1. 70%+ depending on exactly what assumptions you're making, eg selfish mining.
reply
Bitcoin does not require a majority of miners to be honest. It requires a large percentage¹ to be independent, and economically rational. That's a much weaker requirement than honest.
Suppose someone can censor your transactions at enormous cost, and you rely on your ability to transact uncensored anyway. I think that means you are trusting them not to do that i.e. you are trusting them to be honest
we could have just increased the block size
we did
(ok that's not totally true but I couldn't resist)
reply
First of all, you were talking about "a majority of miners being honest". Even dishonest miners can't censor by themselves: they need coordination. You're mixing up "majority honest" with 51% attacks.
Second, the defense in this scenario is transaction fees and inflation subsidy: you're paying miners both immediately and an expected return in the future for mining transactions the way we all want them too be mined. That is an example of economic incentives. Not honesty.
Keep in mind that in academic protocol literature, the term "honest" is used to mean someone who rigorously follows a set protocol. Most Bitcoin hash power does not even begin to do that, as they differ from Core in lots of ways.
reply
You're mixing up "majority honest" with 51% attacks
I didn't know there was a difference. If miners perform a 51% attack in order to prevent a transaction from being included in the longest chain, that seems like an example of a dishonest majority
That is an example of economic incentives. Not honesty.
It is an example of an economic incentive, but it does not seem to negate the presence of honesty. Miners who are dishonest (i.e. they want to censor you) can leave aside the economic incentive of fees+subsidy and censor you anyway
in academic protocol literature, the term "honest" is used to mean someone who rigorously follows a set protocol
I don't think I am using the term in an academically rigorous way. By "honest miners" I mean "miners who accept your transaction into their blocks or build on blocks that do." By "dishonest miners" I mean "miners who reject your transaction from their blocks and orphan blocks that include it."
Thanks for the detailed answer.
Honestly what you describe seems (at my noob level) to be a solution to one of the biggest UX problem in LN. It's huge lol
Don't know how hard it would be to convert the whole LN to this new standard but could be pretty fast it it indeed works as you show.
Congratulations anyway 🎉 for this promising idea (among all others)
reply
Is it possible to implement it to lightning?
reply
yes, a hedgehog wallet can be built that sends and receives lightning payments
reply
is it possible to add to lightning channels though?
reply
Any wallet can update its lightning channels to use the hedgehog protocol
reply
Now that's interesting
reply
please correct me if I'm wrong, but don't you need BOTH parties to be online at all times once their shared multisig is funded in case one of the parties tries to exit with invalid state?
reply
No. If a party tries to exit with old state, the victim has 2016 blocks i.e. 2 weeks to come online and fix it. So they don't need to be online "at all times." My proof of concept only uses 5 blocks but in production it should be longer.
reply
Thanks, that makes sense, so the force exit procedure is fairly similar to lightning channels.
1 more question: if the 2nd party isn't online when a hedgehog channel is created where is the information about state changes stored and how can party 2 access it once it comes online?
Thank you for the great work you've been doing!
reply
if the 2nd party isn't online when a hedgehog channel is created where is the information about state changes stored
State changes need to be sent by the 1st party to the 2nd party through some text medium like email. Whatever medium you use is where the information is stored.
how can party 2 access it once it comes online?
They check their email or telegram or whatever you used to send them the new state
Thank you for the great work you've been doing!
You're welcome! :D
reply
I was wondering where the hell did all stackers go. Then I found this and all of the Stackers as well.
That's cool!
reply
Underrated comment. This is the kind of post that brought me to SN in the first place.
all of the Stackers
Maybe the popularity contest currently running is more important to them?
reply
this is some pretty awesome stuff
reply
Is it better in onborading new people in a high fee environment then LN?
reply
I don't think it's better for onboarding, it has the same inbound capacity problem as lightning, and inbound capacity costs money
reply
I am applauding you, good sir
reply
Great work!
reply
Spectacular sir!
reply
So fucking early!
reply
We’re literally about to have dual funded, spliced hedgehog channels combined with e-cash.
reply
reply
Love it!
reply
Cool idea! Maybe I am missing something, but when setting up the Hedgehog channel, what stops Bob from just holding Alice's funds in the 2-of-2 multisig hostage, by not cosigning the transactions proposed by Alice? And potentially blackmailing Alice to cosign only if she sends over more of her funds in the channel?
Looks awesome!
Gotta go fast 🦔