[Bitcoin-development] Proposed alternatives to the 20MB step function

Tier Nolan tier.nolan at gmail.com
Sat May 16 11:09:50 UTC 2015

On Sat, May 16, 2015 at 1:22 AM, Rusty Russell <rusty at rustcorp.com.au>

> Some tweaks:
> 1) Nomenclature: call tx_size "tx_cost" and real_size "tx_bytes"?

Fair enough.

> 2) If we have a reasonable hard *byte* limit, I don't think that we need
>    the MAX().  In fact, it's probably OK to go negative.

I agree, we want people to compress the UTXO space and a transaction with
100 inputs and one output is great.

It may have privacy problem though.

> 3) ... or maybe not, if any consumed UTXO was generated before the soft
>    fork (reducing Tier's perverse incentive).

The incentive problem can be fixed by excluding UTXOs from blocks before a
certain count.

UTXOs in blocks before 375000 don't count.

> 4) How do we measure UTXO size?  There are some constant-ish things in
>    there (eg. txid as key, height, outnum, amount).  Maybe just add 32
>    to scriptlen?

They can be stored as a fixed digest.  That can be any size, depending on
security requirements.

Gmaxwell's cost proposal is 3-4 bytes per UTXO change.  It isn't
4*UXTO.size - 3*UTXO.size

It is only a small nudge.  With only 10% of the block space to play with it
can't be massive.

This requires that transactions include scriptPubKey information when
broadcasting them.

> 5) Add a CHECKSIG cost.  Naively, since we allow 20,000 CHECKSIGs and
>    1MB blocks, that implies a cost of 50 bytes per CHECKSIG (but counted
>    correctly, unlike now).
> This last one implies that the initial cost limit would be 2M, but in
> practice probably somewhere in the middle.
>   tx_cost = 50*num-CHECKSIG
>                 + tx_bytes
>                 + 4*utxo_created_size
>                 - 3*utxo_consumed_size
> > A 250 byte transaction with 2 inputs and 2 outputs would have an adjusted
> > size of 252 bytes.
> Now cost == 352.

That is to large a cost for a 10% block change.  It could be included in
the block size hard fork though.  I think have one combined "cost" for
transactions is good.  It means much fewer spread out transaction checks.
The code for the cost formula would be in one place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/8e5f1099/attachment.html>

More information about the bitcoin-dev mailing list