public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nathan Cook <nathan.cook@gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
Date: Mon, 12 Jun 2017 19:27:14 +0300	[thread overview]
Message-ID: <CAGNXQMRuR8BHFXSjxTWVsFaSs5cXfmSzVvbmds5Nqch4UnBMVQ@mail.gmail.com> (raw)
In-Reply-To: <CAD1TkXtut2LZdp5Qo9ep2FfMGFFYqdxtobLJgoC7UutyNujKKg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

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. Slowly reducing the limit doesn't really solve this problem.

I propose to make them hard enough to confirm that no-one will use them
without a very good reason. Just require that any block containing an
outsized transaction be mined at a greater difficulty – quadratically
greater. Such a block is more expensive *for the block's miner*, not just
for the other miners, or for other nodes. Anyone who really, really needs
to use a 400kb transaction can pay a miner to mine it.

Quadratic hashing isn't risky when it is inherently limited by a
corresponding reduction in the rate at which the "bad" blocks can be
generated. That said, there's nothing I can see which is actually good
about large, expensive to validate transactions, and so >1MB transactions
should remain invalid, as they are today.


Nathan Cook

On 2 June 2017 at 22:40, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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
> blockmaxsize post-HF: does someone have a better one?
>
> I think this is exactly the right direction to head.  There are
> arguments to be made for various maximum sizes... Maybe the limit
> could be set to 1mb initially, and at a distant future block
> height(years?) automatically drop to 500kb or 100kb?  That would give
> anyone with existing systems or pre-signed transactions several years
> to adjust to the change.  Notification could (?possibly?) be done with
> a non-default parameter that must be changed to continue to use 100kb
> - <1mb transactions, so no one running modern software could claim
> they were not informed when that future date hits.
>
> I don't see any real advantages to continuing to support transactions
> larger than 100kb excepting the need to update legacy use cases /
> already signed transactions.
>
> On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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
> > blockmaxsize post-HF: does someone have a better one?
> >
> >
> >
> > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> 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
> >> <bitcoin-dev@lists.linuxfoundation.org> 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.
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6501 bytes --]

  reply	other threads:[~2017-06-12 16:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23 20:23 [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 Luke Dashjr
2017-05-23 23:07 ` Erik Aronesty
2017-05-30 13:27   ` Jorge Timón
2017-05-30 20:10     ` Jacob Eliosoff
2017-05-30 21:24     ` Mark Friedenbach
2017-05-30 22:26       ` Jorge Timón
2017-05-30 23:50       ` James MacWhyte
2017-05-31  1:09         ` Jean-Paul Kogelman
2017-05-31  3:07           ` Jacob Eliosoff
2017-06-02 19:40             ` Jared Lee Richardson
2017-06-12 16:27               ` Nathan Cook [this message]
2017-05-31  1:22         ` Jorge Timón
2017-05-31  4:14           ` Luke Dashjr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGNXQMRuR8BHFXSjxTWVsFaSs5cXfmSzVvbmds5Nqch4UnBMVQ@mail.gmail.com \
    --to=nathan.cook@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jaredr26@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox