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