Closed kajoseph closed 11 months ago
@escottalexander phew! pipeline is passing again. NPM really didn't like me manually adding those dev dependencies.
@kajoseph Still need to address this: https://github.com/bitpay/bitcore/pull/3638#discussion_r1346338177 I think it got lost when you pushed changes to fix the pipeline.
Currently, bitcore-client wallets are pubkeyhash wallets only. This adds the ability to create wallets using other address types.
Note, taproot addresses are not fully implemented in bitcore-lib yet and don't work (hence the bypass in the tests)
Also, this fixes several bugs:
bitcore-lib-cash
andbitcore-lib-doge
disregarded the specified address type when computing an address from a public keywallet-send
was all kinds of messed up due to the fee calculation.--feeRate
optional param.selectCoins
method required afee
param, but none was given, so it produced a NaN, causing the tx to not have any inputs. So, I added a|| 0
in the reduce.feeRate
inwallet-send
did a multiplication byscale
, but thefeerate
value returned from bitcore-node was in a different scale for EVM and UTXO chains (i.e. EVM returned Wei, UTXO returned BTC). In both cases, this resulted in the tx having an exorbitant feeRate. I fixed this to calculate sats/KB for UTXO and Wei for EVM, considering if the user specified the--feeRate
param or not.wallet.deriveAddress
fallback when constructing a tx does NOT save the address anywhere. Thus, the wallet would essentially lose those funds since it would have no awareness of the generated change address.wallet storage --import
was broken because it would detect--name
as a function, so the imported wallet would have aname
of undefined, but in order to use the wallet you needed to pass in--name "function(str) { if (arguments.length === 0) return this._name; this._name = str; return this; }"
:grimacing:program.ts
(which unsuccessfully tried to do some param validation), and changed the param formatting to leverage commander's built-in param validation.