Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release/v1.4.0 and v1.4.1 #4655

Merged
merged 143 commits into from Oct 20, 2020
Merged

Release/v1.4.0 and v1.4.1 #4655

merged 143 commits into from Oct 20, 2020

Conversation

ripcurlx
Copy link
Member

No description provided.

ripcurlx and others added 30 commits October 8, 2020 09:39
Segwit is not used for BSQ
Use P2WPKH for AVAILABLE context and P2PKH for the rest.
Disable reusing unused AVAILABLE entries until segwit support is
mandatory in Bisq.
This is for backwards compatibility with bisq nodes that have not
upgraded to bitcoinj 0.15.
mrosseel and others added 13 commits October 14, 2020 15:15
For published delayed payout transactions we do not receive the tx confidence
so we cannot check if it is confirmed so we ignore it for that check. The check is any arbitrarily
using a limit of 20, so we don't need to be exact here. Should just reduce the likelihood of issues with
the too long chains of unconfirmed transactions.
…t-check

Dont include dead transactions in check for unconfirmed txs chain
Only remove offer locally when necessary
It doesn't work when running from the release binaries as JFoenix is relying on it right now.
oscarguindzberg and others added 10 commits October 16, 2020 11:54
…t/response)

We did check in Connection for SupportedCapabilitiesMessage and if a message is of that type we set the capability.
But encrypted messages are wrapped in a PrefixedSealedAndSignedMessage so the payload is not visible as SupportedCapabilitiesMessage without decrypting it.
We need to call maybeHandleSupportedCapabilitiesMessage at decrypting the message. We do that only for direct messages not for mailbox messages as we likely do not have a connection open to the peer in that case (otherwise it would not be a mailbox msg) and as we don't have the connection available (we get is as AddDataMessage broadcast from an peer, so could could not apply it to the Connection of the sender.
Remove republishing at SellerProtocol as we don't know the capability of the peer at that moment and as we also want to republish for completed trades.
…ng-for-encrypted-msg

Handle Capabilities for encrypted messages (offer availibility request/response)
@ripcurlx ripcurlx changed the title Release/v1.4.0 Release/v1.4.0 and v1.4.1 Oct 19, 2020
Copy link
Member

@sqrrm sqrrm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

@sqrrm
Copy link
Member

sqrrm commented Oct 19, 2020

@ripcurlx There is an unsigned commit. I think we should allow it since it's deep in.

@ripcurlx ripcurlx merged commit ebe4618 into master Oct 20, 2020
@ripcurlx ripcurlx deleted the release/v1.4.0 branch November 5, 2020 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants