Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

In principle, there is complete flexibility when it comes to the specific consensus details of the hard fork. One common suggestion has been to phase in a gradual blocksize increase beyond the initial 2MB cap included in Luke-Jr's proposal (a la BIP103); this would certainly be a welcome

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

I'd like to know this too. Is it just that a 4MB blockmaxweight would theoretically allow ~4MB blocks (if ~all witness data), which is too big? Or is there a more subtle reason we still need blockmaxsize after a HF? On May 30, 2017 9:28 AM, "Jorge Timón via bitcoin-dev" <

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

The 1MB classic block size is not redundant after segwit activation. Segwit prevents the quadratic hashing problems, but only for segwit outputs. The 1MB classic block size prevents quadratic hashing problems from being any worse than they are today. Mark On Tue, May 30, 2017 at 6:27 AM, Jorge

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

My understanding is that you cannot possibly violate the 1 MB block size rule without also violating the 4 MB weight rule. Regarding size alone, the only check we care about if we accept segwit is: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2891 [size4] If that doesn't

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

On Wednesday 31 May 2017 1:22:44 AM Jorge Timón via bitcoin-dev wrote: > Why is it > https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661 > not enough at this point? > Why the need for a transaction size limit? Because the bottleneck is hashing the transaction, which costs (in

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

> The 1MB classic block size prevents quadratic hashing > problems from being any worse than they are today. > > Add a transaction-size limit of, say, 10kb and the quadratic hashing problem is a non-issue. Donezo. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

That would invalidate any pre-signed transactions that are currently out there. You can't just change the rules out from under people. > On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev > wrote: > > >> The 1MB classic block size prevents

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

On Wed, May 31, 2017 at 1:50 AM, James MacWhyte wrote: > >> >> The 1MB classic block size prevents quadratic hashing >> problems from being any worse than they are today. >> > > Add a transaction-size limit of, say, 10kb and the quadratic hashing problem > is a non-issue.

[bitcoin-dev] Improvement Proposal

Improvement Proposal To allow users devices (including mobile and/or IoT devices). to connect and some how participate in the same BTC bock chain network without mining. The incentive for this participants can be a lottery schema, running in "parallel to mining in the same network" and in the

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs BIP91 ... how many are there?: https://xkcd.com/927 - If some miners and exchanges collude to enact a rapid 2MB+Segwit hard fork coin... and calling it "bitcoin" on major exchanges this could swiftly fragment the

Re: [bitcoin-dev] Improvement Proposal

Yann, Unfortunately sybil attacks [[https://en.wikipedia.org/wiki/Sybil_attack#Description]](https://en.wikipedia.org/wiki/Sybil_attack#Description) would prevent this from working... even if there was some way to prove that an entity performed the transaction validation. Proving the relay of