Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-22 📝 Original message:On Friday, April 24, 2015 ...
📅 Original date posted:2015-10-22
📝 Original message:On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote:
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
Sorry for the late review. I'm concerned with the "notification address"
requirement, which entails address reuse and blockchain spam. Since it entails
address reuse, the recipient is forced to either leave them unspent forever
(bloating the UTXO set), or spend it which potentially compromises the private
key, and (combined with the payment code) possibly as much as the entire
wallet.
Instead, I suggest making it a single zero-value OP_RETURN output with two
pushes: 1) a hash of the recipient's payment code, and 2) the encrypted
payment code. This can be searched with standard bloom filters, or indexed
with whatever other optimised algorithms are desired. At the same time, it
never uses any space in the UTXO set, and never needs to be
spent/mixed/dusted.
Luke
📝 Original message:On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote:
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
Sorry for the late review. I'm concerned with the "notification address"
requirement, which entails address reuse and blockchain spam. Since it entails
address reuse, the recipient is forced to either leave them unspent forever
(bloating the UTXO set), or spend it which potentially compromises the private
key, and (combined with the payment code) possibly as much as the entire
wallet.
Instead, I suggest making it a single zero-value OP_RETURN output with two
pushes: 1) a hash of the recipient's payment code, and 2) the encrypted
payment code. This can be searched with standard bloom filters, or indexed
with whatever other optimised algorithms are desired. At the same time, it
never uses any space in the UTXO set, and never needs to be
spent/mixed/dusted.
Luke