rich1.0npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclhttps://nostr.ae/npub19a2m7qm80t7mzhgqfgunswhm5c3q4fkqt89057ugy7u8jdxncf2q06mwclnjumphttps://nostr.ae📅 Original date posted:2022-07-12 📝 Original message:BIP119, OP_CTV, allows value to be assigned in a predetermined tree of payments that confirms with a single output. This allows batched transactions in the predetermined tree (e.g. withdrawals from a centralized exchange) to be anchored in a way that disallows double-spending of the inputs, yet allows the recipients to smooth out mining fees for their withdrawal outputs, at their leisure. It's a perfect design for a world where there are always more transactions to be made than block space allows, yet only some of them are urgent. As it applies to concerns mentioned in this thread, it can be used to shift transaction fees to later blocks. Whenever smoothing transaction fees would be a nice-to-have, this is one way to have it. https://utxos.org/uses/scaling/ https://utxos.org/analysis/bip_simulation/ On Tue, Jul 12, 2022 at 9:49 AM Peter <dizzle at pointbiz.com> wrote: > With 3000 Lightning open/ close tx per block and 6 billion adults > it's 38 years of backlog to onboard the entire adult > population. That's not including corporations. Separately, OP_CTV also allows slightly different payment channels from the existing Lightning Network, that allow non-interactive batched opens. Using this technique, onboarding 6 billion adults to payment channels would be limited only by their willingness to participate. https://utxos.org/uses/non-interactive-channels/