Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-07-07 Thread Corey Haddad via bitcoin-dev
>Billy, > >Proof of work and the difficulty adjustment function solve literally everything you are talking about already. >Bitcoin does not need active economic governanance by devs or meddlers. >Please stop spamming this list with this nonsensical thread. > >Love, >John Sorry John, but this is a

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-07-05 Thread Corey Haddad via bitcoin-dev
>Bitcoin's finite supply is the main argument for people investing in it, the whole narrative around bitcoin is based on its finite supply. While it has its flaws and basically condemns bitcoin to be only used as a store >of value (and not as a currency), I don't think it's worth questioning it at

Re: [bitcoin-dev] Bitcoin covenants are inevitable

2022-06-12 Thread Corey Haddad via bitcoin-dev
Even if demand for block space is currently not needed to pay for security due to the block rewards, demand for BTC itself is needed for those rewards to be worth anything. Bitcoin, as a proof of work system, is only secure at scale. Therefore continued growth and user adoption are both critical

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

2022-04-22 Thread Corey Haddad via bitcoin-dev
If none of the alternative proposals have been developed as much as CTV, it seems reasonable to interpret that as a lack of interest in those alternative proposals themselves. That should not be interpreted as lack of interest in covenants. Perhaps if CTV didn't exist, we would have seen more

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

2022-04-22 Thread Corey Haddad via bitcoin-dev
>*A change that increases the number of use cases of Bitcoin affects all users and is *not* non-invasive. More use cases means more blockchain usage which increases the price of a transaction for *everyone*.* This manages to be both incorrect and philosophically opposed to what defines success of

Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0

2021-06-30 Thread Corey Haddad via bitcoin-dev
We cannot prevent people from choosing to take an action based on an unconfirmed transaction. Even though it is trivial to have a double-spending transaction confirmed, accepting a 0-conf tx can be rational in many cases. 0-conf can be interpreted as the customer signaling their 'intent to pay',

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

2016-03-03 Thread Corey Haddad via bitcoin-dev
Since the root cause of what you are trying to address is the reward having, I'd suggest considering an adjustment to the having schedule. Instead of their being a large supply shock every four years, perhaps the reward could drop every 52,500 blocks (yearly), or even at each difficulty

[bitcoin-dev] Fees and the block-finding process

2015-08-11 Thread Corey Haddad via bitcoin-dev
On Tur, Aug 11, 2015 at 07:08 AM, *Mark Friedenbach* via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev wrote: Neither one of those assertions is clear. Keep in mind the goal is to have Bitcoin survive active censorship.