Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
As the idea got positive feedback, I've written the BIP. The draft is available here: https://github.com/bitcoin/bips/pull/856 Am 17.10.19 um 15:23 schrieb Marco Falke via bitcoin-dev: > I also like the "bitcoin invoice address" term by Chris. Invoice is a > common term and easily translatable into other languages. > > Marco > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
I also like the "bitcoin invoice address" term by Chris. Invoice is a common term and easily translatable into other languages. Marco ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
> This may not be the most practical information, but there actually did exist > an almost perfect analogy for Bitcoin addresses from the ancient world: From > wikipedia https://en.wikipedia.org/wiki/Bulla_(seal) I personally do not like the term bulla, it might be a perfect analogy but I personally don't believe that this term is well known. Tbh I didn't knew what a 'bulla' was before. > I propose Funding Codes. I'm neutral on this. With code I associate something that is slightly more permanent like a code to unlock your mobile phone or a code to unlock your bike if you know what I mean. These kind of codes change sometimes but not as often as a bitcoin address (should). I also agree that Payment Tokens might confuse with other currencies and block chain. > > - Invoices are problematic because they imply that they hold bitcoins and > they specify an amount. However addresses don't specify any amounts while > they themselves can be included inside a real invoice. I think it is wrong to > imply that the "thing" we are sending money to is temporary, because it > isn't. Lightning channels can stay open forever until closed but money > doesn't stay in an invoice for any amount of time. What is with 'Bitcoin Invoice Address'? This is the best of both worlds because it implies the temporary factor with 'invoice' and the way that you send something to something. Also, this is more a personal opinion but I thunk that 'funding' implies more to donate to something. I think this could lead to misunderstandings. To summarize it up, here are the following suggested terms: * Invoice ID * Payment Token * Bitcoin invoice (address) * Bitcoin invoice (path) * Bulla * Funding code Greetings, Emil Engler pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
I would propose a term different than all the others mentioned so far. I propose Funding Codes. The word funding can be used as a verb or a noun and this works for the nature of Bitcoin transactions. Funding can be seen as what someone needs to do with the code as well as referring to it as the code that has funding once bitcoins have been transfered to it "give me a funding code". The word code is fitting since codes are what addresses ultimately describe, the signature script, a piece of code. When speaking about the lightning transaction graph it's easy to talk about transactions making bitcoins flow from code to code, each code different for a different purpose "funding is sent from this code to that code" and "funding is kept in this code for 144 blocks". - Payment tokens feel like they themselves hold the value and can be transfered but anyone can generate as many payment tokens as they desire. This name conflicts with other cryptocurrencies that focus their blockchain on payments and refer to their currency as tokens. - Invoices are problematic because they imply that they hold bitcoins and they specify an amount. However addresses don't specify any amounts while they themselves can be included inside a real invoice. I think it is wrong to imply that the "thing" we are sending money to is temporary, because it isn't. Lightning channels can stay open forever until closed but money doesn't stay in an invoice for any amount of time. - I actually prefer Addresses over both Payment Tokens and Invoices. It's actually very natural to send something to an address and an address can hold something for a long time. However addresses fall short due to people only having one. This makes them think that they have to memorize a bitcoin address. There are also all the other reasons people have mentioned. The word code fits well in the divide between technical and non-technical people. To the layman a code is just a string of characters and that is what we can visually see and check and compare when one of these funding codes are transfered between two parties "does your finding code end with xyz?". To programmers code is something that can be executed which is exactly what addresses are. Especially ones with complicated logic and lots of conditions "this funding code can only be unlocked by Alice or Bob plus Charlie or Dave after 1000 blocks". Funding codes work even better when thinking about self executing smart contracts "they are funded and running code with their funds". Contracts don't make sense at all when it's an autonomous thing that didn't strike any contract with anyone. Contracts should only be referred to the transactions people send to funding codes or "smart" codes. Addresses also fail when transferring between two of your own wallets because it doesn't make sense for someone to have so many addresses but it does make sense for someone to have many codes. Lightning already has "funding addresses" and "funding transactions". With schnorr and taproot coming it will be possible to create more complex situations and they all need funding codes so that funds can be sent to it and be locked up in the code (sigscript). One criticism might be that funding codes sound like they are funding something which doesn't appear to be true. But indeed they are! Funding codes fund a situation, a setup. The common setup is that you can unlock them at any time. Other setups demand multi-party coordination. The funding code is what funds all these setups. Funding codes are also two words and three syllables which is great because using only one word is not descriptive enough and using four or more syllables is way too long. Having the second word "code" makes for easy abbreviation when the conversation is already about Bitcoin "which code did you send them to?" People will naturally use funding code and bitcoin code interchangeably. This is a good thing because bitcoin is a type of fund, so there is no contradiction. The more common term should still be funding code because there is more than one type of "code" in Bitcoin Most importantly funding codes sound good when spoken. This goes for both singular and plural. "First a receiver must generate a funding code to have a sender fund it with their from their own funding code which had been previously funded" Cheers Ariel Lorenzo-Luaces On Oct 10, 2019, 7:20 PM, at 7:20 PM, Karl-Johan Alm via bitcoin-dev wrote: >I've proposed bitcoin invoice for awhile now. See >https://twitter.com/kallewoof/status/1165841566105079808 > >I like bitcoin invoice address into bitcoin address as proposed by >Chris. > > >On Fri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev > wrote: >> >> * Sorry if this mail was sent multiple times, my E-Mail client went >crazy * >> >> Thanks for all your feedback. >> I came to the decision to write a BIP for this, even if it might not >be >> implemented by many wallets, a standardiza
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
Hi Thread, This may not be the most practical information, but there actually did exist an almost perfect analogy for Bitcoin addresses from the ancient world: From wikipedia https://en.wikipedia.org/wiki/Bulla_(seal) "Transactions for trading needed to be accounted for efficiently, so the clay tokens were placed in a clay ball (bulla), which helped with dishonesty and kept all the tokens together. In order to account for the tokens, the bulla would have to be crushed to reveal their content. This introduced the idea of impressing the token onto the wet bulla before it dried, to insure trust that the tokens hadn't been tampered with and for anyone to know what exactly was in the bulla without having to break it." You could only use the bulla once because it had to be destroyed in order to get the tokens out! I think there are even examples of bulla with a kind of "signature" on them (an imprint with the seal of a noble family etc). "send me a Bitcoin bulla" has a nice ring to it! Sincerely, LL On Fri, Oct 11, 2019 at 2:44 AM Emil Engler via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > * Sorry if this mail was sent multiple times, my E-Mail client went crazy * > > Thanks for all your feedback. > I came to the decision to write a BIP for this, even if it might not be > implemented by many wallets, a standardization is never wrong and this > would be the first step in the correct direction for better on-chain > privacy. > > However currently we still need a good term for the 'address' replacement. > > The current suggestions are: > * Invoice ID > * Payment Token > * Bitcoin invoice (address) > * Bitcoin invoice (path) > > Because of the LN term invoice I really like the term 'Bitcoin Invoice' > by Chris Belcher. > > So how do find a consensus about these terms? > > Greetings > Emil Engler > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
I've proposed bitcoin invoice for awhile now. See https://twitter.com/kallewoof/status/1165841566105079808 I like bitcoin invoice address into bitcoin address as proposed by Chris. On Fri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev wrote: > > * Sorry if this mail was sent multiple times, my E-Mail client went crazy * > > Thanks for all your feedback. > I came to the decision to write a BIP for this, even if it might not be > implemented by many wallets, a standardization is never wrong and this > would be the first step in the correct direction for better on-chain > privacy. > > However currently we still need a good term for the 'address' replacement. > > The current suggestions are: > * Invoice ID > * Payment Token > * Bitcoin invoice (address) > * Bitcoin invoice (path) > > Because of the LN term invoice I really like the term 'Bitcoin Invoice' > by Chris Belcher. > > So how do find a consensus about these terms? > > Greetings > Emil Engler > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
* Sorry if this mail was sent multiple times, my E-Mail client went crazy * Thanks for all your feedback. I came to the decision to write a BIP for this, even if it might not be implemented by many wallets, a standardization is never wrong and this would be the first step in the correct direction for better on-chain privacy. However currently we still need a good term for the 'address' replacement. The current suggestions are: * Invoice ID * Payment Token * Bitcoin invoice (address) * Bitcoin invoice (path) Because of the LN term invoice I really like the term 'Bitcoin Invoice' by Chris Belcher. So how do find a consensus about these terms? Greetings Emil Engler pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
This is an excellent idea and I hope something like this happens. I've had the idea of using an intermediate name to make the transition easier, for example "Bitcoin address" becomes "Bitcoin invoice address" which after 10 years becomes "Bitcoin invoice" (or "Bitcoin invoice"). "Invoice" would also work well because Lightning uses the name invoice for the object which is used to receive payments. So it's easy to imagine that the GUI text input presented to users can be called "invoice" and users can put both kinds of invoices there leaving the wallet to easily figure out whether it makes an on-chain transaction or a Lightning Network transaction. Changing a commonly-used name like this could be very hard, but the gains in terms of privacy are immense. On 05/10/2019 22:57, 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 > > 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 > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
> 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. I don't know much about this topic in Bitcoin so far, but I meant the address :) > That problem would require using a different term than "address" to address. I meant this the whole time, sorry for misunderstandings. > A BIP is unlikely to do the job (though it may help). Why? They are specifications and implementations need them (even if some do not implement everything). Also BIP 21 would need an alternative/separate parameter with the new term. > Neither the address nor pubkey are a password... In Germany at least (where I live), you need to provide a 'Password' (the german translation of thin word of course) in the purpose of the transaction if you pay with a bank transfer. They are used as IDs but I agree, ID is definitely a better suffix. > Some possible alternative terms would be "invoice id", "payment token", etc. ACK Greetings, Emil Engler pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'
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 pEpkey.asc Description: application/pgp-keys ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
