Rusty Russell on Nostr: My thoughts here are definitely unrefined, but I am sceptical of the "onchain rush ...
My thoughts here are definitely unrefined, but I am sceptical of the "onchain rush solved by covenants" argument.
1. You're assuming fee volatility. I expect this to reduce over time, as regular Bitcoin usages adapt their behaviour and smooth fees
2. You're assuming wallet infrastructure which is pre-built to handle this case.
3. You're changing the deal, so the *recipient* now pays fees. If you shape things as payment trees, the tradeoff gets worse (approaching twice the weight of just paying normally, requiring that much fee volatility to make sense), and you introduce games between the recipients to figure out who pays fees.
4. You have created a novel financial instrument on fee futures, not something I accept as a "payment", as I have not received it, and you've offloaded an unknown level of costs to me to "collect" it.
5. In real bankruptcy, this is *not what you want*. You don't want your funds stuck on chain. Many might want theirs transferred in one tx to Coinbase. Others will want payment over lightning, or fiat.
6. You can do this badly, today. You can publish a zero-fee tx which pays everyone, or even a tree. That at least proves you have the funds, and can be seen by existing wallets. This, of course, requires the mempool changes which James complains about.
In summary, I don't see congestion trees actually being used: certainly not for this bank-run-in-high-fee scenario.
1. You're assuming fee volatility. I expect this to reduce over time, as regular Bitcoin usages adapt their behaviour and smooth fees
2. You're assuming wallet infrastructure which is pre-built to handle this case.
3. You're changing the deal, so the *recipient* now pays fees. If you shape things as payment trees, the tradeoff gets worse (approaching twice the weight of just paying normally, requiring that much fee volatility to make sense), and you introduce games between the recipients to figure out who pays fees.
4. You have created a novel financial instrument on fee futures, not something I accept as a "payment", as I have not received it, and you've offloaded an unknown level of costs to me to "collect" it.
5. In real bankruptcy, this is *not what you want*. You don't want your funds stuck on chain. Many might want theirs transferred in one tx to Coinbase. Others will want payment over lightning, or fiat.
6. You can do this badly, today. You can publish a zero-fee tx which pays everyone, or even a tree. That at least proves you have the funds, and can be seen by existing wallets. This, of course, requires the mempool changes which James complains about.
In summary, I don't see congestion trees actually being used: certainly not for this bank-run-in-high-fee scenario.
quoting nevent1q…m7kwI responded on Twitter too, but this is such a strange rant to me.
Bitcoin Core (contributor)’s current push for better mempool policy is *directly* related to multi-party UTXO ownership and scaling. It specifically substantially improves lighting in practice today, and will certainly be required for any future scaling technologies.
In the mean time, lots of folks (like James) continue to do research into how to scale Bitcoin (and cryptocurrencies generally). There’s no reason to care if that happens from Bitcoin Core contributors or others, and we’re still really far from having any particularly good ideas on this front. As that research continues, there’s no reason for concrete software towards short-term soft-forks. note16h9…tlgm