public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dr Adam Back <adam@cypherspace•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
Date: Tue, 22 Jan 2019 21:22:36 +0100	[thread overview]
Message-ID: <CALqxMTFC9uEarJ7wA3LcLbpNtWfqrkqbadADgpbeUA7ixVDhcQ@mail.gmail.com> (raw)
In-Reply-To: <wTXHV7W_AXHz5xdhXJVJr2OdSpEOaFh0PBQubFdZv4JyF6SlImszj2QyF9G-_Dem06A3iBWLF3vdgiHC_NlsVqy7DFX5XTphajNnMqiU6r0=@protonmail.com>

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


  parent reply	other threads:[~2019-01-22 20:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 22:59 Matt Bell
2019-01-19  1:42 ` ZmnSCPxj
2019-01-19  5:35   ` Matt Bell
2019-01-20  2:06     ` ZmnSCPxj
2019-01-21 18:47       ` Matt Bell
2019-01-22  9:19         ` ZmnSCPxj
2019-01-22 14:58           ` Satoshin
2019-01-22 20:03             ` Dustin Dettmer
2019-01-22 16:33           ` Dustin Dettmer
2019-01-24 10:03             ` ZmnSCPxj
2019-01-24 18:46               ` Matt Bell
2019-01-25  0:16               ` Peter Todd
2019-01-25  5:33                 ` ZmnSCPxj
2019-01-22 20:22           ` Dr Adam Back [this message]
2019-02-01  9:19 ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALqxMTFC9uEarJ7wA3LcLbpNtWfqrkqbadADgpbeUA7ixVDhcQ@mail.gmail.com \
    --to=adam@cypherspace$(echo .)org \
    --cc=ZmnSCPxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox