2023 Mar 04

• Even homebrew has telemetry by default.

• Saw someone say on nostr how they take more of a payment by receiving payments on a private lightning node only accessible through their own routing node, so they get the routing base fee in addition to the payment. Seems like this shouldn’t be a thing…but I can’t tell if it’s a problem.

• If I have the technical capacity and money to be able to secure my setup and protect my privacy, why wouldn’t I?

• PTLCs - HTLC payment parts can be identified as they use the same hash, while PTLCs can use signatures to different points (i.e. locked by points on the elliptic curve) to be unlocked. Also with schnorr signatures, elliptic curve points can be aggregated so that the extra lock doesn’t take up extra space if claimed on-chain and obfuscates that different spending conditions are even present.

  • Why can’t HTLC MPPs just use different hashes? Doesn’t payment_secret solve this? Think about how payments actually work. For an invoice payment, the preimage is generated by the receiver, who is agnostic of how the sender will route the payment, so for the sender to use different hashes, they’d need to provide the different preimages to receiver. Maybe a keysend MPP could use different hashes, but then I guess how do you tell they are a part of the same payment?

  • I’ve actually sort of wondered why keysend doesn’t seem to be that popular? Maybe because no proof of payment?

• Adaptor signatures - schnorr signatures allow for special combinations to hide and reveal information to help coordinate multiparty signature schemes.

  • An adaptor signature is like a normal schnorr signature but with an added hidden value (message m is public) (optech also hashes public key, which I’m not sure why it would be necessary).

    // normal
    s = r + H(R || m) * p -> (s, R)
    // adaptor - t is a hidden value
    s = r + t + H(R + T || m) * p -> (s - t, R, T)
    

  • Say Alice sends this adaptor to Bob. Bob can verify the adaptor but cannot use s - t as a signature in anyway because he doesn’t know T and he can’t modify s or create a new s to change what is being hashed.

  • However Bob can create his own adaptor that when sent to Alice (or anyone who knows t) can reveal his signature on the original hidden value.

    s_b = r_b + H(R_b + T || m) * p_b
    

  • Alice can verify the adaptor, and produce Bob’s signature on t by just adding: s_b + t. Alice has retrieved a signature on t from Bob without Bob knowing the value of t!

  • Then if Alice ever broadcasts this signature, Bob will be able to find t, and therefore also Alice’s original signature s.

  • Don’t know many examples of how these can be used, will look more into it sometime.

• Stuckless/cancellable payments - 2 rounds to accept a payment. Currently, all the data needed to claim a payment is sent along a route (or generated by the receiver), so if a payment gets stuck and you retry successfully, that stuck payment could become unstuck and you end up unintentionally overpaying. If you require the receiver to make another request to the sender (to obtain some secret) in order to claim the payment, you can prevent this. Downside is 2 rounds uses more bandwidth and is slower.

• Scriptless scripts - because schnorr signatures allow for signature/key aggregation, you can lock UTXOs on the possession of secret keys, who’s public keys can be aggregated with other public keys to eliminate the need for certain scripts used today.