Nadav Ivgi [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-03 📝 Original message:I had an idea for a ...
📅 Original date posted:2014-01-03
📝 Original message: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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140103/312ac06c/attachment.html>;
📝 Original message: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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140103/312ac06c/attachment.html>;