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?

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

[bitcoin-dev] Bandwidth limits and LN w/ node relay network topography

Bandwidth limits: Would be nice to specify global and per node up/down bandwidth limits. Communicate limits to peers. Monitor actual bandwidth with peers. Adjust connections accordingly to attain bandwidth goals/limits. With Lightning Network: Prepay for bandwidth/data. Continue paying nodes who

Re: [bitcoin-dev] Flag day activation of segwit

"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov 2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is signaling readiness, segwit will be activated in the retarget cycle after the next one" Just change BIP9 and the code to say "if in a full

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?

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

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?

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?

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] Fraud proofs for block size/weight

On Mar 25, 2017 12:17 AM, "Luke Dashjr via bitcoin-dev" wrote: Any ideas? :/ Can't the size be aggregated up the tree such that each midstate hash is the hash of branches below plus the agreegate of the sizes below. This would make the root hash(left

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