Author Topic: Secure Payments to Users by Name  (Read 11139 times)

0 Members and 1 Guest are viewing this topic.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
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):
Quote
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.

Quote
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 )

Quote
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?
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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?
« Last Edit: June 01, 2014, 03:50:55 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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?
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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?
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

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

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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?
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

clout

  • Guest
I think it should be Transfer Invisibly To Any Name

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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.
« Last Edit: May 27, 2014, 06:30:55 am by xeroc »

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

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Titanshares

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk


Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
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 :)

█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline jae208

  • Hero Member
  • *****
  • Posts: 525
    • View Profile
We should also have something called 'Darkshares'  8)
Maybe people are attracted to the Dark...
http://bitsharestutorials.com A work in progress
Subscribe to the Youtube Channel
https://www.youtube.com/user/BitsharesTutorials

Offline yellowecho

 +5% this sounds so rad!   8)
696c6f766562726f776e696573

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile

I suggested:

Transfer Invisibly to A Name  => TITAN

Other names are welcome.


That's a really great name, isn't it? I really like TITAN

█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline bytemaster



Stealth addresses is one thing... eliminating the use of 'addresses' is the real feature... ie: send to a name. 

Does Darkcoin have an internal name system?
[/quote]

Has the Keyhotte id changed in the scheme of things?  It would be strange to have a ID for bitshares x and a ID for Keyhotte?
[/quote]

Yes... keyhotee will now use name@xts to address individuals, DACs are like companies, you can get 'email addresses' at every company. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Bitcoinfan

  • Sr. Member
  • ****
  • Posts: 240
    • View Profile

[/quote]

Stealth addresses is one thing... eliminating the use of 'addresses' is the real feature... ie: send to a name. 

Does Darkcoin have an internal name system?
[/quote]

Has the Keyhotte id changed in the scheme of things?  It would be strange to have a ID for bitshares x and a ID for Keyhotte?

Offline jae208

  • Hero Member
  • *****
  • Posts: 525
    • View Profile
PLUS Bitshares is a/will be a decentralized exchange ie: Bitcoin 2.0

As for Darkcoin... its just a coin  8)
http://bitsharestutorials.com A work in progress
Subscribe to the Youtube Channel
https://www.youtube.com/user/BitsharesTutorials

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Offline bytemaster

Hey guys I think actually this already existed and it's called "stealth addresses"....
All we did is add name->key mapping on top =(

haha nooooooo! a bit tragic for sure, but TITAN/SATAN still sound awesome even if another implementation of stealth addresses already exists... and personally im happy to hear that this innovation is in development for the bitshares ecosystem

Stealth addresses is one thing... eliminating the use of 'addresses' is the real feature... ie: send to a name. 

Does Darkcoin have an internal name system?
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline solaaire

  • Full Member
  • ***
  • Posts: 177
  • praise the sun!
    • View Profile
Hey guys I think actually this already existed and it's called "stealth addresses"....
All we did is add name->key mapping on top =(

haha nooooooo! a bit tragic for sure, but TITAN/SATAN still sound awesome even if another implementation of stealth addresses already exists... and personally im happy to hear that this innovation is in development for the bitshares ecosystem 

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
And Darkcoin actually does already do this
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Hey guys I think actually this already existed and it's called "stealth addresses"....
All we did is add name->key mapping on top =(

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline jae208

  • Hero Member
  • *****
  • Posts: 525
    • View Profile
I think it is good that other members of other communities 'steal' our ideas and implement them. That way they can take the risk and we can learn if the idea actually works on them. What happens when they steal our ideas and implement them is that we are 'delegating' risk.  8)

I like SATAN MAUAHAHAHA  :D
http://bitsharestutorials.com A work in progress
Subscribe to the Youtube Channel
https://www.youtube.com/user/BitsharesTutorials

Offline mf-tzo

  • Hero Member
  • *****
  • Posts: 1725
    • View Profile
These developments are amazing. I am not a tech guy and I don't understand much of what you guys are talking about most of the time but there are a lot of people from other communities that do understand steal your ideas, come up with a better marketing and boom!!

My point is to bytemaster. You should already know by now who are the tech guys in here that can support you and give you valuable advice for your ideas. I don't understand why you should communicate your ideas to everyone else? It is of course always good for the rest of us to see that you guys have great ideas (I mean seeing that now I want to invest more money that I do not have) but isn't that dangerous?

A suggestion could be for example, some sensitive information and ideas that you have are not posted for the viewing of everyone but only for members of this forums above a specific status?

Maybe all these are not so important and I am being paranoid so if that is the case just ignore me...



Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I am so flashed of recent upgrates!!! +5%

Offline bytemaster

For added security on the users public keys (ie: to avoid any potential of information leak from using the same key for every single operation... the check signature could use   SCOTTS_EXT_PUBLIC_KEY.child(SECRET) rather than SCOTT_EXT_PUBLIC_KEY directly.     Not sure if this extra indirection has any meaningful security enhancements or not. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
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.

Man, you must do that more frequently  ;)

Offline bytemaster

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):
Quote
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.

Quote
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 )

Quote
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)

There are only two people in the world who can generate the CHECK_SECRET (dan and scott), because the signature isn't required to verify funds transfer and is only used to prevent 'spoof payments' the SHORT_HASH(CHECK_SECRET) could reduce the signature down to 8 bytes rather than using the 65 bytes required for a normal ECC compact signature. 

Total additional size to send an anonymous payment from a certified address:
33 OneTimePublicKey
4   from id
8   from check
20  [optional fixed size memo]

65 bytes, equal to a single normal signature.   The fixed size memo is there to provide a description.  It must be fixed size to prevent analysis by size.   The memo is 20 bytes so that the entire size of the encrypted data is 32 bytes which is a multiple of the AES block size.  So the encrypted info block is either 16, 32 or 48 bytes long. 

I could probably avoid AES encryption all together and simply XOR data with SHA512(SECRET) as a means of encrypting/decrypting.

I am looking for ideas on what to name this Scheme.... so far Toast has proposed

Send Anonymously To A Name => SATAN

I suggested:

Transfer Invisibly to A Name  => TITAN

Other names are welcome.
« Last Edit: May 25, 2014, 01:31:01 pm by bytemaster »
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
absolute genius
we nees to proberly market this feature in the next newsletter!!!!!!!

+ 5

Sent from my ALCATEL ONE TOUCH 997D using Tapatalk


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
absolute genius
we nees to proberly market this feature in the next newsletter!!!!!!!

clout

  • Guest

Offline bytemaster

Quote
Only the receiver has the private key and only the sender & receiver know SECRET and thus the transactions are entirely unlink able.

To be clear, the transaction in/out is still inked, just the addresses are not linked to names even though the user sees it as "send X to Name" (only sender and receiver have info to connect the address to the name).

More than that if you send 3 payments to the same name no one can tell the payments are linked.  This means that if you have three unspent outputs in your wallet, you can send 3 separate transactions to that name and no one will be able to tell that the funds moved.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Quote
Only the receiver has the private key and only the sender & receiver know SECRET and thus the transactions are entirely unlink able.

To be clear, the transaction in/out is still inked, just the addresses are not linked to names even though the user sees it as "send X to Name" (only sender and receiver have info to connect the address to the name).
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline bytemaster

I was talking with Toast in the car on the way to Subway for lunch and came up with an entirely secure, single-transaction, mode of operation.  It is so incredibly simple I could not believe I didn't think of it from the beginning.

Every name can register a single extended public key that allows people to derive public keys from it.  Extended public keys are twice the size of normal public keys.   

Given an extended public key + index  you can generate a child public key.    If I have the extended private key + index then I can generate the corresponding child private key. 

So we can use the same process as above.

TEMP_PRIVATE_KEY * EXTENDED_PUBLIC_KEY => SECRET
EXTENDED_PUBLIC_KEY.child( SECRET ) =>  RECEIVER_PUBLIC_KEY => RECEIVER_ADDRESS

You then broadcast a transaction that includes TEMP_PUBLIC_KEY + RECEIVER_ADDRESS
The receiver then does the following:

TEMP_PUBLIC_KEY * EXTENDED_PRIVATE_KEY => SECRET
EXTENDED_PRIVATE_KEY.child( SECRET ) => RECEIVER_PRIVATE_KEY => RECEIVER_PUBLIC_KEY => RECIEVER_ADDRESS

Only the receiver has the private key and only the sender & receiver know SECRET and thus the transactions are entirely unlink able.

This process would only expand the transaction size by 33 bytes and allow people to transact entirely by name with automatic unique addresses for every transaction. 


For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
Given we have a name system in the blockchain that allows you to know the public key of user A.   We can use DH ECC to generate a unique receiving address for user A as so.

Create TempPrivateKey   TEMP.PRIVATE_KEY
TEMP.PRIVATE_KEY * USER.PUBLIC_KEY => SECRET  => ONE_TIME_PRIVATE_KEY => ONE_TIME_ADDRESS

Send a transaction that pays to ONE_TIME_ADDRESS and attaches TEMP.PUBLIC_KEY

Every client on the network will be able to perform the following operation:

USER.PRIVATE_KEY * TEMP.PUBLIC_KEY => SECRET => ONE_TIME_PRIVATE_KEY

If ONE_TIME_PRIVATE_KEY is the one that controls ONE_TIME_ADDRESS  then user will immediately spend the funds from ONE_TIME_ADDRESS to NEW_ADDRESS because the sender retains the ability to cancel the transaction. 


The plus side of this is:
  a) no need to exchange addresses
  b) ability to encode a message and 'from' data into the transaction
  c) the receiver is anonymous to everyone but the sender
  d) potential to cancel/retract a transfer if it is not accepted in a timely manner.
  e) simplifies accounting in the wallet
  f) generates higher fees and dividends

The downside to this:
  a) Uses more space in the blockchain
  b) Requires two transactions
  c) Results in higher fees


Discuss...

 +5%

If it is secure then it's excellent. If this feature exists make sure it has good marketing behind it so it's not a hidden feature like with some of Bitcoin's features.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
The plus side of this is:
  a) no need to exchange addresses
  b) ability to encode a message and 'from' data into the transaction
  c) the receiver is anonymous to everyone but the sender
  d) potential to cancel/retract a transfer if it is not accepted in a timely manner.
  e) simplifies accounting in the wallet
this is so cool ..

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
As i get it this is basically the idea of bitcoins stealth addreses with usernames ... very cool

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
ECDSA is literally magic. There should be a "programming pearls" just for ECDSA algebra.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline bytemaster

Given we have a name system in the blockchain that allows you to know the public key of user A.   We can use DH ECC to generate a unique receiving address for user A as so.

Create TempPrivateKey   TEMP.PRIVATE_KEY
TEMP.PRIVATE_KEY * USER.PUBLIC_KEY => SECRET  => ONE_TIME_PRIVATE_KEY => ONE_TIME_ADDRESS

Send a transaction that pays to ONE_TIME_ADDRESS and attaches TEMP.PUBLIC_KEY

Every client on the network will be able to perform the following operation:

USER.PRIVATE_KEY * TEMP.PUBLIC_KEY => SECRET => ONE_TIME_PRIVATE_KEY

If ONE_TIME_PRIVATE_KEY is the one that controls ONE_TIME_ADDRESS  then user will immediately spend the funds from ONE_TIME_ADDRESS to NEW_ADDRESS because the sender retains the ability to cancel the transaction. 


The plus side of this is:
  a) no need to exchange addresses
  b) ability to encode a message and 'from' data into the transaction
  c) the receiver is anonymous to everyone but the sender
  d) potential to cancel/retract a transfer if it is not accepted in a timely manner.
  e) simplifies accounting in the wallet
  f) generates higher fees and dividends

The downside to this:
  a) Uses more space in the blockchain
  b) Requires two transactions
  c) Results in higher fees


Discuss...

Single Transaction Variation

Given an extended public key + index  you can generate a child public key.    If I have the extended private key + index then I can generate the corresponding child private key. 

So we can use the same process as above.

TEMP_PRIVATE_KEY * EXTENDED_PUBLIC_KEY => SECRET
EXTENDED_PUBLIC_KEY.child( SECRET ) =>  RECEIVER_PUBLIC_KEY => RECEIVER_ADDRESS

You then broadcast a transaction that includes TEMP_PUBLIC_KEY + RECEIVER_ADDRESS
The receiver then does the following:

TEMP_PUBLIC_KEY * EXTENDED_PRIVATE_KEY => SECRET
EXTENDED_PRIVATE_KEY.child( SECRET ) => RECEIVER_PRIVATE_KEY => RECEIVER_PUBLIC_KEY => RECIEVER_ADDRESS

Only the receiver has the private key and only the sender & receiver know SECRET and thus the transactions are entirely unlink able.

This process would only expand the transaction size by 33 bytes and allow people to transact entirely by name with automatic unique addresses for every transaction. 

This is a variation on: http://www.coindesk.com/stealth-addresses-secret-bitcoin-privacy   that leverages the name system to solve the first part of the problem.
« Last Edit: May 25, 2014, 06:14:51 pm by bytemaster »
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.