Poll: Do you use first-class messaging?

[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

[1713998841]

1713998841

[1713998841]

1713998841

[1713998841]

1713998841

[1713998841]

1713998841

[1713998841]

1713998841

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