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

The problem with >100kb transactions isn't that there are a lot of already-signed transactions out there, or even that there are good use cases for them, but that such transactions and use cases could exist, and there is no way of disallowing them without possibly costing someone a lot of money.

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

> Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has > quadratic hashing risks, and maybe James' 10KB is too ambitious; but even if > so, a simple 1MB tx size limit would clearly do the trick. The broader point > is that quadratic hashing is not a compelling reason to keep

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

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.

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

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

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

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

Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing. I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM growth, of which bandwidth seems the most constraining. - Erik On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev <