ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-11-27 📝 Original message: Good morning Andres, ...
📅 Original date posted:2020-11-27
📝 Original message:
Good morning Andres, t-bast, Gleb, et al,
> > But instead it could be a point-to-point property: each node provides its own stake certificate
> > to the next node (and only to that node). Alice provides a stake certificate to Bob, then Bob
> > provides a stake certificate to Carol, and so on. If that's the case, it can be in a tlv field in the
> > `update_add_htlc` message and doesn't need to be inside the onion. This also makes it less
> > likely that Alice is exposing herself to remote nodes in the route (payer privacy).
>
> If the above paragraph is confirmed, then does this mean StakeCertificates with privacy are possible without ZK proofs?
> Or did I miss something?
Logically speaking, for this model, a proof is unnecessary --- the node offering the HTLC already has a channel that contains funds that is locked.
Specifically, it is the channel itself where the HTLC is being instantiated, that contains funds owned by the offerer, and which are locked for use in the Lightning Network.
Since the receiver of the HTLC offer is already aware of this channel and its existence, it requires no proof at all.
Thus, I have my doubts on this model --- it seems to me that the current Lightning Network is already equivalent to this model, and the current Lightning Network is (supposedly) attackable by these "griefing" attacks.
Another example is that, if the offerring node has a number of published channels, that is sufficient proof as well, without requiring any privacy-preserving proofs.
This is precisely the current Lightning Network, yet we consider the current Lightning Network attackable by griefing.
Instead, payers, or payees (i.e. by providing the proof in an invoice) must set aside separate non-trivial stake, not tied to channels, but provably tied only to this stake certificate mechanism, in order to assuage the fear of forwarding nodes that the HTLCs will not be claimed immediately.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Andres, t-bast, Gleb, et al,
> > But instead it could be a point-to-point property: each node provides its own stake certificate
> > to the next node (and only to that node). Alice provides a stake certificate to Bob, then Bob
> > provides a stake certificate to Carol, and so on. If that's the case, it can be in a tlv field in the
> > `update_add_htlc` message and doesn't need to be inside the onion. This also makes it less
> > likely that Alice is exposing herself to remote nodes in the route (payer privacy).
>
> If the above paragraph is confirmed, then does this mean StakeCertificates with privacy are possible without ZK proofs?
> Or did I miss something?
Logically speaking, for this model, a proof is unnecessary --- the node offering the HTLC already has a channel that contains funds that is locked.
Specifically, it is the channel itself where the HTLC is being instantiated, that contains funds owned by the offerer, and which are locked for use in the Lightning Network.
Since the receiver of the HTLC offer is already aware of this channel and its existence, it requires no proof at all.
Thus, I have my doubts on this model --- it seems to me that the current Lightning Network is already equivalent to this model, and the current Lightning Network is (supposedly) attackable by these "griefing" attacks.
Another example is that, if the offerring node has a number of published channels, that is sufficient proof as well, without requiring any privacy-preserving proofs.
This is precisely the current Lightning Network, yet we consider the current Lightning Network attackable by griefing.
Instead, payers, or payees (i.e. by providing the proof in an invoice) must set aside separate non-trivial stake, not tied to channels, but provably tied only to this stake certificate mechanism, in order to assuage the fear of forwarding nodes that the HTLCs will not be claimed immediately.
Regards,
ZmnSCPxj