[bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

Emil Engler me at emilengler.com
Sat Oct 5 21:57:48 UTC 2019


Hello dear mailing list subscribers.
Before I'll explain my idea here, I need to define a term first

'address':
When I use the terms address, pubkey, etc., I mean the same: The Base58
string

Ok now let's get into it:
As you should know, sending bitcoins to an address more than once is a
very bad approach.
In my opinion the problem why so many people are still doing this is
because of the term 'address' which is used in lots of wallets,
implementations, BIP 21 and so on. It is a design issue.
With the term 'address' most people identify things that are fixed and
don't change really often (e.g postal address, IP address [depends on
provider], Domain, E-Mail address, ...).
Because of this most people compare bitcoin addresses with e-mail
addresses and use this address to send the recipient money multiple times.

My suggestion would be to change the term address in wallets, the URI
scheme and so on to something of the following options by a
Informational/Process BIP:

* Payment Password
* Transaction Password
* ...

The guideline for the term should indicate that it is:
* temporary
* Something that identifies the recipient

I've chosen 'password' because they can be used as a pseudonym to
identify a person.
This is already used in stuff like bank transfers where something like
the transaction id should be used as the purpose or at universities
there are student numbers.
The first is probably a better example because student numbers aren't
temporary.

What do you think? Should I write a BIP for this or use another term?
Feedback is most welcome :)

Greetings,
Emil Engler

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191005/6875962d/attachment-0001.bin>


More information about the bitcoin-dev mailing list