Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2011-10-26 🗒️ Summary of this message: The proposal to ...
📅 Original date posted:2011-10-26
🗒️ Summary of this message: The proposal to introduce a standard multikey payment that hides the address could cause problems for projects like blockexplorer, bitcoin-js, and others.
📝 Original message:On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager <gronager at ceptacle.com> wrote:
> I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the addr to tx mapping:
The additional material _IS_ then part of the private key. It's not
something seperate. Its something you need to know in order to author
the address. This was fundamentally my argument. Not that you could
hide information, but that information was already hidden.
Right now under conventional uses I can't identify all the
transactions that land in your wallet, because I don't know the keys
it contains. With the proposal it's the same situation.
> This possibility is used today in:
> * blockexplorer
> * bitcoin-js
> * my own tiered implementation for thin clients
[snip]
> So, if we introduce a standard (multikey) payment that hides the address (or makes it overly complicated to extract it) it will be a major problem for the projects that I listed above.
These projects will be able to use the _same_ procedure to extract the
identifying information. Except now instead of
ripemd160(sha256(pubkey)) it will be more like ripemd160(sha256([some
extra bytes generated by the wallet holder]||pubkey)) that you
extract. If the former is not a problem for these applications, why
is the latter?
🗒️ Summary of this message: The proposal to introduce a standard multikey payment that hides the address could cause problems for projects like blockexplorer, bitcoin-js, and others.
📝 Original message:On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager <gronager at ceptacle.com> wrote:
> I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the addr to tx mapping:
The additional material _IS_ then part of the private key. It's not
something seperate. Its something you need to know in order to author
the address. This was fundamentally my argument. Not that you could
hide information, but that information was already hidden.
Right now under conventional uses I can't identify all the
transactions that land in your wallet, because I don't know the keys
it contains. With the proposal it's the same situation.
> This possibility is used today in:
> * blockexplorer
> * bitcoin-js
> * my own tiered implementation for thin clients
[snip]
> So, if we introduce a standard (multikey) payment that hides the address (or makes it overly complicated to extract it) it will be a major problem for the projects that I listed above.
These projects will be able to use the _same_ procedure to extract the
identifying information. Except now instead of
ripemd160(sha256(pubkey)) it will be more like ripemd160(sha256([some
extra bytes generated by the wallet holder]||pubkey)) that you
extract. If the former is not a problem for these applications, why
is the latter?