Tive uma conversa esta semana sobre como a Phoenix alcança a desvinculabilidade especificamente como a mesma nota pode ser endereçada a alguém sem revelar quem é essa pessoa. O mecanismo no whitepaper é uma única fórmula que faz duas coisas separadamente, dependendo de quem está lendo.
A fórmula é: chave pública da nota: npk = H(rA)G + B. O remetente computa isso usando a chave pública do destinatário (A B) e um valor aleatório r que ele escolhe fresco para cada transação. R = rG é incluído na nota e é público. Mas o próprio r é secreto e é descartado após o uso.
O que npk faz para o remetente: como r é aleatório e fresco a cada vez, a chave pública da nota muda em cada transação. Mesmo que o remetente envie dez notas para o mesmo destinatário, cada nota tem um npk diferente. Nenhum observador olhando a cadeia consegue vincular várias notas entre si nem ligá-las à identidade do remetente apenas com os dados públicos.
O que NPK faz para o destinatário: apenas o destinatário consegue identificar quais notas são as dele. Ele usa sua chave de visualização (a B) e verifica se npk é igual a H(aR)G + B para qualquer nota que encontre. Essa verificação funciona porque, pela matemática, rA e aR produzem o mesmo valor quando A = aG. Assim, a chave de visualização do destinatário é suficiente para fazer a varredura de notas recebidas.
Mesmo objetivo. Mecanismo fundamentalmente diferente para cada parte. A aleatoriedade do remetente esconde quem enviou o quê. O material de chave do destinatário faz com que ele seja a única parte capaz de identificar o que é dele. Para gastar, é necessária a chave secreta completa (a b) para computar a chave secreta da nota nsk = H(aR) + b; então, a chave de visualização dá visibilidade sem dar capacidade de gasto.
#dusk
Eu realmente acho que a interação entre esses dois usos da mesma fórmula é mais elegante do que qualquer parte individual: remetente e destinatário são protegidos contra coisas diferentes pela mesma peça de criptografia.
O que eu ainda não resolvi é se a escolha de r afeta algo além da desvinculabilidade—se um r fraco ou previsível teria implicações de segurança além de permitir vinculação de transações, ou se o único ataque a partir de um r fraco é. @Dusk
$DUSK
A fórmula é: chave pública da nota: npk = H(rA)G + B. O remetente computa isso usando a chave pública do destinatário (A B) e um valor aleatório r que ele escolhe fresco para cada transação. R = rG é incluído na nota e é público. Mas o próprio r é secreto e é descartado após o uso.
O que npk faz para o remetente: como r é aleatório e fresco a cada vez, a chave pública da nota muda em cada transação. Mesmo que o remetente envie dez notas para o mesmo destinatário, cada nota tem um npk diferente. Nenhum observador olhando a cadeia consegue vincular várias notas entre si nem ligá-las à identidade do remetente apenas com os dados públicos.
O que NPK faz para o destinatário: apenas o destinatário consegue identificar quais notas são as dele. Ele usa sua chave de visualização (a B) e verifica se npk é igual a H(aR)G + B para qualquer nota que encontre. Essa verificação funciona porque, pela matemática, rA e aR produzem o mesmo valor quando A = aG. Assim, a chave de visualização do destinatário é suficiente para fazer a varredura de notas recebidas.
Mesmo objetivo. Mecanismo fundamentalmente diferente para cada parte. A aleatoriedade do remetente esconde quem enviou o quê. O material de chave do destinatário faz com que ele seja a única parte capaz de identificar o que é dele. Para gastar, é necessária a chave secreta completa (a b) para computar a chave secreta da nota nsk = H(aR) + b; então, a chave de visualização dá visibilidade sem dar capacidade de gasto.
#dusk
Eu realmente acho que a interação entre esses dois usos da mesma fórmula é mais elegante do que qualquer parte individual: remetente e destinatário são protegidos contra coisas diferentes pela mesma peça de criptografia.
O que eu ainda não resolvi é se a escolha de r afeta algo além da desvinculabilidade—se um r fraco ou previsível teria implicações de segurança além de permitir vinculação de transações, ou se o único ataque a partir de um r fraco é. @Dusk
$DUSK
