Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

2023-12-22 Thread jlspc via bitcoin-dev
Hi Antoine, Thanks for your thoughtful response. Comments inline below: > Hi John, > While the idea of using sliding reaction window for blockchain congestion > detection has been present in the "smart contract" space at large [0] and > this has been discussed informally among Lightning devs

Re: [bitcoin-dev] Swift Activation - CTV

2023-12-22 Thread alicexbt via bitcoin-dev
Hi Luke, This is not the first time I am writing this but you keep ignoring it and threaten with URSF. Please build BIP 8 client with LOT=TRUE if you think its the best way to activate and share it so that users can run it. I had created this branch specifically for it but needed help which I

Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1

2023-12-22 Thread Yuri S VB via bitcoin-dev
There are three possible cryptanalysis to LAMPPRI in my scheme: 1. From ADDR alone before T0-1 (to be precise, publishing of (TX, SIG)); 2. From ADDR and (TX, SIG) after T0-1 (to be precise, publishing of (TX, SIG)); 3. Outmine the rest of mining community starting from a disadvantage of not

Re: [bitcoin-dev] Altruistic Rebroadcasting - A Partial Replacement Cycling Mitigation

2023-12-22 Thread Peter Todd via bitcoin-dev
On Thu, Dec 21, 2023 at 09:59:04PM +, Antoine Riard wrote: > Hi Peter, > > > Obviously a local replacement cache is a possibility. The whole point of > my > > email is to show that a local replacement cache isn't necessarily needed, > as > > any alturistic party can implement that cache for

Re: [bitcoin-dev] Scaling Lightning Safely With Feerate-Dependent Timelocks

2023-12-22 Thread Eric Voskuil via bitcoin-dev
The fees paid to mine the set of transactions in a given block are known only to the miner that produced the block. Assuming that tx inputs less outputs represents an actual economic force is an error.eOn Dec 22, 2023, at 09:24, jlspc via bitcoin-dev wrote:Hi Antoine, Thanks for your thoughtful