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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1Vh5v4-00084E-PQ
for bitcoin-development@lists.sourceforge.net;
Thu, 14 Nov 2013 23:01:50 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([192.3.11.21])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Vh5v2-0002Ja-TG for bitcoin-development@lists.sourceforge.net;
Thu, 14 Nov 2013 23:01:50 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:be5f:f4ff:febf:4f76])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id BC3E810813F2;
Thu, 14 Nov 2013 23:01:50 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Thu, 14 Nov 2013 23:01:38 +0000
User-Agent: KMail/1.13.7 (Linux/3.12.0; KDE/4.10.5; x86_64; ; )
References: <CAKaEYhK4oXH3hB7uS3=AEkA6r0VB5OYyTua+LOP18rq+rYajHg@mail.gmail.com>
<528547FD.2070300@gmail.com>
<CAJfRnm7-34jwX0m+0Trj9-YvXFeUYMGq35AoRkY7bq9w-XpabA@mail.gmail.com>
In-Reply-To: <CAJfRnm7-34jwX0m+0Trj9-YvXFeUYMGq35AoRkY7bq9w-XpabA@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201311142301.39550.luke@dashjr.org>
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Vh5v2-0002Ja-TG
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: Thu, 14 Nov 2013 23:01:50 -0000
On Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote:
> Obviously the answer is to just display all fees and trading rates as BTC
> or MBTC (.0000005 MBTC fee? how cheap!). On a more serious note, the
> transition should definitely be thought out well as it could be very
> damaging to have this confusion, but I would prefer to do it only once
> rather than twice.
I wonder if it might make sense to bundle some other terminology fixups at the
same time.
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 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?
Thoughts?
Luke
|
