Nostr notes by

📅 Original date posted:2021-10-13 📝 Original message: Hello ...

2023-06-09T15:04:14+02:00

In reply to nevent1q…gyza
_________________________

📅 Original date posted:2021-10-13
📝 Original message:
Hello Matt, can you clarify what you mean with this particular paragraph?:

But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.

So the use case here is more narrow? You mean that the recipient is a
mobile user that has his phone locked?
Just so I understand better what the problem is.

On Wed, 13 Oct 2021 at 12:44, Matt Corallo <lf-lists at mattcorallo.com> wrote:

> I'm sure most of y'all are familiar with this problem by now - a lightning
> user on a phone trying to
> pay another lightning user on a phone requires some amount of coordination
> to ensure the sender and
> recipient are, roughly, online at the same time.
>
> Invoices provide this somewhat today by requiring the recipient provide
> some live-ish data to the
> sender with their phone in their hand.
>
> But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.
>
> There's a few things live today which make progress towards this goal, but
> don't quite get there
> (and mostly aren't trying to solve this problem, but are worth mentioning):
>
> * just have the recipient use a custodial product/run a full lightning
> node at home on an RPi.
> Obviously this has some pretty substantial drawbacks, I'm not sure I
> even need to list them, but
> the "just require the recipient use a custodial service" is what Twitter
> ended up shipping with for
> lightning tipping, and we should all probably feel ashamed that they felt
> the need to do that.
>
> * Blockstream Greenlight.
> This change the online-requirements model - with the keys on your
> phone/elsewhere you still have
> to have your phone online with the same requirements as running a full
> lightning node. It just means
> fewer resources on that device.
>
> * use keysend/AMP/whatever.
> This is great for tips, but only half the story. Sender goes to send a
> keysend payment, gets to
> one hop before the recipient, and then a day later the recipient comes
> online to find the payment
> long-since timed out and failed backwards. Or you could use a long CLTV on
> the payment to make sure
> the recipient has time to claim it, which is basically a DoS on the
> lightning network's capacity,
> one that may eventually be fixed, breaking your payments, and which is
> just generally antisocial.
> Still, my understanding is some folks do this today cause its the only
> option for a mobile device.
>
> * lnurl
> ...is a great way to get an invoice, presumably from a trusted LSP for
> the recipient, trusting
> them to not give the same invoice twice, but doesn't help the recipient
> receive the payment, they
> still need to be online, unless...
>
> * have a fully-trusted LSP that accepts payments and forwards them later
> this is also fine, where its practical, I guess, but I'd hope we can
> do better. Worse, as far as
> I understand the places where this is practical are becoming fewer and
> fewer as the regulatory
> uncertainty clears and everyone realizes the regulatory overhead of this
> is...well you might as well
> start applying for that banking charter now.
>
> * have an untrusted LSP that sends you a notification to open the app
> when a payment is received
> Several lightning apps do this today, and its somewhat of a stop-gap
> but does help. On platforms
> where the app gets some meager CPU time in response to a notification,
> this can even fully solve the
> problem by claiming the HTLC in response to the notification pushed
> out-of-band. Sadly, the refrain
> I've heard repeatedly is, these days, on both Android and especially iOS,
> you can't even rely on a
> microsecond of CPU time in response to a notification. The OS fully
> expects your app to run code
> only when its on and in the foreground, unless you're a VoIP app you're
> screwed. Relying on the user
> to open the app immediately when they receive a notification is...fine, I
> guess, absent a better
> idea it seems like the best we've got today, but I'm not sure you'd find a
> UX designer who would
> *suggest* this :).
>
>
> But what would it take to do better? What follows is a simple straw-man,
> but something that's
> borderline practical today and may at least generate a few ideas. It comes
> in two variants
>
> If we accept the lnurl trust model of "a third-party I can give a list of
> pre-signed invoices, which
> I trust to never provide an invoice twice, but otherwise is untrusted",
> then we could do something
> like this:
>
> Step 1. Tipper gets an invoice from the lnurl endpoint they wish to pay,
> which contains some
> "recipient is behind an LSP and rarely online, act accordingly" flag.
>
> Step 2. Tipper sender sends a HTLC with a long CLTV timeout to their own
> LSP with instructions
> saying "when you get an onion message telling you nonce B, forward this
> HTLC, until then, just sit
> on it". The LSP accepts this HTLC but does not forward it and is generally
> okay with the long CLTV
> delta because it would otherwise just be the users' balance anyway - if
> they want to encumber their
> own funds forever, no harm done.
> Note that if tipper is online regularly they can skip this step and
> move on.
>
> Step 3. The Tipper sends an onion message to recipient's LSP saying "hey,
> when recipient is online
> again, use the included reply path to send nonce B to my LSP".
>
> - sender can now safely go offline -
>
> Step 4. When the Recipient comes online, their LSP sends the reply to the
> Tipper's LSP,
>
> Step 5. causing the Tipper's LSP to (finally) forward the original HTLC,
> which the Recipient receives.
>
> You'll note that this solution, unlike simply sending a high-CLTV HTLC,
> does not encumber funds for
> any extended period of time except for the original sender, who wants to
> send the funds off
> elsewhere anyway. Nor does it rely on any parties who can at any point run
> away with the funds (or
> reasonably be construed as custodians for the funds). Further, this
> solution does not rely on the
> sender deanonymizing themselves to the recipient (or even informing the
> recipient who the senders'
> LSP is).
>
> Note that lnurl here could be replaced with BOLT 12 if BOLT 12 gets some
> flag indicating the Tipper
> should ask an LSP for the invoice.
>
> But, okay, so the lnurl model of a trusted party not reusing invoices so
> that the Recipient's LSP
> cannot just steal all funds after the first claim kinda really sucks, how
> do we do better?
>
> The Obvious (tm) solution here is PTLCs - just have the sender always add
> some random nonce * G to
> the PTLC they're paying and send the recipient a random nonce in the
> onion. I'd generally suggest we
> just go ahead and do this for every PTLC payment, cause why not? Now the
> sender and the lnurl
> endpoint have to collude to steal the funds, but, like, the sender could
> always just give the lnurl
> endpoint the money. I'd love suggestions for fixing this short of PTLCs,
> but its not immediately
> obvious to me that this is possible.
>
> Thanks to Steve for pushing on the "how does a let users get tips in
> lightning" issue, various
> people for giving him feedback and the relayed to me, AJ for the PTLC
> proposal, and Rusty for
> tireless drum-beating on onion messages and BOLT 12.
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/d180dac7/attachment.html>;

📅 Original date posted:2021-02-11 📝 Original message: This ...

2023-06-09T15:01:59+02:00

In reply to nevent1q…rwqy
_________________________

📅 Original date posted:2021-02-11
📝 Original message:
This looks cool but would hinder UX too much for certain scenarios: e.g. if
the escrow in place is part of a bitcoin exchange, then you require the
bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
users (which could maybe only have fiat). Am I right?

So are you saying that this is not doable without PTLCs (with simple HTLCs)
unless it's done like suggested?

On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Nadav and Andres,
>
> Thank you for bringing up this topic again.
>
> Let me provide a new twist to this old idea.
>
> This is the entire logic of the contract to the seller:
>
> SELLER && (BUYER || ESCROW)
>
> Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||`
> which is difficult and requires ECDH and proof that the ECDH was done
> correctly.
>
> But we can observe the De Morgan Theorem:
>
> A || B <=> !(!A && !B)
>
> So how about we *invert* the logic?
>
> So what we do is, we make *two* payments of the same amount:
>
> * Seller -> Buyer , claimable by BUYER && ESCROW key.
> * Buyer -> Seller, claimable by SELLER key.
>
> So the ritual is this:
>
> * Seller -> Buyer claimable by BUYER && ESCROW.
> * Buyer -> Seller claimable by SELLER.
> * Seller hands over item.
> * Buyer judges whether to accept, or complain to Escrow.
>
> Now let us consider our cases:
>
> * Buyer is satisfied with the product.
> * Buyer fails the Seller->Buyer payment after seller claims the
> Buyer->Seller payment, so Seller is paid and has no more obligations.
> * Buyer is dissastisfied and wants the Escrow to judge:
> * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who
> then clawbacks the payment to the seller.
> * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not
> ESCROW"), and the Seller->Buyer payment eventually times out, ending the
> obligation of the Seller.
>
> The "reverse" payment is effectively the inversion of logic by the De
> Morgan theorem, and the "normal case" (buyer ultimately pays seller) has
> the Escrow not revealing the privkey.
> In addition, in the case where Buyer is satisfied (i.e. both Buyer and
> Seller agree the trade is beneficial) the Escrow is never involved (the
> Escrow might have a timeout for the temporary ESCROW keypair, which it will
> eventually delete; since all payments on LN need a timeout anyway, this is
> fine) and thus does not know about the trade, except that some trade was
> requested (since it must provide a temporary ESCROW pubkey).
>
> This even provides a simple BUYER + ESCROW keypair that gives the seller a
> proof-of-refund, and of course the simple SELLER gives the buyer a
> proof-of-payment as well.
> It only just requires twice as much Bitcoins getting locked.
>
> Thoughts?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210211/c6a316f0/attachment.html>;

📅 Original date posted:2020-11-27 📝 Original message: Hey, ...

2023-06-09T15:01:34+02:00

In reply to nevent1q…utzn
_________________________

📅 Original date posted:2020-11-27
📝 Original message:
Hey,

On Fri, 27 Nov 2020 at 19:18, Bastien TEINTURIER <bastien at acinq.fr> wrote:

> Good morning list,
>
> This is an interesting approach to solve this problem, I really like the
> idea.
> It definitely deserves digging more into it: the fact that it doesn't add
> an additional
> payment makes it largely superior to upfront payment schemes in terms of
> UX.
>
> If we restrict these stake certificates to LN funding txs, which have a
> very specific format
> (multisig 2-of-2) there are probably smart ways to achieve this.
> If for example we're able to do it easily with Schnorr-based funding txs,
> it may be worth
> waiting for that to happen.
> I'm a bit afraid of having to use ZKPs for general statements, I'd prefer
> something tailored
> to that specific case (it would likely be more efficient and have less new
> assumptions - even
> though you're right to point out that this is a non-critical system, so
> we're freer to experiment
> with hot new stuff).
>
> I completely agree with Z that it should be added to the requirements that
> a node cannot
> reuse a stake certificate from another node for himself.
>
> Another constraint is that the proof has to be small, since we have to fit
>> it all in a small onion...
>>
>
> I'm not sure that's necessary. If I understand correctly, you're saying
> that because in your
> model, the sender (Alice) creates one stake certificate for each node in
> the route (Bob, Carol)
> and puts them in the onion.
>
> 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?

>
> Of course, this depends on the implementation details we choose, but I
> think it's worth stressing
> that these two models exist and are quite different.
>
> Thanks,
> Bastien
>
> Le ven. 27 nov. 2020 à 07:46, ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> a écrit :
>
>> Good morning Gleb,
>>
>> > Thank you for your interest :)
>> >
>> > > Quick question: if I am a routing node and receive a valid stake
>> certificate, can I reuse this stake certificate on my own outgoing payments?
>> >
>> > That probably should be avoided, otherwise a mediocre routing node gets
>> a lot of jamming opportunities for no good.
>> >
>> > You are right, that’s a strong argument for proof “interactivity”:
>> every Certificate should probably commit to *at least* public key of the
>> routing node it is generated for.
>>
>> Right, it would be better to have the certificate commit to a specific
>> routing node rather than the payment hash/point as I proposed.
>> Committing to a payment hash/point allows a random forwarding node to
>> probe the rest of the network using the same certificate, lowering the
>> score for that certificate on much of the network.
>>
>> Another constraint is that the proof has to be small, since we have to
>> fit it all in a small onion...
>>
>> Presumably we also want the score to eventually "settle to 0" over time.
>>
>> Regards,
>> ZmnSCPxj
>>
>> >
>> > – gleb
>> > On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj <ZmnSCPxj at protonmail.com>,
>> wrote:
>> >
>> > > Good morning Gleb and Antoine,
>> > >
>> > > This is certainly interesting!
>> > >
>> > > Quick question: if I am a routing node and receive a valid stake
>> certificate, can I reuse this stake certificate on my own outgoing payments?
>> > >
>> > > It seems to me that the proof-of-stake-certificate should also
>> somehow integrate a detail of the current payment (such as payment
>> hash/point) so it cannot be reused by routing nodes for their own outgoing
>> payments.
>> > >
>> > > For example, looking only at your naive privacy-broken proposal, the
>> signature must use a `sign-to-contract` where the `R` in the signature is
>> actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
>> > >
>> > > Regards,
>> > > ZmnSCPxj
>> > >
>> > > > Hello list,
>> > > >
>> > > > In this post, we explore a different approach to channel jamming
>> mitigation.
>> > > > We won’t talk about the background here, for the problem
>> description as well as some proposed solutions (mainly upfront payment
>> schemes), see [1].
>> > > >
>> > > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake
>> Certificates) to solve this problem. Previously, these proofs were only
>> used in the Lightning Network at channel announcement time to prevent
>> malicious actors from announcing channels they don’t control. One can think
>> of it as a “fidelity bond” (as a scarce resource) as a requirement for
>> sending HTLCs.
>> > > >
>> > > > We start by overviewing issues with other solutions, and then
>> present a naive, privacy-broken Stake Certificates. Then we examine
>> designing a privacy-preserving version, evaluating them. At the end, we
>> talk about non-trivial design decisions and open questions.
>> > > >
>> > > > ## Issues with other proposals
>> > > >
>> > > > We find unsatisfying that upfront payment schemes come at a cost of
>> new fees (forward and/or backward), thus inflating payment cost for *any*
>> payment.
>> > > > In the future, the upfront base fee might even make “micropayments”
>> economically infeasible by exceeding the value they transfer. Thus, a good
>> solution should not inflate payment cost while still requiring “burning” a
>> scarce resource (so that the attack is not free).
>> > > >
>> > > > Another issue with upfront payments is a circular trust dependency.
>> Ideally, we shouldn’t introduce anything less trust-minimized than the
>> Lightning Network itself.
>> > > > Upfront payment schemes are not like that, because they in one way
>> or another rely on the honest behavior of route participants.
>> > > >
>> > > > We believe Stake Certificates we are going to introduce are
>> satisfactory in both of these directions: they don’t inflate payment costs
>> for honest users and don’t require trust. The main disadvantage of Stake
>> Certificates seems to be the novel cryptography required.
>> > > > See more details in the “Evaluation” section.
>> > > >
>> > > > ## Channel Ownership Proofs as Routing Credit Balance
>> > > >
>> > > > Let’s say Alice wants to relay an HTLC to Carol through Bob. Per
>> the Stake Certificates scheme, she has to commit to a particular channel
>> UTXO by embedding an ownership proof in the onion packet while sending an
>> HTLC to Bob.
>> > > >
>> > > > Bob then unwraps the onion and verifies:
>> > > > 1) the channel identifier is pointing unambiguously to an on-chain
>> UTXO;
>> > > > 2) the ownership proof (e.g., a signature) is valid against the
>> previously disclosed UTXO witness script.
>> > > >
>> > > > If all those checks succeed, Bob should see if Alice hasn’t
>> exceeded her credit balance. In case she hasn’t, Bob has to “decrement
>> Alice’s credit balance” and relay the HTLC to Carol.
>> > > > Decrementing credit balance unconditionally of packet success or
>> failure bounds liquidity abuse by malicious HTLC senders.
>> > > > Since there is no credit assigned initially, “decrementing the
>> credit balance” means just remembering that “Alice spent X out of Y of the
>> credit she received for her Stake Certificates”.
>> > > >
>> > > > Unfortunately, this naive protocol is a privacy nightmare, because
>> routing nodes can now easily assign every HTLC they forward to the sender’s
>> UTXO.
>> > > >
>> > > > Let’s first define the terms here one more time, and then proceed
>> to the non-naive, private Stake Certificates.
>> > > >
>> > > > - Stake Certificate. Either means a solution we’re proposing or the
>> primitive it is based on, namely proof of UTXO ownership. As we will argue
>> later, it actually makes sense to use proof of LN channel UTXO ownership
>> specifically rather than any funds ownership.
>> > > > - Stake Certificate value. An amount of the corresponding UTXO or a
>> ballpark this amount provably belongs to.
>> > > > - Credit balance. When Alice provides a routing node Bob with a
>> Stake Certificate, Bob should increase Alice’s routing credit balance.
>> Alice is then limited in her payments by this balance, and this rule is
>> enforced by routing nodes to prevent free channel jamming in the network.
>> Note that ideally “Alice’s credit balance“ should be virtual and only known
>> to Alice, while routing nodes should only observe per-UTXO credit balance.
>> We currently assume that each routing node keeps track of per-UTXO credit
>> balance separately, see “Design decisions” for more details.
>> > > > - Stake-to-credit function defines how much credit balance is given
>> per a Stake Certificate of a given value. This function is a policy of a
>> routing node, and it should be announced.
>> > > > - Credit-to-value-transferred function defines how much value a
>> sender can transfer along a given channel considering how much credit they
>> might claim. The function may also consider different factors (e.g., the
>> available capacity of a channel being used) to provide extra robustness.
>> > > >
>> > > > ## Privacy-preserving Stake Certificates
>> > > >
>> > > > The presented scheme could preserve privacy if it relied on
>> zero-knowledge proofs of UTXO ownership by avoiding pointing to a
>> particular UTXO.
>> > > > More specifically, the verifier should be able to check that:
>> > > > a) The staked UTXO is an element of the current UTXO set
>> > > > b) The prover knows the witness script committed by the UTXO
>> witness program
>> > > > c) The prover knows a valid witness for the witness script
>> > > > d) The staked UTXO was not used to produce a different Stake
>> Certificate which is currently in use as well.
>> > > >
>> > > > The verifier should also have a way to see a Stake Certificate
>> value to properly account for the credit. This can be achieved by
>> restricting the UTXO set being proved upon to only those UTXOs with a
>> specific range of values: “I will prove that I own a UTXO among all UTXOs
>> between 0.5 BTC and 1 BTC”.
>> > > >
>> > > > Unfortunately, steps (b) and (c) require zero-knowledge protocols
>> for general statements, which are more experimental primitives than most of
>> the stuff we have in Bitcoin protocols,
>> > > > although we assume it’s feasible to consider them for non-consensus
>> stuff.
>> > > >
>> > > > ## Evaluation
>> > > >
>> > > > Stake Certificates, upfront payment schemes, and other potential
>> solutions (given a particular configuration) may be compared along the
>> following axis:
>> > > > 1) Economic feasibility
>> > > > 1a) What is the cost of overcoming the protection for an attacker?
>> Likely a non-linear function: sats_spent =f(channels_to_jam, […])
>> > > > 1b) How does this solution limit honest users?
>> > > > 2) How sophisticated is this solution in terms of integration and
>> making good UX?
>> > > > 3) How complex is this solution in terms of protocol
>> design/implementation?
>> > > >
>> > > > When it comes to (1a), both Stake Certificates and upfront payments
>> are probably equal, in a way that they’re just best-effort ideas to
>> increase the attack cost. Unfortunately, we currently don’t know how to
>> design something as economically powerful as PoW in Bitcoin [3].
>> > > > This aspect can be properly evaluated by applying these ideas to
>> different hypothetical kinds of LN in a simulation and observing the
>> resulting trade-off between (1a) and (1b) considering different attack
>> strategies.
>> > > >
>> > > > In the previous sections of this post, we have argued that Stake
>> Certificates may provide a much better (1b) for the cost of (3) because it
>> relies on zero-knowledge.
>> > > > When it comes to (2), the design of Stake Certificates may vary in
>> terms of UX burden, from completely automatic to requiring custom actions
>> with private keys from users.
>> > > >
>> > > > Some of these trade-offs along with other interesting questions are
>> discussed in the following section.
>> > > >
>> > > > ## Design decisions and questions
>> > > >
>> > > > #### Should the credit spending be gossipped across the entire
>> network, or should only the routing nodes involved in the payment know?
>> > > >
>> > > > Economically, these two approaches are likely to be equivalent, and
>> it’s just a matter of stake-to-credit ratio.
>> > > > However, announcing credit spending to the network results in a
>> privacy leak. It also imposes bandwidth and CPU overhead on the routing
>> nodes.
>> > > >
>> > > > #### Which zero-knowledge system should be used for Stake
>> Certificates?
>> > > >
>> > > > Choosing a ZK system boils down to picking the right trade-offs of
>> proving and verifying time, and assumptions. As we mentioned previously, we
>> would need proving general statements.
>> > > > At the same time, we need something cheap in both proving and
>> verification, because Lightning is supposed to be fast.
>> > > > At the same time, the setup probably doesn’t matter, because proofs
>> are supposed to be verified only by one participant, a routing node this
>> proof is generated for.
>> > > > Perhaps we can also pick any cryptographic assumptions we want
>> since this stuff is not mission-critical and can be easily updated if
>> someone breaks a cryptographic assumption and we observe an attack.
>> > > >
>> > > > #### Should we allow holding *any* Bitcoins (not just LN channels)
>> for Stake Certificates?
>> > > >
>> > > > This idea might make sense if we’re worried that some LN users
>> might want to send more payments than they can afford per their credit.
>> However, 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).
>> > > > Instead, we should a) design the credit-to-stake-functions better;
>> b) encourage users send payments across different routing nodes (since
>> credits are not tracked globally) [4].
>> > > >
>> > > > #### What’s the best credit-to-value-transferred function?
>> > > >
>> > > > We reckon that this function should be not just linear to provide
>> maximum security against malicious channel jammers. For example, we can
>> charge more credit for the last 20% of the capacity of the *channel used
>> for routing*. Alternatively, we could discourage making too many payments
>> from the same UTXO within a short period of time by charging more credit in
>> this case.
>> > > >
>> > > > #### What about the interactivity and lifetime of Stake
>> Certificates?
>> > > >
>> > > > Interactive proofs mean that they are constructed on demand of a
>> routing node, non-interactive means constructed by a payment sender ahead
>> of time.
>> > > > Both interactivity and lifetime have something to do with the ease
>> of producing proof and accessing keys.
>> > > > We will omit the details of the trade-off we consider, but it
>> remains an open question.
>> > > >
>> > > > #### If Stake Certificates are valid for N blocks after proof
>> generation, does it mean that if the UTXO is spent during those N blocks,
>> new proof can be generated from the same coins without invalidating the old
>> proof?
>> > > >
>> > > > Yes, but an attacker would, first of all, have to pay an on-chain
>> fee for this. If we’re still worried about this problem, there are
>> workaround ideas.
>> > > > For example, we could have epochs of 100 blocks (every epoch starts
>> at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the
>> UTXO set, it provides very little credit.
>> > > > Alternatively, we could expand the zero-knowledge part to proving
>> that the coins were not yet spent.
>> > > >
>> > > > #### Should spending a UTXO reveal all Stake Certificates generated
>> from it?
>> > > >
>> > > > This would also solve the problem in the previous question, but it
>> would mean a retrospective privacy leak again. To avoid a privacy leak, we
>> should prevent this.
>> > > >
>> > > > #### What if malicious Sybil *routing* nodes failing payments
>> causing other honest routing nodes to reduce the credit of an honest
>> payment sender?
>> > > >
>> > > > Both Stake Certificates and upfront payment schemes suffer from
>> malicious routing nodes failing the payments and “wasting” the sender’s
>> credit or fees. This problem even applies out of the channel jamming
>> context, when considering payment failure rate.
>> > > > This problem can be addressed by reducing the reputation of faulty
>> links and routing nodes on the payment sender node. When payment routing
>> becomes a for-profit activity, this would encourage routing nodes to
>> sanitize their links.
>> > > > The mitigation can be even stronger by using “provable blaming”
>> introduced in [2].
>> > > >
>> > > > ## Conclusion
>> > > >
>> > > > We propose Stake Certificates, a new solution to channel jamming.
>> Perhaps, it might not be the best near-term solution due to the complexity,
>> but the zero satoshi overhead for honest payments is an appealing argument
>> to switch to it in the future.
>> > > > This proposal also illustrates how stake-based protocols can solve
>> Sybil challenges in the Bitcoin ecosystem. Since this might be useful in
>> other contexts (Sybil-resistance of many kinds, proof-of-ownership),
>> discussing Stake Certificates is even more useful.
>> > > > The next step is a discussion of Stake Certificates. If the
>> community finds it interesting, then we should discuss the design questions
>> mentioned above, and choose a cryptosystem.
>> > > >
>> > > > Cheers,
>> > > > Gleb Naumenko and Antoine Riard
>> > > >
>> > > > ———
>> > > >
>> > > > References and footnotes:
>> > > > 1.
>> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
>> > > > 2.
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
>> > > > 3. We don’t actually suggest PoW to solve these issues, because a)
>> the trade-off between honest user cost and attacker cost is misaligned due
>> to specialized hardware and b) smartphones would die too fast if they have
>> to compute PoW; PoW is just an unreachable example of system robustness due
>> to well-aligned game theory.
>> > > > 4. Secondary markets are still possible even if we restrict
>> acceptable proofs to only LN channels, but supply would be much smaller,
>> and markets would work much worse for an attacker.
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201127/ca1ded55/attachment-0001.html>;