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. Sl
> 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
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
blockmaxsiz
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 C
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 quadratic hashing
>> problems from being
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. Donezo.
Why is it
http
> 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
bitcoin-dev
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 fai
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 Ti
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" <
bitcoin-dev@lists.linux
Why not simply remove the (redundant after sw activation) 1 mb size
limit check and increasing the weight limit without changing the
discount or having 2 limits?
On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
wrote:
> Personally, I would prefer if a 2MB lock-in that uses BIP103 f
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 <
bitcoin-dev@list
In light of some recent discussions, I wrote up this BIP for a real 2 MB block
size hardfork following Segwit BIP148 activation. This is not part of any
agreement I am party to, nor anything of that sort. Just something to throw
out there as a possible (and realistic) option.
Note that I cannot
13 matches
Mail list logo
