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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1QwuIC-00056o-7t
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 11:09:44 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
helo=mail-vw0-f47.google.com;
Received: from mail-vw0-f47.google.com ([209.85.212.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QwuIB-0005zB-Et
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 11:09:44 +0000
Received: by vwe42 with SMTP id 42so3868880vwe.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 26 Aug 2011 04:09:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.22.237 with SMTP id h13mr1001820vdf.228.1314356977998; Fri,
26 Aug 2011 04:09:37 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.164.165 with HTTP; Fri, 26 Aug 2011 04:09:37 -0700 (PDT)
In-Reply-To: <20110825201453.GA28296@ulyssis.org>
References: <20110825201453.GA28296@ulyssis.org>
Date: Fri, 26 Aug 2011 13:09:37 +0200
X-Google-Sender-Auth: k8LId0Q9IOfQAYzdOvf8hmaJ1qY
Message-ID: <CANEZrP0OyKSqEZj3UF0ArKFePuTi_HyM2_OZA8zXO5Uf+bAZwA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QwuIB-0005zB-Et
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
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: Fri, 26 Aug 2011 11:09:44 -0000
> On the github pull request I posted a general scheme that can convert arbitrary
> expressions over signature-checks (given in RPL notation) to bitcoin scripts.
> Maybe we can define an address type that encodes an expression in RPL form (which
> should be more compact and more easily parseable)?
What are the use cases for this?
From a mobile apps perspective, it doesn't make much sense to have
arbitrary scripts in a user-facing address. The software has to be
able to present some kind of reasonable user interface given an
address, it has to explain what is going to happen to the users money
and so on. From this perspective, doing pattern matching against some
encoded script template is annoying and inefficient. It'd be better to
just define another type of URI for each kind of transaction you wish
to support. This is doubly true because often to do the more
interesting contracts, you need out of band protocols, so the
"address" would probably specify some information that's not in the
final output script, like a rendezvous point.
|
