From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6681EAC8 for ; 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 ; 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 To: bitcoin-dev@lists.linuxfoundation.org, Emil Engler 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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