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
143
144
145
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <maciej@bitalo.com>) id 1VCkpp-0005Xp-1T
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Aug 2013 06:27:01 +0000
Received-SPF: fail (sog-mx-1.v43.ch3.sourceforge.com: domain of bitalo.com
does not designate 74.125.82.199 as permitted sender)
client-ip=74.125.82.199; envelope-from=maciej@bitalo.com;
helo=mail-we0-f199.google.com;
Received: from mail-we0-f199.google.com ([74.125.82.199])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VCkpm-0006iA-Nw
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Aug 2013 06:27:00 +0000
Received: by mail-we0-f199.google.com with SMTP id t60so208119wes.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 22 Aug 2013 23:26:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=ruG++WnAd7yGBrixwhIiygtnUbP++FDMpvNZIwxvPsI=;
b=FMQLXIMDUXNHzI03/aL2MJ1Rn0eJ7YjQxYgjNedMEscb5fadtsJDdr9OpQhpBc1F8d
6FUbchNQK05aXJievtfjNjQbXMWHQflWLYrurE2qbBLg19IgaUG5zRt1hdDJv8I/DyGX
CvQARFws1GYAIBexeadNGEo48KPwOuHpHvyGg311dcp4v0qlsZ53p1hsZ+1CI+2krXWk
RBMxu72uxF/W/6K9gcpWj6ictceJNeOZYmm4V0Z6aAmTgm3iNqN46Jt31OutPMrsODmG
sgTjVha8IILqR+yCpWDmxeMDox/15umXx1+W1QlxnXVVyU2Y1eP4T20SiWTeX3Aqykf9
cMhw==
X-Gm-Message-State: ALoCoQnBfcPjhF6IKZ0OG/gHvwo2st6lhuQjvEx6YTjAb2k2Bxo3a6I5YzG38Z68dpSmLbU3jgTf
MIME-Version: 1.0
X-Received: by 10.180.73.103 with SMTP id k7mr904794wiv.24.1377239211401; Thu,
22 Aug 2013 23:26:51 -0700 (PDT)
Received: by 10.217.2.17 with HTTP; Thu, 22 Aug 2013 23:26:51 -0700 (PDT)
X-Originating-IP: [83.30.116.231]
Date: Fri, 23 Aug 2013 08:26:51 +0200
Message-ID: <CAD=_8RR=vm0ivpdNg7=bnX_bQ7CC8oZnVi5iWXvbgeBD8W4Ctg@mail.gmail.com>
From: Maciej Trebacz <maciej@bitalo.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=f46d043c815ef7754704e4977dbd
X-Spam-Score: 5.9 (+++++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
4.0 SPF_CHECK_FAIL SPF reports sender host as NOT permitted to send
mails from
0.9 SPF_FAIL SPF: sender does not match SPF record (fail)
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VCkpm-0006iA-Nw
Subject: [Bitcoin-development] Way to tell that transaction was issued by a
specific person/company
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, 23 Aug 2013 06:27:01 -0000
--f46d043c815ef7754704e4977dbd
Content-Type: text/plain; charset=ISO-8859-1
As far as I know current Bitcoin protocol doesn't let you to include any
arbitrary data with the transactions (as it would become non-standard and
clients would not relay it). So if you have multiple addresses you can't
sign them with a single private key and include that signature in the
transaction so other party can verify it against your public key. This
could become very handy though - a reputable wallet service could issue
transactions that require zero confirmations from the other party,
because with the added signature they know that the transaction is from
this reputable service and they trust that this service won't try to double
spend. I'm thinking of something like Mt.Gox's "green address", but baked
into protocol (Mt.Gox does this by sending your funds to some known by the
others Bitcoin address and then relaying them to the final destination).
Do you think it's possible/feasible to add a feature like this to the
current protocol without forking the chain? This could be as simple as
adding support for following scripts:
<data block> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECK
<data block> OP_DROP OP_HASH160 <pubKeyHash> OP_EQUAL
The <data block> should not be longer than 34 bytes (or more, depending if
we want to have some room for future use cases). This is all that needs to
be changed in the Bitcoin client. Now for actually using the feature a
further definition of <data block> is required:
22 AC 20 <32 byte signature>
22 is data block length and "AC 20" is just a sub-opcode that can be either
defined by the protocol (in this case I'm reusing OP_CHECKSIG's opcode but
that's not required since this is all part of data block) or just agreed
upon between people that want to use this feature.
It's possible that the above could be achieved in some simpler way using
other opcodes or mechanisms present in Bitcoin protocol that I'm not aware
of. Either way, I'd like to hear your opinions whether a feature like this
should be considered and added.
--f46d043c815ef7754704e4977dbd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As far as I know current Bitcoin protocol doesn't let =
you to include any arbitrary data with the transactions (as it would become=
non-standard and clients would not relay it). So if you have multiple addr=
esses you can't sign them with a single private key and include that si=
gnature in the transaction so other party can verify it against your public=
key. This could become very handy though - a reputable wallet service coul=
d issue transactions that require zero confirmations from the other party, =
because=A0with the added signature they know that the transaction is from t=
his reputable service and they trust that this service won't try to dou=
ble spend. I'm thinking of something like Mt.Gox's "green addr=
ess", but baked into protocol (Mt.Gox does this by sending your funds =
to some known by the others Bitcoin address and then relaying them to the f=
inal destination).<div>
<br></div><div>Do you think it's possible/feasible to add a feature lik=
e this to the current protocol without forking the chain? This could be as =
simple as adding support for following scripts:</div><div><br></div><div>
<data block> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVER=
IFY OP_CHECK<br></div><div><data block> OP_DROP OP_HASH160=A0<pubK=
eyHash> OP_EQUAL</div><div><br></div><div>The <data block> should =
not be longer than 34 bytes (or more, depending if we want to have some roo=
m for future use cases). This is all that needs to be changed in the Bitcoi=
n client. Now for actually using the feature a further definition of <da=
ta block> is required:</div>
<div><br></div><div>22 AC 20 <32 byte signature></div><div><br></div>=
<div>22 is data block length and "AC 20" is just a sub-opcode tha=
t can be either defined by the protocol (in this case I'm reusing OP_CH=
ECKSIG's opcode but that's not required since this is all part of d=
ata block) or just agreed upon between people that want to use this feature=
.</div>
<div><br></div><div>It's possible that the above could be achieved in s=
ome simpler way using other opcodes or mechanisms present in Bitcoin protoc=
ol that I'm not aware of. Either way, I'd like to hear your opinion=
s whether a feature like this should be considered and added.</div>
</div>
--f46d043c815ef7754704e4977dbd--
|
