From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles
Date: Sun, 21 Dec 2014 10:29:37 -0500 [thread overview]
Message-ID: <20141221152936.GB3927@savin.petertodd.org> (raw)
In-Reply-To: <CALqxMTHC0Rhotei4B1civoc_9NF5M+tw-qmE46EmHSadCrmScQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]
On Sun, Dec 21, 2014 at 10:01:37AM +0000, Adam Back wrote:
> 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.
There's no need to get into the specifics of crypto math so early; you
can just as easily and only slightly less efficiently obtain the same
result with a few extensions to the Bitcoin scripting system to verify
ECDSA signatures directly.
The interesting question is how "risky" this actually is? Sybil attacks
are reasonably easy to pull off, and users have little incentive to
validate if 99% of the time everything works, so you don't want to
create a system where an actual attack will likely go undetected.
Talking about the low level details of how double-spend punishment is
actually detailed is just premature optimization.
As usual in Bitcoin, the hard part is *not* the math.
--
'peter'[:-1]@petertodd.org
000000000000000012f5511833a1304a72a754df8afef26f5712438bcc40826b
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2014-12-21 15:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 9:05 [Bitcoin-development] Setting the record straight on Proof-of-Publication Peter Todd
2014-12-12 12:25 ` Gareth Williams
2014-12-12 17:04 ` Alex Mizrahi
[not found] ` <CAOG=w-v3qjG3zd_WhfFU-OGnsHZEuYvY82eL4GqcdgY6np5bvA@mail.gmail.com>
2014-12-12 17:50 ` Alex Mizrahi
2014-12-13 13:32 ` Gareth Williams
2014-12-15 4:52 ` Peter Todd
2014-12-17 11:55 ` Gareth Williams
2014-12-21 6:12 ` Peter Todd
2014-12-15 4:17 ` Peter Todd
2014-12-12 13:41 ` odinn
2014-12-12 14:17 ` Justus Ranvier
2014-12-15 4:59 ` Peter Todd
2014-12-17 1:16 ` odinn
2014-12-20 14:48 ` [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles Peter Todd
[not found] ` <CAOG=w-vrHPY1aCNndmoW9QyCh9XnWyv8uZn2PyjZ6rNg2MoSSw@mail.gmail.com>
2014-12-21 5:52 ` Peter Todd
[not found] ` <CAOG=w-tZke--6OsqNjJhE9SOdCwdZYZM8iz1VBTFziegt9UZWw@mail.gmail.com>
2014-12-21 7:01 ` Peter Todd
[not found] ` <CAOG=w-s1_VXJAKxBpMOK=B50qnHjxSe4J=vwwSfFPRz0_Cb9rA@mail.gmail.com>
2014-12-21 15:32 ` Peter Todd
2014-12-21 11:25 ` Jorge Timón
2014-12-21 16:07 ` Peter Todd
2014-12-21 19:39 ` Jorge Timón
2014-12-21 10:01 ` Adam Back
2014-12-21 15:29 ` Peter Todd [this message]
2014-12-21 13:49 ` paul snow
2014-12-21 15:22 ` Peter Todd
2014-12-21 15:41 ` paul snow
2014-12-22 0:11 ` Peter Todd
2015-01-06 11:03 ` joliver
2014-12-22 20:05 ` Adam Back
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=20141221152936.GB3927@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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