Explanation of how exactly the pederson commitments in monero work?
up vote
2
down vote
favorite
so lets say for the first commitment (after a mined transaction)
let a = miner_reward
this is a known number.
to generate the first commitment, one does;
input = x.G + a.H; output = x.G + a.H
Then using diffie-hellman the sender lets the receiver know the values of both x an a. The problem is, if the receiver now wants to spend the outputted commitment, he must add a further layer of masking/encryption. Because if he doesn't and some malicious actor down the road receives a payment, all the bad actor has to do is reveal x, and everyone in the chain that used x as a blinding key, will have their amounts compromised.
So my question is, how exactly does the receiver add the further encryption to the commitment? Proofs of why its valid would be nice as well.
cryptography encryption
asked Nov 9 at 10:18
cookiekid
1563
add a comment |
up vote
2
down vote
favorite
so lets say for the first commitment (after a mined transaction)
let a = miner_reward
this is a known number.
to generate the first commitment, one does;
input = x.G + a.H; output = x.G + a.H
Then using diffie-hellman the sender lets the receiver know the values of both x an a. The problem is, if the receiver now wants to spend the outputted commitment, he must add a further layer of masking/encryption. Because if he doesn't and some malicious actor down the road receives a payment, all the bad actor has to do is reveal x, and everyone in the chain that used x as a blinding key, will have their amounts compromised.
So my question is, how exactly does the receiver add the further encryption to the commitment? Proofs of why its valid would be nice as well.
cryptography encryption
asked Nov 9 at 10:18
cookiekid
1563
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
so lets say for the first commitment (after a mined transaction)
let a = miner_reward
this is a known number.
to generate the first commitment, one does;
input = x.G + a.H; output = x.G + a.H
Then using diffie-hellman the sender lets the receiver know the values of both x an a. The problem is, if the receiver now wants to spend the outputted commitment, he must add a further layer of masking/encryption. Because if he doesn't and some malicious actor down the road receives a payment, all the bad actor has to do is reveal x, and everyone in the chain that used x as a blinding key, will have their amounts compromised.
So my question is, how exactly does the receiver add the further encryption to the commitment? Proofs of why its valid would be nice as well.
cryptography encryption
asked Nov 9 at 10:18
cookiekid
1563
so lets say for the first commitment (after a mined transaction)
let a = miner_reward
this is a known number.
to generate the first commitment, one does;
input = x.G + a.H; output = x.G + a.H
Then using diffie-hellman the sender lets the receiver know the values of both x an a. The problem is, if the receiver now wants to spend the outputted commitment, he must add a further layer of masking/encryption. Because if he doesn't and some malicious actor down the road receives a payment, all the bad actor has to do is reveal x, and everyone in the chain that used x as a blinding key, will have their amounts compromised.
So my question is, how exactly does the receiver add the further encryption to the commitment? Proofs of why its valid would be nice as well.
cryptography encryption
cryptography encryption
asked Nov 9 at 10:18
cookiekid
1563
asked Nov 9 at 10:18
cookiekid
1563
asked Nov 9 at 10:18
cookiekid
1563
asked Nov 9 at 10:18
cookiekid
1563
asked Nov 9 at 10:18
cookiekid
1563
1563
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
Blinding factors are random numbers that are only used once per commitment. No two commitments should ever share the same blinding factor, even if they're for the same amount. The blinding factor is generated by the sender and communicated to the receiver in encrypted form using the DH shared secret (as you've pointed out).
If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.
Therefore for transactions spending multiple inputs, you avoid this problem by creating new commitments for the inputs you're spending, and these are called "PseudoOuts" in the transaction structure. See Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT
answered Nov 9 at 12:18
knaccc
6,137618
Ok so it would look like this;original = xG + aH.new = yG + aH. Then to prove the value sums to zero you do(xG + aH) - (yG + aH). which is the same asxG-yGor(x-y)G. andx-yis the private key used to generate a signature that proves the value ofawas not changed. Is this correct?
– cookiekid
Nov 9 at 12:47
1
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Blinding factors are random numbers that are only used once per commitment. No two commitments should ever share the same blinding factor, even if they're for the same amount. The blinding factor is generated by the sender and communicated to the receiver in encrypted form using the DH shared secret (as you've pointed out).
If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.
Therefore for transactions spending multiple inputs, you avoid this problem by creating new commitments for the inputs you're spending, and these are called "PseudoOuts" in the transaction structure. See Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT
answered Nov 9 at 12:18
knaccc
6,137618
Ok so it would look like this;original = xG + aH.new = yG + aH. Then to prove the value sums to zero you do(xG + aH) - (yG + aH). which is the same asxG-yGor(x-y)G. andx-yis the private key used to generate a signature that proves the value ofawas not changed. Is this correct?
– cookiekid
Nov 9 at 12:47
1
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
add a comment |
up vote
3
down vote
accepted
Blinding factors are random numbers that are only used once per commitment. No two commitments should ever share the same blinding factor, even if they're for the same amount. The blinding factor is generated by the sender and communicated to the receiver in encrypted form using the DH shared secret (as you've pointed out).
If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.
Therefore for transactions spending multiple inputs, you avoid this problem by creating new commitments for the inputs you're spending, and these are called "PseudoOuts" in the transaction structure. See Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT
answered Nov 9 at 12:18
knaccc
6,137618
Ok so it would look like this;original = xG + aH.new = yG + aH. Then to prove the value sums to zero you do(xG + aH) - (yG + aH). which is the same asxG-yGor(x-y)G. andx-yis the private key used to generate a signature that proves the value ofawas not changed. Is this correct?
– cookiekid
Nov 9 at 12:47
1
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Blinding factors are random numbers that are only used once per commitment. No two commitments should ever share the same blinding factor, even if they're for the same amount. The blinding factor is generated by the sender and communicated to the receiver in encrypted form using the DH shared secret (as you've pointed out).
If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.
Therefore for transactions spending multiple inputs, you avoid this problem by creating new commitments for the inputs you're spending, and these are called "PseudoOuts" in the transaction structure. See Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT
answered Nov 9 at 12:18
knaccc
6,137618
Blinding factors are random numbers that are only used once per commitment. No two commitments should ever share the same blinding factor, even if they're for the same amount. The blinding factor is generated by the sender and communicated to the receiver in encrypted form using the DH shared secret (as you've pointed out).
If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.
Therefore for transactions spending multiple inputs, you avoid this problem by creating new commitments for the inputs you're spending, and these are called "PseudoOuts" in the transaction structure. See Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT
answered Nov 9 at 12:18
knaccc
6,137618
edited Nov 10 at 0:02
answered Nov 9 at 12:18
knaccc
6,137618
answered Nov 9 at 12:18
knaccc
6,137618
answered Nov 9 at 12:18
knaccc
6,137618
6,137618
Ok so it would look like this;original = xG + aH.new = yG + aH. Then to prove the value sums to zero you do(xG + aH) - (yG + aH). which is the same asxG-yGor(x-y)G. andx-yis the private key used to generate a signature that proves the value ofawas not changed. Is this correct?
– cookiekid
Nov 9 at 12:47
1
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
add a comment |
Ok so it would look like this;original = xG + aH.new = yG + aH. Then to prove the value sums to zero you do(xG + aH) - (yG + aH). which is the same asxG-yGor(x-y)G. andx-yis the private key used to generate a signature that proves the value ofawas not changed. Is this correct?
– cookiekid
Nov 9 at 12:47
1
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
Ok so it would look like this;
original = xG + aH. new = yG + aH. Then to prove the value sums to zero you do (xG + aH) - (yG + aH). which is the same as xG-yG or (x-y)G. and x-y is the private key used to generate a signature that proves the value of a was not changed. Is this correct?– cookiekid
Nov 9 at 12:47
Ok so it would look like this;
original = xG + aH. new = yG + aH. Then to prove the value sums to zero you do (xG + aH) - (yG + aH). which is the same as xG-yG or (x-y)G. and x-y is the private key used to generate a signature that proves the value of a was not changed. Is this correct?– cookiekid
Nov 9 at 12:47
1
1
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
@cookiekid Yes, exactly. Commitments are effectively public keys, so knowing the private key allows you to create a signature to prove you know the private key, in exactly the same way that signatures work for ordinary public/private keypairs.
– knaccc
Nov 9 at 13:04
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmonero.stackexchange.com%2fquestions%2f10517%2fexplanation-of-how-exactly-the-pederson-commitments-in-monero-work%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
