Rhavar [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-15 📝 Original message:I don't have anything ...
📅 Original date posted:2017-12-15
📝 Original message:I don't have anything interesting to add, except that I have been using 'bits' on my site for over 3 years. It's a great unit that people quickly adapt to, and it's far more convenient. When dealing with large amounts of money, people have no problem naturally thinking in "thousand bits" or "million bits" (a bitcoin).
I would highly encourage it to be a default everywhere. Consistency is really important.
Also slightly unrelated, but the whole "sat/B" thing for fees is such a clusterfuck. Half the time it's used as "vbyte" and half the time actual bytes. Users are constantly confused because of explorers and wallet and stuff all showing it inconsistently. I would suggest there that there is a "standard" of "bits per kiloweight" (i.e. how many bits of fees to pay for a transaction that is 1000 weight)
-Ryan
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination
> Local Time: December 15, 2017 12:20 PM
> UTC Time: December 15, 2017 6:20 PM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Marcel Jamin <marcel at jamin.net>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
>>Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the >correct< approach. It's tidy, systematic and precise.
>
> The SI system is great, but it's nice if you pick a base unit that is easy for intuition to comprehend.
>
> It is a fact that I weigh approximately .000,000,000,000,000,000,000,014 Earth masses. If we arrived at rough consensus that this was a cumbersome way to express the mass of a human, we might then find a group of people making the superficially sensible proposal that we use SI prefixes and say I weigh 14 yoctoearths. This would be tidy, systematic and precise, but that might not be enough to make it the best option. It might be even better to choose a base unit that human intuition can make sense of, and THEN add prefixes as needed.
>
> I dislike the name "bits" but I think 100 satoshis does make a nice base unit. If we cannot crowdsource a more inspiring label we may be stuck with bits just due to linguistic network effects.
>
> -Ethan
>
> On Fri, Dec 15, 2017 at 1:27 AM, Marcel Jamin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think one could make the argument that the only people who talk
>> about and understand 24 bit audio or 256 bit cryptography are the ones
>> who can tell the difference very easily.
>>
>> To me, your example seems to try hard to make the case for a problem
>> that won't exist in reality.
>>
>> Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the
>>>correct< approach. It's tidy, systematic and precise. But that won't
>> stop people from using something that's easier to deal with as I just
>> had to google the µ character again.
>>
>> Let's also keep in mind that Coinbase has been using "bits" as the
>> default for over 2 years now:
>> https://blog.coinbase.com/bits-is-the-new-default-and-all-new-users-get-100-bits-for-free-9165f757594b
>>
>> Just from a linguistic standpoint, chances are we'll end up with bits
>> anyway. Why fight it? We don't have a SI prefix educational mandate.
>>
>> Marcel
>>
>> On 14 December 2017 at 23:01, Natanael <natanael.l at gmail.com> wrote:
>>>
>>> Reposting /u/BashCo's post on reddit here, for visibility:
>>>
>>> ---8<---------------------------------------------------------------
>>>
>>>> Before anyone says 'bits' are too confusing because it's a computer
>>>> science term, here's a list of homonyms
>>>> [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every
>>>> day. Homonyms are fine because our brains are able to interpret language
>>>> based on context, so it's a non-argument.
>>>
>>>
>>> This ignores the fact that there exists multiple meanings of bits *within
>>> the same context*, and that beginners likely can't tell them apart.
>>>
>>> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
>>> value with somebody who doesn't understand Bitcoin. Then explain that the
>>> cryptography uses 256 bit keys. I would be surprised if you could find
>>> somebody who would not be confused by that.
>>>
>>> Let's say a website says a song is 24 bits. Was that 24 bit audio resolution
>>> or 24 bit price? Somebody writes about 256 bit keys, are that their size or
>>> value?
>>>
>>> You guys here can probably tell the difference. Can everybody...? Bits will
>>> cause confusion, because plenty of people will not be able to tell these
>>> apart. They will not know WHEN to apply one definition or the other.
>>>
>>> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171215/375ec903/attachment.html>;
📝 Original message:I don't have anything interesting to add, except that I have been using 'bits' on my site for over 3 years. It's a great unit that people quickly adapt to, and it's far more convenient. When dealing with large amounts of money, people have no problem naturally thinking in "thousand bits" or "million bits" (a bitcoin).
I would highly encourage it to be a default everywhere. Consistency is really important.
Also slightly unrelated, but the whole "sat/B" thing for fees is such a clusterfuck. Half the time it's used as "vbyte" and half the time actual bytes. Users are constantly confused because of explorers and wallet and stuff all showing it inconsistently. I would suggest there that there is a "standard" of "bits per kiloweight" (i.e. how many bits of fees to pay for a transaction that is 1000 weight)
-Ryan
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] BIP Proposal: Utilization of bits denomination
> Local Time: December 15, 2017 12:20 PM
> UTC Time: December 15, 2017 6:20 PM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Marcel Jamin <marcel at jamin.net>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>
>>Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the >correct< approach. It's tidy, systematic and precise.
>
> The SI system is great, but it's nice if you pick a base unit that is easy for intuition to comprehend.
>
> It is a fact that I weigh approximately .000,000,000,000,000,000,000,014 Earth masses. If we arrived at rough consensus that this was a cumbersome way to express the mass of a human, we might then find a group of people making the superficially sensible proposal that we use SI prefixes and say I weigh 14 yoctoearths. This would be tidy, systematic and precise, but that might not be enough to make it the best option. It might be even better to choose a base unit that human intuition can make sense of, and THEN add prefixes as needed.
>
> I dislike the name "bits" but I think 100 satoshis does make a nice base unit. If we cannot crowdsource a more inspiring label we may be stuck with bits just due to linguistic network effects.
>
> -Ethan
>
> On Fri, Dec 15, 2017 at 1:27 AM, Marcel Jamin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think one could make the argument that the only people who talk
>> about and understand 24 bit audio or 256 bit cryptography are the ones
>> who can tell the difference very easily.
>>
>> To me, your example seems to try hard to make the case for a problem
>> that won't exist in reality.
>>
>> Bitcoin (BTC), Millibitcoin (mBTC) and Microbitcoin (µBTC) is the
>>>correct< approach. It's tidy, systematic and precise. But that won't
>> stop people from using something that's easier to deal with as I just
>> had to google the µ character again.
>>
>> Let's also keep in mind that Coinbase has been using "bits" as the
>> default for over 2 years now:
>> https://blog.coinbase.com/bits-is-the-new-default-and-all-new-users-get-100-bits-for-free-9165f757594b
>>
>> Just from a linguistic standpoint, chances are we'll end up with bits
>> anyway. Why fight it? We don't have a SI prefix educational mandate.
>>
>> Marcel
>>
>> On 14 December 2017 at 23:01, Natanael <natanael.l at gmail.com> wrote:
>>>
>>> Reposting /u/BashCo's post on reddit here, for visibility:
>>>
>>> ---8<---------------------------------------------------------------
>>>
>>>> Before anyone says 'bits' are too confusing because it's a computer
>>>> science term, here's a list of homonyms
>>>> [https://en.wikipedia.org/wiki/List_of_true_homonyms] that you use every
>>>> day. Homonyms are fine because our brains are able to interpret language
>>>> based on context, so it's a non-argument.
>>>
>>>
>>> This ignores the fact that there exists multiple meanings of bits *within
>>> the same context*, and that beginners likely can't tell them apart.
>>>
>>> Feel free to try it yourself - talk about Bitcoin "bits" of a particular
>>> value with somebody who doesn't understand Bitcoin. Then explain that the
>>> cryptography uses 256 bit keys. I would be surprised if you could find
>>> somebody who would not be confused by that.
>>>
>>> Let's say a website says a song is 24 bits. Was that 24 bit audio resolution
>>> or 24 bit price? Somebody writes about 256 bit keys, are that their size or
>>> value?
>>>
>>> You guys here can probably tell the difference. Can everybody...? Bits will
>>> cause confusion, because plenty of people will not be able to tell these
>>> apart. They will not know WHEN to apply one definition or the other.
>>>
>>> https://www.reddit.com/r/bitcoin/comments/24m3nb/_/ch8gua7
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171215/375ec903/attachment.html>;