rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 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>