Re: [bitcoin-dev] Improving RBF Policy

In reading through more of the discussion, it seems the idea I presented above might basically be a reformulation of t-bast's rate-limiting idea presented in this comment . Perhaps he

Re: [bitcoin-dev] Speedy Trial

> A mechanism of soft-forking against activation exists. What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin? That simply isn't

Re: [bitcoin-dev] Speedy Trial

> If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude

[bitcoin-dev] Covenants and feebumping

The idea of a soft fork to fix dynamic fee bumping was recently put back on the table. It might sound radical, as what prevents today reasonable fee bumping for contracts with presigned transactions (pinning) has to do with nodes' relay policy. But the frustration is understandable given the

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote: > > A major contender to the Speedy Trial design at the time was to mandate >> eventual forced signalling, championed by luke-jr. It turns out that, at >> the time of that proposal, a large amount of hash power simply did not have >> the

Re: [bitcoin-dev] Removing the Dust Limit

> We should remove the dust limit from Bitcoin. Any node operator can do that. Just put "dustrelayfee=0." in your bitcoin.conf. And there is more: you can also conditionally allow free transactions: mintxfee=0.0001 minrelaytxfee=0. blockmintxfee=0. Then, when using

Re: [bitcoin-dev] Covenants and feebumping

Hi Antoine, I have a few high level thoughts on your post comparing these types of primitive to an explicit soft fork approach: 1) Transaction sponsors *is* a type of covenant. Precisely, it is very similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I defined in my 2017