Hi Gleb et al, I really appreciate the out-of-the-box thinking of this proposal. I will put to the side the very difficult task of creating a cryptosystem that efficiently achieves what's necessary for this to work because that seems not to be the main concern.
I agree with Z that this proposal is missing a strong argument as to why this is a better "proof-of-stake" than channel balances themselves. In order to send a jamming HTLC you have to have to lock up funds to do it (they need outgoing balance for the sender and incoming balance for the receiver). Why would stake certificates be more powerful than this? I get that you decrement the UTXO's credit even if they fail. This increases the cost of sending spam (but it also increases the cost of sending normal payments since you now may be honest but have all your UTXOs run out of credit.) Does this increased cost (it was not zero before) actually prevent the attack without inhibiting normal usage? In general there seems to be an open question about whether these channel jamming attacks are actually economic. If I want to get more payments routed through me would it really be optimal to do channel jamming? Suppose that the nodes react to the jamming by adding extra capacity by splicing out from somewhere else. Then I have jammed up my own coins and got nothing for it. What if instead of attacking I allocated the coins instead to creating more valuable channels. Couldn't this be more profitable? I just posed this question in [1]. If we are talking about non-economic adversaries who simply wish to destroy LN then that's another game altogether. For example if the CCP with its 1% of all Bitcoin it seized from the plustoken scam were to try and attack lightning they would likely succeed even if we had this system in place simply because they have a lot of "stake". As David points out I don't think you can make a distinction between real LN outputs and fake ones. It seems unavoidable that any coins you own could be used to produce a certificate to give you spam bandwidth (especially if you actually manage to guarantee privacy through ZKPs). [1] https://github.com/t-bast/lightning-docs/issues/7 Cheers, LL On Sun, Nov 29, 2020 at 5:25 AM David A. Harding <d...@dtrt.org> wrote: > On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote: > > > > Hello list, > > Gleb and Antoine, > > This is an interesting idea! Thank you for working on it. > > I had difficulty with one part of the proposal: > > > #### Should we allow holding *any* Bitcoins (not just LN channels) for > Stake Certificates? > > > > [...] we believe that allowing any UTXO would give an attacker more > > opportunities to use their cold funds for this attack, or even have a > > secondary market where holders sell their proofs (they have nothing to > > loose). > > Can't a malicious user get around this restriction by opening channels > with themself? (Also, aren't current channel open outputs just P2WSH > 2-of-2 multisigs, and in the future won't they be generic P2TR outputs? > How would a stake certificate prove that the UTXO was generated for LN > rather than just belonging to a user with a 2-of-2 multisig wallet or > any key-path-spendable taproot wallet?) > > According to some random website, the current total channel balance of > the public LN is about 1,000 BTC. Although I'm sure this will grow with > time, it seems to me that an attacker who can rent access to stake > certificates for a one-week attack at, say, a 5% annual interest rate > would only need to pay 1 BTC to acquire stake certificates equal to all > honest users at present. That cost doesn't seem high enough to me to > effectively prevent attacks. Am I missing something? > > Thanks, > > -Dave > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
