Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

> Signed by the key pair that was referenced in the output of the on-chain
> transaction?

Signed by the key pair referenced in the private output.

>  (Bob in my example, actually)

I misread your example.  If it was Bob, then the troll couldn't
generate the correct spend proof because he didn't see the private
output C.  The troll could try to replay the spend proof in the
Alice's transaction as soon as he sees it in the mempool, but then the
spend proof would be signed by the wrong user.

> Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?

Only the recipients of the private outputs can see the previous owners
of the coins they receive (including amounts).  What everybody else
sees, is just meaningless hashes that hide both the recipient of the
coin and the amount.


2016-08-10 7:31 GMT+03:00 James MacWhyte :
> Signed by the key pair that was referenced in the output of the on-chain
> transaction? (Bob in my example, actually) Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?
>
> On Tue, Aug 9, 2016, 04:40 Tony Churyumoff  wrote:
>>
>> This troll is harmless.  A duplicate spend proof should also be signed
>> by the same user (Alice, in your example) to be considered a double
>> spend.
>>
>> 2016-08-09 3:18 GMT+03:00 James MacWhyte :
>> > One more thought about why verification by miners may be needed.
>> >
>> > Let's say Alice sends Bob a transaction, generating output C.
>> >
>> > A troll, named Timothy, broadcasts a transaction with a random hash,
>> > referencing C's output as its spend proof. The miners can't tell if it's
>> > valid or not, and so they include the transaction in a block. Now Bob's
>> > money is useless, because everyone can see the spend proof referenced
>> > and
>> > thinks it has already been spent, even though the transaction that
>> > claims it
>> > isn't valid.
>> >
>> > Did I miss something that protects against this?
>> >
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

Signed by the key pair that was referenced in the output of the on-chain
transaction? (Bob in my example, actually) Doesn't that mean it's easy to
follow who is paying whom, you just can't see how much is going to reach
recipient?

On Tue, Aug 9, 2016, 04:40 Tony Churyumoff  wrote:

> This troll is harmless.  A duplicate spend proof should also be signed
> by the same user (Alice, in your example) to be considered a double
> spend.
>
> 2016-08-09 3:18 GMT+03:00 James MacWhyte :
> > One more thought about why verification by miners may be needed.
> >
> > Let's say Alice sends Bob a transaction, generating output C.
> >
> > A troll, named Timothy, broadcasts a transaction with a random hash,
> > referencing C's output as its spend proof. The miners can't tell if it's
> > valid or not, and so they include the transaction in a block. Now Bob's
> > money is useless, because everyone can see the spend proof referenced and
> > thinks it has already been spent, even though the transaction that
> claims it
> > isn't valid.
> >
> > Did I miss something that protects against this?
> >
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Henning Kopp via bitcoin-dev]

Hi Tony,

> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?

I am not entirely sure if this works. You wrote:

> There is one technical nuance that I omitted above to avoid distraction.
>  Unlike regular bitcoin transactions, every output in a private payment
> must also include a blinding factor, which is just a random string.  When
> the output is spent, the corresponding spend proof will therefore depend on
> this blinding factor (remember that spend proof is just a hash of the
> output).  Without a blinding factor, it would be feasible to pre-image the
> spend proof and reveal the output being spent as the search space of all
> possible outputs is rather small.

Instead of a hash function you may use a keyed hash function (HMAC) where
the key is just the random string. They key needs to be stored in the
history of the coin to allow for verification.

Best
Henning

On Mon, Aug 08, 2016 at 07:03:28PM +0300, Tony Churyumoff wrote:
> Hi Henning,
> 
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
> 
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
> 
> Tony
> 
> 
> 2016-08-08 18:47 GMT+03:00 Henning Kopp :
> 
> > Hi Tony,
> >
> > I see some issues in your protocol.
> >
> > 1. How are mining fees handled?
> >
> > 2. Assume Alice sends Bob some Coins together with their history and
> > Bob checks that the history is correct. How does the hash of the txout
> > find its way into the blockchain?
> >
> > Regarding the blinding factor, I think you could just use HMAC.
> >
> > All the best
> > Henning
> >
> >
> > On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> > wrote:
> > > This is a proposal about hiding the entire content of bitcoin
> > > transactions.  It goes farther than CoinJoin and ring signatures, which
> > > only obfuscate the transaction graph, and Confidential Transactions,
> > which
> > > only hide the amounts.
> > >
> > > The central idea of the proposed design is to hide the entire inputs and
> > > outputs, and publish only the hash of inputs and outputs in the
> > > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > > inputs and outputs is sent directly to the payee via a private message,
> > and
> > > never goes into the blockchain.  The payee then calculates the hash and
> > > looks it up in the blockchain to verify that the hash was indeed
> > published
> > > by the payer.
> > >
> > > Since the plaintext of the transaction is not published to the public
> > > blockchain, all validation work has to be done only by the user who
> > > receives the payment.
> > >
> > > To protect against double-spends, the payer also has to publish another
> > > hash, which is the hash of the output being spent.  We’ll call this hash
> > *spend
> > > proof*.  Since the spend proof depends solely on the output being spent,
> > > any attempt to spend the same output again will produce exactly the same
> > > spend proof, and the payee will be able to see that, and will reject the
> > > payment.  If there are several outputs consumed by the same transaction,
> > > the payer has to publish several spend proofs.
> > >
> > > To prove that the outputs being spent are valid, the payer also has to
> > send
> > > the plaintexts of the earlier transaction(s) that produced them, then the
> > > plaintexts of even earlier transactions that produced the outputs spent
> > in
> > > those transactions, and so on, up until the issue (similar to coinbase)
> > > transactions that created the initial private coins.  Each new owner of
> > the
> > > coin will have to store its entire history, and when he spends the coin,
> > he
> > > forwards the entire history to the next owner and extends it with his own
> > > transaction.
> > >
> > > If we apply the existing bitcoin design that allows multiple inputs and
> > > multiple outputs per transaction, the history of ownership transfers
> > would
> > > grow exponentially.  Indeed, if we take any regular bitcoin output and
> > try
> > > to track its history back to coinbase, our history will branch every time
> > > we see a transaction that has more than one input (which is not
> > uncommon).
> > > After such a transaction (remember, we are traveling back in time), we’ll
> > > have to track two or more histories, for each respective input.  Those
> > > histories will branch again, and the total number of history entries
> > grows
> > > exponentially.  For example, if every transaction had exactly two inputs,
> > > the size of history would grow as 2^N where N is the number of steps back
> > > in history.
> > >
> > > To avoid such rapid growth of ownership history (which is not only
> > > inconvenient to move, but also exposes too much private information about
> > > previous owners of all the contributing coins), we will require each
> > > private transaction to have exactly one input (i.e. to consume 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

The whole point is in preventing every third party, including miners, from
seeing the details of what is being spent and how.  The burden of
verification is shifted to the owners of the coin (which is fair).

In fact we could have miners recognize spend proofs and check that the same
spend proof is not entered into the blockchain more than once (which would
be a sign of double spend), but it is not required.  The coin owners can
already do that themselves.

2016-08-09 0:41 GMT+03:00 James MacWhyte :

> Wouldn't you lose the ability to assume transactions in the blockchain are
> verified as valid, since miners can't see the details of what is being
> spent and how? I feel like this ability is bitcoin's greatest asset, and by
> removing it you're creating an altcoin different enough to not be connected
> to/supported by the main bitcoin project.
>
> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Henning,
>>
>> 1. The fees are paid by the enclosing BTC transaction.
>> 2. The hash is encoded into an OP_RETURN.
>>
>> > Regarding the blinding factor, I think you could just use HMAC.
>> How exactly?
>>
>> Tony
>>
>>
>> 2016-08-08 18:47 GMT+03:00 Henning Kopp :
>>
>>> Hi Tony,
>>>
>>> I see some issues in your protocol.
>>>
>>> 1. How are mining fees handled?
>>>
>>> 2. Assume Alice sends Bob some Coins together with their history and
>>> Bob checks that the history is correct. How does the hash of the txout
>>> find its way into the blockchain?
>>>
>>> Regarding the blinding factor, I think you could just use HMAC.
>>>
>>> All the best
>>> Henning
>>>
>>>
>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
>>> bitcoin-dev wrote:
>>> > This is a proposal about hiding the entire content of bitcoin
>>> > transactions.  It goes farther than CoinJoin and ring signatures, which
>>> > only obfuscate the transaction graph, and Confidential Transactions,
>>> which
>>> > only hide the amounts.
>>> >
>>> > The central idea of the proposed design is to hide the entire inputs
>>> and
>>> > outputs, and publish only the hash of inputs and outputs in the
>>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>>> > inputs and outputs is sent directly to the payee via a private
>>> message, and
>>> > never goes into the blockchain.  The payee then calculates the hash and
>>> > looks it up in the blockchain to verify that the hash was indeed
>>> published
>>> > by the payer.
>>> >
>>> > Since the plaintext of the transaction is not published to the public
>>> > blockchain, all validation work has to be done only by the user who
>>> > receives the payment.
>>> >
>>> > To protect against double-spends, the payer also has to publish another
>>> > hash, which is the hash of the output being spent.  We’ll call this
>>> hash *spend
>>> > proof*.  Since the spend proof depends solely on the output being
>>> spent,
>>> > any attempt to spend the same output again will produce exactly the
>>> same
>>> > spend proof, and the payee will be able to see that, and will reject
>>> the
>>> > payment.  If there are several outputs consumed by the same
>>> transaction,
>>> > the payer has to publish several spend proofs.
>>> >
>>> > To prove that the outputs being spent are valid, the payer also has to
>>> send
>>> > the plaintexts of the earlier transaction(s) that produced them, then
>>> the
>>> > plaintexts of even earlier transactions that produced the outputs
>>> spent in
>>> > those transactions, and so on, up until the issue (similar to coinbase)
>>> > transactions that created the initial private coins.  Each new owner
>>> of the
>>> > coin will have to store its entire history, and when he spends the
>>> coin, he
>>> > forwards the entire history to the next owner and extends it with his
>>> own
>>> > transaction.
>>> >
>>> > If we apply the existing bitcoin design that allows multiple inputs and
>>> > multiple outputs per transaction, the history of ownership transfers
>>> would
>>> > grow exponentially.  Indeed, if we take any regular bitcoin output and
>>> try
>>> > to track its history back to coinbase, our history will branch every
>>> time
>>> > we see a transaction that has more than one input (which is not
>>> uncommon).
>>> > After such a transaction (remember, we are traveling back in time),
>>> we’ll
>>> > have to track two or more histories, for each respective input.  Those
>>> > histories will branch again, and the total number of history entries
>>> grows
>>> > exponentially.  For example, if every transaction had exactly two
>>> inputs,
>>> > the size of history would grow as 2^N where N is the number of steps
>>> back
>>> > in history.
>>> >
>>> > To avoid such rapid growth of ownership history (which is not only
>>> > inconvenient to move, but also exposes too much private information
>>> about
>>> > previous owners of all the contributing coins), we will require each
>>> 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

One more thought about why verification by miners may be needed.

Let's say Alice sends Bob a transaction, generating output C.

A troll, named Timothy, broadcasts a transaction with a random hash,
referencing C's output as its spend proof. The miners can't tell if it's
valid or not, and so they include the transaction in a block. Now Bob's
money is useless, because everyone can see the spend proof referenced and
thinks it has already been spent, even though the transaction that claims
it isn't valid.

Did I miss something that protects against this?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff  wrote:

> The whole point is in preventing every third party, including miners, from
> seeing the details of what is being spent and how.  The burden of
> verification is shifted to the owners of the coin (which is fair).
>
> In fact we could have miners recognize spend proofs and check that the
> same spend proof is not entered into the blockchain more than once (which
> would be a sign of double spend), but it is not required.  The coin owners
> can already do that themselves.
>
> 2016-08-09 0:41 GMT+03:00 James MacWhyte :
>
>> Wouldn't you lose the ability to assume transactions in the blockchain
>> are verified as valid, since miners can't see the details of what is being
>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>> removing it you're creating an altcoin different enough to not be connected
>> to/supported by the main bitcoin project.
>>
>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Henning,
>>>
>>> 1. The fees are paid by the enclosing BTC transaction.
>>> 2. The hash is encoded into an OP_RETURN.
>>>
>>> > Regarding the blinding factor, I think you could just use HMAC.
>>> How exactly?
>>>
>>> Tony
>>>
>>>
>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp :
>>>
 Hi Tony,

 I see some issues in your protocol.

 1. How are mining fees handled?

 2. Assume Alice sends Bob some Coins together with their history and
 Bob checks that the history is correct. How does the hash of the txout
 find its way into the blockchain?

 Regarding the blinding factor, I think you could just use HMAC.

 All the best
 Henning


 On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
 bitcoin-dev wrote:
 > This is a proposal about hiding the entire content of bitcoin
 > transactions.  It goes farther than CoinJoin and ring signatures,
 which
 > only obfuscate the transaction graph, and Confidential Transactions,
 which
 > only hide the amounts.
 >
 > The central idea of the proposed design is to hide the entire inputs
 and
 > outputs, and publish only the hash of inputs and outputs in the
 > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
 > inputs and outputs is sent directly to the payee via a private
 message, and
 > never goes into the blockchain.  The payee then calculates the hash
 and
 > looks it up in the blockchain to verify that the hash was indeed
 published
 > by the payer.
 >
 > Since the plaintext of the transaction is not published to the public
 > blockchain, all validation work has to be done only by the user who
 > receives the payment.
 >
 > To protect against double-spends, the payer also has to publish
 another
 > hash, which is the hash of the output being spent.  We’ll call this
 hash *spend
 > proof*.  Since the spend proof depends solely on the output being
 spent,
 > any attempt to spend the same output again will produce exactly the
 same
 > spend proof, and the payee will be able to see that, and will reject
 the
 > payment.  If there are several outputs consumed by the same
 transaction,
 > the payer has to publish several spend proofs.
 >
 > To prove that the outputs being spent are valid, the payer also has
 to send
 > the plaintexts of the earlier transaction(s) that produced them, then
 the
 > plaintexts of even earlier transactions that produced the outputs
 spent in
 > those transactions, and so on, up until the issue (similar to
 coinbase)
 > transactions that created the initial private coins.  Each new owner
 of the
 > coin will have to store its entire history, and when he spends the
 coin, he
 > forwards the entire history to the next owner and extends it with his
 own
 > transaction.
 >
 > If we apply the existing bitcoin design that allows multiple inputs
 and
 > multiple outputs per transaction, the history of ownership transfers
 would
 > grow exponentially.  Indeed, if we take any regular bitcoin output
 and try
 > to track its history back to coinbase, our history will branch 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

That is a good point. As you said, it puts a lot more burden on the coin
holders. One big downside would be data management. Instead of simply
backing up a single HD private key, the user would have to back up entire
histories of every output that has been sent to them if they want to secure
their funds.

It also requires them to be online to receive payments, and I think finding
a method of sending the private message containing the coin's history is
going to be a bit of a challenge. If you connect directly to the recipient
to convey the information through traditional channels, anonymity is lost.
Sending messages through the bitcoin network is one option to protect
anonymity, but without active pathfinding there's no guarantee the payee
will even get the message. I'm assuming you'd have to essentially replace
tx messages with encrypted BBC histories, and mempools are quite full as it
is.

Tony, do you have any more thoughts on exactly how users would convey the
private messages to payees?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff  wrote:

> The whole point is in preventing every third party, including miners, from
> seeing the details of what is being spent and how.  The burden of
> verification is shifted to the owners of the coin (which is fair).
>
> In fact we could have miners recognize spend proofs and check that the
> same spend proof is not entered into the blockchain more than once (which
> would be a sign of double spend), but it is not required.  The coin owners
> can already do that themselves.
>
> 2016-08-09 0:41 GMT+03:00 James MacWhyte :
>
>> Wouldn't you lose the ability to assume transactions in the blockchain
>> are verified as valid, since miners can't see the details of what is being
>> spent and how? I feel like this ability is bitcoin's greatest asset, and by
>> removing it you're creating an altcoin different enough to not be connected
>> to/supported by the main bitcoin project.
>>
>> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Henning,
>>>
>>> 1. The fees are paid by the enclosing BTC transaction.
>>> 2. The hash is encoded into an OP_RETURN.
>>>
>>> > Regarding the blinding factor, I think you could just use HMAC.
>>> How exactly?
>>>
>>> Tony
>>>
>>>
>>> 2016-08-08 18:47 GMT+03:00 Henning Kopp :
>>>
 Hi Tony,

 I see some issues in your protocol.

 1. How are mining fees handled?

 2. Assume Alice sends Bob some Coins together with their history and
 Bob checks that the history is correct. How does the hash of the txout
 find its way into the blockchain?

 Regarding the blinding factor, I think you could just use HMAC.

 All the best
 Henning


 On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via
 bitcoin-dev wrote:
 > This is a proposal about hiding the entire content of bitcoin
 > transactions.  It goes farther than CoinJoin and ring signatures,
 which
 > only obfuscate the transaction graph, and Confidential Transactions,
 which
 > only hide the amounts.
 >
 > The central idea of the proposed design is to hide the entire inputs
 and
 > outputs, and publish only the hash of inputs and outputs in the
 > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
 > inputs and outputs is sent directly to the payee via a private
 message, and
 > never goes into the blockchain.  The payee then calculates the hash
 and
 > looks it up in the blockchain to verify that the hash was indeed
 published
 > by the payer.
 >
 > Since the plaintext of the transaction is not published to the public
 > blockchain, all validation work has to be done only by the user who
 > receives the payment.
 >
 > To protect against double-spends, the payer also has to publish
 another
 > hash, which is the hash of the output being spent.  We’ll call this
 hash *spend
 > proof*.  Since the spend proof depends solely on the output being
 spent,
 > any attempt to spend the same output again will produce exactly the
 same
 > spend proof, and the payee will be able to see that, and will reject
 the
 > payment.  If there are several outputs consumed by the same
 transaction,
 > the payer has to publish several spend proofs.
 >
 > To prove that the outputs being spent are valid, the payer also has
 to send
 > the plaintexts of the earlier transaction(s) that produced them, then
 the
 > plaintexts of even earlier transactions that produced the outputs
 spent in
 > those transactions, and so on, up until the issue (similar to
 coinbase)
 > transactions that created the initial private coins.  Each new owner
 of the
 > coin will have to store its entire history, and when he spends the
 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Peter Todd via bitcoin-dev]

On Mon, Aug 08, 2016 at 09:41:27PM +, James MacWhyte via bitcoin-dev wrote:
> Wouldn't you lose the ability to assume transactions in the blockchain are
> verified as valid, since miners can't see the details of what is being
> spent and how? I feel like this ability is bitcoin's greatest asset, and by
> removing it you're creating an altcoin different enough to not be connected
> to/supported by the main bitcoin project.

The fact that miners verify transactions is just an optimisation:

https://petertodd.org/2013/disentangling-crypto-coin-mining

Preventing double-spending however is a fundemental requirement of Bitcoin, and
this proposal does prevent double-spending perfectly well (although there may
be better ways to do it).

The OP's proposal sounds quite similar to my earlier one along similar lines:

https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[James MacWhyte via bitcoin-dev]

Wouldn't you lose the ability to assume transactions in the blockchain are
verified as valid, since miners can't see the details of what is being
spent and how? I feel like this ability is bitcoin's greatest asset, and by
removing it you're creating an altcoin different enough to not be connected
to/supported by the main bitcoin project.

On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Henning,
>
> 1. The fees are paid by the enclosing BTC transaction.
> 2. The hash is encoded into an OP_RETURN.
>
> > Regarding the blinding factor, I think you could just use HMAC.
> How exactly?
>
> Tony
>
>
> 2016-08-08 18:47 GMT+03:00 Henning Kopp :
>
>> Hi Tony,
>>
>> I see some issues in your protocol.
>>
>> 1. How are mining fees handled?
>>
>> 2. Assume Alice sends Bob some Coins together with their history and
>> Bob checks that the history is correct. How does the hash of the txout
>> find its way into the blockchain?
>>
>> Regarding the blinding factor, I think you could just use HMAC.
>>
>> All the best
>> Henning
>>
>>
>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
>> wrote:
>> > This is a proposal about hiding the entire content of bitcoin
>> > transactions.  It goes farther than CoinJoin and ring signatures, which
>> > only obfuscate the transaction graph, and Confidential Transactions,
>> which
>> > only hide the amounts.
>> >
>> > The central idea of the proposed design is to hide the entire inputs and
>> > outputs, and publish only the hash of inputs and outputs in the
>> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
>> > inputs and outputs is sent directly to the payee via a private message,
>> and
>> > never goes into the blockchain.  The payee then calculates the hash and
>> > looks it up in the blockchain to verify that the hash was indeed
>> published
>> > by the payer.
>> >
>> > Since the plaintext of the transaction is not published to the public
>> > blockchain, all validation work has to be done only by the user who
>> > receives the payment.
>> >
>> > To protect against double-spends, the payer also has to publish another
>> > hash, which is the hash of the output being spent.  We’ll call this
>> hash *spend
>> > proof*.  Since the spend proof depends solely on the output being spent,
>> > any attempt to spend the same output again will produce exactly the same
>> > spend proof, and the payee will be able to see that, and will reject the
>> > payment.  If there are several outputs consumed by the same transaction,
>> > the payer has to publish several spend proofs.
>> >
>> > To prove that the outputs being spent are valid, the payer also has to
>> send
>> > the plaintexts of the earlier transaction(s) that produced them, then
>> the
>> > plaintexts of even earlier transactions that produced the outputs spent
>> in
>> > those transactions, and so on, up until the issue (similar to coinbase)
>> > transactions that created the initial private coins.  Each new owner of
>> the
>> > coin will have to store its entire history, and when he spends the
>> coin, he
>> > forwards the entire history to the next owner and extends it with his
>> own
>> > transaction.
>> >
>> > If we apply the existing bitcoin design that allows multiple inputs and
>> > multiple outputs per transaction, the history of ownership transfers
>> would
>> > grow exponentially.  Indeed, if we take any regular bitcoin output and
>> try
>> > to track its history back to coinbase, our history will branch every
>> time
>> > we see a transaction that has more than one input (which is not
>> uncommon).
>> > After such a transaction (remember, we are traveling back in time),
>> we’ll
>> > have to track two or more histories, for each respective input.  Those
>> > histories will branch again, and the total number of history entries
>> grows
>> > exponentially.  For example, if every transaction had exactly two
>> inputs,
>> > the size of history would grow as 2^N where N is the number of steps
>> back
>> > in history.
>> >
>> > To avoid such rapid growth of ownership history (which is not only
>> > inconvenient to move, but also exposes too much private information
>> about
>> > previous owners of all the contributing coins), we will require each
>> > private transaction to have exactly one input (i.e. to consume exactly
>> one
>> > previous output).  This means that when we track a coin’s history back
>> in
>> > time, it will no longer branch.  It will grow linearly with the number
>> of
>> > transfers of ownership.  If a user wants to combine several inputs, he
>> will
>> > have to send them as separate private transactions (technically, several
>> > OP_RETURNs, which can be included in a single regular bitcoin
>> transaction).
>> >
>> > Thus, we are now forbidding any coin merges but still allowing coin
>> > splits.  To avoid ultimate splitting into the dust, we will also require
>> > that all 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

Hi Henning,

1. The fees are paid by the enclosing BTC transaction.
2. The hash is encoded into an OP_RETURN.

> Regarding the blinding factor, I think you could just use HMAC.
How exactly?

Tony


2016-08-08 18:47 GMT+03:00 Henning Kopp :

> Hi Tony,
>
> I see some issues in your protocol.
>
> 1. How are mining fees handled?
>
> 2. Assume Alice sends Bob some Coins together with their history and
> Bob checks that the history is correct. How does the hash of the txout
> find its way into the blockchain?
>
> Regarding the blinding factor, I think you could just use HMAC.
>
> All the best
> Henning
>
>
> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev
> wrote:
> > This is a proposal about hiding the entire content of bitcoin
> > transactions.  It goes farther than CoinJoin and ring signatures, which
> > only obfuscate the transaction graph, and Confidential Transactions,
> which
> > only hide the amounts.
> >
> > The central idea of the proposed design is to hide the entire inputs and
> > outputs, and publish only the hash of inputs and outputs in the
> > blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> > inputs and outputs is sent directly to the payee via a private message,
> and
> > never goes into the blockchain.  The payee then calculates the hash and
> > looks it up in the blockchain to verify that the hash was indeed
> published
> > by the payer.
> >
> > Since the plaintext of the transaction is not published to the public
> > blockchain, all validation work has to be done only by the user who
> > receives the payment.
> >
> > To protect against double-spends, the payer also has to publish another
> > hash, which is the hash of the output being spent.  We’ll call this hash
> *spend
> > proof*.  Since the spend proof depends solely on the output being spent,
> > any attempt to spend the same output again will produce exactly the same
> > spend proof, and the payee will be able to see that, and will reject the
> > payment.  If there are several outputs consumed by the same transaction,
> > the payer has to publish several spend proofs.
> >
> > To prove that the outputs being spent are valid, the payer also has to
> send
> > the plaintexts of the earlier transaction(s) that produced them, then the
> > plaintexts of even earlier transactions that produced the outputs spent
> in
> > those transactions, and so on, up until the issue (similar to coinbase)
> > transactions that created the initial private coins.  Each new owner of
> the
> > coin will have to store its entire history, and when he spends the coin,
> he
> > forwards the entire history to the next owner and extends it with his own
> > transaction.
> >
> > If we apply the existing bitcoin design that allows multiple inputs and
> > multiple outputs per transaction, the history of ownership transfers
> would
> > grow exponentially.  Indeed, if we take any regular bitcoin output and
> try
> > to track its history back to coinbase, our history will branch every time
> > we see a transaction that has more than one input (which is not
> uncommon).
> > After such a transaction (remember, we are traveling back in time), we’ll
> > have to track two or more histories, for each respective input.  Those
> > histories will branch again, and the total number of history entries
> grows
> > exponentially.  For example, if every transaction had exactly two inputs,
> > the size of history would grow as 2^N where N is the number of steps back
> > in history.
> >
> > To avoid such rapid growth of ownership history (which is not only
> > inconvenient to move, but also exposes too much private information about
> > previous owners of all the contributing coins), we will require each
> > private transaction to have exactly one input (i.e. to consume exactly
> one
> > previous output).  This means that when we track a coin’s history back in
> > time, it will no longer branch.  It will grow linearly with the number of
> > transfers of ownership.  If a user wants to combine several inputs, he
> will
> > have to send them as separate private transactions (technically, several
> > OP_RETURNs, which can be included in a single regular bitcoin
> transaction).
> >
> > Thus, we are now forbidding any coin merges but still allowing coin
> > splits.  To avoid ultimate splitting into the dust, we will also require
> > that all private coins be issued in one of a small number of
> > denominations.  Only integer number of “banknotes” can be transferred,
> the
> > input and output amounts must therefore be divisible by the denomination.
> > For example, an input of amount 700, denomination 100, can be split into
> > outputs 400 and 300, but not into 450 and 250.  To send a payment, the
> > payer has to pick the unspent outputs of the highest denomination first,
> > then the second highest, and so on, like we already do when we pay in
> cash.
> >
> > With fixed denominations and one input per transaction, coin 

Re: [bitcoin-dev] Hiding entire content of on-chain transactions

[Henning Kopp via bitcoin-dev]

Hi Tony,

I see some issues in your protocol.

1. How are mining fees handled?

2. Assume Alice sends Bob some Coins together with their history and
Bob checks that the history is correct. How does the hash of the txout
find its way into the blockchain?

Regarding the blinding factor, I think you could just use HMAC.

All the best
Henning


On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev wrote:
> This is a proposal about hiding the entire content of bitcoin
> transactions.  It goes farther than CoinJoin and ring signatures, which
> only obfuscate the transaction graph, and Confidential Transactions, which
> only hide the amounts.
> 
> The central idea of the proposed design is to hide the entire inputs and
> outputs, and publish only the hash of inputs and outputs in the
> blockchain.  The hash can be published as OP_RETURN.  The plaintext of
> inputs and outputs is sent directly to the payee via a private message, and
> never goes into the blockchain.  The payee then calculates the hash and
> looks it up in the blockchain to verify that the hash was indeed published
> by the payer.
> 
> Since the plaintext of the transaction is not published to the public
> blockchain, all validation work has to be done only by the user who
> receives the payment.
> 
> To protect against double-spends, the payer also has to publish another
> hash, which is the hash of the output being spent.  We’ll call this hash 
> *spend
> proof*.  Since the spend proof depends solely on the output being spent,
> any attempt to spend the same output again will produce exactly the same
> spend proof, and the payee will be able to see that, and will reject the
> payment.  If there are several outputs consumed by the same transaction,
> the payer has to publish several spend proofs.
> 
> To prove that the outputs being spent are valid, the payer also has to send
> the plaintexts of the earlier transaction(s) that produced them, then the
> plaintexts of even earlier transactions that produced the outputs spent in
> those transactions, and so on, up until the issue (similar to coinbase)
> transactions that created the initial private coins.  Each new owner of the
> coin will have to store its entire history, and when he spends the coin, he
> forwards the entire history to the next owner and extends it with his own
> transaction.
> 
> If we apply the existing bitcoin design that allows multiple inputs and
> multiple outputs per transaction, the history of ownership transfers would
> grow exponentially.  Indeed, if we take any regular bitcoin output and try
> to track its history back to coinbase, our history will branch every time
> we see a transaction that has more than one input (which is not uncommon).
> After such a transaction (remember, we are traveling back in time), we’ll
> have to track two or more histories, for each respective input.  Those
> histories will branch again, and the total number of history entries grows
> exponentially.  For example, if every transaction had exactly two inputs,
> the size of history would grow as 2^N where N is the number of steps back
> in history.
> 
> To avoid such rapid growth of ownership history (which is not only
> inconvenient to move, but also exposes too much private information about
> previous owners of all the contributing coins), we will require each
> private transaction to have exactly one input (i.e. to consume exactly one
> previous output).  This means that when we track a coin’s history back in
> time, it will no longer branch.  It will grow linearly with the number of
> transfers of ownership.  If a user wants to combine several inputs, he will
> have to send them as separate private transactions (technically, several
> OP_RETURNs, which can be included in a single regular bitcoin transaction).
> 
> Thus, we are now forbidding any coin merges but still allowing coin
> splits.  To avoid ultimate splitting into the dust, we will also require
> that all private coins be issued in one of a small number of
> denominations.  Only integer number of “banknotes” can be transferred, the
> input and output amounts must therefore be divisible by the denomination.
> For example, an input of amount 700, denomination 100, can be split into
> outputs 400 and 300, but not into 450 and 250.  To send a payment, the
> payer has to pick the unspent outputs of the highest denomination first,
> then the second highest, and so on, like we already do when we pay in cash.
> 
> With fixed denominations and one input per transaction, coin histories
> still grow, but only linearly, which should not be a concern in regard to
> scalability given that all relevant computing resources still grow
> exponentially.  The histories need to be stored only by the current owner
> of the coin, not every bitcoin node.  This is a fairer allocation of
> costs.  Regarding privacy, coin histories do expose private transactions
> (or rather parts thereof, since a typical payment will likely consist of

[bitcoin-dev] Hiding entire content of on-chain transactions

[Tony Churyumoff via bitcoin-dev]

This is a proposal about hiding the entire content of bitcoin
transactions.  It goes farther than CoinJoin and ring signatures, which
only obfuscate the transaction graph, and Confidential Transactions, which
only hide the amounts.

The central idea of the proposed design is to hide the entire inputs and
outputs, and publish only the hash of inputs and outputs in the
blockchain.  The hash can be published as OP_RETURN.  The plaintext of
inputs and outputs is sent directly to the payee via a private message, and
never goes into the blockchain.  The payee then calculates the hash and
looks it up in the blockchain to verify that the hash was indeed published
by the payer.

Since the plaintext of the transaction is not published to the public
blockchain, all validation work has to be done only by the user who
receives the payment.

To protect against double-spends, the payer also has to publish another
hash, which is the hash of the output being spent.  We’ll call this hash *spend
proof*.  Since the spend proof depends solely on the output being spent,
any attempt to spend the same output again will produce exactly the same
spend proof, and the payee will be able to see that, and will reject the
payment.  If there are several outputs consumed by the same transaction,
the payer has to publish several spend proofs.

To prove that the outputs being spent are valid, the payer also has to send
the plaintexts of the earlier transaction(s) that produced them, then the
plaintexts of even earlier transactions that produced the outputs spent in
those transactions, and so on, up until the issue (similar to coinbase)
transactions that created the initial private coins.  Each new owner of the
coin will have to store its entire history, and when he spends the coin, he
forwards the entire history to the next owner and extends it with his own
transaction.

If we apply the existing bitcoin design that allows multiple inputs and
multiple outputs per transaction, the history of ownership transfers would
grow exponentially.  Indeed, if we take any regular bitcoin output and try
to track its history back to coinbase, our history will branch every time
we see a transaction that has more than one input (which is not uncommon).
After such a transaction (remember, we are traveling back in time), we’ll
have to track two or more histories, for each respective input.  Those
histories will branch again, and the total number of history entries grows
exponentially.  For example, if every transaction had exactly two inputs,
the size of history would grow as 2^N where N is the number of steps back
in history.

To avoid such rapid growth of ownership history (which is not only
inconvenient to move, but also exposes too much private information about
previous owners of all the contributing coins), we will require each
private transaction to have exactly one input (i.e. to consume exactly one
previous output).  This means that when we track a coin’s history back in
time, it will no longer branch.  It will grow linearly with the number of
transfers of ownership.  If a user wants to combine several inputs, he will
have to send them as separate private transactions (technically, several
OP_RETURNs, which can be included in a single regular bitcoin transaction).

Thus, we are now forbidding any coin merges but still allowing coin
splits.  To avoid ultimate splitting into the dust, we will also require
that all private coins be issued in one of a small number of
denominations.  Only integer number of “banknotes” can be transferred, the
input and output amounts must therefore be divisible by the denomination.
For example, an input of amount 700, denomination 100, can be split into
outputs 400 and 300, but not into 450 and 250.  To send a payment, the
payer has to pick the unspent outputs of the highest denomination first,
then the second highest, and so on, like we already do when we pay in cash.

With fixed denominations and one input per transaction, coin histories
still grow, but only linearly, which should not be a concern in regard to
scalability given that all relevant computing resources still grow
exponentially.  The histories need to be stored only by the current owner
of the coin, not every bitcoin node.  This is a fairer allocation of
costs.  Regarding privacy, coin histories do expose private transactions
(or rather parts thereof, since a typical payment will likely consist of
several transactions due to one-input-per-transaction rule) of past coin
owners to the future ones, and that exposure grows linearly with time, but
it is still much much better than having every transaction immediately on
the public blockchain.  Also, the value of this information for potential
adversaries arguably decreases with time.

There is one technical nuance that I omitted above to avoid distraction.
 Unlike regular bitcoin transactions, every output in a private payment
must also include a blinding factor, which is just a random string.  When
the output is