Skip to content

Instantly share code, notes, and snippets.

Avatar
https://keybase.io/tbast

Bastien Teinturier t-bast

https://keybase.io/tbast
View GitHub Profile
@t-bast
t-bast / asymmetrical-feature.md
Created Jul 9, 2021
Asymmetrical feature example
View asymmetrical-feature.md

Asymmetrical features

Let's explore the following scenario. There is an asymmetrical feature F, with a clear client side and provider side. The client side of the protocol is activated by feature X. The provider side of the protocol is activated by feature Y.

Some nodes want to be a client, but not a provider, and want to connect only to nodes that are providers of this feature. They obviously turn on feature X. Since they are only clients of the feature, they cannot turn on feature Y, so how do they require their peers to support feature Y?

@t-bast
t-bast / phoenix-splicing.md
Created May 12, 2021
Phoenix in a splicing future (a.k.a death to all swaps)
View phoenix-splicing.md

Phoenix in a splicing future (a.k.a death to all swaps)

Phoenix implements trusted swaps for users' convenience (to allow easy onboarding and offboarding). But it's not a satisfying solution for the following reasons:

  • It uses two on-chain transactions for swap-in where one should be sufficient (one transaction from the user to Acinq followed by a channel open)
  • Swap-out feerates are unpredictable (because we may fund the swap-out with unconfirmed previous outputs) which is frustrating for users
  • It forces Acinq to use its own utxos, which doesn't scale well and is an operational burden
  • If Acinq doesn't have any utxos available and the mempool is completely full, swaps are stuck which is also frustrating for users
@t-bast
t-bast / trampoline-error.md
Created Jun 10, 2020
Description of trampoline error encryption/decryption
View trampoline-error.md

Trampoline error encryption

Trampoline nodes apply the same error-wrapping mechanism that's used for normal onions at the trampoline onion level. That means there's simply two layers of error wrapping.

Notations

We note ss(Alice, Bob) the shared secret between Alice and Bob for the outer onion encryption, and tss(Alice, Bob) the shared secret between Alice and Bob

@t-bast
t-bast / sphinx-rdv.md
Last active Feb 26, 2020
Sphinx Rendezvous
View sphinx-rdv.md

Sphinx Rendezvous

Alice wants to receive a payment via rendezvous node Bob. Carol will pay this by "finishing" the onion encryption to route to Bob.

Carol -> N -> Bob -> M -> Alice

Notation:

@t-bast
t-bast / decoys.md
Last active Mar 30, 2020
Node ids and short channel ids blinding
View decoys.md

Route Blinding

Notations

  • Alice's real node_id is P_a = k_a * G
  • Bob's real node_id is P_b = k_b * G
  • Alice's blinded node_id is D_a = d_a * G
  • Bob's blinded node_id is D_b = d_b * G
  • Alice <-> Bob real short_channel_id is scid_ab
  • Alice <-> Bob blinded short_channel_id is blinded_scid_ab
View phoenix-privacy.md

On-chain Privacy in Phoenix

Phoenix users never fund channels themselves; it's always the routing node they're connecting to that opens channels to them via pay-to-open. Let's call such a node an LSP (Lightning Service Provider). Note that for now Phoenix only supports one LSP (Acinq).

We will show that this model provides good UTXO privacy for Phoenix users (and good unlinkability between on-chain and off-chain identities).

Pay-to-Open

View PowersOfTau
The BLAKE2b hash of `./response` is:
e4dafd1b 0fa438a2 b313d66c c9566a0a
be6d7abe 76252eeb 7d294028 770f830d
e8670f14 5ed8c8af 4e5c3476 f591d0c7
bfd58ddd 36dd7c4d 311d1358 420d551f
View keybase.md

Keybase proof

I hereby claim:

  • I am t-bast on github.
  • I am tbast (https://keybase.io/tbast) on keybase.
  • I have a public key ASAOUDcPswM4FtA7kgxGQyAhcF73gVTekNpkrrc_k_X-_Qo

To claim this, I am signing this object: