-
Notifications
You must be signed in to change notification settings - Fork 266
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
indicate explicit to the user that the wallet balances shown is watch only. #37
Conversation
edit@saibato The prefix word "Your " implies that the user can spend this confirmed and not pending balance even though he has or had never the keys,
We could sure even add more here and make a longer text that hints the user to the correct |
My understanding is that the language "spendable balance" is deliberate as it does not include unconfirmed transactions which are considered not yet "spendable". If my understanding is correct it is a Concept NACK from me. |
@michaelfolkson hmm,,. this is not about unconfirmed transactions, they are confirmed and the balance is in sum correct. |
Spendable as in whoever has the keys can spend them. Not yet spendable would be funds in unconfirmed transactions. The language isn't referring to who has the keys, it is referring to whether the transactions are confirmed or not. In the example image you posted all your funds are spendable. |
Your ... is a synonym for whoever hmm... Prob by this Gavin was tricked? |
Unrelated, but the wallet generally considers unconfirmed change as spendable as well |
Yup, when you begin to see what we do with user eye;s, there is some work ahead. And this is probably anyway an edge case and this wrong hint is somehow a minor bug, but since we allow watch only wallets, i still would like to have the ui state in any from that those balances are not spendable at all by the wallet that is currently visible to the user. In general we clearly show that watch-only utxos are unspendable and have split row to diff , but not in this case. An unaware user might think since in this case the ui show's up almost like the normal full spendable wallet. And i must admit when testing back and forth with wallets, for a short moment, even i thought wow they are spendbable, only after inspecting deeper i saw that this was only watched utxos, |
@MarcoFalke Btw. since rona has gave me lots of free timeslots, if you know others thing to be addressed, that you have in your backlog and think, would be nice to have, pls ping. |
There'd be #1 for example |
thx, for hint, |
6db25ea
to
90ac7ff
Compare
fixup-Update; I considered @michaelfolkson argument and he is right that those confirmed balances are spendable, if you have the keys, what we know from the wallet, if the keys are there, but even So this fixup changes in addition also the This is the current way we display watch only wallets, they look the same as a normal spendable full key wallet, although the wallet has no keys and we might not had them also never. After change; |
90ac7ff
to
d0d83d2
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.
We already have the watch only icon on the status bar, maybe it should be more visible?
@promag thx, whatever helps, my point is that up till now this design is not optimal and serve;s not perfect our high standards . An unaware user could even have there keys stripped from there wallet by i.e. some rpc remote or local bytecode insert exploit or simple fileops filesytem wallet.dat exchange. And even long term experts could in my view, be somewhat astound, if they switch to newer node software. Where keyless and multiple wallets are possible. |
I can't imagine a case where it would make sense for malware to turn a read/write wallet into watch-only. Typically, they would just spend the coins to a key they control exclusively. Even if they wanted to pull a trick like this, it would be comparable to just corrupt the private keys... Also, aren't watch-only funds spendable with stuff like hardware wallets? |
@luke-jr I know, its not easy to follow or see the links of sense i would like to have changed in core and some of my PR are only hints and I never cared honestly, if any is merged, i done my footprint early on, but be assured, if you at some point will see the 3 stage picture that i see water clear, you will think omg, the heist of the century. imho |
Sure but i would say, that's technically an other wallet? And btw, I will not push script hint pr's , but honestly why even doubt, that what i outlined And have you hovered about the little disabled hd icon on the bottom, if you tell me |
@achow101 @meshcollider Mind looking into this PR? |
I'm ~0 on this, as promag said, there is already an indicator. And spendable isn't the same as confirmed so I'm not convinced on that change either, Happy if other people want this though. |
Spendable takes into account confirmed/unconfirmed, whether wallet contains all the key(s) needed to spend, whether sufficient time has passed for coinbase output to be spent etc. So as @meshcollider says spendable meets more conditions than just confirmed. As a result it is a Concept NACK on this change. I do wonder though whether it should be made clearer to the GUI user how "spendable" is defined either in the UI or in documentation. |
d0d83d2
to
990c2cd
Compare
Since the bug pun line confirmed did not resonated to action by review, here a modified version that address solely the poor hint and indication that a wallet is pure watch-only. Also we can see here that blanked out HD symbol in status line is hardly to distinguish from a blanked eye. With the description header and the hint, that distinction should be sufficient. (change: add a headerline Watch-only in the watch only case and applied the same hint from watch-only address from the mixed cases ) Here for reference how the other cases will still look like : (unchnaged/ by this PR same display as in old version ) (unchanged/ by this PR same display as in old version) |
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.
ACK 990c2cd. I had similar idea when switching between spendable and watch-only wallets on a testnet few days ago and got confused for a brief moment.
Yes, I didn't notice it before this comment actually. Also, with wallets having both spendable and watch-only addresses you have "Watch-only" / "Spendable" above amounts, so one might expect the same behaviour when having loaded wallet with only watch-only addresses. |
exactly, if I interpret correctly the case u describe? Mixed stay untouched since they already display in two columns with a hinting header and this seams to be fine AFAICS. |
@achow101 Could you be interested in reviewing this PR? |
There hasn't been much activity lately. What is the status here? Finding reviewers may take time. However, if the patch is no longer relevant, please close this pull request. If the author lost interest or time to work on this, please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future. |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
Concept ACK I don't think this should be limited to just legacy wallets - descriptor wallets can have private keys disabled as well. This should probably apply to all wallets that have private keys disabled, as the the watch-only icon does. |
Are you still working on this? If so, mind addressing @achow101's #37 (comment) please? |
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.
tACK 8f9fd44
Current change doesn't display the desirable goal:
I agree with @achow101, the change should be moved outside the legacy logic.
The commit title/ message could start with "gui:
", it shouldn't finish with a dot I think, and perhaps the commit body could be rephrased a bit to explain more direct the purpose of this change, eg (please check the commit guidelines):
gui: Show spendable balance for keyless watch-only
Make labelSpendable visible for watch only wallets
with their private keys disabled.
Also set the labelBalance accordingly for the same
condition.
@@ -201,7 +201,10 @@ void OverviewPage::setBalance(const interfaces::WalletBalances& balances) | |||
m_balances = balances; | |||
if (walletModel->wallet().isLegacy()) { | |||
if (walletModel->wallet().privateKeysDisabled()) { | |||
ui->labelSpendable->setText(tr("OverviewPage", "Watch-only:")); |
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.
ui->labelSpendable->setText(tr("OverviewPage", "Watch-only:")); | |
ui->labelSpendable->setText(tr("Watch-only:")); |
ui->labelBalance->setText(BitcoinUnits::formatWithPrivacy(unit, balances.watch_only_balance, BitcoinUnits::SeparatorStyle::ALWAYS, m_privacy)); | ||
ui->labelBalance->setToolTip(tr("OverviewPage", "Your current balance in watch-only addresses")); |
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.
ui->labelBalance->setToolTip(tr("OverviewPage", "Your current balance in watch-only addresses")); | |
ui->labelBalance->setToolTip(tr("Your current balance in watch-only addresses")); |
Closing due to lack of support from the author. |
This little change got me back to earth when i realized that the
balance hint Your current spendable balance was just a label and
not the result of of some random pubkey addresses i imported with
importaddress warping into keys for those addresses,
At least for some short moment i felt mainnet btc rich, but this change
in hint wording should be done.
edit@saibato Todo: before merge run translation Makefile after we agree in wording.