Brands credentials use this single show, and multiple show credentials. It's based on the representation problem which is the generalisation to multiple bases where Schnorr is one base, Pedersen Commitments are two bases, Representation problem is n>2 bases.
The method used would work for Schnorr or DSA and there was some 2013 era #bitcoin-wizards discussion on this topic, where if you spend twice miners can take your money, as a strong way to "discourage" address reuse. One side effect though is you force ACID log oriented storage on the wallet, and many wallets are low power devices or even a few in VMs that could be snapshotted or rolled back. Similar risk model to the lightning penalty for accidentally doing a hostile close in the current model (where ELTOO has non-penalty based close). You would have to be careful to not use related nonces (k=nonce committed to by R=kG), as Schnorr and DSA are highly vulnerable to that, like simultaneous equation two samples solvable. What the Brands n-show credential looks like is a precommitment like single show the address becomes A=H(R,Q) where Q is the public key, and n-show becomes A=H(R1,...,Rn,Q). Signing becomes providing i,Ri,Q in the Script to satisfy a ScriptPubKey that includes the three. You would need to in practice store the Ri values in a merkle tree probably so that you don't need to provide n inputs, but log(n) or some other structuring. Anyway main point being the fragility to related nonces, and cost of ACID log structured storage levels of reliability in wallets. Adam On Tue, 22 Jan 2019 at 15:14, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Good Morning Matt, > > > ### ZmnSCPxj, > > > > I'm intrigued by this mechanism of using fixed R values to prevent multiple > > signatures, but how do we derive the R values in a way where they are > unique for each blockheight but still can be used to create signatures or > verify? > > One possibility is to derive `R` using standard hierarchical derivation. > Then require that the staking pubkey be revealed to the sidechain network as > actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly with > some trivial protection against Taproot). > To sign for a blockheight `h`, you must use your public key `P` and the > specific `R` we get from hierarchical derivation from `parent_R` and the > blockheight as index. > > > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
