When syncing from genesis the number of blocks are limited so we get the
`onParseBlockCompleteAfterBatchProcessing` called each time when the received
blocks are processed, and as we are not at wallet height we repeat requesting
blocks. But the new check for the BTC recipient triggers a resync from resource call.
We add now a check that we do this check only once the wallet is synced and our
block height from dao state matches wallet blockheight.
- At genesis we use the genesis height for request (not height+1)
- If wallet is not synced yet we do not call onParseBlockChainComplete (as it was before)
There are no asserts, but helpful for looking at affects of CLI commands
from terminal because apitest cases use gRPC service stubs instead of terminal.
Add a check of 'scriptTypeId' field, against the output of the spending
tx, to the 'RawTransactionInput::validate' method. Also make the seller
as well as the buyer validate each raw BSQ/BTC input received from the
peer. This prevents either peer from claiming that any of their
non-segwit inputs are segwit in order to underpay the tx fee.
The editoffer validation bug fixes:
- A trigger-price edit forced offer.price-margin=0.00.
This needs to be checked in new apitest case asserts.
- An activate state (only) edit forced offer.isUseMarketBasedPrice=true.
The CLI does not have the offer instance, and cannot know the correct
value of the isUseMarketBasedPrice param sent in the editoffer request.
The daemon has to figure this out. If the editType parameter value
sent to daemon is ACTIVATION_STATE_ONLY, use the current offer.isUseMarketBasedPrice.
The refactoring includes more useful and readable information in core's EditOfferValidator
and MutableOfferPayloadFields toString methods, for debugging with the daemon log. And some
adjustments for allowing edits to XMR offers.
Prevent the seller from stealing the combined tx fee as change by lying
about the value of one or more of his BTC inputs, which are passed to
the buyer as raw inputs in the 'BsqSwapFinalizeTxRequest' message.
To this end, add a 'RawTransactionInput::validate' method to check the
'value' field against the output value of the respective spending tx and
run it on every seller input in 'ProcessBsqSwapFinalizeTxRequest', so
that the buyer is no longer just trusting those numbers.
Additionally, check that the spending txIds from the raw BTC inputs
supplied by the seller actually match those of his signed inputs in the
accompanying partially signed tx, thus tying the raw input values to the
seller's tx.
**Unconfirmed** BSQ swap seems like something failed. **Processing** is used by some wallets for unconfirmed transactions and has no negative implications.
Fix a trivial bug in the iterator returned by 'IntListMultimap::get',
caused by mistaken use of the iterator index in place of the key when
doing lookups into the overspill map. This was causing puzzle solutions
to be invalid about 3% of the time, as well as substantially reducing
the average number of solutions found per nonce.
As the fix increases the mean solution count per nonce to the correct
value of 2.0 predicted by the paper (regardless of puzzle params k & n),
inline the affected constants to simplify 'Equihash::adjustDifficulty'.
The OfferIdOptionParser superclass reduces duplication for parsing
offer-id parameters, but it needs to let subclass parsers' other
options pass validation.
