{"type":"rich","version":"1.0","title":"Carla Kirk-Cohen [ARCHIVE] wrote","author_name":"Carla Kirk-Cohen [ARCHIVE] (npub17x…anw36)","author_url":"https://yabu.me/npub17xugd458km0nm8edu8u2efuqmxzft3tmu92j3tyc0fa4gxdk9mkqmanw36","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-19\n🗒️ Summary of this message: The text is a summary of the annual specification meeting held in NYC. It includes discussions on package relay, commitment transactions, and zero fee commitments.\n📝 Original message:\nHi List,\n\nAt the end of June we got together in NYC for the annual specification\nmeeting. This time around we made an attempt at taking transcript-style\nnotes which are available here:\nhttps://docs.google.com/document/d/1MZhAH82YLEXWz4bTnSQcdTQ03FpH4JpukK9Pm7V02bk/edit?usp=sharing\n.\nTo decrease our dependence on my google drive I've also included the\nfull set of notes at the end of this email (no promises about the\nformatting however).\n\nWe made a semi-successful attempt at recording larger group topics, so\nthese notes roughly follow the structure of the discussions that we had\nat the summit (rather than being a summary). Speakers are not\nattributed, and any mistakes are my own.\n\nThanks to everyone who traveled far, Wolf for hosting us in style in\nNYC and to Michael Levin for helping out with notes \u003c3\n\n# LN Summit - NYC 2023\n\n## Day One\n\n### Package Relay\n- The current proposal for package relay is ancestor package relay:\n  - One child can have up to 24 ancestors.\n  - Right now, we only score mempool transactions by ancestry anyway, so\nthere isn’t much point in other types of packages.\n- For base package relay, commitment transactions will still need to have\nthe minimum relay fee.\n  - No batch bumping is allowed, because it can open up pinning attacks.\n  - With one anchor, we can package RBF.\n- Once we have package relay, it will be easier to get things into the\nmempool.\n- Once we have V3 transactions, we can drop minimum relay fees because we\nare restricted to one child pays for one parent transaction:\n  - The size of these transactions is limited.\n  - You can’t arbitrarily attach junk to pin them.\n- If we want to get rid of 330 sat anchors, we will need ephemeral anchors:\n  - If there is an OP_TRUE output, it can be any value including zero.\n  - It must be spent by a child in the same package.\n  - Only one child can spend the anchor (because it’s one output).\n  - The parent must be zero fee because we never want it in a block on its\nown, or relayed without the child.\n  - If the child is evicted, we really want the parent to be evicted as\nwell (there are some odd edge cases at the bottom of the mempool, so zero\nensures that we’ll definitely be evicted).\n- The bigger change is with HLTCs:\n  - With SIGHASH_ANYONECANPAY, your counterparty can inflate the size of\nyour transaction - eg: HTLC success, anyone can attack junk.\n  - How much do we want to change here?\n- So, we can get to zero fee commitment transactions and one (ephemeral)\nanchor per transaction.\n  - With zero fee commitments, where do we put trimmed HTLCs?\n     - You can just drop it in an OP_TRUE, and reasonably expect the miner\nto take it.\n- In a commitment with to_self and to_remote and an ephemeral anchor that\nmust be spent, you can drop the 1 block CSV in the transaction that does\nnot have a revocation path (ie, you can drop it for to_remote).\n  - Any spend of this transaction must spend the one anchor in the same\nblock.\n  - No other output is eligible to have a tx attached to it, so we don’t\nneed the delay anymore.\n     - Theoretically, your counterparty could get hold of your signed local\ncopy, but then you can just RBF.\n- Since these will be V3 transactions, the size of the child must be small\nso you can’t pin it.\n  - Both parties can RBF the child spending the ephemeral anchor.\n  - This isn’t specifically tailored to lightning, it’s a more general\nconcept.\n  - Child transactions of V3 are implicitly RBF, so we won’t have to worry\nabout it not being replaceable (no inheritance bug).\n- In general, when we’re changing the mempool policy we want to make the\nminimal relaxation that allows the best improvement.\n- We need “top of block” mempool / cluster mempool:\n  - The mempool can have clusters of transactions (parents/children\narranged in various topologies) and the whole mempool could even be a\nsingle cluster (think a trellis of parents and children “zigzagging”).\n  - The mining algorithm will pick one “vertical” using ancestor fee rate.\n  - There are some situations where you add a single transaction and it\nwould completely change the order in which our current selection picks\nthings.\n  - Cluster mempool groups transactions into “clusters” that make this\neasier to sort and reason about.\n  - It can be expensive (which introduces a risk of denial of service), but\nif we have limits on cluster sizes then we can limit this.\n  - This is the only way to get package RBF.\n- How far along is all of this?\n  - BIP331: the P2P part that allows different package types is moving\nalong and implementation is happening. This is done in a way that would\nallow us to add different types of packages in future if we need them.\n     - There are some improvements being made to core’s orphan pool,\nbecause we need to make sure that peers can’t knock orphans out of your\npool that you may later need to retrieve as package ancestors.\n     - We reserve some spots with tokens, and if you have a token we keep\nsome space for you.\n  - V3 transactions: implemented on top of package relay, since they don’t\nreally make sense without it. This is an opt-in regime where you make\nthings easier to RBF.\n  - Ephemeral Anchors: on top of package relay and V3.\n  - Cluster Mempool: This is further out, but there’s been some progress.\nRight now people are working on the linearization algorithm.\n- If these changes don’t suit lightning’s use case, now is the time to\nspeak because it’s all being worked on.\n  - In what way does it not fit LN, as it’s currently designed?\n     - With the V3 paradigm, to stop all pinning vectors, HTLC transactions\nwill need to get anchors and you will have to drop ANYONECANPAY (to use\nanchors instead).\n     - Could we fix this with additional restrictions on V3 (or a V4)?\n     - You could do something where V4 means that you can have no ancestors\nand no descendants (in the mempool).\n     - V3 restricts the child, you could also restrict the parent further.\n     - You could have a heuristic on the number of inputs and outputs, but\nanyone can pay or add inputs.\n     - You could commit to the whole thing being some size by setting a\nseries of bits in sequence to mark maximum size but that would involve\nrunning script (which is annoying).\n     - The history of V3 was to allow a parent of any size because\ncommitment transactions can be any size.\n- What about keeping HTLCs the way they are today?\n  - A lot of other things are less pineapple, maybe that’s ok? It’s a step\nforward.\n  - The long term solution is to change relay policy to top of mempool. We\nshouldn’t be doing things until the long term solution is clear, and we\nshouldn’t change the protocol in a way that doesn’t fit with the long term.\n  - We already do a lot of arbitrary things, if we were starting from day\none we wouldn’t do HTLCs with anchors (it’s too much bloat), and being\nunable to RBF is more bloat because you overpay.\n  - If the remote commitment is broadcast, you can spen the HTLC with V2.\nYou can’t add a V3 child (it won’t get in the mempool).\n  - If you want to be consistent, even when it’s the remote commit you need\na presigned transaction, we should just use it as designed today.\n- What is the “top of mempool” assumption?\n  - If large transactions are at the top of your mempool, you (a miner)\nwant transactions with higher fee rates to increase your total revenue.\n  - Today, you can’t really easily answer or reason about these questions.\n  - We want to accept transactions in our mempool in a denial of service\nresistant way that will strictly increase our miner fees.\n  - If a transaction is at the top of your mempool, you may be more willing\nto accept a replacement fee. If it’s way down in the mempool, you would\nprobably replace more slowly.\n  - It’s conceivable that we could get here, but it’s years off.\n     - Once we have this, pinning only happens with large transactions at\nthe bottom of the mempool. If you just slow roll these transactions, you\ncan just relay what you’ve got.\n     - If somebody comes and replaces the bottom with something small\nthat’ll be mined in the next two blocks, you clearly want to accept that.\n- Does cluster mempool fix rule 3?\n  - No but they help.\n  - Today when you get a transaction you don’t know which block it’s going\nin - we don’t have a preference ordering.\n  - Miners don’t make blocks as they go - with cluster mempool you can make\nvery fast block templates.\n  - When talking about relay, you can ignore block making and just get a\nvery good estimate.\n- The question is: when do we jump?\n  - Wail until V3? Package Relay?\n     - Package relay will help. You still negotiate fees but they don’t\nmatter as much.\n     - We’d like to kill upate fee and have a magic number for fees, can we\ndo that when we get package relay?\n     - Package relay is the hard part, V3 should be relatively easier after\nthat.\n     - When we get V3 we can drop to zero fee.\n- Is there a future where miners don’t care about policy at all?\n  - Say, the block that I’m mining has V3 transactions. They’re just\nmaximizing fees so they’ll accept anything out of band, ignoring these new\npolicy rules.\n  - Accelerators are already starting to emerge today - how are they doing\nit?\n  - We’re carving out a small space in which mempool rules work, and it’s\nokay to work around it.\n  - If a miner mines it, great - that’s what we want. The problem is not\ngetting mined (ie pinning).\n- Figuring this out is not simple:\n  - Today there are times where we accept replacements when we should\nreject them and times where we reject replacements when we should accept\nthem.\n  - There can be situations where miners will mine things that aren’t\nincentive compatible (ie, not the best block template).\n- What if somebody pays out of band not to mine?\n- Ephemeral anchors are interesting, they never enter the UTXO set - if the\nchild gets evicted, you get evicted.\n  - The first transaction being zero is optimal, want to be sure it’ll be\nevicted (there are some mempool quirks).\n  - It must be zero fee so that it will be evicted.\n- Should we add trimmed HTLCs to the ephemeral anchor?\n  - We don’t want to get above min relay fee because then we could hang\naround in the mempool.\n  - The eltoo implementation currently does this.\n  - You can’t keep things in OP_TRUE because they’ll be taken.\n  - You can also just put it in fees as before.\n- More on cluster mempools:\n  - It can be used for block selection, but it’s currently focused on\nmempool selection.\n  - You can simulate template selection with it.\n  - When you’re mining, you have to pick from an ancestor downwards.\n  - First we lineralize the transactions to flatten the structure\nintelligently (by topology and fee rate).\n  - Then we figure out the best ordering of this flat structure.\n  - Each chunk in a cluster is less than 75 transactions, and a cluster has\nchunks of transactions.\n  - If you woul include a transaction with the ancestor, it goes in the\nsame chunk. Otherwise it goes in the next chunk.\n  - Miners select the highest fee rate chunks, lower fee rate ones can\nsafely be evicted.\n  - For replacement, you can just check replacement for a single cluster,\nrechunk it and then resort the chunks.\n     - It must beat the fee rate of the chunks to get in.\n     - You can check how much it beats the chunk by, whether it would go in\nthe next block(s) and then decide.\n  - Chunk ordering takes into account transaction size, beyond 25\ntransactions we just do ancestor set feerate.\n  - One of the limits is going away, one is sticking around. We still have\nsibling eviction issues.\n  - Is one of the issues with chunks is that they’re limited by transaction\nweight, 101 kilo-v-bytes, which is the maximum package size?\n     - We should be okay, these limits are higher than present.\n     - You can bound chunk size pretty easily.\n  - If we get chunk fee rate replacement then you can do batch fee bumping\n(eg, a bunch of ephemeral anchors that are all batched together).\n- Are there long term policy implications for privacy for ephemeral anchors?\n  - You’re essentially opting into transaction sponsors?\n  - If everyone uses V3 eventually there’s no issue.\n  - For right now, it would be nice if V3 is only for unilateral closes.\n  - It’s also useful in a custodial wallet setting, where you have one team\ncreating on chain transactions and the other attaching fees. This is a\ncommon accounting headache. People can also non-interactively fee bump.\n\n### Taproot\n- Spec is still in draft right now, and the code is a bit ahead of the test\nvectors.\n- The biggest change that has been made is around anchors, which become\nmore complicated with taproot:\n  - The revocation path on to_local takes the script path, so now we need\nto reveal data for the anchor.\n  - The downside is that revocation is more expensive - 32 more bytes in\nthe control block.\n- The to_remote has a NUMS point, previously we just had multisig keys:\n  - If you’re doing a rescan, you won’t know those keys.\n  - Now you just need to know the NUMS point and you can always rescan.\n  - The NUMS point itself is pretty verifiable, you just start with a\nstring and hash it.\n  - It is constant, you just use it randomized with your key.\n- The internal pubkey is constant on to_remote.\n- Co-op close [broke into several different discussions]:\n  - The idea here is to remove negotiation, since we’ve had disagreement\nissues in the past.\n  - In this version, the initiator just accepts the fee.\n  - Do we want negotiation?\n     - In the past we’ve had bugs with fee rate estimates that won’t budge.\n  - Why don’t we just pick our fees and send two sets of signatures?\n     - This would no longer be symmetric.\n     - What if nobody wants to close first? We’d need to work through the\ngame theory.\n     - The person who wants their funds has an incentive.\n  - Why is RBF so hard for co-op close?\n     - Closing should be marked as RBF, there’s no reason not to.\n     - Just pick your fee rate, pay it and then come back and RBF if you’d\nlike. You can bump/broadcast as much as you like.\n     - If we’re going to have something like that where we iterate, why\ndon’t we just do the simple version where we pick a fee and sign?\n     - If you have to pay the whole fee, you have less incentive to sign.\n  - Why is this linked to taproot work?\n     - It needs to change anyway, and we need to add nonces.\n  - What about, whoever wants to close sends a fee rate (paying the fees)\nand the responder just sends a signature?\n     - If you don’t have enough balance, you can’t close. But why do you\ncare anyway, you have no funds?\n     - We can do this as many times as we want.\n  - Shutdown is still useful to clear the air on the channel.\n  - When you reconnect, you start a new interaction completely.\n  - TL;DR:\n     - Shutdown message stays.\n     - You send a signature with a fee rate.\n     - The remote party signs it.\n     - If they disagree, you do it again.\n     - It’s all RBF-able.\n     - You must retransmit shutdown, and you must respond with a shutdown.\n     - You can send nonces at any time:\n     - In revoke and ack.\n     - On channel re-establish.\n- For taproot/musig2 we need nonces:\n  - Today we store the commitment signature from the remote party. We don’t\nneed to store our own signature - we can sign at time of broadcast.\n  - To be able to sign you need the verification nonce - you could remember\nit, or you could use a counter:\n     - Counter based:\n     - We re-use shachain and then just use it to generate nonces.\n     - Start with a seed, derive from that, use it to generate nonces.\n     - This way you don’t need to remember state, since it can always be\ngenerated from what you already have.\n     - Why is this safe?\n     - We never re-use nonces.\n     - The remote party never sees your partial signature.\n     - The message always stays the same (the dangerous re-use case is\nusing the same nonce for different messages).\n     - If we used the same nonce for different messages we could leak our\nkey.\n     - You can combine the sighash + nonce to make it unique - this also\nbinds more.\n     - Remote party will only see the full signature on chain, never your\npartial one.\n  - Each party has sign and verify nonces, 4 total.\n  - Co-op close only has 2 because it’s symmetric.\n\n### Gossip V1.5 vs V2\n- How much do we care about script binding?\n  - It it’s loose, it can be any script - you can advertise any UTXO.\n  - You revel less information, just providing a full signature with the\nfull taproot public key.\n  - If it’s tight, you have to provide two keys and then use the BIP 86\ntweak to check that it’s a 2-of-2 multisig.\n- Should we fully bind to the script, or just allow any taproot output?\n  - Don’t see why we’d want additional overhead.\n  - Any taproot output can be a channel - let people experiment.\n  - We shouldn’t have cared in the first place, so it doesn’t matter what\nit’s bound to.\n  - It’s just there for anti-DOS, just need to prove that you can sign.\n- Let every taproot output be a lightning channel, amen.\n- We’re going to decouple:\n  - You still need a UTXO but it doesn’t matter what it looks like.\n  - This also allows other channel types in future.\n  - We send:\n     - UTXO: unspent and in the UTXO set\n     - Two node pubkeys\n     - One signature\n- How much do we care about amount binding?\n  - Today it is exact.\n     - People use it for capacity graphs.\n     - Graph go up.\n     - We can watch the chain for spends when we know which UTXO to watch\nper-channel.\n  - Is there an impact on pathfinding if we over-advertize?\n     - We use capacity to pathfind.\n     - What’s the worst case if people lie? We don’t use them.\n  - If we’ve already agreed that this can be a UTXO that isn’t a channel,\nthen it shouldn’t matter.\n  - If you allow value magnification, we can use a single UTXO to claim for\nmultiple channels. Even in the most naive version (say 5x), you’re only\nrevealing 20% of your UTXOs.\n  - How much leverage can we allow? The only limit is denial of service.\n  - There’s the potential for a market for UTXOs.\n- There’s a privacy trade-off:\n  - If you one-to-one map them, then there’s no privacy gain.\n  - Do we know that you get substantial privacy?\n     - Even if you have two UTXOs and two channels, those UTXOs are now not\nlinked (because you can just use the first one to advertise).\n     - This is only assuming that somebody implements it/ infrastructure is\nbuilt out.\n     - People could create more elaborate things over time, even if\nimplementations do the “dumb” way.\n- Gossip 1.5 (ie, with amount binding) fits in the current flow, V2 (ie,\nwithout amount binding) has a very different scope.\n  - It’s a big step, and you don’t truly know until you implement it.\n  - What about things like: a very large node and a very small node, whose\nannounced UTXO do you use?\n- We decided not to put UTXOs in node announcement, so we’d put it in\nchannel announcement:\n  - Sometimes there’s a UTXO, sometimes there isn’t.\n  - You look at a node’s previous channels to see if they still have\n“quota”.\n  - If you don’t have “quota” left, you have to include a signature TLV.\n- With the goal of publicly announcing taproot channels, 1.5 gets us there\nand is a much smaller code change.\n- We’ve talked alot about capacity for pathfinding, but we haven’t really\ntouched on control valves like max HTLC:\n  - Currently we don’t use these valves to tune our pathfinding, people\ndon’t use it.\n  - If we get better here, we won’t need capacity.\n  - This value is already \u003c 50% anyway.\n- If we don’t un-bind amounts now, when will we do it?\n  - It’s always a lower priority and everyone is busy.\n  - If we allow overcommitting by some factor now, it’s not unrealistic\nthat it will allow some degree of privacy.\n  - Between these features, we have opened the door to leasing UTXOs:\n     - Before we do more over-commitment, let’s see if anybody uses it?\n- We add channel capacity to the channel announcement with a feature bit:\n  - If we turn the feature off, we are on-to-one mapped.\n  - But a node can’t use the upgraded version until everyone is upgraded?\n     - Our current “get everyone upgraded” cycle is 18 months (or a CVE).\n     - If you’re upgrading to 2x multiplier, nobody on 1x will accept that\ngossip.\n     - People will not pay for privacy (via lost revenue of people not\nseeing their gossip).\n     - This is additive to defeating chain analysis.\n     - Private UTXO management is already complicated, we don’t know the\nideal that we’re working towards.\n- What about if we just set it to 2 today?\n  - Is 2 qualitatively better than 1 (without script binding) today?\n  - Will a marketplace magically emerge if we allow over-commitment?\n- We don’t know the implications of setting a global multiplier for routing\nor denial of service, and we don’t have a clear view of what privacy would\nlook like (other than “some” improvement).\n- We agree that adding a multiplier doesn’t break the network.\n  - People with a lower value will see a subnet when we upgrade.\n- We’re going to go with gossip “1.75”:\n  - Bind to amount but not script.\n  - We include a TLV cut out that paves the way to overcommitment.\n\n### Multi-Sig Channel Parties\n- There are a few paths we could take to get multi-sig for one channel\nparty:\n  - Script: just do it on the script level for the UTXO, but it’s heavy\nhanded.\n  - FROSTy: you end up having to do a bunch of things around fault\ntolerance which require a more intense setup. You also may not want the\nshachain to be known by all of the parties in the setup (we have an ugly\nsolution for this, we think).\n  - Recursive musig:\n- Context: you have one key in the party, but you actually want it to be\nmultiple keys under the hood. You don’t want any single party to know the\nrevocation secrets, so you have to each have a part and combine them.\n- Ugliest solution: just create distinct values and store them.\n- Less ugly solution uses multiple shachains:\n  - Right now we have a shachan, and we reveal two leaves of it.\n  - You have 8 shachains, and you XOR them all together.\n     - Why do we need 8? That’ll serve a 5-of-7.\n     - Maybe we need 21? 5 choose 7, we’re not sure.\n  - How does this work with K-of-N?\n     - Each party has a piece, and you can always combine them in different\ncombinations (of K pieces) to get to the secret you’re using.\n\n### PTLCs\n- We can do PTLCs in two ways:\n  - Regular musig\n  - Adaptor signatures\n- Do they work with trampoline as defined today?\n  - The sender picks all the blinding factors today, so it’s fine.\n- There’s a paper called: splitting locally while routing\ninterdimensionally:\n  - You can let intermediate nodes do splitting because they know all the\nlocal values.\n  - Then can generate new blinding factors and split out to the next node.\n  - Adaptor signatures could possibly be combined for PTLCs that get fanned\nout then combined.\n- There are a few options for redundant overpayment (ie, “stuckless”\npayments):\n  - Boomerang:\n     - Preimages are coefficients of a polynomial, and you commit to the\npolynomial itself.\n     - If you have a degree P polynomial and you take P+1 shares, then you\ncan claim in the other direction.\n     - Quite complex.\n     - You have to agree on the number of splits in advance.\n  - Spear:\n     - H2TLC: there are two payment hashes per-HTLC, one if from the sender\nand one is from the invoice.\n     - When you send a payment, the sender only reveals the right number of\nsender preimages.\n     - This also gives us HTLC acknowledgement, which is nice.\n     - You can concurrently split, and then spray and pray.\n     - Interaction is required to get preimages.\n- Do we want to add redundant overpayment with PTLCs?\n  - We’ll introduce a communication requirement.\n  - Do we need to decide that before we do PTLCs?\n     - Can we go for the simplest possible option first and then add it?\n     - For spear, yes - the intermediate nodes don’t know that it’s two\nhashes.\n     - We could build them out without thinking about overpayment, and then\nmix in a sender secret so that we can claim a subset.\n  - We’ll have more round trips, but you also have the ability to ACK HTLCs\nthat have arrived.\n  - Spray and pray uses the same about as you would with our current “send\n/ wait / send”, it’s just concurrently not serially.\n- Is it a problem that HLTCs that aren’t settled don’t pay fees?\n  - You’re paying the fastest routes.\n  - Even if it’s random, you still get a constant factor of what we should\nhave gotten otherwise.\n- It makes sense to use onion messages if it’s available to us.\n- Are we getting payment acknowledgement? Seems so!\n\n## Day Two\n\n### Hybrid Approach to Channel Jamming\n- We’ve been talking about jamming for 8 years, back and forth on the\nmailing list.\n- We’d like to find a way to move forward so that we can get something\ndone.\n- Generally when we think about jamming, there are three “classes” of\nmitigations:\n  - Monetary: unconditional fees, implemented in various ways.\n  - Reputation: locally assessed (global is terrible)\n  - Scarce Resources: POW, stake, tokens.\n- The problem is that none of these solutions work in isolation.\n  - Monetary: the cost that will deter an attacker is unreasonable for an\nhonest user, and the cost that is reasonable for an honest user is too low\nfor an attacker.\n  - Reputation: any system needs to define some threshold that is\nconsidered good behavior, and an attacker can aim to fall just under it.\nEg: if you need a payment to resolve in 1 minute, you can fall just under\nthat bar.\n  - Scarce resources: like with monetary, pricing doesn’t work out.\n     - Paper: proof of work doesn’t work for email spam, as an example.\n     - Since scarce resources can be purchased, they could be considered a\nsubset of monetary.\n- There is no silver bullet for jamming mitigation.\n- Combination of unconditional fees and reputation:\n  - Good behavior grants access to more resources, bad behavior loses it.\n  - If you want to fall just below that threshold, we close the gap with\nunconditional fees.\n- Looking a these three classes implemented in isolation, are there any\nunresolved questions that people have - “what about this”?\n  - Doesn’t POW get you around the cold start problem in reputation where\nif you want to put money in to quickly bootstrap you can?\n     - Since POW can be rented, it’s essentially a monetary solution - just\nextra steps.\n     - We run into the same pricing issues.\n- Why these combinations?\n  - Since scarce resources are essentially monetary, we think that\nunconditional fees are the simplest possible monetary solution.\n- Unconditional Fees:\n  - As a sender, you’re building a route and losing money if it doesn’t go\nthrough?\n     - Yes, but they only need to be trivially small compared to success\ncase fee budgets.\n     - You can also eventually succeed so long as you retry enough, even if\nfailure rates are very high.\n  - How do you know that these fees will be small? The market could decide\notherwise.\n     - Routing nodes still need to be competitive. If you put an\nunconditional fee of 100x the success case, senders will choose to not send\nthrough you because you have no incentive to forward.\n     - We could also add an in-protocol limit or sender-side advisory.\n  - With unconditional fees, a fast jamming attack is very clearly paid for.\n- Reputation:\n  - The easiest way to jam somebody today is to send a bunch of HTLCs\nthrough them and hold them for two weeks. We’re focusing on reputation to\nbegin with, because in this case we can quite easily identify that people\nare doing something wrong (at the extremes).\n  - If you have a reputation score that blows up on failed attempts,\ndoesn’t that fix it without upfront fees?\n     - We have to allow some natural rate of failure in the network.\n     - An attacker can still aim to fall just below that failure threshold\nand go through multiple channels to attack an individual channel.\n     - THere isn’t any way to set a bar that an attacker can’t fall just\nbeneath.\n     - Isn’t this the same for reputation? We have a suggestion for\nreputation but all of them fail because they can be gamed below the bar.\n  - If reputation matches the regular operation of nodes on the network,\nyou will naturally build reputation up over time.\n     - If we do not match reputation accumulation to what normal nodes do,\nthen an attacker can take some other action to get more reputation than the\nrest of the network. We don’t want attackers to be able to get ahead of\nregular nodes.\n     - Let’s say you get one point for success and one for failure, a\nnormal node will always have bad reputation. An attacker could then send 1\nsay payments all day long, pay a fee for it and gain reputation.\n- Can you define jamming? Is it stuck HTLCs or a lot of 1 sat HTLCS\nspamming up your DB?\n  - Jamming is holding HTLCs to or streaming constant failed HTLCs to\nprevent a channel from operating.\n  - This can be achieved with slots or liquidity.\n- Does the system still work if users are playing with reputation?\n  - In the steady state, it doesn’t really matter whether a node has a good\nreputation or not.\n  - If users start to set reputation in a way that doesn’t reflect normal\noperation of the network, it will only affect their ability to route when\nunder attack.\n- Isn’t reputation monetary as well, as you can buy a whole node?\n  - There is a connection, and yes in the extreme case you can buy an\nentire identity.\n  - Even if you do this, the resource bucketing doesn’t give you a “golden\nticket” to consume all slots/liquidity with good reputation, so you’re\nstill limited in what you can do.\n- Can we learn anything from research elsewhere / the way things are done\non the internet?\n  - A lot of our confidence that these solutions don’t work in isolation is\nbased on previous work looking at spam on the internet.\n  - Lightning is also unique because it is a monetary network - we have\nmoney built in, so we have different tools to use.\n- To me, it seems like if the scarce resource that we’re trying to allocate\nis HTLC slots and upfront fees you can pay me upfront fees for the worst\ncase (say two weeks) and then if it settles if 5 seconds you give it back?\n  - The dream solution is to only pay for the amount of time that a HTLC is\nheld in flight.\n  - The problem here is that there’s no way to prove time when things go\nwrong, and any solution without a universal clock will fall back on\ncooperation which breaks down in the case of an attack.\n  - No honest user will be willing to pay the price for the worst case,\nwhich gets us back to the pricing issue.\n  - There’s also an incentives issue when the “rent” we pay for these two\nweeks worst case is more than the forwarding fee, so a router may be\nincentivized to just hang on to that amount and bank it.\n  - We’ve talked about forwards and backwards fees extensively on the\nmailing list:\n     - They’re not large enough to be enforceable, so somebody always has\nto give the money back off chain.\n     - This means that we rely on cooperation for this refund.\n     - The complexity of this type of system is very high, and we start to\nopen up new “non-cooperation” concerns - can we be attacked using this\nmechanism itself?\n     - Doesn’t an attacker need to be directly connected to you to steal in\nthe non-cooperative case?\n     - At the end of the day, somebody ends up getting robbed when we can’t\npull the money from the source (attacker).\n- Does everybody feel resolved on the statement that we need to take this\nhybrid approach to clamp down on jamming? Are there any “what about\nsolution X” questions left for anyone? Nothing came up.\n\n### Reputation for Channel Jamming\n- Resource bucketing allows us to limit the number of slots and amount of\nliquidity that are available for nodes that do not have good reputation.\n  - No reputation system is perfect, and we will always have nodes that\nhave low-to-no activity, or are new to the network that we can’t form\nreputation scores for.\n  - It would be a terrible outcome for lightning to just drop these HTLCs,\nso we reserve some portion of resources for them.\n- We have two buckets: protected and general (split 50/50 for the purposes\nof explanation, but we’ll find more intelligent numbers with further\nresearch):\n  - In the normal operation of the network, it doesn’t matter if you get\ninto the protected slots. When everyone is using the network as usual,\nthings clear out quickly so the general bucket won’t fill up.\n  - When the network comes under attack, an attacker will fill up slots and\nliquidity in the general bucket. When this happens, only nodes with good\nreputation will be able to use the protected slots, other HTLCs will be\ndropped.\n  - During an attack, nodes that don’t have a good reputation will\nexperience lower quality of service - we’ll gradually degrade.\n- What do you mean by the steady state?\n  - Nobody is doing anything malicious, payments are clearing out as usual\n- not sitting on the channel using all 483 slots.\n- We decide which bucket the HTLC goes into using two signals:\n  - Reputation: whether the upstream node had good reputation with our\nlocal node.\n  - Endorsement: whether the upstream node has indicated that the HTLC is\nexpected to be honest (0 if uncertain, 1 if expected to be honest).\n  - If reputation \u0026\u0026 endorsement, then we’ll allow the HTLC into protected\nslots and forward the HTLC on with endorsed=1.\n  - We need reputation to add a local viewpoint to this endorsement signal\n- otherwise we can just trivially be jammed if we just copy what the\nincoming peer said.\n  - We need endorsement to be able to propagate this signal over multiple\nhops - once it drops, it’s dropped for good.\n  - There’s a privacy questions for when senders set endorsed:\n     - You can flip a coin or set the endorsed field for your payments at\nthe same proportion as you endorse forwards.\n- We think about reputation in terms of the maximum amount of damage that\ncan be done by abusing it:\n  - Longest CLTV that we allow in the future from current height 2016\nblocks (~2 weeks): this it the longest that we can be slow jammed.\n  - Total route length ~27 hops: this is the largest amplifying factor an\nattacker can have.\n- We use the two week period to calculate the node’s total routing revenue,\nthis is what we have to lose if we are jammed.\n- We then look at a longer period, 10x the two week period to see what the\npeer has forwarded us over that longer period.\n- If they have forwarded us more over that longer period than what we have\nto loose in the shorter period, then they have good reputation.\n- This is the damage that is observable to us - there are values outside of\nthe protocol that are also affected by jamming:\n  - Business reliability, joy of running a node, etc\n  - We contend that these values are inherently unmeasurable to protocol\ndevs:\n     - End users can’t easily put a value on them.\n     - If we try to approximate them, users will likely just run the\ndefaults.\n- One of the simplest attacks we can expect is an “about turn” where an\nattacker behaves perfectly and then attacks:\n  - So, once you have good reputation we can’t just give you full access to\nprotected slots.\n- We want to reward behavior that we consider to be honest, so we consider\n“effective” HTLC fees - the fee value that a HTLC has given us relative to\nhow long it took to resolve:\n  - Resolution period: the amount of time that a HTLC can reasonably take\nto resolve - based on MPP timeout / 1 minute.\n  - We calculate opportunity cost for every minute after the first\n“allowed” minute as the fees that we could have earned with that\nliquidity/slot.\n  - Reputation is only negatively affected if you endorsed the HTLC.\n  - If you did not endorse, then you only gain reputation for fast success\n(allowing bootstrapping).\n- When do I get access to protected slots?\n  - When you get good reputation, you can use protected slots for your\nendorsed HTLCs but there is a cap on the number of in flight HLTCs that are\nallowed.\n  - We treat every HLTC as if it will resolve with the worst possible\noutcome, and temporarily dock reputation until it resolves:\n     - In the good case, it resolves quickly and you get your next HLTC\nendorsed.\n     - In the bad case, you don’t get any more HTLCs endorsed and you\nreputation remains docked once it resolves (slowly).\n- Wouldn’t a decaying average be easier to implement, rather than a sliding\nwindow?\n  - If you’re going to use large windows, then a day here or there doesn’t\nmatter so much.\n- Have you thought about how to make this more visible to node operators?\n  - In the steady state we don’t expect this to have any impact on routing\noperations, so they’ll only need a high level view.\n- Can you elaborate on slots vs liquidity for these buckets?\n  - Since we have a proportional fee for HTLCs, this indirectly represents\nliquidity: larger HTLCs will have larger fees so will be more “expensive”\nto get endorsed.\n- Where do we go from here?\n  - We would like to dry run with an experimental endorsement field, and\nask volunteers to gather data for us.\n  - Are there any objections to an experimental TLV?\n     - No.\n     - We could also test multiple endorsement signals / algorithms in\nparallel.\n- In your simulations, have you looked at the ability to segment off\nattacks as they happen? To see how quickly an attacker's reputation drops\noff, and that you have a protected path?\n  - Not yet, but plan to.\n- Do any of these assumptions change with trampoline? Don’t think it’s\nrelated.\n- Your reputation is at stake when you endorse, when do you decide to\nendorse my own payments?\n  - You do the things you were already doing to figure out a good route.\nPaths that you think have good liquidity, and have had success with in the\npast.\n- What about redundant overpayment, some of your HTLCs are bound to fail?\n  - Provided that they fail fast, it shouldn’t be a problem.\n- Is it possible that the case where general slots are perpetually filled\nby attackers becomes the steady state? And we can’t tell the difference\nbetween a regular user and attacker.\n  - This is where unconditional fees come in, if somebody wants to\nperpetually fill up the general bucket they have to pay for it.\n- Is there anything we’d like to see that will help us have move confidence\nhere?\n  - What do you think is missing from the information presented?\n     - We can simulate the steady state / create synthetic data, but can’t\nsimulate every attack. Would like to spend more time thinking through the\nways this could possibly be abused.\n  - Would it help to run this on signet? Or scaling lightning?\n     - Its a little easier to produce various profiles of activity on\nregtest[.\n\n### Simplified Commitments\n- Simplified commitments makes our state machine easier to think about.\n  - Advertise option_simplified_commitment: once both peers upgrade, we can\njust use it.\n  - Simplify our state machine before we make any more changes to it.\n- Right now Alice and Bob can have changes in flight at the same time:\n  - Impossible to debug, though technically optimal.\n  - Everyone is afraid of touching the state machine.\n- We can simplify this by introducing turn taking:\n  - First turn is taken by the lower pubkey.\n  - Alice: update / commit.\n  - Bob: revoke and ack.\n  - If alice wants to go when it’s bob’s turn, she can just send a message.\n  - Bob can ignore it, or yield and accept it.\n  - This has been implemented in CLN for LNSymmetry\n- It’s less code to not have the ignore message, but for real performance\nwe’ll want it. Don’t want to suck up all of that latency.\n- The easiest way is to re-establish is to upgrade on re-establish.\n  - If it wasn’t somebody’s turn, you can just do lowest pubkey.\n  - If it was somebody’s turn, you can just resume it.\n- We could also add REVOKE and NACK:\n  - Right now we have no way to refuse updates.\n  - Why do we want a NACK?\n     - You currently have to express to the other side what they can put in\nyour channel because you can’t handle it if they give you something you\ndon't’ like (eg, a HTLC below min_htlc).\n     - You can likely force a break by trying to send things that aren't\nallowed, which is a robustness issue.\n     - We just force close when we get things we don’t allow.\n     - Could possibly trigger force closes.\n- There’s an older proposal called fastball where you send a HTLC and\nadvise that you’re going to fail it.\n  - If Alice gets it, she can reply with UNADD.\n  - If you don’t get it in time,you just go through the regular cycle.\n- When you get commitment signed, you could NACK it. This could mean you’re\nfailing the whole commitment, or just a few HTLCs.\n  - You can’t fail a HTLC when you’ve sent commitment signed, so you need a\nnew cycle to clear it out.\n  - What NACK says is: I’ve ignored all of your updates and I’m progressing\nto the next commitment.\n- Revoke and NACK is followed by commitment signed where you clear out all\nthe bad HTLCs, ending that set of updates.\n- You have to NACk and then wait for another commitment signature, signing\nfor the same revocation number.\n- Bob never has to hold a HTLC that he doesn't want from Alice on his\ncommitment.\n- This is bad for latency, good for robustness.\n  - Alice can send whatever she wants, and Bob has a way to reject it.\n  - There are a whole lot of protocol violations that Alice can force a\nforce close with, now they can be NACKed.\n- This is good news for remote signers where policy has been violate\nbecause we have cases where policy has been violated and our only way right\nnow is the close the channel.\n- You still want Alice to know Bob’s limits so that you can avoid endless\ninvalid HTLCs.\n- Simplified commitment allows us to do things more easily in the protocol.\n  - When we specced this all out, we didn’t foresee that update fee would\nbe so complicated, with this we know update fee will be correct.\n - If we don’t do this, we have to change update fee?\n     - Sender of the HTLC adds fee.\n     - Or fixed fee.\n- Even if we have zero fees, don’t we still have HTLC dust problems?\n  - You can have a bit on update add that says the HTLC is dust.\n  - You can’t be totally fee agnostic because you have to be able to\nunderstand when to trim HLTCs.\n- Even update fee aside, shouldn’t things just be simpler?\n- Would a turn based protocol have implications for musig nonces?\n  - If you’re taking a turn, it’s a session.\n  - You’d need to have different nonces for different sessions.\n- We should probably do this before we make another major change, it\nsimplifies things.\n- Upgrade on re-establish is pretty neat because you can just tell them\nwhat type you’d like.\n  - This worked very well for CLN getting rid of static remote.\n- What about parameter exchange?\n  - There’s a version of splice that allows you to add new inputs and\noutputs.\n  - Splice no splice which means that you can only make a new commitment\ntransaction, no on-chain work.\n  - Seems like you can get something like dynamic commitments with this,\nand it’s a subset of splicing.\n\n## Day Three\n\n### Meta Spec Process\n- Do we want to re-evaluate the concept of a “living document”?\n  - It’s only going to get longer.\n  - As we continue to update, we have two options:\n     - Remove old text and replace entirely.\n     - Do an extension and then one day replace.\n- If implementing from scratch, what would you want to use?\n  - Nobody is currently doing this.\n  - By the time they finished, everything would have move.\n- The protocol isn’t actually that modular:\n  - Except for untouched BOLT-08, which can be read in isolation.\n  - Other things have tentacles.\n     - We should endeavor for things to be as modular as possible.\n- Back in Adelaide we have a version with a set of features.\n  - We have not re-visited that discussion.\n  - Is it possible for us to come up with versions and hold ourselves\naccountable to them?\n  - If we’re going to start having different ideas of what lightning looks\nlike, versioning helps.\n  - Versioning is not tied one-to-one to the protocol:\n     - Features make it less clean because you have a grab bag of features\non top of any “base” version we decide on.\n     - Does a version imply that we’re implementing in lock step?\n  - If we do extraction, remove and cleanup, we could say that we’re on\nversion X with features A/B/C.\n- How confident are we that we can pull things out? Only things that are\nbrand new will be easy to do this with.\n- Keeping context in your head is hard, and jumping between documents\nbreaks up thought.\n  - Should we fully copy the current document and copy it?\n  - Not everything is a rewrite, some things are optional.\n- What’s our design goal?\n  - To be able to more easily speak about compatibility.\n  - To have a readable document for implementation.\n- A single living document works when we were all making a unified push,\nnow it makes less sense:\n  - You can’t be compliant “by commit” because things are implemented in\ndifferent orders.\n  - We can’t fix that with extensions, they’re hard to keep up to date?\n     - RFCs work like this, they have replacement ones.\n- BOLT 9 can act as a control bolt because it defines features.\n- Extensions seem helpful:\n  - Can contain more rationale.\n  - You can have spaghetti and ravioli code, these could be raviolo\nextensions.\n  - If everything is an extension BOLT with minimal references, we avoid\nthe if-else-ey structure we have right now.\n- For small things, we can just throw out the old stuff.\n- If it were possible to modularize and have working groups, that would be\ngreat but it seems like we’d tread on each other’s toes.\n- We must avoid scenarios like vfmanprint:\n  - The return value says “vfprintf returns -1 on error”\n  - The next sentence says “this was true until version 2”\n  - But nobody reads the next sentence.\n- Cleanup PRs won’t be looked at, and need to be maintained as new stuff\ngets in.\n- Eg: legacy onion - we just looked at network use and removed when it was\nunused:\n  - Rip out how you generate them.\n  - Rip out how you handle them.\n- One of the issues with deleting old text is that existing software that\ndelete the old text is annoying when you run into interop issues on the old\nspec version.\n  - If there are real things to deal with on the network, we must keep them.\n  - We must reference old commits so that people at least know what was\nthere and can do git archeology to find out what it used to be.\n- We can remove some things today!\n  - Static remote\n  - Non-zero fee anchors\n  - ANYSEGWIT is default (/compulsory)\n  - Payment secrets / basic MPP.\n- Should we have regular cleanups?\n  - Even if we do, they need review.\n- For now, let’s do wholesale replacement to avoid cleanup.\n- The proposals folder is nice to know what’s touched by what changes.\n- Rationale sections need improvement: sometimes they’re detailed,\nsometimes vague.\n- Once a feature becomes compulsory on the network we can possibly ignore\nit.\n- What about things that are neither bolts nor blips - like inbound fees?\n  - Why does it need to be merged anywhere?\n  - If it’s an implementation experiment, we can merge it once we’re\nconvinced it works.\n  - If we reach a stage where we all agree it should be universally done,\nthen it should be a bolt.\n     - This is a BLIP to BOLT path.\n- Communication:\n  - We’re not really using IRC anymore - bring it back!\n  - We need a canonical medium, recommit to lightning-dev.\n\n### Async Payments/ Trampoline\n- Blinded payments are a nice improvement for trampoline because you don’t\nknow where the recipient is.\n- The high level idea is:\n  - Light nodes only see a small part of the network that they are close\nto.\n  - Recipients only give a few trampolines in the network that they can be\nreached via.\n  - In the onion for the first trampoline, there will be an onion for the\nsecond trampoline.\n  - You just need to give a trampoline a blinded path and they can do the\nrest.\n- If you only have one trampoline, they can probably make a good guess\nwhere the payment came from (it’s in the reachable neighborhood).\n- Is there a new sync mode for trampoline gossip?\n  - We’d now need radius-based gossip rather than block based.\n  - The trust version is just getting this from a LSP.\n  - In cold bootstrap, you’re probably going to open a channel so you ask\nthem for gossip.\n- Can you split MPP over trampoline? Yes.\n- Routing nodes can learn more about the network because they make their\nown attempts.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230719/ea8a0ec2/attachment-0001.html\u003e"}