Closed diehuxx closed 9 months ago
This is like how in the US, the sales tax is not included in the listed price, so then when you go to checkout you pay the amount+some, but then in Europe they mandate that the listed price also includes sales tax and when Europeans come to the US for the first time they're like, "hey what the heck, that's not what you listed as the price"
Are the fees included in the amount always?
I'm also not sure if there was ever a decision made -- It's just my opinion that amount
should include fees
.
My thinking is that 1) it's better to choose whether includes or excludes rather than being ambiguous 2) it's more convenient to just grab the price from the JSON than to get both price + fees and do girlmath to get the total
If I'm jumping the gun and we should kick this decision down the road further, I can remove that change from this PR.
Notes from our sync today:
.
, e.g. $2.50
. In some locales, it is common to use a comma as a decimal separator, e.g. 2,50
. We're split on whether .
should always be the decimal separator or we should use ,
for currencies like EUR.Are subunits strings actually the best way to represent currency amounts? Ideally, subunits allow us to use integer amounts. But if an exchange involves millisatoshi amounts, for example, we will need to use fractional amounts of subunits, which defeats the purpose. Major unit amount strings may be easier.
I strongly suggest that we refrain from modelling any numbers as integers nor floats. When dealing with finances, it is extremely important to not loose any precision, nor have overflow problems.
Showing localized currency number to users should be done, IMHO, at the presentation layer. That's higher than the protocol layer.
Example from our earlier sync for what @diehuxx posted
the above can be read as:
If we use major unit amount strings, what is the decimal separator symbol? May currencies, including USD and BTC, use a period ., e.g. $2.50. In some locales, it is common to use a comma as a decimal separator, e.g. 2,50. We're split on whether . should always be the decimal separator or we should use , for currencies like EUR.
was previously leaning towards using what makes the most sense for the currency, however now leaning towards snapping to .
.
examples that have standardized around using .
Programming Languages: Most programming languages, such as Python, Java, C++, and JavaScript, use a period as the decimal separator. This is the standard practice for representing deciminal numbers in code.
JSON (JavaScript Object Notation): numbers are represented using a period as the decimal separator. This follows the conventions of JavaScript.
XML (eXtensible Markup Language): also typically uses a period as the decimal separator in its syntax.
CSV (Comma-Separated Values): typically rely on using a .
given that the commas need to be escaped
IEEE 754 (Floating Point Arithmetic) This is a standard for floating-point arithmetic used in computers and programming languages. It defines formats and methods for representing and manipulating floating-point numbers in binary.
SQL Databases: SQL databases, such as MySQL, PostgreSQL, and SQL Server, typically use a period as the decimal separator for storing and querying floating-point numbers.
International System of Units (SI): basis for international scientific measurements, uses a period as the decimal separator in English-speaking countries.
Just added one more commit folding PaymentInstruction
into QuoteDetails
rather than having two sets of payin/payout fields each for QuoteDetails
and PaymentInstructions
hmm, i don't think we ever fully decided (or just not documented?) whether the amountSubunits always included fees. My assumption til now was that they were separate, which is why we had a separate field named
feeSubunits
.cc: @phoebe-lew @mistermoe if they are aware of any docs / decisions made i'm not remembering