Peter Todd

On Wed, Apr 17, 2024 at 04:32:14AM -0700, Chris Stewart wrote: > @dgpv @petertodd what do you think is the path forward for this? Seems to me that one reasonable...

> Concept NACK. This seems to encourage and promote spam. We should be doing the exact opposite. This proposal is merely a way of doing something that is already done...

On July 8, 2024 8:42:50 PM GMT+02:00, Luke Dashjr ***@***.***> wrote: >>This proposal is merely a way of doing something that is already done - signed anchor outputs - in...

> since we'll always have a single anchor FYI anchor channels having two anchor outputs is actually a design oversight. Only one anchor output is needed in almost all cases:...

I responded to all those points, as you can see in the thread. Anyway, it's clearly an on topic FYI as it impacts how useful this feature actually is. But...

So long as you support RBF for all transactions, and update the backend to support this, Concept ACK.

@1ma Please read the relevant mailing list discussion first: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ There are good reasons why this is being brought up again.

@1ma As was discussed in the mailing list discussion, entities are using unspendable outputs in liu of OP_Return outputs. Precisely because of the size limit. This increases the UTXO set...

@Retropex Data publishing via unspendable UTXOs is undetectable. We can't block it without significant changes to the consensus protocol.

> This is false. It would require invasive changes to the address format (and disabling old address formats), but there are no consensus changes required. You are referring to standardness...