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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1Qx3yl-0002aA-GW
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 21:30:19 +0000
X-ACL-Warn:
Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130]
helo=cavuit02.kulnet.kuleuven.be)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Qx3yk-0007qe-FI for bitcoin-development@lists.sourceforge.net;
Fri, 26 Aug 2011 21:30:19 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 1F0871282EB.A5DF7
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 1F0871282EB;
Fri, 26 Aug 2011 23:30:11 +0200 (CEST)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id E884B31E702;
Fri, 26 Aug 2011 23:30:10 +0200 (CEST)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id 9A8ABF8004;
Fri, 26 Aug 2011 23:33:51 +0200 (CEST)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 0856087C1B0; Fri, 26 Aug 2011 23:30:11 +0200 (CEST)
Date: Fri, 26 Aug 2011 23:30:11 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20110826213009.GA22361@ulyssis.org>
References: <20110825201453.GA28296@ulyssis.org>
<CANEZrP0OyKSqEZj3UF0ArKFePuTi_HyM2_OZA8zXO5Uf+bAZwA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP0OyKSqEZj3UF0ArKFePuTi_HyM2_OZA8zXO5Uf+bAZwA@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qx3yk-0007qe-FI
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 21:30:19 -0000
On Fri, Aug 26, 2011 at 01:09:37PM +0200, Mike Hearn wrote:
> > 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.
You're quite right - currently addresses encode a particular output script,
and the client pattern matches to know how to deal with the incoming funds.
It's far from sure this will remain the case in the future. Maybe we'll have
an out of band protocol over which a request "i want to pay you for item X"
is sent, with the required transaction output as answer.
A generic way for encoding complex transaction scripts in a compact form may
be useful for "manual" playing with them - but I agree that we should
probably wait for a use case for this.
Independent from the question of complex-script-addresses are useful, I do
think it is useful (and possible, see pull req) to allow a class of scripts
that represent boolean expressions over signature checks to pass the
IsStandard() test - that way we make sure that whenever in the future we
want to support creating such an expression, there will at least be a to
encode it in a way that the network will accept it. The only question is
what possible problems there are with accepting them.
--
Pieter
|
