Re: [bitcoin-dev] Bitcoin covenants are inevitable

>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

>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

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 fo

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

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 progr

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

>*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

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', a

Re: [bitcoin-dev] Hardware Wallet Standard

*One of my biggest fears about using any wallet is the "whoops, cosmic ray flipped a bit while producing receiving address; SFYL!" possibility. For high value cold storage, I always generate my addresses on two independent machines using two different pieces of software. Am I nuts for doing that?*

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

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 adjustment,

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

We don't have any evidence of how fast nodes will upgrade when faced with an impending hard fork, but it seems like a very safe assumption that the upgrade pace will be significantly faster. The hard fork case it is: "upgrade or be kicked off the network". In the previous cases it has been, "here

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

A planned hardfork, similar to certain softforks, leaves users with some reduction in security. It does not leave them defenseless. Consider the following: 1: Hard to be robbed on the basis of hashpower. In reality the old chain will see mining all but stop, and blocks would be hours to days ap

Re: [bitcoin-dev] Scaling Bitcoin conference micro-report

If it turns out that the blocksize divide is hinging on differing developer views on the nature of the threat posed by governments, perhaps it would be better to defer to people who specialize in that area. There are plenty of them operating in the Bitcoin space. I am familiar with some of the Un

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

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