📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 02:36 PM, Adam Back wrote:
> This maybe simpler and trivially compatible with existing type2 public
> keys
> (ones that are multiples of a parent public key): send an ECDSA
> signature of
> the multiplier, and as we know you can compute ("recover") the parent
> public
> key from an the ECDSA signature made using it.
>
> Adam
>
> On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
>> [q-th root with unknown no discrete log artefact]
>>
>> If it was a concern I guess you could require a proof of knowledge of
>> discrete log. ie as well as public key parent, multiplier the
>> address must
>> include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
>> knowledge of the discrete log of Q to base G.)
It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet. I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option. The "observer wallet" should be
able to do anything it needs to on its own, without help from the
offline wallet.
Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...? If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}. So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature. That's better than the alternative, but it's still
extra bloat for the wallet apps.
Either way, I'm not convinced that these are a problem for the specified
use cases I outlined. In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway. After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store. Or it
is transmitted and the payer verifies it's correct. Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys.
In the case that a business is checking whether the cashout address of a
customer is the same as the last time: if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation. If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/55223863/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:03:32
in reply to nevent1q…l4hw
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:03:32Event JSON
{
"id": "ef8d18a9ef776faffdfb1c378417c85222ddde6acc1870495114c0a1b1cc1d3c",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686150212,
"kind": 1,
"tags": [
[
"e",
"60c63b2d935c09c2d6c618c7776de45a3225391d6d5c2bbb728d2b54da18fc56",
"",
"root"
],
[
"e",
"f67b28f715f707115028dd9d41f9c4c82a2e58f6b7e6fef89fea70773d50805d",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2013-06-19\n📝 Original message:On 06/19/2013 02:36 PM, Adam Back wrote:\n\u003e This maybe simpler and trivially compatible with existing type2 public\n\u003e keys\n\u003e (ones that are multiples of a parent public key): send an ECDSA\n\u003e signature of\n\u003e the multiplier, and as we know you can compute (\"recover\") the parent\n\u003e public\n\u003e key from an the ECDSA signature made using it.\n\u003e\n\u003e Adam\n\u003e\n\u003e On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:\n\u003e\u003e [q-th root with unknown no discrete log artefact]\n\u003e\u003e\n\u003e\u003e If it was a concern I guess you could require a proof of knowledge of\n\u003e\u003e discrete log. ie as well as public key parent, multiplier the\n\u003e\u003e address must\n\u003e\u003e include ECDSA sig or Schnorr proof of knowledge (which both demonstrate\n\u003e\u003e knowledge of the discrete log of Q to base G.)\n\nIt's a cool trick but requiring a signature on each multiplier defeats\none of the purposes of a deterministic wallet. I don't want to have to\nexplicitly export a whole bunch of signatures from my offline system\njust to exercise this address option. The \"observer wallet\" should be\nable to do anything it needs to on its own, without help from the\noffline wallet. \n\nUnless you mean that there is a one-time signature from the offline\ncomputer that works for all addresses, that can be exported with the\nobserver wallet...? If all you want to do is prove that /someone/ owns\nthat private key, you could send {Sign(MagicString), Multiplier}. So\nit becomes one signature operation *per wallet*, but creating new\nwallets would require going back to the offline computer for that\none-time signature. That's better than the alternative, but it's still\nextra bloat for the wallet apps.\n\nEither way, I'm not convinced that these are a problem for the specified\nuse cases I outlined. In cases where you have a persistent business\nrelationship, they need to verify the parent public key exchange\nanyway. After that, the software doesn't technically require the\ntransmission of the PubKey, it only needs the Name/ID of the party and\nthe multiplier and it will fetch the PubKey from its data store. Or it\nis transmitted and the payer verifies it's correct. Computing an\nalternate {PubKey', Mult'} that produces the same address and then using\nit in a MitM attack doesn't work here if the two parties pre-verified\nthe public keys. \n\nIn the case that a business is checking whether the cashout address of a\ncustomer is the same as the last time: if the first payout was not\nreplaced by an attacker, then the business already has the correct\npublic key in their DB and a replacement of further payout requests will\nfail validation. If the first payout was replaced... well that could've\nbeen done anyway (with or without this alternate form), and the customer\nwouldn't have received their money and the whole process would be\nflagged and terminated before further transactions.\n\n-Alan\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/55223863/attachment.html\u003e",
"sig": "603983dfe08b70366d564054b793b33b10e6040d40f88465665dff502098355caeeae2a2b76a674478f51c7bf2027df09618abfe4bc5a077818aaf09d951c85a"
}