Jeremy Papp [ARCHIVE] on Nostr: π
Original date posted:2016-02-10 π Original message:On 2/10/2016 5:53 AM, ...
π
Original date posted:2016-02-10
π Original message:On 2/10/2016 5:53 AM, Henning Kopp wrote:
> Hi Jeremy,
>
>> My understanding of the paper is that the blinding factor would be included
>> in the extra data which is incorporated into the ring signatures used in the
>> range proof.
> Yep, that is a possibility. The blinding factor could be encrypted
> with the public key of the receiver. Thus it is only visible for the
> receiver who can then check that the correct amount has been sent.
ECC doesn't work like RSA; you can't encrypt directly with a public
key. That's why you generate a shared secret between sender and
receiver. See also, ECDH. (Basically, if (m, M = m*G) is your
private/public key pair, and (n, N = n*G) is your recipient's private
public key pair, you can both generate shared secret S = m*N = n*M =
m*n*G without revealing your private keys to each other, and without
revealing the secret to anyone else as long as they don't know either
private key. You then use S as the basis for the key to some symmetric
algorithm.)
>> you'd transmit it then, though in any case, since using it will pretty much
>> require segwit, adding extraneous data isn't much of a problem. In both
>> cases, I imagine the blinding factor would be protected from outside
>> examination via some form of shared secret generation... Although that would
>> require the sender to know the recipient's unhashed public key; I don't know
>> of any shared secret schemes that will work on hashed keys.
> Here you lost me.
> Why do we need to create a shared secret? Is this shared secret used
> as the blinding factor?
> Also I think the sender knows the unhashed public key of the receiver.
> The only reason not to include it in the transaction script is that an
> external observer is unable to see the receiver directly in the
> blockchain.
Normal Bitcoin transactions are made to the hash of a public key because
once the public key is known, it becomes easier to break it if we ever
develop quantum computers. That's why it's recommended that you only
spend from a particular address once (if possible) since its only in
spending that you are required to reveal your public key. Since you
can't do a shared secret with a public key hash, AFAIK, you'd have to
know the public key of your recipient to be able to do ECDH.
Jeremy Papp
Published at
2023-06-07 17:49:01Event JSON
{
"id": "c1c739c2b05abf688f2e90562679c410abd3e6b8c3be21da9c70db108cb38e44",
"pubkey": "6aa532b0f5d6cc365b63a055d1122ebd4984d1f9ef10b2e6bf909b822594d820",
"created_at": 1686160141,
"kind": 1,
"tags": [
[
"e",
"ecce5e206f5ce817a148e6742efb6fbb69da668616fb0d71ac468c42688bea0a",
"",
"root"
],
[
"e",
"ed7d260592c518fe617598b4578b7b372ee0a8ecbd6c15799743b9ee7983addc",
"",
"reply"
],
[
"p",
"5f0a91713bf7b0eac4f3af9f2a7714d917168ae44ba350b1b95c1d4b32c3ce35"
]
],
"content": "π
Original date posted:2016-02-10\nπ Original message:On 2/10/2016 5:53 AM, Henning Kopp wrote:\n\u003e Hi Jeremy,\n\u003e\n\u003e\u003e My understanding of the paper is that the blinding factor would be included\n\u003e\u003e in the extra data which is incorporated into the ring signatures used in the\n\u003e\u003e range proof.\n\u003e Yep, that is a possibility. The blinding factor could be encrypted\n\u003e with the public key of the receiver. Thus it is only visible for the\n\u003e receiver who can then check that the correct amount has been sent.\nECC doesn't work like RSA; you can't encrypt directly with a public \nkey. That's why you generate a shared secret between sender and \nreceiver. See also, ECDH. (Basically, if (m, M = m*G) is your \nprivate/public key pair, and (n, N = n*G) is your recipient's private \npublic key pair, you can both generate shared secret S = m*N = n*M = \nm*n*G without revealing your private keys to each other, and without \nrevealing the secret to anyone else as long as they don't know either \nprivate key. You then use S as the basis for the key to some symmetric \nalgorithm.)\n\u003e\u003e you'd transmit it then, though in any case, since using it will pretty much\n\u003e\u003e require segwit, adding extraneous data isn't much of a problem. In both\n\u003e\u003e cases, I imagine the blinding factor would be protected from outside\n\u003e\u003e examination via some form of shared secret generation... Although that would\n\u003e\u003e require the sender to know the recipient's unhashed public key; I don't know\n\u003e\u003e of any shared secret schemes that will work on hashed keys.\n\u003e Here you lost me.\n\u003e Why do we need to create a shared secret? Is this shared secret used\n\u003e as the blinding factor?\n\u003e Also I think the sender knows the unhashed public key of the receiver.\n\u003e The only reason not to include it in the transaction script is that an\n\u003e external observer is unable to see the receiver directly in the\n\u003e blockchain.\nNormal Bitcoin transactions are made to the hash of a public key because \nonce the public key is known, it becomes easier to break it if we ever \ndevelop quantum computers. That's why it's recommended that you only \nspend from a particular address once (if possible) since its only in \nspending that you are required to reveal your public key. Since you \ncan't do a shared secret with a public key hash, AFAIK, you'd have to \nknow the public key of your recipient to be able to do ECDH.\n\nJeremy Papp",
"sig": "2b2a184a8008db703da026ef252d2a461248773ffc181a6aba1a8e3e8bff487b2ba6f872b9b07fba6a58c0237015da1dcb0dea6eed6e159fc26eb660f83f443f"
}