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

[Ariel Lorenzo-Luaces <arielluaces@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5986 bytes --]

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 <bitcoin-dev@lists.linuxfoundation.org> 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
><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

[-- Attachment #2: Type: text/html, Size: 7069 bytes --]