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.

[1714822536]

1714822536

[1714822536]

1714822536

[1714822536]

1714822536

[1714822536]

1714822536

[1714822536]

1714822536

[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.

[paraipan]

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.

Well said, hope Gavin and the team sees it too

[rjk]

Too many options means that there is very poor UX design. I think signing should still be a menu choice, and not a separate tab.

[etotheipi]

Message signing is appropriate as a core feature of the Bitcoin client.  Once it is easy to use, it has a variety of uses which further demonstrate the power of Bitcoin.  For instance, you order stuff from the internet and need it shipped.  Receiver's address should be signed by the address that paid for it, to guarantee that the same person that paid is the same person that's getting it (or deciding where it's going).  I could even see this being used for authentication for online services: the first payment address you ever used would be the one used for authentication.  "Please sign the following message to confirm your action..." (which could be a massive withdrawal).  Hell, I could see some users using it instead of GPG signatures for non BTC stuff, solely because they already have it and understand how to use it.

Message signing will not only be a powerful feature, but a core feature.  I'm sure there's a dozen other use-cases, and they all justify having this part of the core functionality -- merchants should be able to request signed data from the user without having a separate "How to setup message signing" page. 

[Pieter Wuille]

There was some discussion about earlier on IRC.

Right now, message signing is a very low-level function. It has very interesting applications, but in its current form, you're not going to use it unless someone tells you to, or know what it does.

The one point where it makes sense, and the only way I see it being intuitive, easy and useful, is as part of a payment protocol. By which I mean this: an address is a URL or something e-mail like, and the client connects and requests payment information (such as the public key/script to send to, the amount, maybe a message, maybe an order id), the client constructs a transaction and sends it directly to receiver or his payment processor. When such an address is selected, the client could enable a text input field for a message to attach to it, and it would travel together with the transaction directly to the one who cares, with a signature that it comes from the payer.

At that point, it absolutely should be a first-class feature. But right now, it's obscure and unclear.

[etotheipi]

There was some discussion about earlier on IRC.

Right now, message signing is a very low-level function. It has very interesting applications, but in its current form, you're not going to use it unless someone tells you to, or know what it does.

The one point where it makes sense, and the only way I see it being intuitive, easy and useful, is as part of a payment protocol. By which I mean this: an address is a URL or something e-mail like, and the client connects and requests payment information (such as the public key/script to send to, the amount, maybe a message, maybe an order id), the client constructs a transaction and sends it directly to receiver or his payment processor. When such an address is selected, the client could enable a text input field for a message to attach to it, and it would travel together with the transaction directly to the one who cares, with a signature that it comes from the payer.

At that point, it absolutely should be a first-class feature. But right now, it's obscure and unclear.

I think if this could be added to the URI spec, it would be useful and easy to use.  For instance:

(1) I want to buy a widget, so I got to the widget merchant website
(2) Enter in my shipping address and details
(3) Click on the link to pay -- client pops up asking if the payment details are correct
(4) Merchant site detects the payment and gives a link: "Please confirm payment details"
(5) Client pops up saying:  "Please confirm shipping address for your order: Name: ... Address: ... Email: ..."
(6) User clicks "sign" and sends it back

It would be even better if the message signing URI included an IP address so that the client would just dump the signed message where it needs to go after signing and the user doesn't have to do anything other than click "Sign".

In this particular use-case, the user doesn't even need to realize they're "signing a message."  They are just confirming transaction details.  If it's handled under-the-hood like this, merchants can get the benefit of authenticated messages without much inconvenience to the user.

[2112]

I think if this could be added to the URI spec, it would be useful and easy to use.  For instance:

Sir, I beg you: please don't reinvent Acrobat Reader secure form signing. Please leave the attempts to embrace, extend and fuck up the electronic commerce by unnecessary integration to the giants like Adobe.

Please!

Thanks.

[SgtSpike]

etotheipi, I think you're trying to put the cart before the horse.  Yes, there are plenty potential use-cases for it, but very few of those use-cases are wanted/needed/used by anyone right now.  I don't hear any merchants clamoring to have customers sign their physical address information with their payment address - for the merchants, it is plenty good enough to just have the user fill out their address information into a normal HTML form at the time of purchase (and really, why wouldn't that be good enough?).

[Rassah]

etotheipi, I think you're trying to put the cart before the horse.  Yes, there are plenty potential use-cases for it, but very few of those use-cases are wanted/needed/used by anyone right now.  I don't hear any merchants clamoring to have customers sign their physical address information with their payment address - for the merchants, it is plenty good enough to just have the user fill out their address information into a normal HTML form at the time of purchase (and really, why wouldn't that be good enough?).

Yeah, I think this would be more appropriate for cases where a change is requested (change delivery address, change subscription terms, or change ownership of something registered to one address to a different address).

[etotheipi]

etotheipi, I think you're trying to put the cart before the horse.  Yes, there are plenty potential use-cases for it, but very few of those use-cases are wanted/needed/used by anyone right now.  I don't hear any merchants clamoring to have customers sign their physical address information with their payment address - for the merchants, it is plenty good enough to just have the user fill out their address information into a normal HTML form at the time of purchase (and really, why wouldn't that be good enough?).

I half-agree.  If it's easy enough, why wouldn't you?   The purpose is for the merchant to know for sure, that the same person who paid for the merchandise just told them where to send it.  Just like Bitcoin is beneficial for merchants to avoid chargebacks, this can also avoid transaction hijacking, and also enable better communication between parties that are operating more anonymously than with fiat transactions.  How is a site going to verify that their semi-anonymous customer really wants their refund sent to address X, or wants to change shipping address to Y, or invest all their money in fund Z?  

Maybe "specify shipping address" is not the best example.  And, it may not be a critical feature for everyone at all times, but it is definitely a feature that can improve security without too much inconvenience (if it's done right).

[ErebusBat]

etotheipi, I think you're trying to put the cart before the horse.  Yes, there are plenty potential use-cases for it, but very few of those use-cases are wanted/needed/used by anyone right now.  I don't hear any merchants clamoring to have customers sign their physical address information with their payment address - for the merchants, it is plenty good enough to just have the user fill out their address information into a normal HTML form at the time of purchase (and really, why wouldn't that be good enough?).

I disagree with this...

It is a chicken and egg problem.  If it were there then people would use it, organically.

You can see much the same problem with the iPad:  there were no crys of "GIVE US TABLETS"  but Apple came along and sparked a whole ecosystem.  Try to take away someones tablet now (even if it is an android) and chances are they will raise a huge storm.

[dree12]

etotheipi, I think you're trying to put the cart before the horse.  Yes, there are plenty potential use-cases for it, but very few of those use-cases are wanted/needed/used by anyone right now.  I don't hear any merchants clamoring to have customers sign their physical address information with their payment address - for the merchants, it is plenty good enough to just have the user fill out their address information into a normal HTML form at the time of purchase (and really, why wouldn't that be good enough?).

I disagree with this...

It is a chicken and egg problem.  If it were there then people would use it, organically.

You can see much the same problem with the iPad:  there were no crys of "GIVE US TABLETS"  but Apple came along and sparked a whole ecosystem.  Try to take away someones tablet now (even if it is an android) and chances are they will raise a huge storm.

+1.

I support both first-class by default (this is less confusing to the average user than the arcane "Receive coins" screen), and the inclusion of Armory-style signature blocks.

[ErebusBat]

I support both first-class by default (this is less confusing to the average user than the arcane "Receive coins" screen), and the inclusion of Armory-style signature blocks.

Agreed.. I think for any serious future use that we need some sort of signature block format.