From: Peter Todd <pete@petertodd•org>
To: Adam Back <adam@cypherspace•org>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] An idea for alternative payment scheme
Date: Fri, 3 Jan 2014 15:39:39 -0500 [thread overview]
Message-ID: <20140103203939.GA30273@savin> (raw)
In-Reply-To: <20140103202320.GA16515@netbook.cypherspace.org>
[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]
On Fri, Jan 03, 2014 at 09:23:20PM +0100, Adam Back wrote:
> Seems like you (Nadav) are the third person to reinvent this idea so far :)
Lol, fourth if you include me, although my case is rather embarassing as
I had re-read Bytecoin's original post recently and completely missed
the main point of it!
> I wrote up some of the post-Bytecoin variants here:
>
> https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530
>
> The general limitation so far is its not SPV compatible, so the recipient
> has to test each payment to see if its one he can compute the private key
> for. Or the sender has to send the recipient out of band the derivation
> key.
Actually I think it has the potential to be *more* SPV compatible than
the alternative, as in conjunction with prefix filters it lets you
receive unlimited unrelated payments that you can find in the blockchain
with a single prefix query with a fixed bandwidth/anonymity set size
tradeoff. (obviously in conjunction with one of the many ways of tagging
transactions for more efficient search)
The BIP38 approach with UI's that make it easy to create a new address
for every payment on the other hand force you to either accept higher
bandwidth consumption, or decrease your anonymity set size, or lose
payments. (inclusive)
I've got a post talking about this in more detail as well as an overview
of bloom filters vs. prefix filters that I'll publish tomorrow. (tl;dr:
bloom filters have very poor O(n^2) scalability and should be
depreciated)
> However at present most of the bitcoin infrastructure is using the bitcoin
> broadcast channel as the communication channel, which also supports payer
> and payee not being simultaneously online. You have to be careful also not
> to lose the key. You dont want a subsequent payer data loss event to lose
> money for the recipient. You want the message to be sent atomically.
>
> It does seem like a very attractive proposition to be able to fix the
> address reuse issue. Admonishment to not reuse addresses doesnt seem to
> have been successful so far, and there are multiple widely used wallets that
> reuse addresses (probably in part because they didnt implement HD wallets
> and so are scared of losing addresses due to backup failure risks of non HD
> wallets and fresh addresses).
--
'peter'[:-1]@petertodd.org
0000000000000001a96469654430aa06e4ae7c7328a7eb848c6fc63443f24e4a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
prev parent reply other threads:[~2014-01-03 20:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 18:00 Nadav Ivgi
2014-01-03 18:16 ` Tier Nolan
2014-01-03 18:23 ` Mark Friedenbach
2014-01-03 18:30 ` Gregory Maxwell
2014-01-03 20:23 ` Adam Back
2014-01-03 20:39 ` Peter Todd [this message]
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=20140103203939.GA30273@savin \
--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