pull down to refresh

1000 sats \ 1 reply \ @conduition 27 Mar \ on: Hedgehog: A protocol for asynchronous layer two bitcoin payments bitcoin
The Hedgehog demo repo is here.
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.
write
preview
200 sats \ 0 replies \ @supertestnet OP 28 Mar
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