-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add segwit support to the BTC wallet #4568
Add segwit support to the BTC wallet #4568
Conversation
@oscarguindzberg If you run into Codacy issues please let me know upfront, so you don't need to create unnecessary workarounds. I just checked the current complaints and removed the pattern for comment intention as IntelliJ is doing it differently by default. The other remaining two are legit (formatting issue and unused import) |
f09d829
to
40d67ba
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
778a7aa
to
d1e3e09
Compare
This PR is ready to be merged IMHO. |
@ripcurlx @sqrrm @chimp1984 Just bringing you attention in case you are in charge of approving/merging this PR. |
@@ -584,23 +584,13 @@ public AddressEntry getOrCreateAddressEntry(String offerId, AddressEntry.Context | |||
if (emptyAvailableAddressEntry.isPresent()) { | |||
return addressEntryList.swapAvailableToAddressEntryWithOfferId(emptyAvailableAddressEntry.get(), context, offerId); | |||
} else { | |||
AddressEntry entry = new AddressEntry(wallet.freshReceiveKey(), context, offerId); | |||
AddressEntry entry = new AddressEntry(wallet.freshReceiveKey(), context, offerId, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that never called from a trade protocol entry? e.g. the one for the multisig.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems you commented on outdated code.
@@ -601,6 +603,9 @@ public Transaction takerSignsDepositTx(boolean takerIsSeller, | |||
for (int i = 0; i < buyerInputs.size(); i++) { | |||
TransactionInput transactionInput = makersDepositTx.getInputs().get(i); | |||
depositTx.addInput(getTransactionInput(depositTx, getMakersScriptSigProgram(transactionInput), buyerInputs.get(i))); | |||
if (!TransactionWitness.EMPTY.equals(transactionInput.getWitness())) { | |||
depositTx.getInput(depositTx.getInputs().size()-1).setWitness(transactionInput.getWitness()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of depositTx.getInputs().size()-1)
I would suggest to make a local var from the getTransactionInput(depositTx, getMakersScriptSigProgram(transactionInput), buyerInputs.get(i))
we add earlier so its more clear. Maybe even do the check before adding, technically no difference but somehow more clean if the input gets completely defined before added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we do not support now segwit in the trade process, is that change needed at all? I dont see a risk to have it there but maybe better to leave all that out until we start adding segwit support to the trade protocol? Not sure if you started already in more pleaces to add support which do not interfere (as we discussed it is our strategy to add as much as possible without activating segwit in trade protocol...), so if you have started that process already all find, otherwise if its a single change it would be maybe more clear to start after the release with that process...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You seem to be right. In any case, it causes no harm.
@ripcurlx Found a bug migrating encrypted wallets, added WIP tag. Will remove WIP once the bug is fixed. |
3b772f6
to
4fabbdf
Compare
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.
4fabbdf
to
87da2ae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
See small suggestion in comment...
if (migratedWalletToSegwit.get()) { | ||
startPeerGroup(); | ||
} else { | ||
migratedWalletToSegwit.addListener((observable, oldValue, newValue) -> startPeerGroup()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add a if(newValue)
to make it more clear/safe. As we change only once from false to true it would not matter but feels more correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed 261e0ec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
post merge ACK - tested OK on mainnet using encrypted wallet for send and receive, and also using mixed segwit/legacy inputs/outputs all worked fine |
This is just the BTC wallet.
Trade protocol keeps using legacy addresses.
This PR does not require a hardfork.