<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 06/19/2013 02:36 PM, Adam Back wrote:<br>
    <blockquote
      cite="mid:20130619183657.GA16708@netbook.cypherspace.org"
      type="cite">This maybe simpler and trivially compatible with
      existing type2 public keys
      <br>
      (ones that are multiples of a parent public key): send an ECDSA
      signature of
      <br>
      the multiplier, and as we know you can compute ("recover") the
      parent public
      <br>
      key from an the ECDSA signature made using it.
      <br>
      <br>
      Adam
      <br>
      <br>
      On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
      <br>
      <blockquote type="cite">[q-th root with unknown no discrete log
        artefact]
        <br>
        <br>
        If it was a concern I guess you could require a proof of
        knowledge of
        <br>
        discrete log.&nbsp; ie as well as public key parent, multiplier the
        address must
        <br>
        include ECDSA sig or Schnorr proof of knowledge (which both
        demonstrate
        <br>
        knowledge of the discrete log of Q to base G.)
        <br>
      </blockquote>
    </blockquote>
    <br>
    It's a cool trick but requiring a signature on each multiplier
    defeats one of the purposes of a deterministic wallet.&nbsp; I don't want
    to have to explicitly export a whole bunch of signatures from my
    offline system just to exercise this address option.&nbsp; The "observer
    wallet" should be able to do anything it needs to on its own,
    without help from the offline wallet.&nbsp; <br>
    <br>
    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...?&nbsp; If all you want to do is prove that <i>someone</i>
    owns that private key, you could send {Sign(MagicString),
    Multiplier}.&nbsp;&nbsp; So it becomes one signature operation <b>per wallet</b>,
    but creating new wallets would require going back to the offline
    computer for that one-time signature.&nbsp; That's better than the
    alternative, but it's still extra bloat for the wallet apps.<br>
    <br>
    Either way, I'm not convinced that these are a problem for the
    specified use cases I outlined.&nbsp;&nbsp; In cases where you have a
    persistent business relationship, they need to verify the parent
    public key exchange anyway.&nbsp; 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.&nbsp; Or it is transmitted and the payer
    verifies it's correct.&nbsp; 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.&nbsp; <br>
    <br>
    In the case that a business is checking whether the cashout address
    of a customer is the same as the last time:&nbsp; 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.&nbsp; 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.<br>
    <br>
    -Alan<br>
    <br>
    <br>
  </body>
</html>