shesek



Offline



Activity: 24

Merit: 0







NewbieActivity: 24Merit: 0 Alternative payment scheme January 02, 2014, 03:39:14 PM

Last edit: January 03, 2014, 03:51:08 PM by shesek #1



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

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 (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 and doesn't require any protocol 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? 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:Advantages:Disadvantages:What do you think?

oleganza



Offline



Activity: 200

Merit: 100





Software design and user experience.







Full MemberActivity: 200Merit: 100Software design and user experience. Re: Alternative payment scheme January 02, 2014, 04:16:57 PM #2 How does it increase privacy compared to payee generating new address for every payment? If you see that payee reuses the address for your payments, what's cheaper for payee: to start generating new addresses or adopting more complex scheme involved receiving some data from the payer (instead of just observing the blockchain)? Bitcoin analytics: blog.oleganza.com / 1TipsuQ7CSqfQsjA9KU5jarSB1AnrVLLo

shesek



Offline



Activity: 24

Merit: 0







NewbieActivity: 24Merit: 0 Re: Alternative payment scheme January 02, 2014, 04:33:42 PM #3 Quote from: oleganza on January 02, 2014, 04:16:57 PM How does it increase privacy compared to payee generating new address for every payment? If you see that payee reuses the address for your payments, what's cheaper for payee: to start generating new addresses or adopting more complex scheme involved receiving some data from the payer (instead of just observing the blockchain)?



The main advantage is that the payee doesn't have to be active and provide addresses every time someone wants to make a payment. The payer can independently and without any action from the payee create an address and make the payment. As I wrote above, this makes it easier for cases like an open source project development fund, where people can just send payments without talking with the payee first. The main advantage is that the payee doesn't have to be active and provide addresses every time someone wants to make a payment. The payer can independently and without any action from the payee create an address and make the payment. As I wrote above, this makes it easier for cases like an open source project development fund, where people can just send payments without talking with the payee first.

ffe



Offline



Activity: 305

Merit: 250









Sr. MemberActivity: 305Merit: 250 Re: Alternative payment scheme January 05, 2014, 06:49:34 AM #4 Quote from: shesek on January 02, 2014, 03:39:14 PM Its a really thin abstraction layer and doesn't require any protocol changes



It does require the payee to publish his full public key. That is not common practice today. Bitcoin receive addresses are hashes of public keys and can't be used to derive related keys.



Nice idea, though. See this related topic:



Quote from: ffe on April 11, 2013, 06:39:01 AM This added note is to show how Alice allows a server fronting her business to verify that she owns a blinded transaction without requiring the server to have her secret key thus protecting her wallet if the server is hacked.



Its done this way:



Alice generates a secondary key used to verify blinded transactions from her master key. Her private key is a. She generates a verifier private part b by hashing a, b = Hash(a). Let the public part of a be A and the public part of b be B. A = aQ and B = bQ. The doublet A,B is published as the blind transaction enabling public key. A,B and the private verifier b are given to the server she is using to manage monitoring the block chain for her. With b the server can verify transaction ownership but not spend. Hacking the server does not give you a.



A sender would recognize A,B as a blindable key. The sender then generates "X" as follows: s = Hash(m,yB); X = sA. The sender sends coin to X.



A server holding verifier "b" can check every new transaction for the property that s = Hash(m,bY) and X = sA to know to add the coins to the balance in Alices wallet. (Note yB = bY). Notice that the server does not need a to verify the transaction. The server can verify X but cannot generate the private part of X.



Alice later generates "x", the private part of "X", as follows: She is given m and Y from the transaction; then s = Hash(m,bY); x = sa (modulo a large prime determined by the ECC); She can check that X = xQ. Alice can now sign a prepared transaction using x and publish the signed transaction when spending.

It does require the payee to publish his full public key. That is not common practice today. Bitcoin receive addresses are hashes of public keys and can't be used to derive related keys.Nice idea, though. See this related topic: