Topic: Hiding the recipient and amount until the money is spent (Read 8370 times)

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.

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

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

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.

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.


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.

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

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.

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

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

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.

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

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

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