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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6681EAC8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Oct 2019 11:39:29 +0000 (UTC)
X-Greylist: delayed 00:06:37 by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C49F8712
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Oct 2019 11:39:28 +0000 (UTC)
Received: from ishibashi.lan (adsl-67-34-245-3.asm.bellsouth.net [67.34.245.3])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 1EFEF38A0CDE;
Sun, 6 Oct 2019 11:32:43 +0000 (UTC)
X-Hashcash: 1:25:191006:bitcoin-dev@lists.linuxfoundation.org::dSqhYd0VxcM/4vh5:ab0UN
X-Hashcash: 1:25:191006:me@emilengler.com::ahCwOHWlcqPRK/id:g32t
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Emil Engler <me@emilengler.com>
Date: Sun, 6 Oct 2019 11:32:33 +0000
User-Agent: KMail/1.9.10
References: <58e44347-6eee-a0c3-3b8a-965c7450780e@emilengler.com>
In-Reply-To: <58e44347-6eee-a0c3-3b8a-965c7450780e@emilengler.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201910061132.39215.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of
the term 'address'
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Oct 2019 11:39:29 -0000
On Saturday 05 October 2019 21:57:48 Emil Engler via bitcoin-dev wrote:
> 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
But a pubkey is not a Base58 string, and fundamentally different from an
address. An address identifies the recipient and the purpose of the payment;
a pubkey does not. The pubkey remains with the UTXO; an address does not.
> 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.
That problem would require using a different term than "address" to address.
A BIP is unlikely to do the job (though it may help).
> 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
> * ...
Neither the address nor pubkey are a password...
Some possible alternative terms would be "invoice id", "payment token", etc.
> 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
|
