Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/24/2017 04:27 PM, Emin Gün Sirer wrote: > Because there's no consensus on the contents of the mempool, this approach > is unsafe and will lead to forks. It also opens a new attack vector where > people can time the flood of new transactions

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Le 27/03/2017 à 00:15, Eric Voskuil via bitcoin-dev a écrit : > On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote: > > > > The repeated use of the term "network upgrade" in place of the > accepted technical term (hard fork) is misleading. This and the > presupposition that the hard fork is

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote: Peter, > Yes, it is different. It’s different because the future network > upgrade to larger blocks includes a loosening of the consensus > ruleset whereas previous upgrades have included a

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote: > On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev > > wrote: > > With a tightening of the rule set, a hash power minority that has > not

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/26/2017 01:22 PM, Bryan Bishop via bitcoin-dev wrote: > On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev > > wrote: > > With a tightening of the

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

>> With a tightening of the rule set, a hash power minority that has not upgraded will not produce a minority branch; instead they will simply have any invalid blocks they produce orphaned, serving as a wake-up call t>o upgrade. > False. With bip9-based soft-fork-based activation of segwit, miner

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann wrote: > He stated that "any invalid blocks they produce" will be orphaned. This is > not false. If non-upgraded miners do not produce blocks that are invalid > per the new rules, their blocks will not be orphaned. This is

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

As a user, I would far prefer a split over any kind of mandatory change that would drastically harm the ecosystem. Many users feel the same way. Level 3 is a pure attack on users who do not conform to your beliefs. Please do not put words in people's mouths claiming they wouldn't prefer a split

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Hello Alex, Thank you for the thoughtful reply. > Surely you are aware that what you are proposing is vastly different from the > way soft forks have historically worked. Yes, it is different. It’s different because the future network upgrade to larger blocks includes a loosening of the

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

No I actually agree with a lot of what you said. I feel there has been a lack of precision and consistency in talking about these things in the past. This is not intentional, but its just what happens when a lot of different people are all giving their own arguments. I tried to be a bit more

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: As a Bitcoin user I find it abhorrent the way you are proposing to intentionally cripple the chain and rules I want to use instead of just peacefully splitting. I just want to point out what

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Surely you are aware that what you are proposing is vastly different from the way soft forks have historically worked. First of all, the bar for miners being on the new chain is extremely high, 95%. Second of all, soft forks make rule restrictions on classes of transactions that are already

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

One of the purported benefits of a soft-forking change (a tightening of the consensus rule set) is the reduced risk of a blockchain split compared to a loosening of the consensus rule set. The way this works is that miners who fail to upgrade to the new tighter ruleset will have their

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what "Time is running short I fear" stands for and when 50% > is supposed to be reached -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what "Time is running short I fear"

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Because there's no consensus on the contents of the mempool, this approach is unsafe and will lead to forks. It also opens a new attack vector where people can time the flood of new transactions with the discovery of a block by a competitor, to orphan the block and to fork the chain. The

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Since I have been working on crypto currencies/bitcoin, I kept repeating: btc should make a priority to significantly increase the ridiculous number of full nodes we have today, design an incentive for people to run full nodes and design a system for people to setup full nodes in an acceptable

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Since I have been working on crypto currencies/bitcoin, I kept repeating: btc should make a priority to significantly increase the ridiculous number of full nodes we have today, design an incentive for people to run full nodes and design a system for people to setup full nodes in an acceptable

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

> For example would be something like this: > If block = (empty OR <%75 of mempool) THEN discard > This threshold just an example I don't think this is a good idea, mempool is different from node to node and is not a part of the consensus. Hampus 2017-03-24 18:29 GMT+01:00 Nick ODell via

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Two concerns: 1) This makes block validity depend on things that aren't in the blockchain. If you and I have different minrelaytxfee's, we will have different mempool sizes. Your node will discard a block, but my node will think it is valid, and our nodes will not come to consensus. 2) This is