Skip to content

Instantly share code, notes, and snippets.

@supertestnet

supertestnet/burrow.md

Last active April 18, 2024 11:03
Show Gist options
  • Star 10 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save supertestnet/14addffae669058a9bb9df2e2608ff7f to your computer and use it in GitHub Desktop.
Save supertestnet/14addffae669058a9bb9df2e2608ff7f to your computer and use it in GitHub Desktop.
Download ZIP
Burrow: a federated coinpool built on hedgehog channels
Raw
burrow.md

Burrow

Burrow is a proposal for a federated coinpool on top of hedgehog channels. The coinpool can have a bunch of cool properties:

  • a single-honest-party assumption, so the federation can't rug any user unless the keyholders in the federation are all scoundrels

  • users can onboard into the pool without an on-chain transaction (e.g. maybe you send in coins via lightning, or maybe another user gives you your first coins from within the pool)

  • every onboarded user gets their own wallet interface with their own personal balance and Send/Receive buttons

  • no transfer fees within the pool, and internal transactions happen faster than lightning (due to no need for pathfinding, and no liveness assumption about the recipient -- only the server must be online)

  • users can issue off-chain "cheques" which are essentially vtxos that you give someone else the right to spend. The recipient does not need to be in the coinpool, they can be literally anyone. The cheque issuer can send the cheque to the recipient e.g. via email, and the recipient can redeem it off-chain even if the issuer is offline (but the server has to be online for this part, and can censor, though the issuer can override censorship via a force closure)

  • a lightning gateway can allow transferring sats into or out of the pool, e.g. for users who want to withdraw to a fully self custodial wallet (mining fees would apply there if you send to a base layer wallet, and routing fees if you send to a lightning wallet)

How it could work

It's all based on the idea that the virtual utxos created in a hedgehog channel by tx0 and tx1 are "normal" utxos. As far as you and the server are concerned, they are just as good as confirmed utxos, so the two of you can safely use them as normal utxos for any payments between one another...that includes using vtxos to make new "virtual" hedgehog channels inside an existing "real" hedgehog channel

To explain that point more clearly, imagine this: you have a hedgehog channel. Within it, you can create tx0s that produce tx1s containing vtxos. You know you can broadcast tx0 and tx1 at any time to turn your vtxos into real utxos.

The vtxos created by tx1 can be locked to any valid bitcoin script. For example, you could create a state update in your hedgehog channel whose tx1, if broadcasted, would create a 2-of-2 utxo for a friend, where your friend has one key and the server you're using has the other.

Before you broadcast that tx1, that 2-of-2 output is only virtual...but the two keyholders (your friend and the server) can, if they want to, treat this 2-of-2 vtxo as a virtual hedgehog channel without the need for your further involvement. State updates are all done locally, by the keyholders alone, so there's no need for you to cosign any state updates in their virtual channel. [**EDIT: later I realized the last clause is only "technically" true, but practically false -- see footnote 1]

It functions exactly like an ordinary hedgehog channel, with send and receive buttons and a nice little balance for the user. Even though it's virtual, the server knows it's as good as gold, and the user knows that he can't get rugged unless you and the server both cosign to erase his vtxo

You could even mark the vtxo containing your friend's virtual channel as special and tell your wallet (and the server) not to cosign any transaction that erases it without your friend's consent

Now that might not sound very safe if it's all based on the honesty of just you and the server... But there's no reason you have to be involved, and there's no reason the server has to be just one person

The server could be a 15-of-15 federation, serving all users just like a single sig server would, except all 15 keyholders need to cosign any state changes. And in that case, if they cosign to create a virtual channel for someone using one of their own utxos, the only way that virtual channel gets erased is if all 15 keyholders collude to erase it.

Even if there's a force closure because some keyholder died so the federation can't sign anything anymore, as long as one honest party broadcasts the latest signed tx0 and tx1, the virtual channel just goes onchain, becomes a real channel with the same state, and continues operating as normal

Voila, virtual or real channels for anyone who wants one, and a single-honest-party security assumption for federation users. And if the server runs a lightning node, any Burrow user can use their hedgehog channel (real or virtual) to make lightning payments on the real lightning network through the server acting as a gateway

I don't see any reason why this wouldn't work and the implications are shocking, it's too good to be true, it's got the same whiz bang speed and cost efficiency of the latest payment tech, but it's all done on bitcoin, with no forks required

It's a big improvement in trust assumptions over all current stuff except lightning, and even the "single honest party" assumption only applies if you want to be in a burrow -- you can also just be a lone hedgehog, reject any new trust assumptions beyond bitcoin's standard ones, and still interoperate with everyone else

Footnotes

  1. Earlier I said that if Alice creates a virtual channel for someone, she doesn't have to cosign any state changes. It's true that she doesn't have to cosign but she has to do something equally onerous. Every time she updates her own channel, the txid that creates the virtual channel changes, invalidating all of the signatures that its current state depends on. So she cannot do that without effectively erasing the virtual channel. If she wants the virtual channel to stay valid, then before updating her own channel's state, she must get the server to make new signatures that recreate the current state of the virtual channel based on whatever the new txid will be. And that means whoever "owns" that virtual channel must notify Alice of every state change so that she knows what state to recreate. Which is almost just as bad as having to cosign every state change. I think it's still perfectly practical though -- the virtual channel owner just now has a privacy incentive to make his own channel and stop using a virtual one. Otherwise, every time he changes his channel's state, he has to tell Alice the new state, and "download" any needed state updates from Alice every time she changes the state of her own channel. Virtual channel users already trust that at least one of their host or the server will be honest, so that trust assumption is unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment