4 ms·

Woah, this is beyond just "bitter taste." If these values are potentially stored in JS Numbers, this scheme is completely dead on arrival. It is not acceptable

Woah, this is beyond just "bitter taste." If these values are potentially stored in JS Numbers, this scheme is completely dead on arrival. It is not acceptable for currency to be stored in a floating-point data type, full stop. This proposal needs to at a minimum define a datatype for how these values should be stored, not just leave it up to implementations to throw it at `var currency = x;` This RFC is woefully underspecified, and the fact that there's an amount of its already-small specification devoted to "7.5. Bitcoin Address" makes me question their priorities and destroys a lot of confidence in the proposal.

gnutaler 6y ago
If you deal with money, you do have to store the fraction separately anyway and clearly should not use floating point. But that's beyond the point. The upper bound is there to ensure that you do not have to use BigNum in languages like JavaScript, not to tempt you to simply represent the amount in a double.
- akersten 6y ago
  > The upper bound is there to ensure that you do not have to use BigNum in languages like JavaScript, I think that is a far too generous read of the document. I think it's because they wanted you to be able to use a JS Number to store the value, which is the Wrong Thing To Do. In fact, using two BigInts to separately represent the fractional and whole pieces of the currency would be far better. This is the kind of ambiguity that I refer to when I say this is underspecified.
  - chrismorgan 6y ago
    Eh, it’s not underspecified. It’s just… strangely specified, in a way that people will ignore and misparse. But then, if it had been specified in any other way people would have ignored and misparsed it too.
    - lanstin 6y ago
      People going to put money in floats unless you make it impossible. Then they send it via json and round and probably over or under flow and all sorts of amusing bugs result.
  - michaelt 6y ago
    If JavaScript numbers work up to 2^52 that could precisely represent $45 trillion in cents. IMHO if they had a choice between dropping Javascript support in preference of languages with BigInt support, or dropping support for payments larger than $45 trillion, they probably made the right decision.
    - megous 6y ago
      Javascript has bigint support. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
chrismorgan 6y ago
I think you’re exaggerating the severity of the issues. “Such-and-such an integer must be less than 2⁵³” is normally a reasonable constraint to make life easier for people across all environments, and to make some such constraint is typically a good thing, rather than leaving it unspecified. I just think that the limit is on the low side here and probably unjustified due to what else is going on—and that perhaps this should be one of the rare cases where you deliberately don’t specify any limit (to the magnitude of unit or the length of fraction), and leave it to the client to decide what makes sense. On the Bitcoin part: that’s just putting an entry in the registry, a perfectly reasonable and normal thing to do in such a specification. They’ve included entries for four of the main traditional banking systems, and two of the main new-generation systems that people are sure to want to combine this with.
- fomine3 6y ago
  2^53 isn't enough in hyper inflation situation.

gnutaler 6y ago

If you deal with money, you do have to store the fraction separately anyway and clearly should not use floating point. But that's beyond the point. The upper bound is there to ensure that you do not have to use BigNum in languages like JavaScript, not to tempt you to simply represent the amount in a double.

akersten 6y ago
> The upper bound is there to ensure that you do not have to use BigNum in languages like JavaScript, I think that is a far too generous read of the document. I think it's because they wanted you to be able to use a JS Number to store the value, which is the Wrong Thing To Do. In fact, using two BigInts to separately represent the fractional and whole pieces of the currency would be far better. This is the kind of ambiguity that I refer to when I say this is underspecified.
- chrismorgan 6y ago
  Eh, it’s not underspecified. It’s just… strangely specified, in a way that people will ignore and misparse. But then, if it had been specified in any other way people would have ignored and misparsed it too.
  - lanstin 6y ago
    People going to put money in floats unless you make it impossible. Then they send it via json and round and probably over or under flow and all sorts of amusing bugs result.
- michaelt 6y ago
  If JavaScript numbers work up to 2^52 that could precisely represent $45 trillion in cents. IMHO if they had a choice between dropping Javascript support in preference of languages with BigInt support, or dropping support for payments larger than $45 trillion, they probably made the right decision.
  - megous 6y ago
    Javascript has bigint support. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

chrismorgan 6y ago

I think you’re exaggerating the severity of the issues. “Such-and-such an integer must be less than 2⁵³” is normally a reasonable constraint to make life easier for people across all environments, and to make some such constraint is typically a good thing, rather than leaving it unspecified. I just think that the limit is on the low side here and probably unjustified due to what else is going on—and that perhaps this should be one of the rare cases where you deliberately don’t specify any limit (to the magnitude of unit or the length of fraction), and leave it to the client to decide what makes sense. On the Bitcoin part: that’s just putting an entry in the registry, a perfectly reasonable and normal thing to do in such a specification. They’ve included entries for four of the main traditional banking systems, and two of the main new-generation systems that people are sure to want to combine this with.

fomine3 6y ago
2^53 isn't enough in hyper inflation situation.