I just chatted with Eric on IRC about this, and it looks like the best
solution is to keep parse_amount, but to make the rounding optional.
If the rounding is turned off, the routine will return failure if the
input has more than 8 digits after the decimal point. This maintains
compatibility with the existing btc_to_satoshi routine.

-William

On Sun, Nov 30, 2014 at 2:39 AM, William Swanson <swansontec@???> wrote:
> Hello,
> It looks we have some duplication between btc_to_satoshi/parse_amount
> and satoshi_to_btc/format_amount. These routines both convert between
> strings and numbers for Bitcoin amounts, so we should just pick one or
> the other and remove duplication.
>
> My vote is in favor of the parse_amount/format_amount pair. The
> parse_amount routine, besides having full checks for overflow, invalid
> characters, and so forth, have two features that makes it a bit better
> than btc_to_satoshi.
>
> The first is an adjustable precision parameter, so the routine can
> handle millibits, microbits, and possibly weird altcoins with
> different precisions. We use this in the AirBitz wallet. If we wanted
> to go with btc_to_satoshi, we would have to add this adjustment.
>
> The other feature is rounding. Not everyone is perfect, and our wallet
> occasionally sees URI's with 9 or more digits after the decimal point.
> Failing to parse these URI's would be a horrible user experience, so
> we need to do something reasonable like rounding. Also, the BIP 0021
> standard doesn't say anything about the number of acceptable digits
> after the decimal place, so failing to parse these amounts would
> arguably be non-compliant. So, parse_amount is the better choice here.
>
> The btc_to_satoshi routine does return a bool, which may or may not be
> nicer cosmetic than returning invalid_amount. We can change the
> signature of parse_amount if this is a big deal.
>
> -William