1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
|
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 <<a href=3D"mailto:bitcoin-dev@lists=2Elinuxfoundation=
=2Eorg" target=3D"_blank">bitcoin-dev@lists=2Elinuxfoundation=2Eorg</a>>=
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><bitcoin-dev=
@lists=2Elinuxfoundation=2Eorg> 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--
|