path: root/54/6e40ed1bf090e4edd875551f47e8551263716e

Return-Path: <arielluaces@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 154911081
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Oct 2019 04:22:22 +0000 (UTC)
Received: by mail-pl1-f169.google.com with SMTP id q15so3832805pll.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CALJw2w6FeQDpiFZ9+j-tmho_HMFCyi-0wLrGqze9jD5iSLfuVw@mail.gmail.com>
References: <58e44347-6eee-a0c3-3b8a-965c7450780e@emilengler.com>
	<6fe67006-7131-a861-61fa-65392d5be069@riseup.net>
	<20824fa5-e3fa-8d4e-1678-4c2048b49b6b@emilengler.com>
	<CALJw2w6FeQDpiFZ9+j-tmho_HMFCyi-0wLrGqze9jD5iSLfuVw@mail.gmail.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: <ceb671aa-c85f-47d3-9084-aa66005640a9@gmail.com>
From: Ariel Lorenzo-Luaces <arielluaces@gmail.com>
Date: Thu, 10 Oct 2019 21:22:03 -0700
To: Karl-Johan Alm <karljohan-alm@garage.co.jp>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ceb671aa-c85f-47d3-9084-aa66005640a9@gmail.com>
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 <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: 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 <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> 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
><bitcoin-dev@lists=2Elinuxfoundation=2Eorg=
> 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

<html><head></head><body><div dir=3D"auto">I would propose a term different=
 than all the others mentioned so far=2E<br><br></div>
<div dir=3D"auto">I =
propose Funding Codes=2E<br><br></div>
<div dir=3D"auto">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<br><br></div>
<div dir=3D=
"auto">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<br><br></div>
<div dir=3D"auto">- 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<br><br></div>
<div dir=3D"auto">- 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<br><br></div>
<div dir=3D"auto">- 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<br>=
<br></div>
<div dir=3D"auto">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<br><br></div>=

<div dir=3D"auto">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<br><b=
r></div>
<div dir=3D"auto">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<br>=
<br></div>
<div dir=3D"auto">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<br><b=
r></div>
<div dir=3D"auto">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<br><br></d=
iv>
<div dir=3D"auto">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?"<br><br></div>
<div dir=3D"auto">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 <br><br></div>
<div dir=3D"auto">Most=
 importantly funding codes sound good when spoken=2E This goes for both sin=
gular and plural=2E<br><br></div>
<div dir=3D"auto">"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"<br><br></div>
<div dir=
=3D"auto">Cheers<br></div>
<div dir=3D"auto">Ariel Lorenzo-Luaces<br><br></=
div>
<div class=3D"gmail_quote" >On Oct 10, 2019, at 7:20 PM, Karl-Johan Al=
m via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=
=2Eorg" target=3D"_blank">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a>&gt;=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre cl=
ass=3D"blue">I've proposed bitcoin invoice for awhile now=2E See<br><a href=
=3D"https://twitter=2Ecom/kallewoof/status/1165841566105079808">https://twi=
tter=2Ecom/kallewoof/status/1165841566105079808</a><br><br>I like bitcoin i=
nvoice address into bitcoin address as proposed by Chris=2E<br><br><br>On F=
ri, Oct 11, 2019 at 12:45 AM Emil Engler via bitcoin-dev<br>&lt;bitcoin-dev=
@lists=2Elinuxfoundation=2Eorg&gt; wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; p=
adding-left: 1ex;"><br> * Sorry if this mail was sent multiple times, my E-=
Mail client went crazy *<br><br> Thanks for all your feedback=2E<br> I came=
 to the decision to write a BIP for this, even if it might not be<br> imple=
mented by many wallets, a standardization is never wrong and this<br> would=
 be the first step in the correct direction for better on-chain<br> privacy=
=2E<br><br> However currently we still need a good term for the 'address' r=
eplacement=2E<br><br> The current suggestions are:<br> * Invoice ID<br> * P=
ayment Token<br> * Bitcoin invoice (address)<br> * Bitcoin invoice (path)<b=
r><br> Because of the LN term invoice I really like the term 'Bitcoin Invoi=
ce'<br> by Chris Belcher=2E<br><br> So how do find a consensus about these =
terms?<br><br> Greetings<br> Emil Engler<br><hr><br> bitcoin-dev mailing li=
st<br> bitcoin-dev@lists=2Elinuxfoundation=2Eorg<br> <a href=3D"https://lis=
ts=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev">https://lists=2Eli=
nuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev</a><br></blockquote><hr><b=
r>bitcoin-dev mailing list<br>bitcoin-dev@lists=2Elinuxfoundation=2Eorg<br>=
<a href=3D"https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-d=
ev">https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev</a><=
br></pre></blockquote></div></body></html>
------PBD3R2DBKIWZJF966NPBNU5R3QICQR--