Follow-up improvements to sendbatch API, renew all

[pinheadmz]

replaces #708
follow-up to #686

This still fixes the two bugs listed in #708:

• "Could not resolve preferred inputs" fixed by using getUnspentCoin()
• Fix TX size estimator

This fixes a bug in sendbatch that was just merged:

• sendbatch [] will not actually send an empty 1-in 1-out TX with no covenants :-(

The fixes to the policy weight limit have been applied in a different way:

Current, unchanged behavior:

sendreveal when executed with no arguments attempt to build a batch TX that reveals all bids for all names for all accounts in the wallet. Similar behavior for sendredeem. If there are too many bids to reveal or redeem, these functions will fail by constructing a TX that is too big. This is not changed. We should probably consider deprecating this behavior in a future release, or those rpc commands entirely.

New behavior:

sendbatch and createbatch were recently merged, and so we add new features to that command only. Any combination of these actions is valid:

# current, unchanged behavior, etc...
sendbatch [['REVEAL', 'name1'], ['REVEAL', 'name2'], ['REDEEM', 'name3']]

# new behavior applied to actions with no arguments
sendbatch [['REVEAL']]
sendbatch [['REDEEM']]
sendbatch [['RENEW']]
# even batch them all together:
sendbatch [['RENEW'], ['REVEAL'], ['RENEW']]

In these new cases, the wallet will add as many actions as it can to an MTX and stop just before it crosses the policy weight limit. That means if a user has a lot of bids to reveal, redeem, etc -- this command may be called multiple times until it finally stops sending anything.

"Renew all"

This is a function that has not been available in the hsd wallet before. There is still no "sendrenewal" with no arguments, but can be used with sendbatch and createbatch to renew all expiring names. "Expiring" is hard coded to mean:

• names that are not expired yet
• names that are owned by the wallet
• names that will expire in about 90 days (on mainnet, 13,140 blocks or renewalWindow / 8)

A "renew all" batch will be limited not by policy weight limit, but much sooner below the consensus limit on renewals per block: exports.MAX_BLOCK_RENEWALS / 6 = 100

UX Goal

An hsd-based wallet application can call createbatch([['REVEAL'],['REDEEM'],['RENEW']]) at regular intervals (every block? every boot up? every 5 minutes...?) and display the batch to the user. If the user confirms, the batch will be sent, and the createbatch command called again immediately. There may still be more stuff to do! Applications can request user approval for each batch, or send all the batch transactions needed in sequence until it's done everything it needs to do.

Hosted wallet services with lots of user auction activity can call sendbatch([['REVEAL'],['REDEEM'],['RENEW']]) in a try/catch.

[coveralls]

Coverage increased (+0.2%) to 67.914% when pulling 4e9c7fc on pinheadmz:limit-batch into fb5501c on handshake-org:master.

[pinheadmz]

thanks for the review @rithvikvibhu I addressed everything in 0e2eb39

[rithvikvibhu]

Unlike other make*All functions that cap at 100 (MAX_BLOCK_* / 6), this check happens after adding a finalize so batches are capped at 101. Will either have to pop here or move it to the start of loop.

[pinheadmz]

thanks fixed.

[rithvikvibhu]

To stay consistent with existing create* RPC method behaviour, _validateBatch can maybe set default options.path = true since all other RPC calls do this:

hsd/lib/wallet/rpc.js

Lines 2170 to 2174 in 3fd74e0

	if (!opts.name) {
	const mtx = await wallet.createRevealAll({
	paths: true,
	account: opts.account
	});

[pinheadmz]

added

[rithvikvibhu]

Updated all bulk actions in Bob to use this, and everything works! kyokan/bob-wallet#546