public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Compatibility requirements for hard or soft forks
Date: Wed, 28 Oct 2015 10:06:22 -0400	[thread overview]
Message-ID: <CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com> (raw)

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

I'm hoping this fits under the moderation rule of "short-term changes to
the Bitcoin protcol" (I'm not exactly clear on what is meant by
"short-term"; it would be lovely if the moderators would start a thread on
bitcoin-discuss to clarify that):


Should it be a requirement that ANY one-megabyte transaction that is valid
under the existing rules also be valid under new rules?

Pro:  There could be expensive-to-validate transactions created and given a
lockTime in the future stored somewhere safe. Their owners may have no
other way of spending the funds (they might have thrown away the private
keys), and changing validation rules to be more strict so that those
transactions are invalid would be an unacceptable confiscation of funds.

Con: It is extremely unlikely there are any such large, timelocked
transactions, because the Core code has had a clear policy for years that
100,000-byte transactions are &quot;standard&quot; and are relayed and
mined, and
larger transactions are not. The requirement should be relaxed so that only
valid 100,000-byte transaction under old consensus rules must be valid
under new consensus rules (larger transactions may or may not be valid).


I had to wrestle with that question when I implemented BIP101/Bitcoin XT
when deciding on a limit for signature hashing (and decided the right
answer was to support any "non-attack"1MB transaction; see
https://bitcoincore.org/~gavin/ValidationSanity.pdf for more details).

-- 
--
Gavin Andresen

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

             reply	other threads:[~2015-10-28 14:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 14:06 Gavin Andresen [this message]
2015-10-31  3:43 ` [bitcoin-dev] Compatibility requirements for hard or soft forks Rusty Russell
2015-11-01 14:36   ` Justus Ranvier
2015-11-01 17:28 ` jl2012
2015-11-01 23:46   ` Tier Nolan
2015-11-02  0:23     ` Justus Ranvier
2015-11-02  0:33       ` Luke Dashjr
2015-11-02  1:30       ` Tier Nolan
2015-11-02  4:15         ` Justus Ranvier
2015-11-02  6:12         ` Justus Ranvier
2015-11-02 20:33     ` Gavin Andresen
2015-11-02 22:12       ` Justus Ranvier
2015-11-03  5:32       ` jl2012

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=CABsx9T0Evf3B_NtmdKxc_M1xRQh-jSC4JzTHCx8Ez9RzCypvMg@mail.gmail.com \
    --to=gavinandresen@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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