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

0 Members and 1 Guest are viewing this topic.

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.