Secure Payments to Users by Name

[BTSdac]

While laying in bed this morning I had a flash of insight on how to significantly reduce the size of the signatures that prove who a payment is from.

Given Public Information (in blockchain):

dan => DANS_EXT_PUBLIC_KEY
scott => SCOTTS_EXT_PUBLIC_KEY

Assuming scott wants to send dan a payment anonymously, yet wants dan to know it is from him.

scott:  Generate OneTimePrivateKey  & OneTimePublicKey Pair
scott:  OneTimePrivateKey * DANS_EXT_PUBLIC_KEY => SECRET
                                        DANS_EXT_PUBLIC_KEY.child( SECRET ) => RECEIVE_PUBLIC_KEY => RECEIVE_ADDRESS
scott:  RECEIVE_PUBLIC_KEY * SCOTTS_EXT_PRIVATE_KEY => CHECK_SECRET
                                                                                    => SHORT_HASH(CHECK_SECRET) == SHORT_SIGNATURE

scott-broadcast:   OneTimePublicKey + RECEIVE_ADDRESS + ENCRYPT( from scott + SHORT_SIGNATURE, SECRET )

dan:   OneTimePublicKey * DANS_EXT_PRIVATE_KEY => SECRET
                                      DANS_EXT_PRIVATE_KEY.child( SECRET ) =>
                                                                RECEIVE_PRIVATE_KEY =>
                                                                  RECEIVE_PUBLIC_KEY => RECEIVE_ADDRESS

dan:   DECRYPT( data, SECRET ) => "from scott" + SHORT_SIGNATURE )
dan:   SCOTT_EXT_PUBLIC_KEY * RECEIVE_PRIVATE_KEY => CHECK_SECRET => SHORT_HASH(CHECK_SECRET)

HI  BM , I know you are busy recently , if you have spare , can you explain why use EXT_PRIVATE_KEY.child( SECRET ) rather than  EXT_PRIVATE_KEY(SECRET)  , 
generate many child key is the reason of  low inefficiency?

[HackFisher]

How will you do to implement the notification feature, if you are a developer of blockchain.info?
Is receiving notification possible without ext_private_key?

No extended private keys. 

Notification feature is challenging unless you want to trust someone with read-only access to your funds.

You effectively encrypt with two keys, a read key and a spend key, both of which can be derived from your public key. 

The sending client would have to facilitate the observer.

Sending client and receiving client are decoupled, which means that the sending client do not know whether or not the receive side need such read key(e.g. for notification), when generating the transfer transaction.

My understanding is that there are only two options, in the protocol or not. If it is not in the protocol, then it will be very difficult to support such feature in the network.

By the way, are the read key or spend key the fields user provided in the name account for the sending client to use? So you mean the receiver will tell the sender whether or not facilitate the read observer according to account settings?

[HackFisher]

Does user have to register a new name before other transfer some bts to him? What if that user do not have any balance to pay the name register fee?

You can have an account that isn't registered. You share your public key and they create a sending account with that key.

The "sending account" from sending client is not registered too, which might means TITAN wallet still have to manage local accounts.
I'm wondering whether or not we could simplify it by allowing sending/receiving bts with just key?

[toast]

Does user have to register a new name before other transfer some bts to him? What if that user do not have any balance to pay the name register fee?

You can have an account that isn't registered. You share your public key and they create a sending account with that key.

[HackFisher]

Does user have to register a new name before other transfer some bts to him? What if that user do not have any balance to pay the name register fee?

[bytemaster]

How will you do to implement the notification feature, if you are a developer of blockchain.info?
Is receiving notification possible without ext_private_key?

No extended private keys. 

Notification feature is challenging unless you want to trust someone with read-only access to your funds.

You effectively encrypt with two keys, a read key and a spend key, both of which can be derived from your public key. 

The sending client would have to facilitate the observer.

[HackFisher]

How will you do to implement the notification feature, if you are a developer of blockchain.info?
Is receiving notification possible without ext_private_key?

[xeroc]

x-post to btt: https://bitcointalk.org/index.php?topic=631287.msg7032706#msg7032706

[clout]

I think it should be Transfer Invisibly To Any Name

[xeroc]

I wrote together a few lines of this thread:
http://pad.bitshares.org/p/Upcoming_Newsletter_articles

Please proof-read and add anything useful for possible readers of a newsletter.

[JoeyD]

We should also have something called 'Darkshares'  8)
Maybe people are attracted to the Dark...

yes people are attracted maybe .. but i'm not a friend of this kind of shady names

TITAN sounds epic :)

I agree, I also like the implied connotation of attempting to challenge the gods instead of the hiding in the shadows one when using the dark-adjective. Dark and black are mostly used for things people know nothing about or are uncertain of, so to me it sounds more like a label of weakness or incompetence.

[liondani]

Titanshares

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk

[cass]

We should also have something called 'Darkshares'  8)
Maybe people are attracted to the Dark...

yes people are attracted maybe .. but i'm not a friend of this kind of shady names

TITAN sounds epic :)

[jae208]

We should also have something called 'Darkshares'  8)
Maybe people are attracted to the Dark...

[yellowecho]

 +5% this sounds so rad!   8)