Poll: Do you use first-class messaging?

[Luke-Jr]

First-class messaging, where the "Signatures" tab is part of the main window, was originally the default mode of operation for the Sign Message GUI function, but was relegated to the menu by default due to uncertainty of how much use it would get. I think 0.6 has proven it useful (for example, Bitcoin OTC now uses it for primary authentication) and it should be given first-class by default. However, others disagree and even want to remove the option (to make it first-class) entirely. Supposedly I'm the only one who wants message signatures to be first-class. I am hoping this poll will prove the opposite.

First-class messaging is a compile-time feature for Bitcoin-Qt 0.6. By adding the FIRST_CLASS_MESSAGING=1 option to qmake, builds will treat message signing the same way as other Bitcoin-Qt functions, instead of relegated to another dialog via the menu as it is by default. On Gentoo, users can enable it simply by installing with the "1stclassmsg" USE flag.

Note that the Verify Message will be available with both first-class and second-class messaging.

[Peter Todd]

Just to make things clear, by "first-class" you mean the way to access this functionality is from an always-visible button on the every screen?

[Elwar]

All of my messages fly coach.

[Luke-Jr]

Just to make things clear, by "first-class" you mean the way to access this functionality is from an always-visible button on the every screen?

Yes, it is a tab in the main window like other first-class functionality.

[knight22]

I don't understand what is that for exactly...

[Gaff]

Depends a bit on what you think the default client is for. Newbies are going to wonder what on earth message signing is and why need to do it. However it's getting to the stage where this client isn't really ideal for newbies due to the amount of time it takes to download the blockchain anyway.

If you want to make the client newbie friendly I'd have a "basic mode" with just a create account / receive / send button, and an advanced mode with everything else. If you consider the default client a reference implementation then keep it there as a 1st class function.

[rjk]

The only reason it looks useful is because of the Verify option - or is that because you used a more recent code base than is stable? Maybe because it's exclusive to Linux? in any case, I want that Verify option in my client.

[Luke-Jr]

The only reason it looks useful is because of the Verify option - or is that because you used a more recent code base than is stable? Maybe because it's exclusive to Linux? in any case, I want that Verify option in my client.

It's in 0.7 regardless of first/second class.

[istar]

This does not explain in noob friendly language what this is for.
This is pure geek speak for 100% of the new users.

Sign messages?  Why? To who?
Prove I own them? What them?

A much better text is needed.

The text need to explain.

Why?
What?
Who can see the message, everyone or just the one who recieves the coins?
Does it cost anything?
Will they see the message for sure?
Can the message be changed?
Will it stay forever?


Something like this:

You can prove you own an adress and any coin in it, by signing a message with that adress.
This message can be seen by the one who recieves the coins and anyone who looks at your adress.

[Luke-Jr]

This does not explain in noob friendly language what this is for.
This is pure geek speak for 100% of the new users.

Sign messages?  Why? To who?
Prove I own them? What them?

A much better text is needed.

The text need to explain.

Why?
What?
Who can see the message, everyone or just the one who recieves the coins?
Does it cost anything?
Will they see the message for sure?
Can the message be changed?
Will it stay forever?


Something like this:

You can prove you own an adress and any coin in it, by signing a message with that adress.
This message can be seen by the one who recieves the coins and anyone who looks at your adress.

The explanation text is unrelated to this poll/discussion. If you think the current wording is not good enough, you may wish to open a new issue.

[Gabi]

It's unrelated to sending bitcoins.

You can sign a message with your address. So you can show that you own the private key of that address without revealing it

Why? To prove you own an address. Who can see the message? As i said, it's a feature unrelated to sending bitcoin, you sign the message and it give you the text, then it's up to you copy-pasting where you need to. It's totally free of course.
Changing the message? If you change it the signature no more verify the message.

[paraipan]

All of my messages fly coach.

mine too 

@Luke love the feature and will use it frequently

[Pieter Wuille]

Since I am the one who claimed that Luke was the only proponent of this possibility, let me try to explain.

First of all, signing and verifying of messages is supported by the upcoming client version no matter what. The question is whether it must be a full tab, like send/receive, or an feature only reachable from the menu.

To me, it is obvious that this is a specific, quite separate feature of the client, unrelated to its core functionality. Making it available as prominent as sending/receiving coins is only confusing. I've seen people assume that it was necessary for confirming transactions, so my opinion is that we should make it as clear as possible that it is unrelated. A "tools" menu item would be best suited for this, but that's a separate issue.

Luke introduced the ability to compile with "first class messaging" (=sign/verify in a tab) some time ago, and at the time I considered having it as an optional non-default feature wouldn't hurt anyone. However, as people now have to spend extra work to keep it around and keep it functional, it becomes a burden. Therefore, I supported the opinion that the ability for having it as a full-fledged tab should be removed.

[SgtSpike]

Since I am the one who claimed that Luke was the only proponent of this possibility, let me try to explain.

First of all, signing and verifying of messages is supported by the upcoming client version no matter what. The question is whether it must be a full tab, like send/receive, or an feature only reachable from the menu.

To me, it is obvious that this is a specific, quite separate feature of the client, unrelated to its core functionality. Making it available as prominent as sending/receiving coins is only confusing. I've seen people assume that it was necessary for confirming transactions, so my opinion is that we should make it as clear as possible that it is unrelated. A "tools" menu item would be best suited for this, but that's a separate issue.

Luke introduced the ability to compile with "first class messaging" (=sign/verify in a tab) some time ago, and at the time I considered having it as an optional non-default feature wouldn't hurt anyone. However, as people now have to spend extra work to keep it around and keep it functional, it becomes a burden. Therefore, I supported the opinion that the ability for having it as a full-fledged tab should be removed.

I second this motion.  I can see it being useful in a small set of specific circumstances, but for no reason should it be prominently displayed in its own tab in the default client.  I completely agree that it would only serve to confuse people who didn't know its purpose.

[paraipan]

Since I am the one who claimed that Luke was the only proponent of this possibility, let me try to explain.

First of all, signing and verifying of messages is supported by the upcoming client version no matter what. The question is whether it must be a full tab, like send/receive, or an feature only reachable from the menu.

To me, it is obvious that this is a specific, quite separate feature of the client, unrelated to its core functionality. Making it available as prominent as sending/receiving coins is only confusing. I've seen people assume that it was necessary for confirming transactions, so my opinion is that we should make it as clear as possible that it is unrelated. A "tools" menu item would be best suited for this, but that's a separate issue.

Luke introduced the ability to compile with "first class messaging" (=sign/verify in a tab) some time ago, and at the time I considered having it as an optional non-default feature wouldn't hurt anyone. However, as people now have to spend extra work to keep it around and keep it functional, it becomes a burden. Therefore, I supported the opinion that the ability for having it as a full-fledged tab should be removed.

I second this motion.  I can see it being useful in a small set of specific circumstances, but for no reason should it be prominently displayed in its own tab in the default client.  I completely agree that it would only serve to confuse people who didn't know its purpose.

If you put it this way, I would have to agree, yes, it can be confusing to new users so it would be better to have access from the menu, as a tool.

[etotheipi]

I would be all for message-signing if it was a user-friendly feature in Bitcoin-Qt.   Can we spec out something for using "signature blocks" like I implemented in Armory?  Last I checked,  Bitcoin-Qt message signing/verification is a really poor experience for the user.  Handling random blobs of hex, manually copying the various pieces around, and possibly mis-copying the messages causing signature verification to fail, i.e. an extra space at the end of the message would cause the verification to fail.  

NOTE:  Armory's message-signing interface is a bit cluttered, because it's merged with a ECDSA calculator, but I had no motivation to clean it up and make it a first-class feature, because it's not terribly useful without Bitcoin-Qt supporting it.  I'll update it in a heartbeat if we can interoperate.

I'll be happy to compromise -- I will let you guys redefine the idea "signature blocks" (hopefully with similar properties) and I will support it in Armory -- and then Bitcoin-Qt will implement it?  After that, I think it will be a feature worthy of "first-class".  

Example:

Code:

-----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:    "Armory version 0.60-alpha was released 2012-Mar-"
            "19 07:40pm. Windows binaries have been released "
            "in zip files with the following MD5 hashes:  [Wi"
            "n32::7b6e3dd0e9114523e303db304a87c0d6] [Win64::e"
            "930159411483428da40c127f654bf69] Please do not u"
            "se any zip files whose hash values do not match!"
PublicKey:  0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
            b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
            7571cbe492a7222442b75df75b9a84
Signature:  842590674c06b8712bd9aa04ae7e3fd4c09410f6881ec5a361
            fcab55433f1d28f569b3771216754f400a5674e24984943d62
            9079a8d56b3c5285ee533f8f4f16
-----END-SIGNATURE-BLOCK---------------------------------------

(if you're running Armory right now, you can open Tools-->Message Signing then click on "Import Signature Block" -- copy that text in, and it will verify it)

Includes a Base58 address and public key (which must match), the exact message that was signed, and the signature.  
Select your address, write a message, then sign --> Gives you a signature block
Copy a signature block into the box, press "verify" --> Confirmation of address, message and signature

Extra Credit: Expand the "bitcoin:" URIs to handle signature requests.  This would dramatically improve the process for click-to-authenticate, if the message will fit in a URL string...

[Luke-Jr]

Can we spec out something for using "signature blocks" like I implemented in Armory?

Everything aside, I think this might be a good idea to support. Is there a reason standard PGP doesn't work, though?

[etotheipi]

Can we spec out something for using "signature blocks" like I implemented in Armory?

Everything aside, I think this might be a good idea to support. Is there a reason standard PGP doesn't work, though?

You mean ASCII-armored?  It could work, though I personally prefer something more compact and human-readable.

[Rassah]

Since I am the one who claimed that Luke was the only proponent of this possibility, let me try to explain.

First of all, signing and verifying of messages is supported by the upcoming client version no matter what. The question is whether it must be a full tab, like send/receive, or an feature only reachable from the menu.

To me, it is obvious that this is a specific, quite separate feature of the client, unrelated to its core functionality. Making it available as prominent as sending/receiving coins is only confusing. I've seen people assume that it was necessary for confirming transactions, so my opinion is that we should make it as clear as possible that it is unrelated. A "tools" menu item would be best suited for this, but that's a separate issue.

Luke introduced the ability to compile with "first class messaging" (=sign/verify in a tab) some time ago, and at the time I considered having it as an optional non-default feature wouldn't hurt anyone. However, as people now have to spend extra work to keep it around and keep it functional, it becomes a burden. Therefore, I supported the opinion that the ability for having it as a full-fledged tab should be removed.

I actually disagree. While yes, it may be confusing to some, especially in its current implementation, I feel that this is a very useful and important feature of Bitcoin. Especially when it comes to dealing with business agreements and transactions, signing contracts, etc (I was just discussing the idea of submitting signed public addresses to a company as representations of stock share ownership that the issuing company can keep a record of, pay dividends to, and use signed messages as proofs of sale/transfer of shares to someone else). If this feature is hidden away under a tool menu, likely people may not even be aware that it exists. If it is there prominently, people may be confused and not know what to do with the menu, but at least they'll know that there is something to learn about, and will likely come up with a lot of really nice features that use it down the road. So I even think that it should be included as a first class item for everyone, by default.
TL;DR - My first thought when reading your argument was, "people used to think e-mail and internet were confusing and difficult to use too"

[slothbag]

I'd like to see all these features being added to the bitcoin-qt client as configurable options.

It seems every single design decision has to be debated and agreed upon by 90% of the devs as to what they think is best, why not add everything and allow the users to pick and choose what they would like using the config screen.

I would love to try out messaging as a tab, but would be nice to turn it back off again if I dont find it useful.  I'd like to revert my blockchain progress bar back to the old style before it got all newbie friendly.. and i'd even like to try out Luke' batshit crazy tonal decimal system just briefly

Put 'em in the config screen, and let the individual decide.