Good morning LL, > > > > I suspect part of the proof-of-discrete-log-equivalance can be gated as > > > > well by a ZKCP on payment point+scalar the proof is provided only on > > > > payment. > > > > The selling node operator does not even need to reveal `z`. > > > > > > Actually no -- the fact that you were able to create a secure conditional > > > payment for the proof would always prove the proof existed. > > > You wouldn't need to pay for the proof then! > > > > That depends on the proof. > > > > For example, one pay-for-proof scheme would be somebody to provide you an > > `(R, S)` for a public key `P = p * G`, where `S = s * G` (i.e. a > > signature, or a proof that you know `p` where `P = p * G`), and it would > > not prove anything until you pay for the scalar `s` and the prover can > > provide `s`, since `S` is computable from public information that anyone > > can have. > > So it really depends on what you want to prove; a mere ZKCP is not always > > enough. > > > > Regards, > > ZmnSCPxj > > > > PS I am dabbling in BTRFS now though, so --- > > You're right. I stand corrected. It is possible to construct ZKCP payments > where the messages sent by the prover up until the point the prover claims > the payment (and reveals the witness) could have been simulated by someone > who doesn't know the witness. You give a good example of this. After thinking > about your post I recalled that I used a similar argument about the security > of my protocol for buying an opening of a Pedersen commitment with Bitcoin > [1]. > > [1] https://github.com/LLFourn/buying-pedersen-commitment/blob/master/main.pdf
Yes, but on the other hand --- as pointed out, the seller could be lying and just made up the "other node" in the channel. Proof that the "other node" is in fact the actual "other node" on that channel is relatively worthless if there is no proof that the "other node" is at all something other than the seller. On the other other hand --- if the buyer has additional information that the "other node" here is "of interest" (i.e. it has other data about the "other node" that makes it focus its attention on this "other node", and it suspects the seller is not a sockpuppet of the "other node" here) then this kind of proof just became very valuable. -- Another thought is that this approach potentially makes the LN gossip network a monolithic database that is only weakly consistent. The Bitcoin blockchain layer is an existing monolithic database with strong consistency guarantees. Because of weak consistency, it is possible for a node to exist in your gossip map, you make a channel to that node, then you get amnesia, then that node is no longer in your gossip map. Do we need to find ways to increase the consistency of node gossip? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
