Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-16 📝 Original message:On Sat, May 16, 2015 at ...

📅 Original date posted:2015-05-16
📝 Original message:On Sat, May 16, 2015 at 1:22 AM, Rusty Russell <rusty at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150516/8e5f1099/attachment.html>;