Bitcoin Forum
December 07, 2016, 12:52:16 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Hiding the recipient and amount until the money is spent  (Read 1776 times)
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 15, 2010, 09:53:18 AM
 #1

We can change transactions so that nobody can tell who the recipient is and how much until the recipient spends the money.

At the moment the beneficiary of a transaction is a certain bitcoin address. If that address has ever received coins before then everyone knows that the money is in the same place. Alternatively, that address has been publicized as a receiving address so you know exactly where the money is going.

Instead you specify that the recipient of the money is the address that can decrypt a certain message that you have signed. So your transaction would comprise a load of signed TxIns and a signed public key encrypted message saying how much of the BitCoins goes to the person able to decrypt the message. All the network nodes try to decrypt the message with each of their public keys. The one who succeeds knows that they have received the money and updates their displayed balance accordingly. When the recipient decides to spend the money their transaction includes  the decrypted message. Only when the other network nodes see this do they know who the recipient was and how much the transaction was worth. Any change is ascribed to the signing key and the decrypted message and original are cited when the change is spent in subsequent transactions. Obviously this ties up the sender's change until the recipient spends so you'd need to be a bit careful.

I don't know whether this could be implemented in the current system through adroit use of the scripting language.

ByteCoin
1481115136
Hero Member
*
Offline Offline

Posts: 1481115136

View Profile Personal Message (Offline)

Ignore
1481115136
Reply with quote  #2

1481115136
Report to moderator
1481115136
Hero Member
*
Offline Offline

Posts: 1481115136

View Profile Personal Message (Offline)

Ignore
1481115136
Reply with quote  #2

1481115136
Report to moderator
1481115136
Hero Member
*
Offline Offline

Posts: 1481115136

View Profile Personal Message (Offline)

Ignore
1481115136
Reply with quote  #2

1481115136
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481115136
Hero Member
*
Offline Offline

Posts: 1481115136

View Profile Personal Message (Offline)

Ignore
1481115136
Reply with quote  #2

1481115136
Report to moderator
1481115136
Hero Member
*
Offline Offline

Posts: 1481115136

View Profile Personal Message (Offline)

Ignore
1481115136
Reply with quote  #2

1481115136
Report to moderator
caveden
Legendary
*
Offline Offline

Activity: 1106



View Profile
August 15, 2010, 10:00:37 AM
 #2

I don't see how can the receipt verify whether it is a double-spent or not.

If the same coins were spent in another encrypted transaction, to another address, none of these different receipts would be able to know that another one has also received it.

Maybe I didn't understand very well your idea...

18rZYyWcafwD86xvLrfuxWG5xEMMWUtVkL
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 15, 2010, 11:31:49 PM
 #3

The signed TxIns are not encrypted. The network checks that they haven't been spent before and then marks them as spent. The "in" portion of the payment works exactly as normal.

ByteCoin
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
August 16, 2010, 07:24:42 AM
 #4

This offers the same anonymity as using a new address each time? And you would still want to use a new address each time if you care because eventually you will be revealing yourself.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 16, 2010, 01:49:00 PM
 #5

This offers the same anonymity as using a new address each time? And you would still want to use a new address each time if you care because eventually you will be revealing yourself.
Using a new address each time offers superior privacy for the reason you mentioned.

However, some people publish a constant Bitcoin receiving address for various reasons. One example is the Bitcoin faucet https://freebitcoins.appspot.com/. Another is RHorning, theymos, sirius-m, NewLibertyStandard and Bitcoiner's signatures.

One can imagine many scenarios where you can't guarantee that you can give everyone who wants to pay you a different address and my proposal helps in those instances.

ByteCoin
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 16, 2010, 02:10:41 PM
 #6

However, some people publish a constant Bitcoin receiving address for various reasons. One example is the Bitcoin faucet https://freebitcoins.appspot.com/. Another is RHorning, theymos, sirius-m, NewLibertyStandard and Bitcoiner's signatures.

One can imagine many scenarios where you can't guarantee that you can give everyone who wants to pay you a different address and my proposal helps in those instances.

If you're losing the benefit when you spend the coins anyway, it seems like a lot of work for hardly any gain.

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 16, 2010, 02:11:38 PM
 #7

RE: could you make through adroit use of the scripting language:  you could hide the receiving address, but not the amount.

Bitcoin needs to see TxOut amounts so it can add them up and make sure the transaction includes any necessary fees.

And to make sure the transaction is valid, although I suppose it could allow invalid-but-not-yet-decrypted transactions into the block chain, and just not allow them to be ever spent (it'd be a complicated way of deleting BTC).  But that makes me extremely nervous-- it seems to me it just makes things more complicated and more likely to be exploited.

Also, this: "All the network nodes try to decrypt the message with each of their public keys" ... won't scale.  Busy nodes will have more and more public keys over time (as they give out different receiving addresses for each purchase transaction), and trying them all whenever an encrypted transaction comes over the wire will take an ever-increasing amount of time.


How often do you get the chance to work on a potentially world-changing project?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 16, 2010, 04:20:48 PM
 #8

Bitcoin needs to see TxOut amounts so it can add them up and make sure the transaction includes any necessary fees.

A good observation. I'm not sure exactly what fees are levied but I observe that the majority of transactions do not incur any. Would it not be possible for Bitcoin to assess the fees to be zero while witholding the amount information.

it seems to me it just makes things more complicated and more likely to be exploited.

I suppose if the current integer overflow bug had been an encrypted transaction buried under several thousands of blocks then recovery would have been more troublesome.

Also, this: "All the network nodes try to decrypt the message with each of their public keys" ... won't scale.  Busy nodes will have more and more public keys over time (as they give out different receiving addresses for each purchase transaction), and trying them all whenever an encrypted transaction comes over the wire will take an ever-increasing amount of time.
They only need to bother checking them if they have reason to believe they are the beneficiary. If they don't want to bother then they don't have to and the system still works. The equivalent scaling problem you mention applies with regards to the network checking normal transactions as the useage ramps up.

If you're losing the benefit when you spend the coins anyway, it seems like a lot of work for hardly any gain.

If encrypted transactions were made the default then then it would be much more difficult to assess at any given point who currently holds bitcoins. As they are spent, information is revealed about who used to hold them but their current holder is again obscured. The value of knowing who currently holds the bitcoins is probably vastly more valuable than the value of knowing who recently held the bitcoins and so I think the encrypted transaction proposal is helpful.
The "it seems like a lot of work for hardly any gain" obsevation could be equally leveled at the current scheme of using a new bitcoin address for change transactions which has the added proven disadvantage of losing bitcoins when reverting to saved wallet files. Bitcoin seems to be reliant on the assumption that a lot of extra work is justified for any gains in anonymity and privacy.

Bytecoin
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 16, 2010, 08:30:27 PM
 #9

I just want to correct one little thing; excuse me for being nit-picky, I'll shut up after this:

Also, this: "All the network nodes try to decrypt the message with each of their public keys" ... won't scale.
... The equivalent scaling problem you mention applies with regards to the network checking normal transactions as the useage ramps up.
Assuming you have enough memory to store all your public keys in a hash table in memory, there is no scaling problem with normal transactions.  Since the TxOut contains the public key (well, the hash of the public key), it is constant time to figure out whether or not the TxOut is your public key.  You do NOT have to loop through all your public keys to see which one matches.

How often do you get the chance to work on a potentially world-changing project?
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 17, 2010, 03:01:14 AM
 #10

Assuming you have enough memory to store all your public keys in a hash table in memory, there is no scaling problem with normal transactions.  Since the TxOut contains the public key (well, the hash of the public key), it is constant time to figure out whether or not the TxOut is your public key.  You do NOT have to loop through all your public keys to see which one matches.

Ah, I'm sorry for not being more clear.

It's true that in the existing scheme it's easy to establish whether a transaction is yours using the method you outline above. However you have to verify the signatures of all the TxIns of all the transactions you receive before you accept them as valid even if they are not credits to any of your addresses. For a transaction with multiple TxIns the computation required to verify two or more signatures is easily more than decrypting a message. This signature verification is the scaling problem to which I am referring.

Please feel free not to shut up. I welcome all comments and I'm grateful for the opportunity to participate in this forum.

ByteCoin
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
August 17, 2010, 06:27:42 AM
 #11

For a transaction with multiple TxIns the computation required to verify two or more signatures is easily more than decrypting a message. This signature verification is the scaling problem to which I am referring.

It's not clear that two or more signature verifications are more than decrypting one message.

It's not clear that any conceivable number of transactions received would constitute a scaling problem.

Note many people running block generation now verify all the transaction input signatures on all received blocks and transactions. They still have plenty of time left to mine for more blocks at rates of millions of tries per second. The whole process continues even when the net is tossing transactions at them as fast as they can generate them. I don't think we know for sure where the first scaling bottlenecks will be but my bet is it won't be CPU time.


Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!