Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread Tom Harding via bitcoin-dev
On 7/11/22 15:26, Peter Todd via bitcoin-dev wrote: Anyway, designing protocols for "price go up forever" hopium is a bad idea. Yet that is the design, and it's a good one.  It is equivalent to relying on bitcoin to steadily grow in utility vs. fiat currencies. If it fails to do that, there

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread John Tromp via bitcoin-dev
> The emission curve lasts over 100 years because Bitcoin success state > requires it to be entrenched globally. It effectively doesn't. The last 100 years from 2040-2140 only emits a pittance of about 0.4 of all bitcoin. What matters for proper distribution is the shape of the emission curve. I

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread John Tromp via bitcoin-dev
> There's only one coin whose expected (soft) emission time is larger > than bitcoin's, and it's about an order of magnitude larger, at 50 > years. Make that two coins. For DOGE it is 33 years. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundati

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread Gino Pinuto via bitcoin-dev
What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ? Benefits : - Miners would still be incentivized to collect higher fees transaction with the indirect perspective to generate more reward in future. - Revenues are equally distributed over

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread Erik Aronesty via bitcoin-dev
Bitcoin doesn't rely on fees. It relys on users protecting the network out of self interest - running nodes now - mining later It has always been incentivised by holders acting out of self interest If large holders allocating a small percentage to mining to protect their interest, that's all Bi

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread Manuel Costa via bitcoin-dev
> What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ? This would be a hard fork afaict as it would go against the rules of the coinbase transaction following the usual halving schedule. However, if instead we added a rule that fees have to

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-13 Thread Alfred Hodler via bitcoin-dev
Rather than get bogged down discussing the technical details of how such a change could even take place, I'll go ahead and say that modifying the 21M cap is a supremely reckless idea. Your mathematical proof aside, the idea rests on the unprovable premise that people will keep losing coins indef

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

2022-07-13 Thread Zac Greenwood via bitcoin-dev
> your proof is incorrect (or, rather, relies on a highly unrealistic assumption) The assumption that coin are lost ar a constant rate is not required. Tail emission will asymptotically decrease the rate of inflation to zero, at which point the increase in coin exactly matches the amount of coin l

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

2022-07-13 Thread Anthony Towns via bitcoin-dev
On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote: > Oops, you are right. We need the bribe to be the output of the coinbase, > but due to the maturity rule, it isn't really a bribe. > Too bad coinbases cannot take other coinbase outputs as inputs to bypass > the ma