Users need to be able to preserve their acct age when moving a
payment account to a new client.
Also adjusted affected tests, and did some minor refactoring
of the custom gson type adaptor.
This change fixes the blocking problem in the fee rate request api.
Also redefined the TxFeeRateInfo.
- Redefined grpc.proto message TxFeeRateInfo, added
lastFeeServiceRequestTs field. (CLI user may want to know
TS of last fee request.)
- Adjusted TxFeeRateInfo proto wrapper.
- Adjusted CurrencyFormat and BtcTxFeeRateTest to new TxFeeRateInfo.
- Added @Getter annotation to FeeService. (CLI user may want to know
TS of last fee request).
- Pass resultHandler from GrpcWalletsService through CoreApi, to
CoreWalletsService's tx fee rate api methods.
These do not buy enough in the way of performance, at the cost of
so many additional lines. Buy these checks should be done for
debug log statements that have expensive parameters.
Make sure the taker checks the value of the 2-of-2 multisig output of
the deposit tx created by the maker, before signing it. This avoids a
potential security hole, where the maker attempts to steal most of the
deposit by using the wrong output value and adding an extra 'change'
output to himself.
Note that there's no actual vulnerability at present, as the output
value is indirectly checked via the validation of the delayed payout tx.
In particular, the extra checks added in 345426f as part of #4789 (Fix
remaining blackmail vulnerabilities) place a lower bound on the delayed
payout tx input value and with it the deposit tx output value. However,
explicitly checking the amount is more robust.
To persist in the very last moment before exit might cause problems on some OS.
We do not have confirmed that this might be an issue but to be on the safe side
we add a 1 sec. delay between persistence completed and exit.
and do not read or write persisted data.
We had recently a case where a user downgraded from 1.4.2 to 1.3.9 and
this caused failed trades and the wallet funds have been missing due to
some complexities of the wallet wegwit upgrade. The fund could be recovered
but it took quite some effort.
As downgrade is never tested and can lead to all kind of weird bugs we
should prevent that users accidentally can do it.
If there is valid reason to downgrade they can remove the version file.
Make sure to use the segwit version of Script.correctlySpends in
TradeWalletService.finalizeDelayedPayoutTx, which requires the input
value and witness to be passed explicitly (as the latter holds the
actual signature). This was causing BuyerFinalizesDelayedPayoutTx to
fail to do any kind of signature check.
Also refactor the method slightly and remove a redundant call to
WalletService.checkScriptSig (which does the same thing as
TransactionInput.verify) in the branch used by the seller.
Disallow non-P2WH depositTx inputs from the taker, while continuing to
allow them from the maker, so that offers created pre-v1.5.0 can still
be taken. (After some time, those inputs could be disallowed too.)
This is mainly to prevent mass blackmail attacks, where more victims'
money could be locked up than the DAO could possibly compensate them all
for. (This is probably only an attractive attack for a buyer anyway, at
least with the earlier commits.)
Strip all input witnesses from the depositTx message fields sent from
the buyer, until the last (DelayedPayoutTxSignatureResponse) message is
sent, where they can be bundled in as an extra field. Since the witness
data doesn't affect the final deposit tx id, the seller does not need to
know it until actually publishing the tx.
In the (fully) segwit case, this allows the buyer to prevent the seller
from publishing the deposit tx until the buyer has a valid, fully signed
delayedPayoutTx. Provide the final witness data in an extra 'depositTx'
field in DelayedPayoutTxSignatureResponse, which the seller can merge
with his depositTx witness block (for his own input signatures).
Improve validation of the buyer's delayed payout tx (both before & after
they get the final DepositTxAndDelayedPayoutTxMessage from the peer), by
finalising it independently of the seller. This is now possible since
their 2-of-2 signature is included in the DelayedPayoutSignatureRequest.
Check that the final delayedPayoutTx received from the seller matches it
byte-for-byte (which actually makes its receipt redundant now).
This also fixes an apparent security bug, where the final validation of
the delayedPayoutTx appears to skip any kind of signature check (only a
deposit tx hash check, which is still necessary).
Finally, optimistically check the deposit tx against the input of the
prepared delayedPayoutTx received from the seller, in the case that the
former is non-malleable (that is, the fully segwit case) and thus has a
stable ID given by the hash of the buyer's preparedDepositTx.
