Address expiration does seem to be a generic problem, but Silent Payments could
play a role in solving the problem once and for all. Payment requests often
have expiration in practice because of moving exchange rates but no way to
communicate that to sending software. BTCPay checkout page includ
Very nice! Is there an authentication mechanism to avoid 'breaking the chain'
with an unverifiable new state by a previous owner? Can the current owner prove
the knowledge of a non-identifying secret he learned as recipient to the server
that is related to the statechain tip?
BR,
moonsettler
-
Hi, Salvatore.
Thanks for the update! I like the fact that taptree verification now
can be done on both input and outputs, and having them be symmetrical
also makes the learning curve a bit easier.
I have implemented the updated opcodes in btcd (very rough
implementation)]1] as well as updated th
Hi Dave,
I apologize for the confusion and the inconsistent use of plurals.
The reason I called it a "complete proposal" is that the opcode is
now functionally complete, unlike the previous attempt where the
approach for the output amount introspection was not yet specified.
The semantics are inf
A follow up to this, I have updated the blinded statechain protocol
description to include the mitigation to the Wagner attack by requiring the
server to send R1 values only after commitments made to the server of the
R2 values used by the user, and that all the previous computed c values are
verif
