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

> @befreeandopen " An attacker can calculate whether or not she can prolong > this chain or not and if so with what timestamp." > > The scenario you describe would only be likely to happen at all if the > malicious actor has a very large fraction of the stake - probably quite close > to 50%. At

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

@befreeandopen " An attacker can calculate whether or not she can prolong this chain or not and if so with what timestamp." The scenario you describe would only be likely to happen at all if the malicious actor has a very large fraction of the stake - probably quite close to 50%. At that point, yo

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

@Phuoc "Bitcoin, for now, is heading for destruction when inflation stops. As a self-contained system, this happens when the block reward (plus fee) decreases faster than the price rise." Well, the block reward decreases less and less in comparison to fees every halving. So it seems reasonably lik

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

> > you burn them to be used at a future particular block height > This sounds exploitable. It seems like an attacker could simply focus all > their burns on a particular set of 6 blocks to double spend, minimizing their > cost of attack. could be right. the original idea was to have burns de

[bitcoin-dev] Improvement on Blockbuilding

Hi Bitcoin Devs, We are writing to share with you a suggested improvement to the current bitcoin core block building algorithm. In short, currently Bitcoin Core uses a straightforward greedy algorithm which evaluates each transaction’s effective fee rate in the context of its unconfirmed ancestors

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

Sure, many things that were though only possible with hardforks initially were later shown to be possible with softforks. That doesn't mean hardforks should be taboo in my opinion though. On Mon, May 24, 2021, 01:09 vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Beca

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

On Mon, 24 May 2021 at 22:32, Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Before we can decide on tradeoffs that reduce security in favor of less > energy usage, or less inflation, or whatever goal you might have for > reducing (or delaying) coinbase rewards, we

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

Your analysis is correct. In perfect competition, profits tend to zero, which means the costs of mining tend to equal the reward. Since the reward is fees plus subsidy, reducing the subsidy should reduce mining costs. I think convincing other users we need such a softfork to reeuce the subsidy is

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

> FYI, proof of stake can be done without the "nothing at stake" problem. You > can simply punish people who mint on shorter chains (by rewarding people who > publish proofs of this happening on the main chain). In quorum-based PoS, you > can punish people in the quorum that propose or sign mult

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

Is this the kind of proof of burn you're talking about? > if i have a choice between two chains, one longer and one shorter, i can only choose one... deterministically What prevents you from attempting to mine block 553 on both chains? > miners have a

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

> It seems to me bitcoin's biggest vulnerabilities are either covert compromise of mining pool operations, or widespread compromise of networked mining systems and client node Stratum v2 will solve the mining pool problem. Widespread compromise of mining systems seems far fetched. That would invo

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

If bitcoin were to ever consider changing their PoW algorithm a little, it seems that would immediately make purchased ASIC mining equipment partially or wholly unusable to compromise the chain (and temporarily reduce energy usage without necessarily reducing security). One possible plan to deter

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

> > I don't think 99% of transactions need that level of security > Well you can't get security for the 1% of transactions that need it without > giving that security to all transactions on the chain. Also, the blockchain > security created by miners isn't really a per transaction thing anyway

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

I think security and inflation are intertwined aspects of a monetary system [1]. They are both necessary. Many Bitcoin articles discussed energy and security. More energy translates to more security. The other dimension is inflation. Bitcoin block reward is constant and reduced every 4 years. But i

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

> > your burn investment is always "at stake", any redaction can result in a > > loss-of-burn, because burns can be tied, precisely, to block-heights > I'm fuzzy on how proof of burn works. when you burn coins, you burn them to be used at a future particular block height: so if i'm burning for bl