Re: [bitcoin-dev] Improving RBF Policy

On Mon, Feb 07, 2022 at 11:16:26AM +, Gloria Zhao wrote: > @aj: > > I wonder sometimes if it could be sufficient to just have a relay rate > > limit and prioritise by ancestor feerate though. Maybe something like: > > - instead of adding txs to each peers setInventoryTxToSend immediately, > >

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Rusty, Note that this sort of design introduces recursive covenants similarly to how I described above. Whether that is an issue or not precluding this sort of design or not, I defer to others. Best, Jeremy On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linux

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

Russell O'Connor via bitcoin-dev writes: > Given the overlap in functionality between CTV and ANYPREVOUT, I think it > makes sense to decompose their operations into their constituent pieces and > reassemble their behaviour programmatically. To this end, I'd like to > instead propose OP_TXHASH an

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns wrote: > On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev > wrote: > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html > > For more complex interactions, I was imagining combining this TXHASH

Re: [bitcoin-dev] BIP-119 CTV Meeting #3 Draft Agenda for Tuesday February 8th at 12:00 PT

Reminder: This is in ~24 hours. There have been no requests to add content to the agenda. Best, Jeremy -- @JeremyRubin On Wed, Feb 2, 2022 at 12:29 PM Jeremy Rubin wrote: > Bitcoin Developers, > > The 3rd instance of the recurring meeting is scheduled for T

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > every lightning network transaction adds one dust UTXO > > Could you clarify what you mean here? What dust do lightning transactions > create? > I mean this msg https://lists.linuxfoundation

Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn

> every lightning network transaction adds one dust UTXO Could you clarify what you mean here? What dust do lightning transactions create? I do think that UTXO set size is something that will need to be addressed at some point. I liked the idea of utreexo or some other accumulator as the ultimate

Re: [bitcoin-dev] Improving RBF Policy

Hi everyone, Thanks for giving your attention to the post! I haven't had time to write responses to everything, but sending my thoughts about what has been most noteworthy to me: @jeremy: > A final point is that a verifiable delay function could be used over, e.g., each of the N COutpoints indivi

Re: [bitcoin-dev] Improving RBF Policy

Good morning, > The tricky question is what happens when X arrives on its own and it > might be that no one ever sends a replacement for B,C,D) It feels ok to me, but this is definitely arguable. It covers the fact that B,C,D could have been fake transactions whose sole purpose was to do a pinni