rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2013-03-13 📝 Original message: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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130313/2c3d7d5f/attachment.sig>