Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vz9Ig-00044A-KI for bitcoin-development@lists.sourceforge.net; Fri, 03 Jan 2014 18:16:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.65 as permitted sender) client-ip=209.85.160.65; envelope-from=tier.nolan@gmail.com; helo=mail-pb0-f65.google.com; Received: from mail-pb0-f65.google.com ([209.85.160.65]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vz9If-0000ew-Dh for bitcoin-development@lists.sourceforge.net; Fri, 03 Jan 2014 18:16:50 +0000 Received: by mail-pb0-f65.google.com with SMTP id rq2so12845193pbb.0 for ; Fri, 03 Jan 2014 10:16:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.182.199 with SMTP id eg7mr97127086pac.135.1388773003501; Fri, 03 Jan 2014 10:16:43 -0800 (PST) Received: by 10.70.70.196 with HTTP; Fri, 3 Jan 2014 10:16:43 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Jan 2014 18:16:43 +0000 Message-ID: From: Tier Nolan To: bitcoin-development Content-Type: multipart/alternative; boundary=047d7bd6c70a8c23ee04ef14e9c2 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Vz9If-0000ew-Dh Subject: Re: [Bitcoin-development] An idea for alternative payment scheme X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:16:50 -0000 --047d7bd6c70a8c23ee04ef14e9c2 Content-Type: text/plain; charset=ISO-8859-1 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 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 > > --047d7bd6c70a8c23ee04ef14e9c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The random number that the buyer uses could be genera= ted from a root key too.

This would allow them to regener= ate all random numbers that they used and recreate their receipts.=A0 The m= aster root would have to be stored on your computer though.

The payment protocol is supposed to do something like this a= lready though.


On Fri, Jan 3, 2014 at 6:00 PM, Nadav Ivgi <nadav@shesek.= info> wrote:
I had an idea for a pa= yment scheme that uses key derivation, but instead of the payee deriving th= e addresses, the payer would do it.

It would work like that:
  1. The payee pu= blishes his master public key
  2. The payer generates a random "receipt number" (say, 25 r= andom bytes)
  3. The payer derives an address from the master publi= c key using the receipt number and pays to it
  4. The payer sends t= he receipt to the payee
  5. The payee derives a private key with that receipt and adds it to h= is 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 pay= ment 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 a= s 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 allow= s the payer prove to a third-party that the payment was made to that someon= e. 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 rec= eipt numbers means losing access to your funds, they are random and there&#= 39;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 Bitco= in 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<= br> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynami= cs Pro!
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7bd6c70a8c23ee04ef14e9c2--