Bitcoin-Qt signmessage GUI #582

pull luke-jr wants to merge 1 commits into bitcoin:master from luke-jr:signmessage_gui changing 12 files +418 −2
  1. luke-jr commented at 2:58 AM on October 11, 2011: member

    No description provided.

  2. laanwj commented at 6:04 PM on October 11, 2011: member

    Does this functionality also allow for verifying a signed message? (I checked quickly and was unable to find it)

  3. luke-jr commented at 6:07 PM on October 11, 2011: member

    No, it doesn't. This gets users able to work with webservices. The next logical steps once this is merged would be 1) verify, and/or 2) sign & email from the Send page

  4. laanwj commented at 6:42 PM on October 11, 2011: member

    I'm not entirely convinced that signing/verifying messages should be this prominent in the bitcoin UI. I'm fine with adding it in the menu, but is it central enough to the workflow to warrant adding a tab for it? I tried to keep it as simple as possible with the tabs.

    What does the rest think?

  5. TheBlueMatt commented at 8:17 PM on October 11, 2011: member

    I would agree with laanwj here, a tab should (IMHO) be reserved for something which an average person would do on a regular basis, which message signing just isnt.

  6. luke-jr commented at 8:45 PM on October 11, 2011: member

    So what happens when you open the signing panel? just have none of the tabs selected?

  7. TheBlueMatt commented at 12:34 AM on October 12, 2011: member

    New window?

  8. luke-jr commented at 12:40 AM on October 12, 2011: member

    I kindof like Bitcoin-Qt's single-window design.

  9. laanwj commented at 6:10 AM on October 12, 2011: member

    I agree that this is a dilemma. It would be nice to fit it in the single-window design, but without exposing it as a first-class operation.

    Making the option selectable from the menu bar, then showing it in the main pane while deselecting all of the tabs seems fine with me.

    This gives it a bit of a 'hidden feature' feel. But as there is no verify functionality yet, it still feels pretty experimental anyway.

  10. luke-jr commented at 3:23 PM on October 12, 2011: member

    Ok, I made it only on the File menu, but still appears in the single-window style (deselecting the other tabs).

  11. TheBlueMatt commented at 9:31 PM on October 13, 2011: member

    I would argue that putting it in the main window but without selecting any tabs is worse than having it in either a new window or a tab. The 'hidden feature' feel never sits well with me when I see it in an application - it just makes me feel like no effort went into UI design and it was just slapped in there, which is never a good feeling to have, especially in financial software where every effort needs to be made to encourage trust in the application (ha like we do that now...)

  12. laanwj commented at 5:19 AM on October 14, 2011: member

    You have a point, but in that case it would be better to not include it all yet, because it's not finished yet. And I have a vague idea why signmessage could be useful, but how to integrate "secure messaging" usefully for end users without turning it into half a mail/IM client is not exactly clear with me.

    Still I like experimental features and playing with them. Sometimes you discover novel applications just by having something available. And I don't want to linger pull requests that are essentially good for too long.

    So that's my reasoning to pull this and somehow make it hidden for "normal payment users", or maybe this is a good case for starting a bitcoin-next or UI-next branch where we can be 'innovative'?

    On Thu, Oct 13, 2011 at 11:31 PM, Matt Corallo < reply@reply.github.com>wrote:

    I would argue that putting it in the main window but without selecting any tabs is worse than having it in either a new window or a tab. The 'hidden feature' feel never sits well with me when I see it in an application - it just makes me feel like no effort went into UI design and it was just slapped in there, which is never a good feeling to have, especially in financial software where every effort needs to be made to encourage trust in the application (ha like we do that now...)

    Reply to this email directly or view it on GitHub: #582 (comment)

  13. luke-jr commented at 6:13 AM on October 14, 2011: member

    This feature is finished, as soon as someone decides whether it's allowed to have a tab or not. It provides useful functionality that people need /yesterday/. It's not some "hey, this might be useful for new stuff", it's "hey, people are already needing to use this even before it's got a final release".

  14. laanwj commented at 7:41 AM on October 14, 2011: member

    Well the consensus seems to be a separate window for now.

    But please do explain to us (or point to the wiki) how this is useful in trade in the current form... Op 14 okt. 2011 08:13 schreef "Luke-Jr" < reply@reply.github.com> het volgende:

    This feature is finished, as soon as someone decides whether it's allowed to have a tab or not. It provides useful functionality that people need [i]yesterday[/i]. It's not some "hey, this might be useful for new stuff", it's "hey, people are already needing to use this even before it's got a final release".

    Reply to this email directly or view it on GitHub: #582 (comment)

  15. TheBlueMatt commented at 1:23 PM on October 14, 2011: member

    This is a very useful addition for many merchants or pools who want to verify a user based on bitcoin address. Although I would strongly argue for merchants doing their own auth instead of wasting time with complicated sigh-message stuff, hence why I would argue for this not taking a very central role in the gui. (also, luke stop talking about your need for things in the third person)

    "Wladimir J. van der Laan" reply@reply.github.com wrote:

    Well the consensus seems to be a separate window for now.

    But please do explain to us (or point to the wiki) how this is useful in trade in the current form... Op 14 okt. 2011 08:13 schreef "Luke-Jr" < reply@reply.github.com> het volgende:

    This feature is finished, as soon as someone decides whether it's allowed to have a tab or not. It provides useful functionality that people need [i]yesterday[/i]. It's not some "hey, this might be useful for new stuff", it's "hey, people are already needing to use this even before it's got a final release".

    Reply to this email directly or view it on GitHub: #582 (comment)

    Reply to this email directly or view it on GitHub: #582 (comment)

  16. luke-jr commented at 2:35 PM on October 14, 2011: member

    In most cases, this enables merchants to just publish a single Bitcoin address for payments on their website, and if there is any confusion over who paid request individual customers sign their receipt with a sending address. It is also useful, as BlueMatt implied, for proving an Eligius miner controls an account (which is identified only by its payout address). Both of these problems have been around for a while now. ThomasV also mentioned that he has been waiting for this feature for some unspecified purpose.

  17. gavinandresen commented at 5:43 PM on October 16, 2011: contributor

    ACK on the code changes for release-after-0.5. I don't have an opinion on file menu versus tab.

  18. sipa commented at 7:06 PM on January 26, 2012: member

    First time I look at signmessage_gui:

    • it looks very inconsistent: it's a tab, but it is not listed as a tab?
    • items in the systray should not affect what the main program window does (as opposed to say opening a pop-up separately); i know this is not entirely related to this pull request, but it still feels wrong.
  19. Bitcoin-Qt signmessage GUI a6d3a1ff9e
  20. sipa commented at 7:51 PM on January 26, 2012: member

    ACK

  21. laanwj referenced this in commit 2bc4fd609c on Jan 28, 2012
  22. laanwj commented at 9:05 AM on January 28, 2012: member

    Has been merged

  23. laanwj closed this on Jan 28, 2012

  24. rebroad commented at 10:07 PM on May 2, 2012: contributor

    Is there any documentation anywhere explaining what this feature is for and when it should be used? I suspect most bitcoin users won't know what to use this for otherwise.

  25. luke-jr commented at 10:11 PM on May 2, 2012: member

    Please don't comment on long-closed issues. Open a new one.

  26. coblee referenced this in commit 5f6a0cf1af on Jul 17, 2012
  27. rajarshimaitra referenced this in commit 3b6dcc164e on Aug 5, 2021
  28. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-14 15:16 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me