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

[Tier Nolan <tier.nolan@gmail.com>]

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

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

> 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.

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