From: Adam Back <adam@cypherspace•org>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)
Date: Sat, 25 Jan 2014 17:19:01 +0100 [thread overview]
Message-ID: <20140125161901.GA17457@netbook.cypherspace.org> (raw)
In-Reply-To: <20140124161330.GA31233@petertodd.org>
I think I figured out a proof of existance for a space efficient way to do
better than bloom filters/prefix/bloom-bait. (Must have been dreaming on it
as I woke up with the idea following Peter's suggestion to try prove instead
if its possible or not:).
I wrote up the details here:
https://bitcointalk.org/index.php?topic=431756.new
In summary with a use of novel application of IBE (*) based on weil-pairing
so the recipient can send a delegation private key that is specific to the
block being queried. It means the node that services the query has no
ability to correlate with queries in other blocks from the some user. The
sender derives a pub=IBE-extract(master-pub, id=previous block hash). The
above link has more explanation, links and costs/risks.
I think it maybe within possibility to do further than this because it is
not technically necessary to delegate decryption, only to delegate
filtering, which can be a simpler requirement so there remains perhaps
(speculatively) a possibility to do it without introducing weil pairing
hardness problem or using eg I mentioned public key steganography or
something like that if there is anything similarly efficient but with more
widely used hardness assumptions.
Adam
(*) analogous to the way IBE is used as a building block for Non-Interactive
Forward Secrecy (NIFS)
On Fri, Jan 24, 2014 at 11:13:30AM -0500, Peter Todd wrote:
>On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote:
>> Now while it would be clearly a very nice win if reusable addresses could
>> be made SPV-like in network characteristics and privacy, but we dont have
>> a plausible mechanism yet IMO. [...]
>>
>> If we can find some efficient crypto to solve that last one, we could even
>> adopt them generally if it was efficient enough without needing interactive
>> one-use address release.
>
>Conversely, it'd be interesting if someone can dig up a proof showing
>that doing much better than Gregory's ambiguity tradeoff is impossible.
next prev parent reply other threads:[~2014-01-25 16:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 1:23 [Bitcoin-development] Bait for reusable addresses Gregory Maxwell
2014-01-24 9:02 ` Peter Todd
2014-01-24 12:26 ` Mike Hearn
2014-01-24 15:26 ` Peter Todd
2014-01-24 21:58 ` Jeremy Spilman
2014-01-24 23:15 ` Mike Hearn
2014-01-24 15:42 ` Adam Back
2014-01-24 16:13 ` Peter Todd
2014-01-25 16:19 ` Adam Back [this message]
2014-02-02 2:36 ` [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses) Peter Todd
2014-02-02 9:16 ` Jeremy Spilman
2014-02-02 12:26 ` Peter Todd
2014-02-02 15:26 ` Adam Back
2014-02-02 11:55 ` Peter Todd
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=20140125161901.GA17457@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)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