From: Drak <drak@zikula•org>
To: Luke-Jr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] moving the default display to mbtc
Date: Sat, 16 Nov 2013 00:41:56 +0000 [thread overview]
Message-ID: <CANAnSg1-uW+g3KYyqdfqdvcUybpu2Mn2-j4hJN-5-gVWPrdgvg@mail.gmail.com> (raw)
In-Reply-To: <201311142301.39550.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4118 bytes --]
next prev parent reply other threads:[~2013-11-16 0:42 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 11:45 Melvin Carvalho
2013-11-14 18:18 ` Luke-Jr
2013-11-17 3:22 ` Jacob Lyles
2013-11-14 20:01 ` Alan Reiner
2013-11-14 21:15 ` Mark Friedenbach
2013-11-14 21:55 ` Allen Piscitello
2013-11-14 22:00 ` Alan Reiner
2013-11-14 22:07 ` Allen Piscitello
2013-11-14 23:01 ` Luke-Jr
2013-11-14 23:11 ` Mark Friedenbach
2013-11-14 23:13 ` Luke-Jr
2013-11-14 23:22 ` Jeff Garzik
2013-11-15 0:15 ` Luke-Jr
2013-11-15 0:18 ` Mark Friedenbach
2013-11-16 0:41 ` Drak [this message]
2013-11-16 0:48 ` Mark Friedenbach
2013-11-16 1:10 ` Luke-Jr
2013-11-16 1:19 ` Jean-Paul Kogelman
2013-11-16 1:19 ` Drak
2013-11-16 1:31 ` Mark Friedenbach
2013-11-15 8:55 ` Eugen Leitl
2013-11-14 22:21 ` Mark Friedenbach
2013-11-14 22:32 ` Drak
2013-11-14 22:37 ` Drak
2014-05-02 19:17 ` Jeff Garzik
2014-05-03 0:54 ` Ben Davenport
2014-05-03 1:13 ` Alan Reiner
2014-05-03 1:50 ` Aaron Voisine
2014-05-03 2:10 ` Matias Alejo Garcia
2014-05-03 2:38 ` Luke Dashjr
2014-05-03 2:41 ` Ben Davenport
2014-05-03 2:43 ` Peter Todd
2014-05-03 3:35 ` Un Ix
2014-05-03 12:32 ` Roy Badami
2014-05-03 4:23 ` Tamas Blummer
2013-11-14 22:03 ` Jeff Garzik
2013-11-14 22:31 ` Mark Friedenbach
2013-11-14 22:53 ` Alan Reiner
2013-11-14 23:01 ` Jeff Garzik
2013-11-14 23:10 ` Luke-Jr
2013-11-15 9:23 ` Eugen Leitl
2013-11-15 9:37 ` Alex Kravets
2013-11-15 9:59 ` Adam Back
2013-11-15 10:39 ` Eugen Leitl
2013-11-15 7:18 ` Wladimir
2013-11-18 2:28 ` Wendell
2014-03-13 12:56 ` Jeff Garzik
2014-03-13 13:29 ` Gary Rowe
2014-03-13 13:31 ` Mike Hearn
2014-03-13 13:40 ` Andreas Schildbach
2014-03-14 14:05 ` Andreas Schildbach
2014-03-14 14:14 ` Tamas Blummer
2014-03-14 14:49 ` Andreas Schildbach
2014-03-14 14:57 ` Tamas Blummer
2014-03-14 15:02 ` Andreas Schildbach
2014-03-14 15:12 ` Tamas Blummer
2014-03-14 15:30 ` Andreas Schildbach
2014-03-14 15:32 ` Mike Hearn
2014-03-14 15:56 ` Andreas Schildbach
2014-03-14 16:01 ` Mark Friedenbach
2014-03-14 16:15 ` Alex Morcos
2014-03-14 16:51 ` Ricardo Filipe
2014-03-14 16:58 ` Allen Piscitello
2014-03-14 15:10 ` Tyler
2014-03-14 14:18 ` Roy Badami
2014-03-13 19:38 ` Jeff Garzik
2014-03-13 13:34 ` Wladimir
2014-03-13 13:45 ` Jeff Garzik
2014-03-13 13:53 ` Mike Hearn
2014-03-13 14:32 ` Jeff Garzik
2014-03-13 15:50 ` Mike Hearn
2014-03-13 16:17 ` Troy Benjegerdes
2014-03-13 16:39 ` Melvin Carvalho
2014-03-13 16:55 ` Allen Piscitello
2014-03-13 17:13 ` Mike Hearn
2014-03-13 17:23 ` Allen Piscitello
2014-03-13 16:14 ` Alan Reiner
2014-03-13 16:23 ` Tamas Blummer
2014-03-13 16:29 ` Jeff Garzik
2014-03-13 17:18 ` Mark Friedenbach
2014-03-13 17:21 ` Jeff Garzik
2014-03-13 17:24 ` Mike Hearn
2014-03-13 17:36 ` Alan Reiner
2014-03-13 17:43 ` Wladimir
2014-03-13 17:51 ` Mike Hearn
2014-03-13 17:58 ` Alan Reiner
2014-03-13 19:26 ` Drak
2014-03-13 16:08 ` Troy Benjegerdes
2014-03-13 16:30 ` Tamas Blummer
2014-03-13 16:37 ` slush
2014-03-13 17:48 ` Luke-Jr
2014-03-13 18:23 ` Jorge Timón
2014-03-13 18:29 ` Mike Hearn
2014-03-13 18:51 ` Ben Davenport
2014-03-14 0:34 ` Jorge Timón
2014-03-14 17:14 ` vv01f
2014-03-14 20:13 ` Natanael
2014-03-14 1:26 ` Un Ix
2014-03-14 21:56 ` Odinn Cyberguerrilla
2013-11-15 10:45 ` Wladimir
2013-11-15 10:57 ` Eugen Leitl
2013-11-14 22:27 ` Drak
2013-11-15 0:05 ` Jeff Garzik
2013-11-15 0:37 ` Daniel F
2013-11-15 0:46 ` Melvin Carvalho
2013-11-15 0:57 ` Alan Reiner
2014-05-02 14:29 ` Melvin Carvalho
2013-11-15 5:21 Tamas Blummer
[not found] <mailman.271337.1390426426.2210.bitcoin-development@lists.sourceforge.net>
2014-03-13 15:17 ` Tamas Blummer
2014-03-13 15:37 ` Chris Pacia
2014-03-14 16:25 Andrew Smith
[not found] <536537E2.1060200@stud.uni-saarland.de>
2014-05-03 18:46 ` Jannis Froese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANAnSg1-uW+g3KYyqdfqdvcUybpu2Mn2-j4hJN-5-gVWPrdgvg@mail.gmail.com \
--to=drak@zikula$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox