Re: [bitcoin-dev] Consensus protocol immutability is a feature

> Because the above block header format is hashed to generate the > `prevBlockHash` for the *next* block, it is almost impossible to change the > format without a hardfork. First, assume that everything should be validated as today to be backward-compatible. For that reason, removing SHA-256

Re: [bitcoin-dev] Reducing block reward via soft fork

>> The turn-around time for that takes a population of both users and >> miners to cause. Increasing popularity of bitcoin has a far bigger >> impact here, and it is already raising fees and energy use at an >> established rate. >> >> If it becomes an issue, as bandwidth increases block size could

Re: [bitcoin-dev] Opinion on proof of stake in future

I made a couple typos and mistakes in my couple previous emails: * "People repeat this often, but the facts support this" -> "the facts *don't *support this" * "Together, both of these things reduce PoW's security by a factor of about 83% (1 - 50%*33%)." -> "factor of about 83% (1 - 50%**(50% -

Re: [bitcoin-dev] Opinion on proof of stake in future

@Lloyd > Proof-of-SquareSpace I agree with your points about delegated proof of stake. I wrote my own critique about that as well. And your point, that other forms of PoS devolve

Re: [bitcoin-dev] Consensus protocol immutability is a feature

Good morning vjudeu, > > Perhaps the only things that cannot be usefully changed in a softfork is > > the block header format and how proof-of-work is computed from the block > > header. > > Why not? I can imagine a soft fork where the block header would contain > SHA-256 and SHA-3 hashes in

Re: [bitcoin-dev] Tweaking tapscript instead of public key

Hi, That's an excellent question, but note that answering such questions is not the primary function of this mailing list. Places like Bitcoin Stack Exchange or even IRC are probably better for that! Specific to your question: in Taproot Q = P + hash(P||m)*G. The fact that P is hashed together

Re: [bitcoin-dev] Consensus protocol immutability is a feature

> Perhaps the only things that cannot be usefully changed in a softfork is the > block header format and how proof-of-work is computed from the block header. Why not? I can imagine a soft fork where the block header would contain SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be

[bitcoin-dev] Tweaking tapscript instead of public key

As far as I know, P2TR address contains 32-byte public key. It can be used directly by creating Schnorr signature or indirectly, by revealing tapscript. Does it mean that any taproot output could be modified on-the-fly after being confirmed without changing an address? I mean, if we have base

[bitcoin-dev] Fwd: Reducing block reward via soft fork

> Well, it is done automatically every 4 years :) Bitcoin's price has always been increasing exponentially faster than the block size has been exponentially decreasing. > It is a self-balancing system - more people shout about Bitcoin being dirty -> less adoption -> lower the price -> less energy

Re: [bitcoin-dev] Reducing block reward via soft fork

Good morning Karl, > On 5/23/21, ZmnSCPxj via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Good morning James, > > > > > Background > > > > > > === > > > > > > Reducing the block reward reduces the incentive to mine. It reduces the > > > maximum energy price at which

Re: [bitcoin-dev] Reducing block reward via soft fork

On 5/23/21, ZmnSCPxj via bitcoin-dev wrote: > Good morning James, > >> Background >> === >> Reducing the block reward reduces the incentive to mine. It reduces the >> maximum energy price at which mining is profitable, reducing the energy >> use. >> > > If people want to retain previous levels of

Re: [bitcoin-dev] Reducing block reward via soft fork

Well, it is done automatically every 4 years :) It is a self-balancing system - more people shout about Bitcoin being dirty -> less adoption -> lower the price -> less energy consumption. Add on top the fact that in 2024 block rewards will fall 50% anyway and someday it will be zero. I am all for

Re: [bitcoin-dev] Reducing block reward via soft fork

Good morning James, > Background > === > Reducing the block reward reduces the incentive to mine. It reduces the > maximum energy price at which mining is profitable, reducing the energy use. > If people want to retain previous levels of security, they can offer to pay higher fees, which

Re: [bitcoin-dev] Consensus protocol immutability is a feature

Good morning Jorge, et al, > Hardforks can be useful too. > But, yes, I agree softforks are preferable whenever possible. I think in principle the space of possible softforks is very much wider than can be trivially expected. For instance, maaku7 once proposed a softfork that could potentially

[bitcoin-dev] Reducing block reward via soft fork

Background === Reducing the block reward reduces the incentive to mine. It reduces the maximum energy price at which mining is profitable, reducing the energy use. Bitcoins have value because they are accepted by full node users, from individual node operators, to exchanges and custodians like

Re: [bitcoin-dev] Opinion on proof of stake in future

Hi Billy, I was going to write a post which started by dismissing many of the weak arguments that are made against PoS made in this thread and elsewhere. Although I don't agree with all your points you have done a decent job here so I'll focus on the second part: why I think Proof-of-Stake is