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 154911081 for ; Fri, 11 Oct 2019 04:22:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E97B14D for ; Fri, 11 Oct 2019 04:22:22 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id q15so3832805pll.11 for ; Thu, 10 Oct 2019 21:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=in-reply-to:references:thread-topic:user-agent:mime-version :content-transfer-encoding:subject:from:date:to:message-id; bh=ZOwuHKTrMGezPt1rL3Q/jDfIz5a9JiiNL12BVeI6Om8=; b=F+LuEFBuURxNNuQ7oMnoSkTh82Vl9k+4YCuLcKFBZiuL54JtlcoPjvhKzgH55z5IG1 7UhE1ohEBp8tiPSFZ+Fn+NWyGaiIvzlTCL82fVOccph2VK7mhzX51incb/PZWxt86PPn 1qbOCFNi6ZBdR+Sx/WWJYYN0R3caymS2/Yu19AF0XfHM/x1+f+B3FB3UoKEYEXdLoQ+0 aa67a/m5yn1UdyFBRgXwqDyExz/zX47YA1ze5oxdKlTI0TnFMKBqkrOT30hCbwXWMiym QDTY/jnUwaCJqygZ6IppSnSQaGeXKswst8zJ3BUPGQa8w9AFkJHQwEXaogs734sroec2 3crQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:in-reply-to:references:thread-topic:user-agent :mime-version:content-transfer-encoding:subject:from:date:to :message-id; bh=ZOwuHKTrMGezPt1rL3Q/jDfIz5a9JiiNL12BVeI6Om8=; b=uWGGJbXBx6+ZBvFcqvZuV8qNPio++9S8aoh+q076jn8maPkT0/YjZueA+9QQR3vZUE k4Rfx2X24JMzFPKn0EjsSaSmlTUkjAvjQphm0Dkonmx16h8vcV9ea7BLdvWWQerKGuCx EUvjPsOdeul7bH1vABsKMpQFkvgOIJQa9gmE/qxkMEhzwFRQyLio9tOfESykRnQN43uS XgAeGdwN0RlY9A0nbUK8BbBgvmUiAQj47lMgTJYolcax374/MbYnBI1PmzsWzCkmhofG NHypJ1YSUH19rFN1UHVG+aXDXbjQJzsvCnIaZC7vhfxHCssVD0a5MzI4bW8Isf/vqWy7 z5Eg== X-Gm-Message-State: APjAAAXMzyXBP/uVggK71tzo3TPMEfFildUuDD7yClsf8pqc9fSGzHva FDUnEDWOLYx/XIL4rEsMoJY= X-Google-Smtp-Source: APXvYqyNurJDhWAqN8aH2DI6uSFnSKIQvx+z35SDYqAeUbvTGA8gvnAKTFBHuSa76lHWpAJhzuoTJQ== X-Received: by 2002:a17:902:365:: with SMTP id 92mr7780299pld.126.1570767742478; Thu, 10 Oct 2019 21:22:22 -0700 (PDT) Received: from [10.228.10.41] ([24.244.23.138]) by smtp.gmail.com with ESMTPSA id t21sm8029970pgi.87.2019.10.10.21.22.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Oct 2019 21:22:21 -0700 (PDT) In-Reply-To: References: <58e44347-6eee-a0c3-3b8a-965c7450780e@emilengler.com> <6fe67006-7131-a861-61fa-65392d5be069@riseup.net> <20824fa5-e3fa-8d4e-1678-4c2048b49b6b@emilengler.com> X-Referenced-Uid: 20402 Thread-Topic: Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address' X-Blue-Identity: !l=489&o=96429&fo=98610&pl=448&po=0&qs=PREFIX&f=HTML&n=Ariel%20Lorenzo-Luaces&e=arielluaces%40gmail.com&m=!%3AZjEwN2MyYjMtOWE0OC00NzJhLWEzYTQtYjc3MTEzNTNhODJm%3ASU5CT1g%3D%3AMjA0MDI%3D%3AANSWERED&p=447&q=SHOW User-Agent: Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----PBD3R2DBKIWZJF966NPBNU5R3QICQR" Content-Transfer-Encoding: 7bit X-Local-Message-Id: From: Ariel Lorenzo-Luaces Date: Thu, 10 Oct 2019 21:22:03 -0700 To: Karl-Johan Alm , Bitcoin Protocol Discussion Message-ID: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 11 Oct 2019 06:56:15 +0000 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: Fri, 11 Oct 2019 04:22:24 -0000 ------PBD3R2DBKIWZJF966NPBNU5R3QICQR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 I would propose a term different than all the others mentioned so far=2E I= propose Funding Codes=2E The word funding can be used as a verb or a noun= and this works for the nature of Bitcoin transactions=2E Funding can be se= en 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"=2E The word code is fitting since codes are what addresse= s ultimately describe, the signature script, a piece of code=2E When speaki= ng about the lightning transaction graph it's easy to talk about transactio= ns making bitcoins flow from code to code, each code different for a differ= ent purpose "funding is sent from this code to that code" and "funding is k= ept in this code for 144 blocks"=2E - Payment tokens feel like they themse= lves hold the value and can be transfered but anyone can generate as many p= ayment tokens as they desire=2E This name conflicts with other cryptocurren= cies that focus their blockchain on payments and refer to their currency as= tokens=2E - Invoices are problematic because they imply that they hold bi= tcoins and they specify an amount=2E However addresses don't specify any am= ounts while they themselves can be included inside a real invoice=2E I thin= k it is wrong to imply that the "thing" we are sending money to is temporar= y, because it isn't=2E Lightning channels can stay open forever until close= d but money doesn't stay in an invoice for any amount of time=2E - I actua= lly prefer Addresses over both Payment Tokens and Invoices=2E It's actually= very natural to send something to an address and an address can hold somet= hing for a long time=2E However addresses fall short due to people only hav= ing one=2E This makes them think that they have to memorize a bitcoin addre= ss=2E There are also all the other reasons people have mentioned=2E The wo= rd code fits well in the divide between technical and non-technical people= =2E 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?"=2E T= o programmers code is something that can be executed which is exactly what = addresses are=2E Especially ones with complicated logic and lots of conditi= ons "this funding code can only be unlocked by Alice or Bob plus Charlie or= Dave after 1000 blocks"=2E Funding codes work even better when thinking a= bout self executing smart contracts "they are funded and running code with = their funds"=2E Contracts don't make sense at all when it's an autonomous t= hing that didn't strike any contract with anyone=2E Contracts should only b= e referred to the transactions people send to funding codes or "smart" code= s=2E 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=2E Lightning already has "= funding addresses" and "funding transactions"=2E With schnorr and taproot c= oming it will be possible to create more complex situations and they all ne= ed funding codes so that funds can be sent to it and be locked up in the co= de (sigscript)=2E One criticism might be that funding codes sound like the= y are funding something which doesn't appear to be true=2E But indeed they = are! Funding codes fund a situation, a setup=2E The common setup is that yo= u can unlock them at any time=2E Other setups demand multi-party coordinati= on=2E The funding code is what funds all these setups=2E Funding codes are= also two words and three syllables which is great because using only one w= ord is not descriptive enough and using four or more syllables is way too l= ong=2E Having the second word "code" makes for easy abbreviation when the c= onversation is already about Bitcoin "which code did you send them to?" Pe= ople will naturally use funding code and bitcoin code interchangeably=2E Th= is is a good thing because bitcoin is a type of fund, so there is no contra= diction=2E 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=2E This goes for both singular and plural=2E "Firs= t a receiver must generate a funding code to have a sender fund it with the= ir=C2=A0 from their own funding code which had been previously funded" Che= ers Ariel Lorenzo-Luaces On Oct 10, 2019, 7:20 PM, at 7:20 PM, Karl-Joha= n Alm via bitcoin-dev wrote: >I= 've proposed bitcoin invoice for awhile now=2E See >https://twitter=2Ecom/k= allewoof/status/1165841566105079808 > >I like bitcoin invoice address into = bitcoin address as proposed by >Chris=2E > > >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 clie= nt went >crazy * >> >> Thanks for all your feedback=2E >> I came to the dec= ision to write a BIP for this, even if it might not >be >> implemented by m= any wallets, a standardization is never wrong and >this >> would be the fir= st step in the correct direction for better on-chain >> privacy=2E >> >> Ho= wever currently we still need a good term for the 'address' >replacement=2E= >> >> 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 Belc= her=2E >> >> So how do find a consensus about these terms? >> >> Greetings = >> Emil Engler >> _______________________________________________ >> bitcoi= n-dev mailing list >> bitcoin-dev@lists=2Elinuxfoundation=2Eorg >> https://= lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev >_______________= ________________________________ >bitcoin-dev mailing list >bitcoin-dev@lis= ts=2Elinuxfoundation=2Eorg >https://lists=2Elinuxfoundation=2Eorg/mailman/l= istinfo/bitcoin-dev ------PBD3R2DBKIWZJF966NPBNU5R3QICQR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I would propose a term different= than all the others mentioned so far=2E

I = propose Funding Codes=2E

The word funding c= an be used as a verb or a noun and this works for the nature of Bitcoin tra= nsactions=2E 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"=2E

The word code is fitting since codes are what addresses ultimately d= escribe, the signature script, a piece of code=2E When speaking about the l= ightning transaction graph it's easy to talk about transactions making bitc= oins flow from code to code, each code different for a different purpose "f= unding is sent from this code to that code" and "funding is kept in this co= de for 144 blocks"=2E

- Payment tokens feel= like they themselves hold the value and can be transfered but anyone can g= enerate as many payment tokens as they desire=2E This name conflicts with o= ther cryptocurrencies that focus their blockchain on payments and refer to = their currency as tokens=2E

- Invoices are = problematic because they imply that they hold bitcoins and they specify an = amount=2E However addresses don't specify any amounts while they themselves= can be included inside a real invoice=2E I think it is wrong to imply that= the "thing" we are sending money to is temporary, because it isn't=2E Ligh= tning channels can stay open forever until closed but money doesn't stay in= an invoice for any amount of time=2E

- I a= ctually prefer Addresses over both Payment Tokens and Invoices=2E It's actu= ally very natural to send something to an address and an address can hold s= omething for a long time=2E However addresses fall short due to people only= having one=2E This makes them think that they have to memorize a bitcoin a= ddress=2E There are also all the other reasons people have mentioned=2E
=
The word code fits well in the divide between = technical and non-technical people=2E To the layman a code is just a string= of characters and that is what we can visually see and check and compare w= hen one of these funding codes are transfered between two parties "does you= r finding code end with xyz?"=2E To programmers code is something that can = be executed which is exactly what addresses are=2E Especially ones with com= plicated logic and lots of conditions "this funding code can only be unlock= ed by Alice or Bob plus Charlie or Dave after 1000 blocks"=2E

=
Funding codes work even better when thinking about self = executing smart contracts "they are funded and running code with their fund= s"=2E Contracts don't make sense at all when it's an autonomous thing that = didn't strike any contract with anyone=2E Contracts should only be referred= to the transactions people send to funding codes or "smart" codes=2E
Addresses also fail when transferring between tw= o 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=2E
=
Lightning already has "funding addresses" and = "funding transactions"=2E With schnorr and taproot coming it will be possib= le to create more complex situations and they all need funding codes so tha= t funds can be sent to it and be locked up in the code (sigscript)=2E
One criticism might be that funding codes sound = like they are funding something which doesn't appear to be true=2E But inde= ed they are! Funding codes fund a situation, a setup=2E The common setup is= that you can unlock them at any time=2E Other setups demand multi-party co= ordination=2E The funding code is what funds all these setups=2E

Funding codes are also two words and three syllables = which is great because using only one word is not descriptive enough and us= ing four or more syllables is way too long=2E 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=2E This is= a good thing because bitcoin is a type of fund, so there is no contradicti= on=2E The more common term should still be funding code because there is mo= re than one type of "code" in Bitcoin

Most= importantly funding codes sound good when spoken=2E This goes for both sin= gular and plural=2E

"First a receiver must = generate a funding code to have a sender fund it with their=C2=A0 from thei= r own funding code which had been previously funded"

Cheers
Ariel Lorenzo-Luaces

On Oct 10, 2019, at 7:20 PM, Karl-Johan Al= m via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg>= wrote:
I've proposed bitcoin invoice for awhile now=2E See
https://twi=
tter=2Ecom/kallewoof/status/1165841566105079808

I like bitcoin i=
nvoice address into bitcoin address as proposed by Chris=2E


On F=
ri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev
<bitcoin-dev=
@lists=2Elinuxfoundation=2Eorg> wrote:

 * Sorry if this mail was sent multiple times, my E-=
Mail client went crazy *

 Thanks for all your feedback=2E
 I came=
 to the decision to write a BIP for this, even if it might not be
 imple=
mented by many wallets, a standardization is never wrong and this
 would=
 be the first step in the correct direction for better on-chain
 privacy=
=2E

 However currently we still need a good term for the 'address' r=
eplacement=2E

 The current suggestions are:
 * Invoice ID
 * P=
ayment Token
 * Bitcoin invoice (address)
 * Bitcoin invoice (path)
 Because of the LN term invoice I really like the term 'Bitcoin Invoi=
ce'
 by Chris Belcher=2E

 So how do find a consensus about these =
terms?

 Greetings
 Emil Engler

 bitcoin-dev mailing li=
st
 bitcoin-dev@lists=2Elinuxfoundation=2Eorg
 https://lists=2Eli=
nuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
bitcoin-dev mailing list
bitcoin-dev@lists=2Elinuxfoundation=2Eorg
=
https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev<=
br>
------PBD3R2DBKIWZJF966NPBNU5R3QICQR--