* [Bitcoin-development] An idea for alternative payment scheme
@ 2014-01-03 18:00 Nadav Ivgi
2014-01-03 18:16 ` Tier Nolan
2014-01-03 18:30 ` Gregory Maxwell
0 siblings, 2 replies; 6+ messages in thread
From: Nadav Ivgi @ 2014-01-03 18:00 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
I had an idea for a payment scheme that uses key derivation, but instead of
the payee deriving the addresses, the payer would do it.
It would work like that:
1. The payee publishes his master public key
2. The payer generates a random "receipt number" (say, 25 random bytes)
3. The payer derives an address from the master public key using the
receipt number and pays to it
4. The payer sends the receipt to the payee
5. The payee derives a private key with that receipt and adds it to his
wallet
Advantages:
- It increases privacy by avoiding address reuse
- The process is asynchronous. The payee is completely passive in the
payment process and isn't required to provide new addresses before each
payment (so no payment server required)
- Its usable as a replacement for cases where re-used addresses are the
most viable solution (like putting an address in a forum signature or as a
development fund in a github readme)
- The receipt also acts as a proof of payment that the payer can provide
to the payee
- Also, if the master is known to belong to someone, this also allows
the payer prove to a third-party that the payment was made to that someone.
If the output was spent, it also proves that he was aware of the payment
and has the receipt.
- Its a really thin abstraction layer that doesn't require much changes
Disadvantages:
- Losing the receipt numbers means losing access to your funds, they are
random and there's no way to restore them
- It requires sending the receipt to the payee somehow. Email could work
for that, but a better defined channel that also can talk to the Bitcoin
client and add the receipt would be much better.
What do you think?
[-- Attachment #2: Type: text/html, Size: 1996 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] An idea for alternative payment scheme
2014-01-03 18:00 [Bitcoin-development] An idea for alternative payment scheme Nadav Ivgi
@ 2014-01-03 18:16 ` Tier Nolan
2014-01-03 18:23 ` Mark Friedenbach
2014-01-03 18:30 ` Gregory Maxwell
1 sibling, 1 reply; 6+ messages in thread
From: Tier Nolan @ 2014-01-03 18:16 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]
The random number that the buyer uses could be generated from a root key
too.
This would allow them to regenerate all random numbers that they used and
recreate their receipts. The master root would have to be stored on your
computer though.
The payment protocol is supposed to do something like this already though.
On Fri, Jan 3, 2014 at 6:00 PM, Nadav Ivgi <nadav@shesek•info> wrote:
> I had an idea for a payment scheme that uses key derivation, but instead
> of the payee deriving the addresses, the payer would do it.
>
> It would work like that:
>
> 1. The payee publishes his master public key
> 2. The payer generates a random "receipt number" (say, 25 random bytes)
> 3. The payer derives an address from the master public key using the
> receipt number and pays to it
> 4. The payer sends the receipt to the payee
> 5. The payee derives a private key with that receipt and adds it to
> his wallet
>
>
> Advantages:
>
> - It increases privacy by avoiding address reuse
> - The process is asynchronous. The payee is completely passive in the
> payment process and isn't required to provide new addresses before each
> payment (so no payment server required)
> - Its usable as a replacement for cases where re-used addresses are
> the most viable solution (like putting an address in a forum signature or
> as a development fund in a github readme)
> - The receipt also acts as a proof of payment that the payer can
> provide to the payee
> - Also, if the master is known to belong to someone, this also allows
> the payer prove to a third-party that the payment was made to that someone.
> If the output was spent, it also proves that he was aware of the payment
> and has the receipt.
> - Its a really thin abstraction layer that doesn't require much changes
>
> Disadvantages:
>
> - Losing the receipt numbers means losing access to your funds, they
> are random and there's no way to restore them
> - It requires sending the receipt to the payee somehow. Email could
> work for that, but a better defined channel that also can talk to the
> Bitcoin client and add the receipt would be much better.
>
> What do you think?
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 3730 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] An idea for alternative payment scheme
2014-01-03 18:16 ` Tier Nolan
@ 2014-01-03 18:23 ` Mark Friedenbach
0 siblings, 0 replies; 6+ messages in thread
From: Mark Friedenbach @ 2014-01-03 18:23 UTC (permalink / raw)
To: bitcoin-development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There is a standard mechanism for doing that called deterministic
signatures and is described in RFC 6979. It uses the private key and
the HMAC construction to generate a ECDSA k value.
On 01/03/2014 10:16 AM, Tier Nolan wrote:
> The random number that the buyer uses could be generated from a
> root key too.
>
> This would allow them to regenerate all random numbers that they
> used and recreate their receipts. The master root would have to be
> stored on your computer though.
>
> The payment protocol is supposed to do something like this already
> though.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSxwAqAAoJEAdzVfsmodw4nAoQAJLyI7m2uII6Lp0bk2odiT84
rqoAZut4ESGK+lMHsVoFIkFPKAD4ZXpKEEhOa212Q4ZtQG+Ceescs04qslfzwAfO
bnAQrzRzKQf68bQlvtdZ4xjsfe38GgI5LEkyxHVrwd39ZJhP2Hp4xJT5TbvrNzq7
GRDTNcM30GTAF5nW9HPT4/KXIpzYQcuylaK9IX2KRHdC5/PFMDKu3b5lGe9BqbtF
hYLVyj4jAGfTr/K6UFS37sFbdPoyhkiz+S7YHy6dsqc0XMUFnx3xvkgirKkAtGBw
hjDK6m+Ay+qdR6XcnOft1IXM7ctujH7Ru9RHM6K4x0Pt3x0DBLE5yahPEPg5uEAW
HAHwuOGs0mDoqeYzW9Ftegh2QkmlVd0CZQmGvcVHLzuugxeR49XPIIURNTmEyk6e
9Ui6EKEbFSiQ/jeMnARIKmTAfp3uTHwEIOoNFBgFHXAe5iVtWEr/jkL1dSKrHpVm
Dnt4g+IB5a8HOlvU789QeJh/wVrOH+msuhuXgb1W86zvurnnKxb5eSQx5TMy/fy1
e3IKZ9qKCodVt1I6zSCf1xJjd6QXPpxcnKco/G604GEZsg87sC3sMUsJ+g7GuHJI
M05U8pNAnDjH/HHJLQj3IJhAQO4IforvgMri4sM0OeAEdDfrONjwwbWFnx638kyD
r4jvFeIPyVM1574GwfJW
=8qjF
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] An idea for alternative payment scheme
2014-01-03 18:00 [Bitcoin-development] An idea for alternative payment scheme Nadav Ivgi
2014-01-03 18:16 ` Tier Nolan
@ 2014-01-03 18:30 ` Gregory Maxwell
2014-01-03 20:23 ` Adam Back
1 sibling, 1 reply; 6+ messages in thread
From: Gregory Maxwell @ 2014-01-03 18:30 UTC (permalink / raw)
To: Nadav Ivgi; +Cc: bitcoin-development
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi <nadav@shesek•info> wrote:
> I had an idea for a payment scheme that uses key derivation, but instead of
> the payee deriving the addresses, the payer would do it.
>
> It would work like that:
>
> The payee publishes his master public key
> The payer generates a random "receipt number" (say, 25 random bytes)
> The payer derives an address from the master public key using the receipt
> number and pays to it
> The payer sends the receipt to the payee
> The payee derives a private key with that receipt and adds it to his wallet
Allow me to introduce an even more wild idea.
The payee publishes two public keys PP PP2.
The payer picks the first k value he intends to use in his signatures.
The payer multiplies PP2*k = n.
The payer pays to pubkey PP+n with r in his first signature, or if
none of the txins are ECDSA signed, in an OP_RETURN additional output.
The payer advises the payee that PP+(pp2_secret*r) is something he can
redeem. But this is technically optional because the payee can simply
inspect every transaction to check for this condition.
This is a (subset) of a scheme by Bytecoin published a long time ago
on Bitcoin talk.
It has the advantage that if payer drops his computer down a well
after making the payment the funds are not lost, and yet it is still
completely confidential.
(The downside is particular way I've specified this breaks using
deterministic DSA unless you use the OP_RETURN, ... it could instead
be done by using one of the signature pubkeys, but the pubkeys may
only exist in the prior txin, which kinda stinks. Also the private
keys for the pubkeys may only exist in some external hardware, where a
OP_RETURN nonce could be produced when signing).
These schemes have an advantage over the plain payment protocol
intended use (where you can just give them their receipt number, or
just the whole key) in that they allow the first round of
communication to be broadcast (e.g. payee announced to EVERYONE that
he's accepting payments) while preserving privacy.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] An idea for alternative payment scheme
2014-01-03 18:30 ` Gregory Maxwell
@ 2014-01-03 20:23 ` Adam Back
2014-01-03 20:39 ` Peter Todd
0 siblings, 1 reply; 6+ messages in thread
From: Adam Back @ 2014-01-03 20:23 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
Seems like you (Nadav) are the third person to reinvent this idea so far :)
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.
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).
Adam
On Fri, Jan 03, 2014 at 10:30:38AM -0800, Gregory Maxwell wrote:
>On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi <nadav@shesek•info> wrote:
>> I had an idea for a payment scheme that uses key derivation, but instead of
>> the payee deriving the addresses, the payer would do it.
>>
>> It would work like that:
>>
>> The payee publishes his master public key
>> The payer generates a random "receipt number" (say, 25 random bytes)
>> The payer derives an address from the master public key using the receipt
>> number and pays to it
>> The payer sends the receipt to the payee
>> The payee derives a private key with that receipt and adds it to his wallet
>
>Allow me to introduce an even more wild idea.
>
>The payee publishes two public keys PP PP2.
>
>The payer picks the first k value he intends to use in his signatures.
>
>The payer multiplies PP2*k = n.
>
>The payer pays to pubkey PP+n with r in his first signature, or if
>none of the txins are ECDSA signed, in an OP_RETURN additional output.
>
>The payer advises the payee that PP+(pp2_secret*r) is something he can
>redeem. But this is technically optional because the payee can simply
>inspect every transaction to check for this condition.
>
>This is a (subset) of a scheme by Bytecoin published a long time ago
>on Bitcoin talk.
>
>It has the advantage that if payer drops his computer down a well
>after making the payment the funds are not lost, and yet it is still
>completely confidential.
>
>(The downside is particular way I've specified this breaks using
>deterministic DSA unless you use the OP_RETURN, ... it could instead
>be done by using one of the signature pubkeys, but the pubkeys may
>only exist in the prior txin, which kinda stinks. Also the private
>keys for the pubkeys may only exist in some external hardware, where a
>OP_RETURN nonce could be produced when signing).
>
>These schemes have an advantage over the plain payment protocol
>intended use (where you can just give them their receipt number, or
>just the whole key) in that they allow the first round of
>communication to be broadcast (e.g. payee announced to EVERYONE that
>he's accepting payments) while preserving privacy.
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>organizations don't have a clear picture of how application performance
>affects their revenue. With AppDynamics, you get 100% visibility into your
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] An idea for alternative payment scheme
2014-01-03 20:23 ` Adam Back
@ 2014-01-03 20:39 ` Peter Todd
0 siblings, 0 replies; 6+ messages in thread
From: Peter Todd @ 2014-01-03 20:39 UTC (permalink / raw)
To: Adam Back; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-03 20:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-03 18:00 [Bitcoin-development] An idea for alternative payment scheme 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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox