Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.48 as permitted sender)
	client-ip=209.85.192.48; envelope-from=adam.back@gmail.com;
	helo=mail-qg0-f48.google.com; 
MIME-Version: 1.0
Sender: adam.back@gmail.com
In-Reply-To: <20141220144800.GA26284@savin.petertodd.org>
References: <20141212090551.GA8259@muck>
	<20141220144800.GA26284@savin.petertodd.org>
Date: Sun, 21 Dec 2014 10:01:37 +0000
Message-ID: <CALqxMTHC0Rhotei4B1civoc_9NF5M+tw-qmE46EmHSadCrmScQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The relationship between
 Proof-of-Publication and Anti-Replay Oracles
Precedence: list

On 20 December 2014 at 14:48, Peter Todd <pete@petertodd.org> wrote:
> We need the following primitives operating on message m, pubkey p, and a
> valid signature sig1 for m, p:
>
>     AntiReplaySign(m, p, sig1) -> sig2
>     VerifyAntiReplaySig(m, p, sig2) -> True or False
>
> Additionally once AntiReplaySign() has been used once for a given pubkey
> it is impossible to re-run the primitive on a different message m'. This
> is of course impossible to implement with math alone, but we can
> implement it with a trusted third party.

Well while you cant prevent it you could render it insecure enabling
miners to take funds.

That could work via a one-show signature; normal ECDSA being address
a=H(Q), public key Q=dG, R=kG, r=R.x, s=(H(m)+rd)/k, signature (r,s),
verify: a=?H(Q) and sR=?H(m)G+rQ one-show being: a=H(Q,R), verify
being: a=?H(Q,R) and sR=?H(m)G+rQ.  Now that is unsafe to double-spend
by design as only that specific R is usable and as we know reusing R
with different messages leaks the private key because: s=(H(m)+rd)/k
and s'=(H(m')+rd)/k implies sk=H(m)+rd and s'k=H(m')+rd so
k=(H(m)-H(m'))/(s'-s), and d=(sk-H(m))/r.

Adam