summaryrefslogtreecommitdiff
path: root/df/61fd9015206044ab091d73890684f443dd8a65
blob: 50770c3c132a5fd9bba26f295287dd0d3c9ab9d6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <rusty@ozlabs.org>) id 1YtPs8-0000KV-6X
	for bitcoin-development@lists.sourceforge.net;
	Sat, 16 May 2015 00:22:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of ozlabs.org
	designates 103.22.144.67 as permitted sender)
	client-ip=103.22.144.67; envelope-from=rusty@ozlabs.org;
	helo=ozlabs.org; 
Received: from ozlabs.org ([103.22.144.67])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YtPs6-0002og-UV
	for bitcoin-development@lists.sourceforge.net;
	Sat, 16 May 2015 00:22:32 +0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id 3A3BC140B0E; Sat, 16 May 2015 10:22:23 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Tier Nolan <tier.nolan@gmail.com>
In-Reply-To: <CAE-z3OUzYZDvsOYEDT229vnvNBa9ntW+86O3uA-K5-KaneMF_g@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
	<CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com>
	<CAE-z3OUzYZDvsOYEDT229vnvNBa9ntW+86O3uA-K5-KaneMF_g@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Sat, 16 May 2015 09:52:14 +0930
Message-ID: <87a8x5l6bt.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1YtPs6-0002og-UV
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2015 00:22:32 -0000

Tier Nolan <tier.nolan@gmail.com> writes:
> On Sat, May 9, 2015 at 4:36 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>
>> An example would
>> be tx_size = MAX( real_size >> 1,  real_size + 4*utxo_created_size -
>> 3*utxo_consumed_size).
>
>
> This could be implemented as a soft fork too.
>
> * 1MB hard size limit
> * 900kB soft limit

I like this too.

Some tweaks:

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

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.

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

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?

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.

Cheers,
Rusty.