Emil Engler [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-11 📝 Original message:> This may not be the most ...
📅 Original date posted:2019-10-11
📝 Original message:> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191011/5cac5674/attachment-0001.bin>;
📝 Original message:> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191011/5cac5674/attachment-0001.bin>;