From: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292
Date: Mon, 20 Jul 2015 20:43:51 +0100 [thread overview]
Message-ID: <CAE-z3OVWYaoGc+_=xQN1=CV=LUHdLEtuds6FZCXdktowfCaLYA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T30aUx+Leb2HXx2QrMT8R_eTXV9hiC99av957645iQm1Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
On Mon, Jul 20, 2015 at 8:10 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> After deployment, the maximum serialized size of a transaction allowed
> in a block shall be 100,000 bytes.
>
This could render transactions with a locktime in the future as unspendable.
It is pretty low probability that someone has created a >100kB locked
transaction though.
It violates the principle that no fork should render someone's coins
unspendable.
At the cost of weakening the protection, the rule could be made to only
apply to version 2 transactions.
*Specification*
The transaction version is increased to version two.
All coinbase transactions must be version two or higher.
If any of its parent transactions are version two or higher
then the transaction must be version two or higher.
The maximum serialized size of a version two transactions allowed in
a block is 100,000 bytes.
As time passes more and more of the UTXO set will be from version two
transactions. To launch the attack, the attacker needs an historical UTXO
entry.
Standard software would create version two transactions even if all inputs
were version one.
The rule could be applied to all transactions most of the time, and have
daily blocks that allow legacy transactions.
This rule shall apply to version 1 transactions too unless the block
height is
a multiple of 100.
At the risk of encouraging feature creep, if the transaction size is being
limited, it would be useful to also limit the size of all its inputs.
This helps with fraud proofs and offline signing.
*Specification*
The transaction version is increased to version two.
All coinbase transactions must be version two or higher.
If any of its parent transactions are version two or higher
then the transaction must be version two or higher.
The maximum serialized size of a version two transactions allowed in
a block is 100,000 bytes.
The maximum of the total serialized size of a version two transaction
and all
of its parents allowed in a block shall be 200,000 bytes.
[-- Attachment #2: Type: text/html, Size: 3027 bytes --]
next prev parent reply other threads:[~2015-07-20 19:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 19:10 Gavin Andresen
2015-07-20 19:43 ` Tier Nolan [this message]
2015-07-20 20:30 ` Gavin Andresen
2015-07-20 19:58 ` Ross Nicoll
2015-07-20 20:55 ` Gregory Maxwell
2015-07-21 18:09 ` Gavin Andresen
2015-07-21 18:18 ` Jeremy Rubin
2015-07-23 15:41 ` Gavin Andresen
2015-07-24 20:59 ` Gavin Andresen
2015-07-25 0:47 ` odinn
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='CAE-z3OVWYaoGc+_=xQN1=CV=LUHdLEtuds6FZCXdktowfCaLYA@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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