Re: [Lightning-dev] PoDLEs revisited
On Fri, Jan 29, 2021 at 10:51 AM Rusty Russell wrote: > Less true after taproot though? > The heuristic from [1] is not affected by Taproot. Taproot will be helpful for keeping private channels private against the method in [2] though. > [1] https://arxiv.org/abs/2007.00764 > > [2] https://arxiv.org/pdf/2003.12470.pdf > > [3] https://graphsense.info/ > > > > I am told there is a new revision of [1] coming out any day now that will > > present a few more tricks and have contributions directly from a > scientist > > at Chainalsysis (the company). > > I'll add to my reading list (or wait for one of my colleagues to provide > the TL;DR!). > > Let me TL;DR quickly the core idea quickly as it's not too difficult to grasp. 1. You are node n_1 2. You fund a public channel to node n_2 called c1 3. You use the change to fund a public channel to node n_3 called c2 4. The network sees that n_1 is involved in both c_1 and c_2. They're both public channels so the channel_id gives away the on-chain funding utxo. Everyone can conclude that the owner of n_1 was also the funder of both and therefore owns the change output of the funding of c_2. Consider a variant of this heuristic where instead of using funding change they use the output of a cooperative close of c_1 to to fund c_2. By the same reasoning you can identify the owner of n_1 funded the channel but you can also now know that n_2 is the owner of the other utxo of the close of c_1. The point of this is if you are a node that is churning UTXOs from the funding change or the closing UTXO into other public channels you necessarily associate those UTXOs with your node id and any descendent utxos. This is the point of UTXO probing too but with this you get the info for free by just passively observing the new channel gossip. I think this makes UTXO probing useless as long we can assume that public nodes that accept dual funding requests from random people on the internet (and therefore vulnerable to probing) are also likely to use their wallet funds to fund channels in the future. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning dice
Good morning aj, and list, > Note that Bob could abort the protocol with a winning bet before > requesting the payout from Carol -- he already has enough info to prove > he's won and claim Carol isn't paying him out at this point. > One way of dealing with this is to vet Bob's claim by sending b,R2 and a > PTLC invoice of (50bet,S2) to Carol with yourself as the recipient -- youcan > construct all that info from Bob's claim that Carol is cheating. If > Carol isn't cheating, she won't be able to tell you're not Bob and > will try paying the PTLC; at which point you know Carol's not cheating. > This protocol does't work without better spam defenses in lightning -- > PTLC payments have to be serialised or Carol risks sending the payout > to Bob multiple times, and if many people want to verify Carol is(n't) > cheating, they can be delayed by just one verifier forcing Carol to wait > for the PTLC timeout to be reached. For this particular issue, would not stuckless payments be possible to allow parallelism of validation at least? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev