summaryrefslogtreecommitdiff
path: root/dd/a84c4f80132dee3a3bbec2197ca7a40d1d3000
blob: ec7d1c6d1b988b19c82ef9242a5078c8343f8d14 (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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9B9214A4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 20:34:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
	[209.85.220.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0AB8EE8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 20:34:28 +0000 (UTC)
Received: by qkbm65 with SMTP id m65so106977809qkb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 13:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
	:content-type; bh=6pbEVmwbB7K0BGQTi6hNB2sMEt9HhiEB83NpGsGAfUs=;
	b=wpBqwIyjdx7wm9DSfWZRra7GVn23+NkNj68EB38/o3YdyWo7vy2W+Ngwv56xSiYN/6
	lN/CnGWqQmRcCYfNThvezbpP70fRRhFyO+pxhmt2MK84dNNygoK/uUjSG8ZkbSheprbS
	rLwJRga5MKk5iaGW94Zxi+bgPvIGGgYlxbDSroKjmHBv7azjXFRgnN+rttLCajqcrsfs
	JHqzl5QLKjPP++1To0aIlnGcrqFB0m0XLkgemuGr1/bw6G+4IMiFYtcsYQzdA7SBFO84
	871arhbEMQnBTJU/z8W/WAzHRzjaA2UYWXDm4cLAZ846bhCoqC8K2qvXYWyIDit8vHMD
	2KKw==
MIME-Version: 1.0
X-Received: by 10.140.84.163 with SMTP id l32mr6782862qgd.94.1437597267311;
	Wed, 22 Jul 2015 13:34:27 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Wed, 22 Jul 2015 13:34:27 -0700 (PDT)
In-Reply-To: <CAJ+8mEOPRQ-euqL62nB8_7xTaZbjCmFwKHXUrD9y=bNr56m-rg@mail.gmail.com>
References: <CAJ+8mEOPRQ-euqL62nB8_7xTaZbjCmFwKHXUrD9y=bNr56m-rg@mail.gmail.com>
Date: Wed, 22 Jul 2015 21:34:27 +0100
Message-ID: <CAE-z3OWgdDiFNgKd8D_pPyV6ZdPdUjdFwL7eMQzjAL_xfn+ZUg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c154e872c07f051b7cb245
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 20:34:28 -0000

--001a11c154e872c07f051b7cb245
Content-Type: text/plain; charset=UTF-8

Rather than re-enable OP_LEFT, a NOP could be re-purposed in a soft fork.

OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]] [LEN_PARAM] OP_LEFTEQUALVERIFY
OP_DROP OP_CHECKSIG

A B L OP_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match.
If not, then the script immediately fails.  If either array is less than L
bytes or if there are fewer than 3 values on the stack, then it also fails.

The OP_DROP is needed as the new opcode must count as a NOP for legacy
nodes.

A change like this would only cause a once-off improvement in efficiency,
so it is less likely to be worth the effort.

It also requires most clients to be updated to support the new address
system.

A different BIP could be added for that.

An alternative way to add new opcodes is to use a different script engine
like with P2SH.


On Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While we're all debating the block size, please review this proposal to
> modestly increase the number of transactions per block.
>
> https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63
>
> Best,
>
> Jeremy
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a11c154e872c07f051b7cb245
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Rather than re-enable OP_LEFT, a NOP could be re=
-purposed in a soft fork.<br><br>OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]]=
 [LEN_PARAM] OP_LEFTEQUALVERIFY OP_DROP OP_CHECKSIG<br><br></div>A B L OP_L=
EFTEQUALVERIFY checks if the leftmost L bytes of A and B match.=C2=A0 If no=
t, then the script immediately fails.=C2=A0 If either array is less than L =
bytes or if there are fewer than 3 values on the stack, then it also fails.=
<br><br></div><div>The OP_DROP is needed as the new opcode must count as a =
NOP for legacy nodes.<br></div><div><br></div><div>A change like this would=
 only cause a once-off improvement in efficiency, so it is less likely to b=
e worth the effort.<br><br></div><div>It also requires most clients to be u=
pdated to support the new address system.<br><br></div><div>A different BIP=
 could be added for that.<br></div><div><br></div><div>An alternative way t=
o add new opcodes is to use a different script engine like with P2SH.<br></=
div><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev <span dir=3D"ltr=
">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>While we&#39;re all debating=
 the block size, please review this proposal to modestly increase the numbe=
r of transactions per block.</div><div><br></div><div><a href=3D"https://gi=
st.github.com/JeremyRubin/4d17d28d5c681a93fa63" target=3D"_blank">https://g=
ist.github.com/JeremyRubin/4d17d28d5c681a93fa63</a><br></div><div><br></div=
><div>Best,</div><div><br></div><div>Jeremy</div><div><br></div><div><br></=
div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a11c154e872c07f051b7cb245--