The factory can create, sign, and finalize the warning transaction.

The factory can create, sign, and finalize the redirection transaction.

The factory creates, signs, and finalizes the claim transaction.

…ocol to BaseSellerProtocol

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…l at client code

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…col at client code

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…ivate and constructor protected

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

… custom code but only call super to make it more transparent which handler methods are in the protocol.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…DE_PROTOCOL_VERSION field.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…rotocol_v4 package

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…s base for later implementing the new protocol.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Pass depositTxOutput to make it more clear what is really used.
Use long for claimDelay (to be consistent with lockTime and ScriptBuilder expected type).
Do not pass aesKey in TradeWalletService.signWarningTx as its kept private in that service class.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…it tx.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…meters

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Using a dedicated ProcessModel implementation would cause too much changes in client code. Maybe we still refactor that later, but for now it seems its less painful to add fields and use the same class at the old and new protocol.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

…to BuyerProtocol_v5, but for now we start with one variant (BuyerAsMakerProtocol_v5 and SellerAsTakerProtocol_v5)

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

TODO: check if that is expected when we do not have the full tx chain or if its caused by a bug.

Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>

Also add trade tasks to publish the warning/redirect/claim txs.

Also make claim delay 5 blocks on regtest, and add missing TradeMessage
constructors to provide a default argument for the P2P message version,
for consistency with the other trade messages.

Add an extra flag to 'DelayedPayoutTxReceiverService.getReceivers(..)'
to control the tx fee precision, and refactor to use an EnumSet of flags
activated by particular date, instead of just passing boolean args. This
new 'PRECISE_FEES' flag is currently set to activate at the same time as
the v5 protocol upgrade (though it can be used independently).

When present, the flag changes the receiver list calculation as follows:

 1) Spendable amount depends on individual output ScriptPubKey sizes,
    instead of all outputs assumed to cost 32 bytes each (P2SH cost);
 2) Base cost of DPT is that of the signed instead of unsigned tx (v4
    protocol only - redirect tx base cost is always for the signed tx);
 3) Increase in spendable amount from saved tx fees after filtering out
    the small outputs is taken into account;
 4) Small outputs are filtered out pre-adjustment upwards, rather than
    post-adjustment, so that they don't get erroneously included;
 5) The balance given to the LBM takes the tx fee cost of his output
    into account.

Additionally, restrict the fee bump addresses of the peer's warning and
redirect txs to be P2WPKH, for more predictable tx fee rates.

Make sure the 'signedClaimTx' & 'finalized(Warning|Redirect)Tx' fields
of the 'ProcessModel' & 'TradingPeer' models are persisted properly in
the respective proto objects. To this end, store them serialised as byte
arrays instead of Transaction objects.

(Also clean up the Lombok annotations slightly.)

Add checks that we're not running the v5 protocol, everywhere a missing
delayed payout tx would cause errors or warnings to appear in either the
logs or the Pending Trades or Trade Details views, for a v5 trade that
completes normally.

Also add both the buyer's & seller's redirect & warning txs to the Trade
Details view, in place of the missing DPT, as well as the claim tx if
it's present. (The latter is created & signed at the point of use.) Add
suitable 'get*(BtcWalletService)' methods to 'Trade' for that purpose.

Make 'aesKey' method parameters @nullable where obviously applicable,
for consistency (as it was missed out in a number of places). Also make
the v5-protocol-specific fee bump fields of 'InputsForDepositTxRequest'
@nullable, as expected.

Make sure 'TransactionAwareTrade::isRelatedToTransaction' returns true
for warning, redirect & claim txs belonging to the given trade. Also
optimise the method somewhat by short circuiting on a wider class of txs
than those with zero locktime, when ruling out that the tx is a delayed
payout or warning tx. The previous short circuit test was inadequate due
to the fact that a lot of wallets, such as Sparrow, set a nonzero
locktime on all txs by default, to prevent fee sniping.

Also modify 'TransactionAwareTradable::bucketIndex' to place the new
staged txs in the (global) delayed payout tx bucket, so that they get
past the related transactions filter, used to speed up the pairing of
txs with tradables.

Since the multisig escrow outputs of the deposit & warning txs do not
belong to the user, bitcoinj won't pick up any txs spending them unless
a corresponding watched script (the ScriptPubKey) is added to the
wallet. To this end, provide a trade task to add watched scripts for
those three outputs, which runs just before the client or the peer might
broadcast the deposit tx. Also remove them upon withdrawal of funds at
the end of the trade (closed normally or through a dispute).

We need to add watched scripts for the deposit tx output and both the
user's and the peer's warning tx outputs, so that the peer's warning,
redirect and claim txs are all picked up, regardless of any message sent
to the client.

TODO: Possibly find a way to clear out old watched scripts from failed
 trades, as they will otherwise remain in the user's wallet permanently,
 creating a growing burden for the wallet. Also, we should possibly re-
 add all the watched scripts if the wallet is restored from seed.

Ensure 'TransactionsListItem' recognises warning, redirect & claim txs
and displays appropriate details messages for them. Redirect txs are
made to show the same "Refund collateral" details message as delayed
payout txs and don't distinguish between the user's or peer's tx,
whereas warning & claim tx details do distinguish between them.

Also ensure the correct amounts are displayed in the Transaction view,
when watched scripts are present in the wallet, by changing
'WalletService::getValueSent(To|From)MeForTransaction' not to include
watched outputs or inputs in their respective sums.

Ensure claim txs broadcast by the peer are correctly linked to the trade
and display correctly in the Transactions view, by changing
'BisqRiskAnalysis' not to deem txs with a relative lock time as risky,
as that interferes with the v5 trade protocol.

Finally, make the Trade Details window resilient to missing peer's
redirect & warning tx from old trades, which could be cleared out as
sensitive data, and prevent it from incorrectly displaying the claim tx
as the multisig payout tx (and similarly for the Transactions view).

Also update the expected signed tx sizes accordingly, and require that
the peer provides a low-R signature for them, so that they're never
bigger than expected. (No such requirement is made of any of the txs in
the current v4 protocol, to ensure backwards compatibility.)

Add the 4 values 'WARNING_SENT(_BY_PEER)' & 'ESCROW_CLAIMED(_BY_PEER)'
(all unused at present) to the 'Trade.DisputeState' enum, and update the
proto. The new states are not classed as arbitrated, as arbitration is
only deemed to occur once a redirect tx has been published (and that's
intended to reuse the existing 'REFUND_REQUEST*' dispute states of the
current v4 protocol). But they are an escalation beyond mediation, as
they spend the escrow, and thus disable both the buyer and seller
payment confirmation. Accordingly, add a 'DisputeState::isEscalated'
predicate to include the new states in addition to the arbitrated ones.

Adapt the existing workflow of starting a second-round arbitration
process, upon mediation failure, to the v5 trade protocol, by giving the
trader an option to broadcast his warning tx. This replaces the current
(tertiary) action of broadcasting the (v4 protocol) delayed payout tx to
start arbitration, on the mediation result popup. Instead, the trader
must now wait for the peer to see the warning tx and actually start
arbitration by broadcasting his redirect tx. (This second part is not
yet implemented.)

Also clean up 'DisputeValidation' slightly and prevent the errant
display of a duplicate-DPT-detected message in the event that a dispute
has a missing delayed payout txId (as is currently the case for v5
protocol trades). Fix the logic similarly for missing trade IDs &
deposit txIds.

TODO: Allow peer to start arbitration by broadcasting his redirect tx,
 upon detection (via a suitable listener) of a warning tx broadcast.

Provide a 'SetupWarningTxListener' trade task, which runs at the opening
of the trade and upon initialisation of the trade manager at application
startup. It adds a listener which picks up either warning tx and updates
the dispute state to 'WARNING_SENT(_BY_PEER)', as appropriate.

As the peer's warning tx may be unknown (at least in the unlikely event
that sensitive data was cleared out of an unfailed trade), the listener
detects any spend of the deposit tx escrow output. (This functionality
will also be needed to pick up the peer's claim tx, which has a
completely unknown txId.) To this end, provide a new listener type,
'OutputSpendConfidenceListener', which can be added to or removed from a
'WalletService' instance and detects change in the confidence of any tx
spending the provided (non-detached) 'TranactionOutput' instance.

(Also do some minor cleanup of the 'WalletService' class.)

When either of the trade peers publishes his warning tx, reflect that in
the info panel of the trade step view, providing a red "Redirect to
arbitration" or a (possibly greyed out) green "Claim trade collateral"
button, in place of the usual get-help/open-dispute button. Add four new
values to the 'TradeStepInfo.State' enum to distiguish whose warning tx
was published and whether the corresponding claim tx is still locked.
Provide (currently unimplemented) button action stubs to open a popup to
claim/redirect.

Also do some minor cleanup of 'TradeStepView' and make sure the method
'DisputeManager::checkForMediatedTradePayout' closes the mediation
ticket upon publishing of either warning tx, not just upon starting
arbitration or receiving a payout.

Rename 'SetupWarningTxListener' to 'SetupStagedTxListeners' and add code
to provide a second listener for the redirect or claim tx, upon firing
of the first listener. Set the trade dispute state to one of the four
states 'REFUND_REQUEST(_STARTED_BY_PEER)' or 'ESCROW_CLAIMED(_BY_PEER)',
as appropriate, upon firing of the downstream listener. Also, restore
the peer's redirect or warning tx in the unlikely event that they were
cleared out as sensitive data, and fill in the peer's claim tx if it
gets picked up. Add a proto field to persist the latter, in order to
show it in the details window of a past trade.

Make sure that the peer's staged txs don't get subsequently removed as
sensitive data if the trade wound up in a dispute and any staged txs
were broadcast. Similarly, suppress the removal of watched scripts in
that case, to prevent staged txs disappearing if there's an SPV resync.

Finally, add a missing 'SetupStagedTxListeners' trade task item to the
'PreparedTxBuyerSignaturesMessage' handler of the v5 seller-as-maker
protocol (overriding super), as the listeners weren't being set up at
the start of the trade in that case.

Make the filtering methods 'isPossible(RedirectOrClaimTx|EscrowSpend)',
used to speed up the Transactions view, lenient towards segwit txs that
have missing witness data. This appears to be the case for a lot of txs
fetched from the network by bitcoinj, including all the segwit txs in
the wallet after an SPV resync.

Since the witness data of a peer's claim tx (picked up by bitcoinj) may
in fact be missing, rename the field 'TradingPeer.signedClaimTx' to
'claimTx', along with corresponding proto field.

Finally, make sure the correct details message is shown for refund agent
payout txs, for v5 protocol trades in the Transactions view, by changing
the order of some of the nested if-else branches, in order to avoid an
unwanted '!trade.hasV5Protocol()' clause.

Implement the redirect-to-arbitration & claim buttons in the trade step
view, allowing the warned peer to publish the redirect tx and open a
refund dispute, or the user to close the trade by publishing the claim
tx if an unresponsive peer. To this end, add '(warning|redirect)TxId'
fields to the 'Dispute' DTO and corresponding proto, to use in place of
the (now null) 'delayedPayoutTxId' field. The new fields allow the
refund agent to validate the tx chain in the case of the v5 protocol
(using the Mempool service to make sure the redirect tx is valid and
published/confirmed -- not yet implemented) and guard against replay
attacks. Update the validation logic accordingly (& add some TODOs).

Additionally, tidy up 'DisputeSummaryWindow' a little and fix a bug in
'SetupStagedTxListeners' preventing the redirect/claim tx listener from
firing after the warning tx appears, until an application restart. Also
ensure that it closes the trade instead of merely updating the dispute
state, when a claim tx is picked up.

TODO: Improve popup messages & fix arbtrator tx chain validation logic.