Re: [bitcoin-dev] [Lightning-dev] Scaling Lightning With Simple Covenants
Hi aj, A few more thoughts on this trust/safety vs. capital efficiency tradeoff: > Optimising that formula by making LA [the channel's active lifetime] as large > as possible doesn't > necessarily work -- if a casual user spends all their funds and > disappears prior to the active lifetime running out, then those > funds can't be easily spent by B until the total lifetime runs out, > so depending on how persistent your casual users are, I think that's > another way of ending up with your capital locked up unproductively. The risk of the casual user spending all of their funds can be addressed by having the casual user prepay the cost-of-capital fees for the dedicated user's funds for the entire lifetime of the channel. Then, whenever the dedicated user's funds increase or decrease (due to a send or receive by the casual user), a corresponding prepayment adjustment is included in the new balances defined by the send or receive HTLC. With prepayments, the dedicated user can safely agree to a long active lifetime for the channel. In the paper, I assumed an active lifetime of 110,000 blocks (about 2.1 years), but allowed the casual users to obtain a new channel every 10,000 blocks (about 2.5 months) by staggering their timeout-trees ([1], Sec. 4.8 and 5). The paper includes a rollover period (which covers the casual user's unavailability for up to 2.5 months) in addition to the timeout-tree's active lifetime (25 months) and inactive lifetime (1 week for putting leaves onchain, which definitely introduces risk). Here are some rough calculations if one wants to eliminate risk by making the inactive lifetime long enough to put all leaves of all timeout-trees onchain before the timeout-trees' expiries: TIME BOUND ON NUMBER OF LEAVES: -- There are approximately 52,500 blocks / year, each with at most 4M vbytes, for a total of approximately 210B = 2.1 * 10^11 vbytes per year. If each leaf requires an average (when all leaves in a tree are put onchain) of 2,100 vbytes, then 2.1 * 10^11 / 2,100 = 10^8 = 100M leaves can be put onchain in 1 year with full block capacity devoted to leaves, and in 1/x years with a fraction of x capacity devoted to leaves. Therefore, at x = 0.5 capacity: 50M leaves can be put onchain per year 100M leaves can be put onchain in 2 years 1B leaves can be put onchain in 20 years 10B leaves can be put onchain in 200 years 100B leaves can be put onchain in 2,000 years Assuming an active lifetime of 2.1 years, adding an inactive period of 2 years may be plausible, depending on the cost of capital. Therefore, scaling to 100M or so leaves (across all timeout-trees) while maintaining the ability to put all leaves onchain may be doable. On the other hand, an inactive period of 20 years seems unreasonable. As a result, scaling to billions of leaves probably requires trading off safety vs. capital efficiency (as you noted). FEERATE BOUND ON NUMBER OF LEAVES: - If each leaf requires a maximum (when only that leaf is put onchain) of 10,500 vbytes and the feerate is at least 2 satoshis / vbyte, then each leaf must be worth at least 21,000 satoshis (or else the dedicated user may not have an incentive to be honest, as the casual user would lose funds by putting their leaf onchain). There are at most 2.1 * 10^15 satoshis in existence, so there can be at most 2.1 * 10^15 / 21,000 = 10^11 = 100B leaves. I wrote a small python3 program for analyzing scalability given the requirement that all timeout-tree leaves can be put onchain. The trickiest part was figuring out how to quantify the onchain fees caused by increasing the fraction of each block that's devoted to casual users putting their leaves onchain. I wanted a function that multiplies the base feerate by a factor of 1 when no leaves are put onchain and by a factor approaching infinity when nearly all of the block space is devoted to leaves. I started with the function Fe/(1-x), where Fe is the base feerate (without leaves put onchain) and x is the fraction of block space devoted to putting leaves onchain. This function has the desired behavior when x is near 0 or 1, and it doubles the base feerate when half the block space is devoted to leaves. In reality, the feerate probably increases faster than that, so I added an exponent to capture how quickly the feerate grows: feerate = Fe/(1-x)^Ex where Ex is an arbitrary exponent. The program has the following tunable parameters: * Ac: length (in blocks) of active lifetime of each TT (timeout-tree) * Ro: length (in blocks) of rollover period of each TT (provides for casual user's unavailability) * AS: average size (in vbytes) of transactions required to put one TT leaf onchain when all leaves in TT are put onchain * MS: maximum size (in vbytes) of transactions required to put one TT leaf onchain when only one leaf in TT is put onchain * Fe: feerate (in sats/vbyte) assuming 0% of
Re: [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers
Hi all, I think any valid consensus-change based solution to the pinning and replacement cycling issues for Bitcoin L2s should respect the following properties / requirements (ideally): - non-interactive with contribution of your off-chain counterparty - minimize level of fee-bumping reserve and number of UTXO locked - block any malicious pinning or replacement cycling as long as you can compete with ongoing fee rates - do not make the security of low-value lightning payments conditional on a probabilistic state of local knowledge of historical mempool - generalize to N > 2 multi-party off-chain construction - minimize the witness size by using efficient bitcoin script semantics - do not give an edge to low-hashrate or coalition of low-hashrate miners to play fees games with Lightning / L2 nodes - be composable with a solution to massive force-closure of time-sensitive off-chain states - not make it worst things like partial or global mempool partitioning [0] I think this is already a lot. I had some intuitive solutions aiming to remove package malleability by using something like the annex and sighash_anyamount semantic, though after musing on Peter Todd's op_expire proposal, I wonder if there is not another family of solutions that can be designed using "moon math" cryptos like short-lived proofs and strictly enforced sequential time windows. I don't have any strong design at all, and in any case given the complexity it would be good to have an end-to-end implementation of any solution, at the very least see it works well for the Lightning case (chatted with Gleb out-of-band he's too busy with Erlay for now to research more on those subjects and on my side bored working more on those issues, sadly I don't know that many bitcoin, lightning and covenant researchers that understand that well those problems). I still think pinning and replacement attacks deserve more real-world mainnet experimentation, under usual ethical guidelines . Inviting everyone in the Bitcoin research community to research more on those pinning, replacement cycling and miners incentives misalignment with second-layers. Please do so, those issues are serious enough if we wish to have a reliable fee market in a post-subsidy world and a sustainable decentralized miner ecosystem in the long-term (well...dumb ordinal transactions might save the day, though open another wormhole of technical issues). Best, Antoine [0] See The Ugly scenario here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html Le dim. 22 oct. 2023 à 03:27, Antoine Riard a écrit : > Hi, > > I think if Gleb Naumenko and myself allocate our research time on this > issue, we should (hopefully) be able to come with a strong sustainable fix > to the lightning network, both systematically solving pinnings and > replacement cycling attacks (and maybe other mempools issues or things > related like massive force-closure beyond available blockspace can absorb > before pre-signed transactions timelocks expiration as mentioned in the > original paper). > > I have not yet probed Gleb's mind on this, though we both studied those > cross-layer issues together as early as 2019 / 2020, and I think we have > built an intuitive understanding of the problem-space, with both practical > experience of bitcoin core and rust-lightning codebases and landmark > research in this area [0] [1]. If Gleb isn't too busy with Erlay in core, > I'm sure he'll be enthusiastic to contribute research time at his own pace > (and I might probe a bit of Elichai Turkel time to verify the maths of all > sustainable lightning fixes we might propose and the risks models). All > soft commitments and assuming the interest of the bitcoin community. > > One good advantage of long-term sustainable fixes, it should > (optimistically yet to be demonstrated) lower the fee-bumping reserve value > and number of UTXOs lightning users (and maybe bandwidth) have to lock > continuously to use this worldwide 24 / 7 payment system. > > Reopened the issue on coordinated security issues handling in the LN > ecosystem: > https://github.com/lightning/bolts/pull/772 > > While I'll stay focused on solving the above problems at the base-layer > where they're best solved, at least I'll stay around for a few months > making transitions with the younger generation of LN devs. > > For transparency, I don't have any strong solution design yet at all, > neither code, conceptual draft or paper ready, and game-theory and nodes > network processing resources changes will have to be weighted very > carefully, all under the bitcoin open and responsible process we currently > have. Overall, this will take reasonable time (e.g package relay design > discussions have been started in 2018 and we're only now at the hard > implementation and review phase) to carry on forward. > > Looking forward to hearing thoughts of the Bitcoin and Lightning > development protocols community. > > [0] >
[bitcoin-dev] Fwd: OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
> No, that's not a general underlying issue. You've found two separate issues. > Furthermore, revoked states are clearly different than HTLCs: they're > fraudulent, and thus in punishment-using protocols they are always associated > with high risks of loss if they do in fact get detected or mined. There's > probably tweaks we can do to improve this security. But the general principle > there is certainly true. I see your point in saying we have two separate issues, one the on-chain inclusion of "expired" off-chain output spend (e.g the HTLC-preimage), the other one the usage of revoked or updated or asymmetric states to jam the confirmation of a valid off-chain state. I do think the second one would bring a solution to the first one, as you will be always sure that your counterparty cannot "replay" an "expired" off-chain output at its advantage. Even for solving the first issue, I'm not sure op_expire is enough, you need to expire the worthiness of an off-chain revealed witness secret too (here the preimage). E.g using short-lived proofs, i.e after a specified period of time, the proof is no longer convincing. I still think op_exire is interesting on its own, beyond solving any security issue. E.g for Discreet Log Contract, one can build a time-bounded sequential claim of the same output fund among a set of counterparties. > For a lightning channel to be economical at all in a general routing > environment, the highest likely fee has to be small enough for it to represent > a small percentage of the total value tied up in the Lightning channel. Tying > up a small percentage of the overall capacity for future fee usage is not a > significant expense. Sure, I still think this introduces the corollary for lightning nodes that any payment under the highest likely fee now has a probabilistic security, where the lightning node should make guesses on the worst-level of mempools feerate that can happen between the timelock duration of said payment. > That attack doesn't make sense. HTLCs go to fees at a certain feerate. In a > normal environment where there is a constant supply of fee paying transactions, > the profit for the miner is not the total HTLC value, but the increase in > feerate compared to the transactions they had to give up to mine the commitment > transaction. The attack makes sense in an environment where the level of HTLC trimmed as fees on the commitment transaction renders the feerates of this transaction more interesting than the marginal known transaction in a miner block template. If there is an environment where you're always guaranteed there is a constant supply of fee paying transactions paying a better feerate than the highest-fee rate that trimmed HTLCs can be a commitment transaction, of course the attack wouldn't be plausible. In a world where you have a dynamic blockspace demand market and asymmetries of information, Lightning routing nodes will be always exposed to such attacks. > Second, it's obvious that the total trimmed HTLCs should be limited to what > would be a reasonable transaction fee. A situation where you have 80% of the > channel value going to fees due to a bunch of small HTLCs is obviously > ridiculous, and to the extent that existing implementations have this issue, > should be fixed. This is the hard thing, the existence of asymmetries of information in what is a reasonable transaction fee and what is the level of mempools fee rates at time of broadcast. One could imagine a consensus change where trimmed HTLCs not worthy at the last X blocks of feerates are automatically aggregated or trimmed (think median-time-past though for median fee rates over X blocks). > Yes, obviously. But as I said above, it just doesn't make sense for channels to > be in a situation where closing them costs a significant % of the channel value > in fees, so we're not changing the status quo much. Evaluation of the significant % of the channel value burned in fees in the worst-case at time of off-chain state commitment is the hard thing. > Do you have a concrete attack? I don't have a concrete attack with sufficient testing to say with a satisfying level of certainty that I have a concrete attack. > No, you are missing the point. RBF replacements can use SIGHASH_NOINPUT to sign > HTLC refund transactions, removing the need for a set of different HTLC refund > transactions for each different feerate of the commitment transaction. See above, I think this solution with RBF replacement is robust on the assumption you cannot use the commitment transaction to jam the HTLC-preimage until your HTLC-refund transaction is valid (under nLocktime). Though my point here was only about the LN-symmetry states, not second-stage transactions on top of them. > I'm making no comment on how to do RBF replacements with LN-Symmetry, which I > consider to be a broken idea in non-trusted situations anyway > Removing justice from Lightning is always going to be hopelessly insecure when you can't
Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
Hi floppy disk guy, thanks for prompting me to look closer at Nostr, it's very interesting. I hope that whatever solution is chosen doesn't involve handing power over to a centralized entity that wants collect as much information on every living person as possible, and lock everyone and everything into using it's services forever. On Mon, 2023-11-13 at 18:51 +, alicexbt wrote: > Hi Overthefalls, > > > +1 > > > Using google for bitcoin mailing list is not good. It feels > embarrassing that some developers that built and maintained the only > decentralized network used to settle uncensored payments and some of > them even working on nostr, can't build their own mailing list which > is better than present mailing list. I have some ideas but it seems > the influential developers have already decided and wont accept > anything. > > Nostr can be used to build a mailing list which also allows anyone to > send emails apart from publishing events from different clients. We > just need a new NIP so that nostr relays understand its a different > event. There can be multiple front end with different levels of > moderation to hide some emails and ultimately one will be used the > most. It can use multiple relays and relays share some information in > NIP 11 which can include an email address. > > > /dev/fd0 > floppy disk guy > > > > > > > > > Sent with Proton Mail secure email. > > > > > > On Monday, November 13th, 2023 at 8:35 PM, Overthefalls via > bitcoin-dev wrote: > > > > > On Tue, 2023-11-07 at 09:37 -0600, Bryan Bishop via > > bitcoin-dev wrote: > > > Google Groups is another interesting option, > > > > I don't think I'm the only person on this list that is strongly > > opposed to using google for anything. They are too big and they > > have their hand in everything, and their eyes (and analytics) on > > everything. > > I remember when there were virtually no gmail email addresses that > > posted to this list. Suddenly in 2020 or 2021, we had an influx of > > gmail subscribers and posters. That didn't escape me then and it is > > not lost on me now. > > Email is great for public discussion for many reasons. The fact > > that everyone gets a copy of the data, there is no single central > > authority that can edit emails once they have been sent out. Anyone > > can archive email messages, they can generally store or publish the > > data anywhere they like. That is not the case with web forum > > content. > > I like the lightning anti-spam fee idea. That would encourage me to > > finally adopt lightning, and it would, I'm sure, produce some > > interesting results for the list. > > I don't think email should be out of the question. Does anyone > > besides kanz...@gmail.com think that sticking with email is out of > > the question? > > Let's do what's necessary to stick with email. > > > > > > > > > > > > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
