From: Peter Todd <pete@petertodd•org>
To: Luke-Jr <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] 0.8.1 ideas
Date: Wed, 13 Mar 2013 11:05:01 -0400 [thread overview]
Message-ID: <20130313150501.GA14067@savin> (raw)
In-Reply-To: <201303131256.30144.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
On Wed, Mar 13, 2013 at 12:56:29PM +0000, Luke-Jr wrote:
> Here's a simple proposal to start discussion from...
>
> BEFORE block 262144:
> - Never make a block that, combined with the previous 4 blocks, results in
> over 4500 transaction modifications.
> - Reject any block that includes more than 4500 transaction modifications on
> its own (slight soft-fork)
> - (these rules should make older clients safe under most circumstances)
>
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391 transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe unless a reorg is more than
> 6 blocks deep)
>
> FROM block 393216 onward (hard fork #2):
> - Never make, and reject any block that includes more than 48781 transaction
> modifications on its own (this *should* be equivalent to 2 MB)
> - Accept blocks up to 2 MB in data size
If we're going to consider doing this, at minimum we need to also
include a separate limit for how much the UTXO set can be grown by each
block, calculated as the size of the scriptPubKey + constant metadata.
(tx hash, index #, nValue, nVersion, nHeight should cover it)
A P2SH transaction txout would measure 71bytes under that model. Given
that we haven't even shown we can limit the creation of txouts that can
not be spent economically caution would dictate setting the UTXO growth
limit fairly low, say 1/4th of the block limit.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-03-13 15:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 12:56 Luke-Jr
2013-03-13 13:14 ` Gregory Maxwell
2013-03-13 15:05 ` Peter Todd [this message]
2013-03-13 15:18 ` Gregory Maxwell
2013-03-13 15:26 ` Luke-Jr
2013-03-13 16:04 ` Peter Todd
2013-03-13 17:41 ` Mark Friedenbach
2013-03-13 17:58 ` Pieter Wuille
2013-03-13 18:27 ` Mark Friedenbach
2013-03-13 18:35 ` slush
2013-03-13 18:38 ` Pieter Wuille
2013-03-13 19:30 ` Gregory Maxwell
[not found] ` <16B6728E-4220-4DA6-B740-FA38A7C19CCB@thelibertyportal.com>
2013-03-13 20:24 ` Gregory Maxwell
2013-03-13 20:18 ` Luke-Jr
2013-03-13 18:04 ` Luke-Jr
2013-03-13 21:06 ` Andy Parkins
2013-03-13 21:14 ` Luke-Jr
2013-03-13 21:22 ` Roy Badami
2013-03-13 21:27 ` Gregory Maxwell
2013-03-13 21:36 ` Roy Badami
2013-03-14 0:18 ` Cameron Garnham
2013-03-15 17:06 ` Benjamin Lindner
2013-03-15 19:23 ` Luke-Jr
2013-03-15 19:52 ` Gregory Maxwell
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=20130313150501.GA14067@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)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