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 ) 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 ; 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: <528547FD.2070300@gmail.com> <201311142301.39550.luke@dashjr.org> From: Drak Date: Sat, 16 Nov 2013 00:41:56 +0000 Message-ID: To: Luke-Jr 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 " 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
On 1= 4 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.
= =C2=A0
Right now, Bitcoin-Qt has been using the term "confirmations" (pl= ural) 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 accep= ted as paid.
IMO, the latter use makes sense, but the former leads to confusion especial= ly
in light of scamcoins which abuse this confusion to claim they have "f= aster
confirmations", implying that the actual confirmation occurs faster wh= en it
really doesn't. "5 blocks deep" may not be more clear to laym= en, but at least
it makes it harder for people to confuse with actual confirmation.

I think people are more familiar with check cle= arance - "the payment/check has cleared".=C2=A0

If "confirmation" and "n confirmations" together a= re problematic, I'd talk about "cleared payments" and "n= confirmations"

So "a payment clears aft= er one confirmation, but you might want to wait until the payment has been = confirmed n times".=C2=A0
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.
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 natu= ral
understanding to people. On the other hand, with the advent of the payment<= br> protocol, perhaps address/invoice id use will die out soon?

I think "key id" is a bit alien at user leve= l - it's not something they are used to.
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"
So "payment address" or "bitcoin address" make bet= ter 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-o= ne 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 ar= e familiar with "paypal address" or their "paypal id" s= o again I think valid contenders are "bitcoin address" or "b= itcoin id".

Regards,

Drak

--f46d043d67372f0d2004eb409650--