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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
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 <drak@zikula.org>) id 1VhTxw-0000Pc-86
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Nov 2013 00:42:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of zikula.org
designates 74.125.82.182 as permitted sender)
client-ip=74.125.82.182; envelope-from=drak@zikula.org;
helo=mail-we0-f182.google.com;
Received: from mail-we0-f182.google.com ([74.125.82.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VhTxv-0007KO-6J
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Nov 2013 00:42:24 +0000
Received: by mail-we0-f182.google.com with SMTP id q59so2180978wes.27
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Nov 2013 16:42:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=QCo1/41d8esRU8waNPCgrMCzwYMKJAa5xxFAZFkAqyw=;
b=KhgIjt3yDCANScWQdfgfq1pgoavzZPwWblnDHnOhFv+ZUF19ykzw+XnC22cMeiM7NR
aJ27zQ4s/2p54rIVsqXqGDi32ExVjBwTIGaOW7f3NEVN8LMsD+G0aZhyB2A2msXgifvE
VUcP/Xc2PBuzxZE22UYwqaroJTC2wRNZ4jHtzcp/BBt6OEpmPFYX1pxhuU1NgHqVSa0N
mhU42UX5z14t9DhxCGIAelF93QOeUtXtvRI1rgaOQXbHBwtoaaRsouHYBLN7a0w00tpA
SXnXFJDTiab7J8WDjXwX08JqdyOGS/NHKsEU7nBXY82aKSZ/NiKVpKWblj+MPY4+z03J
39tg==
X-Gm-Message-State: ALoCoQlfYtLevpKp58tHrl11vrc6y4VLh9KSo++jZPbhma0TFhTbXo+DZ10M6skDXYuPfMu9ZzJx
X-Received: by 10.180.72.238 with SMTP id g14mr9105940wiv.17.1384562536930;
Fri, 15 Nov 2013 16:42:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Fri, 15 Nov 2013 16:41:56 -0800 (PST)
In-Reply-To: <201311142301.39550.luke@dashjr.org>
References: <CAKaEYhK4oXH3hB7uS3=AEkA6r0VB5OYyTua+LOP18rq+rYajHg@mail.gmail.com>
<528547FD.2070300@gmail.com>
<CAJfRnm7-34jwX0m+0Trj9-YvXFeUYMGq35AoRkY7bq9w-XpabA@mail.gmail.com>
<201311142301.39550.luke@dashjr.org>
From: Drak <drak@zikula.org>
Date: Sat, 16 Nov 2013 00:41:56 +0000
Message-ID: <CANAnSg1-uW+g3KYyqdfqdvcUybpu2Mn2-j4hJN-5-gVWPrdgvg@mail.gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=f46d043d67372f0d2004eb409650
X-Spam-Score: -0.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_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: dashjr.org]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VhTxv-0007KO-6J
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] moving the default display to mbtc
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 Nov 2013 00:42:24 -0000
--f46d043d67372f0d2004eb409650
Content-Type: text/plain; charset=UTF-8
On 14 November 2013 23:01, Luke-Jr <luke@dashjr.org> wrote:
> I wonder if it might make sense to bundle some other terminology fixups at
> the
> same time.
>
A very good idea.
> Right now, Bitcoin-Qt has been using the term "confirmations" (plural) to
> refer to how many blocks deep a transaction is buried. We also use the term
> "confirmation" to refer to the point where a transaction is accepted as
> paid.
> IMO, the latter use makes sense, but the former leads to confusion
> especially
> in light of scamcoins which abuse this confusion to claim they have "faster
> confirmations", implying that the actual confirmation occurs faster when it
> really doesn't. "5 blocks deep" may not be more clear to laymen, but at
> least
> it makes it harder for people to confuse with actual confirmation.
>
I think people are more familiar with check clearance - "the payment/check
has cleared".
If "confirmation" and "n confirmations" together are problematic, I'd talk
about "cleared payments" and "n confirmations"
So "a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times".
Then at least you are not using the same word for two different meanings
and you're using stuff more familiar in popular lexicon.
I dont think it's helpful for users if we use the word "blocks".
Without the technical details, I just explain to normal bitcoin users that
the Bitcoin network checks and confirms the payment is valid (multiple
times).
I think we all know the problems with the term "address". People naturally
> compare it to postal addresses, email addresses, etc, which operate
> fundamentally different. I suggest that we switch to using "invoice id" to
> refer to what is now known as addresses, as that seems to get the more
> natural
> understanding to people. On the other hand, with the advent of the payment
> protocol, perhaps address/invoice id use will die out soon?
>
I think "key id" is a bit alien at user level - it's not something they are
used to.
For years, people had a problem with "email address", instead using "email
number" but they got there eventually. Most people nowadays use "email
address"
So "payment address" or "bitcoin address" make better sense here when
qualified as a "<foo> address" and not just an "address"
You could also call it "payment id", but I dont think "invoice id" since
no-one pays to an invoice id that's just a reference for a payment, not the
destination.
People are very familiar with Paypal these days, and are familiar with
"paypal address" or their "paypal id" so again I think valid contenders are
"bitcoin address" or "bitcoin id".
Regards,
Drak
--f46d043d67372f0d2004eb409650
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
4 November 2013 23:01, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:luke=
@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">
<div><span style=3D"color:rgb(34,34,34)">I wonder if it might make sense to=
bundle some other terminology fixups at the</span><br></div>
same time.<br></blockquote><div><br></div><div>A very good idea.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
Right now, Bitcoin-Qt has been using the term "confirmations" (pl=
ural) to<br>
refer to how many blocks deep a transaction is buried. We also use the term=
<br>
"confirmation" to refer to the point where a transaction is accep=
ted as paid.<br>
IMO, the latter use makes sense, but the former leads to confusion especial=
ly<br>
in light of scamcoins which abuse this confusion to claim they have "f=
aster<br>
confirmations", implying that the actual confirmation occurs faster wh=
en it<br>
really doesn't. "5 blocks deep" may not be more clear to laym=
en, but at least<br>
it makes it harder for people to confuse with actual confirmation.<br></blo=
ckquote><div><br></div><div>I think people are more familiar with check cle=
arance - "the payment/check has cleared".=C2=A0</div><div><br></d=
iv>
<div>If "confirmation" and "n confirmations" together a=
re problematic, I'd talk about "cleared payments" and "n=
confirmations"</div><div><br></div><div>So "a payment clears aft=
er one confirmation, but you might want to wait until the payment has been =
confirmed n times".=C2=A0</div>
<div>Then at least you are not using the same word for two different meanin=
gs and you're using stuff more familiar in popular lexicon.</div><div>I=
dont think it's helpful for users if we use the word "blocks"=
;.</div>
<div><br></div><div>Without the technical details, I just explain to normal=
bitcoin users that the Bitcoin network checks and confirms the payment is =
valid (multiple times).</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think we all know the problems with the term "address". People =
naturally<br>
compare it to postal addresses, email addresses, etc, which operate<br>
fundamentally different. I suggest that we switch to using "invoice id=
" to<br>
refer to what is now known as addresses, as that seems to get the more natu=
ral<br>
understanding to people. On the other hand, with the advent of the payment<=
br>
protocol, perhaps address/invoice id use will die out soon?<br></blockquote=
><div><br></div><div>I think "key id" is a bit alien at user leve=
l - it's not something they are used to.<br></div><div>For years, peopl=
e had a problem with =C2=A0"email address", instead using "e=
mail number" but they got there eventually. Most people nowadays use &=
quot;email address"</div>
<div>So "payment address" or "bitcoin address" make bet=
ter sense here when qualified as a "<foo> address" and not =
just an "address"</div><div><br></div><div>You could also call it=
"payment id", but I dont think "invoice id" since no-o=
ne pays to an invoice id that's just a reference for a payment, not the=
destination.</div>
<div><br></div><div>People are very familiar with Paypal these days, and ar=
e familiar with "paypal address" or their "paypal id" s=
o again I think valid contenders are "bitcoin address" or "b=
itcoin id".</div>
<div><br></div><div>Regards,</div><div><br></div><div>Drak</div><div><br></=
div></div></div></div>
--f46d043d67372f0d2004eb409650--
|
