Introduction to Lightning Privacy 🚀 Lightning Privacy Researchlightningprivacy.com/en/introduction
15.7k sats \ 6 comments \ @TonyGiorgio 30 Nov 2022 bitcoin
write
preview
related posts
248 sats \ 0 replies \ @DarthCoin 1 Dec 2022
reply
280 sats \ 0 replies \ @TonyGiorgio OP 30 Nov 2022
Summarizing thread: twitter / nitter
reply
131 sats \ 0 replies \ @kr 30 Nov 2022
great to see more work being done to preserve/improve lightning privacy
reply
100 sats \ 0 replies \ @Klee 30 Nov 2022
BEAST
reply
100 sats \ 0 replies \ @DarthCoin 30 Nov 2022
Good stuff!
reply
0 sats \ 0 replies \ @0260378aef 1 Dec 2022
Because we are doing a splice this can remove the need for equal output amounts because we can disguise the resulting amounts because the amount the user received is not explicit on-chain, only the total channel amount.
I'm not sure I grokked this. Say there's an Alice-Bob channel of capacity 4, currently 2-2 so balanced. Then Alice wants to add 1 to her side, provides a 1btc input, splices in by consuming existing channel utxo and creating a new one, now the channel is 3-2 and so total capacity is 5. In this non-coinjoin, simple case, the amount received is explicit on chain right? Only thing not explicit is which of A and B received it?
If we were 'coinjoining' in the sense of multiple splices in the same on chain tx, I can imagine that even without equal amounts, it's possible to create obfuscation of linkages, but right now I'm not immediately seeing how the spliced amounts are not explicit on chain.
reply