You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 24, 2020. It is now read-only.
Every field that represents a value in the "model" classes uses a BigDecimal. This is misleading because BlockCypher always sends and receives satoshis (which are whole numbers, not decimals).
The TransactionService has two methods that take satoshi parameters as longs, and then wrap them in BigDecimal. This implies that longs are large enough to cover any value we may wish to represent. I'm not an expert on bitcoin/altcoin internals and do not know how many satoshis (or altcoin units) could theoretically exist, but if it's more than 9223372036854775807 (which is 92233720368 BTC) then BigInteger would be a safer bet. I'd probably lean towards playing it safe.
The text was updated successfully, but these errors were encountered:
Every field that represents a value in the "model" classes uses a BigDecimal. This is misleading because BlockCypher always sends and receives satoshis (which are whole numbers, not decimals).
Affected fields include:
Address.value
Transaction.fees
Transaction.total
Input.outputValue
Output.value
TransactionSummary.value
The TransactionService has two methods that take satoshi parameters as longs, and then wrap them in BigDecimal. This implies that longs are large enough to cover any value we may wish to represent. I'm not an expert on bitcoin/altcoin internals and do not know how many satoshis (or altcoin units) could theoretically exist, but if it's more than 9223372036854775807 (which is 92233720368 BTC) then BigInteger would be a safer bet. I'd probably lean towards playing it safe.
The text was updated successfully, but these errors were encountered: