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.
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.
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.
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
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
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
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)
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?
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?
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?
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.
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
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.
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
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?
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.
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 ? :)
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
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.
70%+ depending on exactly what assumptions you're making, eg selfish mining.
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)
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.
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."
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?
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.
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?
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
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?
ntransactions if there arenprevious states I could have broadcast - not practical for high-frequency channels.