public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [Bitcoin-development] Reusable payment codes
@ 2015-04-24 20:00 Justus Ranvier
  2015-04-24 20:58 ` Gregory Maxwell
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Justus Ranvier @ 2015-04-24 20:00 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1


https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki


This link contains an RFC for a new type of Bitcoin address called a
"payment code"


Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
addresses which provide useful features such as positively identifying
senders to recipients and automatically providing for transaction refunds.


Payment codes can be publicly advertised and associated with a real-life
identity without causing a loss of financial privacy.


Compared to stealth addresses, payment codes require less blockchain data
storage.


Payment codes require 65 bytes of OP_RETURN data per sender-recipient pair,
while stealth addresses require 40 bytes per transaction.


-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1


iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd

JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa

Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz

QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG

NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR

o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo

2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h

/wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9

EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET

n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI

OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+

SGApMBd4Q89fKzL2djae

=Dypr

-----END PGP SIGNATURE-----

[-- Attachment #2: Type: text/html, Size: 2586 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] Reusable payment codes
    2015-04-24 20:00 [Bitcoin-development] Reusable payment codes Justus Ranvier
  @ 2015-04-24 20:58 ` Gregory Maxwell
         [not found]   ` <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
         [not found] ` <1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>
    2015-06-16 16:26 ` [Bitcoin-development] " odinn
    2 siblings, 1 reply; 17+ messages in thread
  From: Gregory Maxwell @ 2015-04-24 20:58 UTC (permalink / raw)
    To: Justus Ranvier; +Cc: Bitcoin Dev
  
  On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
  <justus.ranvier@monetas•net> wrote:
  > https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
  >
  > This link contains an RFC for a new type of Bitcoin address called a
  > "payment code"
  >
  > Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
  > addresses which provide useful features such as positively identifying
  > senders to recipients and automatically providing for transaction refunds.
  
  So this requires making dust payments to a constantly reused address
  in order to (ab)use the blockchain as a messaging layer.
  
  Indeed, this is more SPV compatible; but it seems likely to me that
  _in practice_ it would almost completely undermine the privacy the
  idea hoped to provide; because you'd have an observable linkage to a
  highly reused address.
  
  It would also more than double the data sent for the application where
  'stealth addresses' are most important: one-time anonymous donations
  (in other contexts; you have two way communication between the
  participants, and so you can just given them a one off address without
  singling in the public network.)
  
  > Alice selects the first exposed public key of the first input of the transaction
  
  So this creates strong "binding" that we would really strongly like to
  avoid in the network; basically what this says is that "You can only
  pay to person X if you use scheme Y for your own Bitcoins"-- who says
  any of your inputs have a ECDH pubkey at all? Of if they do, who says
  its one that you have access to the private key for for use in this
  scheme (e.g. it could be in a HSM that only signs according to a
  policy).   We should avoid creating txout features that restrict what
  kind of scriptPubkey the sender can use, or otherwise we'll never be
  able to deploy new signature features. (We can see how long P2SH took
  to gain adoption because some wallets refused to implement sending to
  it, even though doing so was trivial).
  
  This kind of binding was intentionally designed out of the stealth
  address proposal;  I think this scheme can be made to work without any
  increase in size by reusing the payment code as the ephemeral public
  key (or actually being substantially smaller e.g. use the shared
  secret as the chain code, but I should give it more thought)
  
  Also, SPV wallets do not need to have access to the public keys being
  spent by a particular transaction they learn about; providing that
  access is fundamentally expensive and pushes things back towards
  centralization.
  
  > in uncompressed DER format
  
  This is fundamentally more expensive to compute; please don't specify
  "uncompressed".
  
  This appears incompatible with multisignature; which is unfortunate.
  
  I do very much like the fact that this scheme establishes a shared
  chain once and then doesn't need to reestablish; this was one of the
  improvements I wanted for the stealth address.
  
  I'm disappointed that there isn't any thought given to solving the
  scanning privacy without forcing non-private pure-overhead messaging
  transactions on heavily reused addresses. Are you aware of the IBE
  approach that allows someone to request a third party scan for them
  with block by block control over their delegation of scanning?
  
  
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• • [parent not found: <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>]

  • • * [Bitcoin-development] Fwd:  Reusable payment codes
             [not found]   ` <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
      @ 2015-04-25  0:20     ` Justus Ranvier
             [not found]     ` <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
        1 sibling, 0 replies; 17+ messages in thread
      From: Justus Ranvier @ 2015-04-25  0:20 UTC (permalink / raw)
        To: Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 3849 bytes --]
      
      On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell@gmail•com>
      wrote:
      
      > So this requires making dust payments to a constantly reused address
      > in order to (ab)use the blockchain as a messaging layer.
      >
      > Indeed, this is more SPV compatible; but it seems likely to me that
      > _in practice_ it would almost completely undermine the privacy the
      > idea hoped to provide; because you'd have an observable linkage to a
      > highly reused address.
      >
      
      I agree that the output associated with notification transactions would
      require special handling to avoid privacy leaks. At a minimum they'd
      require mixing or being donated to miners as a transaction fee.
      
      
      >
      > It would also more than double the data sent for the application where
      > 'stealth addresses' are most important: one-time anonymous donations
      > (in other contexts; you have two way communication between the
      > participants, and so you can just given them a one off address without
      > singling in the public network.)
      >
      
      Communication is only one way, except for the case in which the recipient
      wants to send a refund. Assuming no refund and only a single anonymous
      donation in the lifetime of the sender's identity, payment codes would
      require 65 bytes vs 40 bytes for stealth addresses.
      
      As soon as the sender sends more than one donation to the same recipient,
      payment codes show an space advantage over stealth addresses.
      
      This kind of binding was intentionally designed out of the stealth
      >
      address proposal;  I think this scheme can be made to work without any
      > increase in size by reusing the payment code as the ephemeral public
      > key (or actually being substantially smaller e.g. use the shared
      > secret as the chain code, but I should give it more thought)
      >
      
      With 97 byte standard OP_RETURN values the ephemeral public
      key could be appended to the chain code, but that's undesirable for other
      reasons.
      
      This is fundamentally more expensive to compute; please don't specify
      > "uncompressed".
      >
      
      Taking the SHA512 of something less than 512 bits seemed wrong.
      
      
      > This appears incompatible with multisignature; which is unfortunate.
      >
      
      I agree. I could not find a straightforward way to express a multisignature
      payment code in less than 80 bytes.
      
      
      > I'm disappointed that there isn't any thought given to solving the
      > scanning privacy without forcing non-private pure-overhead messaging
      > transactions on heavily reused addresses. Are you aware of the IBE
      > approach that allows someone to request a third party scan for them
      > with block by block control over their delegation of scanning?
      >
      
      I suspect this is a case where we just can't have all the features we want.
      
      In this proposal I optimized for non-reliance on third party services and a
      guaranteed ability to recover spendable funds from a seed backup.
      
      Gaining those two features resulted in some tradeoffs as you noted, but I
      think there are enough benefits to make them worthwhile.
      
      In particular, payment codes could be the basis for a Heartbleed-free
      payment protocol that can positively identify customers and automatically
      provide refund capabilities in a merchant-customer relationship. A merchant
      only requires one payment code which they can safely use for all their
      customers, meaning they only ever need to associate 65 bytes with their
      identity to allow customers to make sure they are paying the right entity.
      
      Exchanges could restrict bitcoin withdrawals to a single payment code known
      to be associated with their identified customer. This would make thefts
      easier (without involving address reuse as in locking withdrawals to a
      single P2PKH address).
      
      In some jurisdictions the ability to prove that withdrawals are sent to a
      positively-identified party, rather than arbitrary third parties, might
      move some Bitcoin businesses out of money transmitter territory into less
      onerous regulatory situations.
      
      [-- Attachment #2: Type: text/html, Size: 5865 bytes --]
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • [parent not found: <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>]

    • • * [Bitcoin-development] Fwd:  Reusable payment codes
               [not found]     ` <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
        @ 2015-04-25  0:21       ` Justus Ranvier
          0 siblings, 0 replies; 17+ messages in thread
        From: Justus Ranvier @ 2015-04-25  0:21 UTC (permalink / raw)
          To: Bitcoin Dev
        
        [-- Attachment #1: Type: text/plain, Size: 4439 bytes --]
        
        I have pushed an updated version of the proposal which incorporates some of
        the received feedback and adds a note about the consequences of sharing a
        payment code-enabled walled on multiple devices:
        
        https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
        
        https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
        
        On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier@monetas•net
        > wrote:
        
        >
        >
        > On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell@gmail•com>
        > wrote:
        >
        >> So this requires making dust payments to a constantly reused address
        >> in order to (ab)use the blockchain as a messaging layer.
        >>
        >> Indeed, this is more SPV compatible; but it seems likely to me that
        >> _in practice_ it would almost completely undermine the privacy the
        >> idea hoped to provide; because you'd have an observable linkage to a
        >> highly reused address.
        >>
        >
        > I agree that the output associated with notification transactions would
        > require special handling to avoid privacy leaks. At a minimum they'd
        > require mixing or being donated to miners as a transaction fee.
        >
        >
        >>
        >> It would also more than double the data sent for the application where
        >> 'stealth addresses' are most important: one-time anonymous donations
        >> (in other contexts; you have two way communication between the
        >> participants, and so you can just given them a one off address without
        >> singling in the public network.)
        >>
        >
        > Communication is only one way, except for the case in which the recipient
        > wants to send a refund. Assuming no refund and only a single anonymous
        > donation in the lifetime of the sender's identity, payment codes would
        > require 65 bytes vs 40 bytes for stealth addresses.
        >
        > As soon as the sender sends more than one donation to the same recipient,
        > payment codes show an space advantage over stealth addresses.
        >
        > This kind of binding was intentionally designed out of the stealth
        >>
        > address proposal;  I think this scheme can be made to work without any
        >> increase in size by reusing the payment code as the ephemeral public
        >> key (or actually being substantially smaller e.g. use the shared
        >> secret as the chain code, but I should give it more thought)
        >>
        >
        > With 97 byte standard OP_RETURN values the ephemeral public
        > key could be appended to the chain code, but that's undesirable for other
        > reasons.
        >
        > This is fundamentally more expensive to compute; please don't specify
        >> "uncompressed".
        >>
        >
        > Taking the SHA512 of something less than 512 bits seemed wrong.
        >
        >
        >> This appears incompatible with multisignature; which is unfortunate.
        >>
        >
        > I agree. I could not find a straightforward way to express a
        > multisignature payment code in less than 80 bytes.
        >
        >
        >> I'm disappointed that there isn't any thought given to solving the
        >> scanning privacy without forcing non-private pure-overhead messaging
        >> transactions on heavily reused addresses. Are you aware of the IBE
        >> approach that allows someone to request a third party scan for them
        >> with block by block control over their delegation of scanning?
        >>
        >
        > I suspect this is a case where we just can't have all the features we want.
        >
        > In this proposal I optimized for non-reliance on third party services and
        > a guaranteed ability to recover spendable funds from a seed backup.
        >
        > Gaining those two features resulted in some tradeoffs as you noted, but I
        > think there are enough benefits to make them worthwhile.
        >
        > In particular, payment codes could be the basis for a Heartbleed-free
        > payment protocol that can positively identify customers and automatically
        > provide refund capabilities in a merchant-customer relationship. A merchant
        > only requires one payment code which they can safely use for all their
        > customers, meaning they only ever need to associate 65 bytes with their
        > identity to allow customers to make sure they are paying the right entity.
        >
        > Exchanges could restrict bitcoin withdrawals to a single payment code
        > known to be associated with their identified customer. This would make
        > thefts easier (without involving address reuse as in locking withdrawals to
        > a single P2PKH address).
        >
        > In some jurisdictions the ability to prove that withdrawals are sent to a
        > positively-identified party, rather than arbitrary third parties, might
        > move some Bitcoin businesses out of money transmitter territory into less
        > onerous regulatory situations.
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 6882 bytes --]
        
        ^ permalink raw reply	[flat|nested] 17+ messages in thread

• [parent not found: <1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>]

• • [parent not found: <CAHabJ+NDqMN-rQ1BN1TfOjGLQHH-3Wd28LdoF95Agn4HdRrThg@mail.gmail.com>]

  • • * [Bitcoin-development] Fwd:  Reusable payment codes
             [not found]   ` <CAHabJ+NDqMN-rQ1BN1TfOjGLQHH-3Wd28LdoF95Agn4HdRrThg@mail.gmail.com>
      @ 2015-04-25  0:22     ` Justus Ranvier
             [not found]       ` <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
        0 siblings, 1 reply; 17+ messages in thread
      From: Justus Ranvier @ 2015-04-25  0:22 UTC (permalink / raw)
        To: Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 2897 bytes --]
      
      Taking the hash of the secret would then require an extra step to make sure
      the hash is valid for secp256k1.
      
      Using the x value directly avoids the need for that check.
      
      On Fri, Apr 24, 2015 at 10:35 PM, Patrick Mccorry (PGR) <
      patrick.mccorry@newcastle•ac.uk> wrote:
      
      >  When computing the diffie Hellman secret - why do you choose the x
      > co-ordinate instead of the hash of the secret which is standard practice
      > for stealth addresses
      >
      > Sent from my iPhone
      >
      > On 24 Apr 2015, at 21:27, Justus Ranvier <justus.ranvier@monetas•net>
      > wrote:
      >
      >   -----BEGIN PGP SIGNED MESSAGE-----
      >
      > Hash: SHA1
      >
      >
      >
      > https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
      >
      >
      >  This link contains an RFC for a new type of Bitcoin address called a
      > "payment code"
      >
      >
      >  Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
      > addresses which provide useful features such as positively identifying
      > senders to recipients and automatically providing for transaction refunds.
      >
      >
      >  Payment codes can be publicly advertised and associated with a real-life
      > identity without causing a loss of financial privacy.
      >
      >
      >  Compared to stealth addresses, payment codes require less blockchain
      > data storage.
      >
      >
      >  Payment codes require 65 bytes of OP_RETURN data per sender-recipient
      > pair, while stealth addresses require 40 bytes per transaction.
      >
      >
      >  -----BEGIN PGP SIGNATURE-----
      >
      > Version: GnuPG v1
      >
      >
      >  iQIcBAEBAgAGBQJVOqCRAAoJECpf2nDq2eYjluEP/RVJk+miDIihY4ilIvUbKvMd
      >
      > JLLqHr7Q1dlZyMIG/UqVWdoP5hzg/16B+q2iAB9jXozPnrDp0mggBh6rIGroevAa
      >
      > Kqfrs+Rrog1w9auhd67LWORDqav6YIrjTJIxdLxe11IEiq5rWbHPNUEDMzdEmHbz
      >
      > QfTH7KWAP2BasO5ETXcfu6BcccrXZ3XOKLON2h3NGD/cEDizY+uT2k3QN54z+KxG
      >
      > NB9scKbzVvsJwkyBrgbV+As9H3k6PnFsojYgAaE9gkp7D2+ahjzUiOH5rv6TbbYR
      >
      > o2X5MOiTY2/YZEqZPG7IR03ZAgeLVCvXXysjPOfzUKbmTF4w849sm8BuhixzDXHo
      >
      > 2V/HHKoGclIohcODBCWi0tVQXshZt4QkCNJBW5o3nL6Nn2YOp6hmw8YKAHnw3E7h
      >
      > /wIgk5f+NOLl/iIxoAxAdavEj5P6N4ic+OB6MAjnhEilWfBvCIpqWLGNvrtOhEa9
      >
      > EnPHcgb4ILBu4OionJhsNpJ/O95C0OEypMm25MIS+rQcV4Uxe5IOS2OuT/GreLET
      >
      > n/7Y0mJbqYbLBjVsfS+DNjvsgyJl5AxhcMrdVyXJjSYVcCoRhcoX5Ceidd+YkbHI
      >
      > OMs5f63tM1Rgi/WY4Ct80SD5EbULZuu8j1KJ9HPGuMt081JSBH+L5isiKuazPeO+
      >
      > SGApMBd4Q89fKzL2djae
      >
      > =Dypr
      >
      > -----END PGP SIGNATURE-----
      >
      >
      > ------------------------------------------------------------------------------
      > One dashboard for servers and applications across Physical-Virtual-Cloud
      > Widest out-of-the-box monitoring support with 50+ applications
      > Performance metrics, stats and reports that give you Actionable Insights
      > Deep dive visibility with transaction tracing using APM Insight.
      > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
      >
      >  _______________________________________________
      > Bitcoin-development mailing list
      > Bitcoin-development@lists•sourceforge.net
      > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
      >
      >
      
      [-- Attachment #2: Type: text/html, Size: 4979 bytes --]
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

    • • [parent not found: <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>]

      • • * Re: [Bitcoin-development] Fwd: Reusable payment codes
                 [not found]       ` <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
          @ 2015-04-25  2:34         ` Justus Ranvier
            2015-04-26 12:58           ` Mike Hearn
            0 siblings, 1 reply; 17+ messages in thread
          From: Justus Ranvier @ 2015-04-25  2:34 UTC (permalink / raw)
            To: Gregory Maxwell; +Cc: Bitcoin Dev
          
          [-- Attachment #1: Type: text/plain, Size: 4938 bytes --]
          
          On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
          
          > On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier
          > <justus.ranvier@monetas•net> wrote:
          > > Taking the hash of the secret would then require an extra step to make
          > sure
          > > the hash is valid for secp256k1.
          >
          > The x value may not be a valid member of the group, effectively the
          > same as with a hash. Its also very unequally distributed, as only
          > about half the possible values are points on the curve.
          
          
          ack
          
          
          > > With 97 byte standard OP_RETURN values the ephemeral public
          > > key could be appended to the chain code, but that's undesirable for
          > other reasons.
          >
          > Can you elaborate?  Storing a ~33 byte (deterministically generated)
          > ephemeral key should be all that is required. Everything else,
          > including the chain code could be derived from it. What reason do you
          > have to include additional data?
          >
          
          The goal of the notification transaction is to send the same payment code
          to every recipient, but obscure the identity of the sender of the
          notification transaction from third party blockchain observers.
          
          The shared secret is used for that purpose, and the sender's public key
          used for ECDH can't be one derived from the payment code since the
          recipient doesn't yet know the payment code.
          
          The notification transaction needs to communicate the 65 byte payment code
          along with one ephemeral public key used for ECDH. If that ephemeral key is
          not located in a signature script, it has to be somewhere else (such as in
          the same OP_RETURN output as the payment code.)
          
          
          > > Taking the SHA512 of something less than 512 bits seemed wrong.
          >
          > Why should it?  Adding the Y does not increase the entropy at all.  As
          > an aside, I think this can be reformulated to only need 256 bits of
          > output, and then the need for yet-another-hash-function could be
          > avoided in some cases.
          >
          
          Already fixed in
          https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521
          but it would be good to get confirmation of whether the way I fixed it is
          valid.
          
          > In this proposal I optimized for non-reliance on third party services
          >
          > The requirement for inputs is a guaranteed dependency on third party
          > services; so if thats whats being optimized for here it must go (well,
          > I think it must go for the reason of avoiding blocking users from
          > using other schemes to control their coins too..).
          >
          
          I'm not sure what you mean by "the requirement for inputs is a guaranteed
          dependency on third party
          services"
          
          At the proposal currently stands, an SPV wallet will have no trouble
          sending or receiving notification transactions without access to a third
          party service. The recipient just needs to see the transactions associated
          with its notification address.
          
          The point about restricting the types of scripts used as inputs is valid,
          but I think workarounds are available. If nothing else, the sender can make
          a suitable input using it's own (suitably mixed) coins first.
          
          > I agree. I could not find a straightforward way to express a
          > multisignature payment code in less than 80 bytes.
          >
          > A prior stealth address proposal here handled them fine with only a
          > single ephemeral point in the op_return. It does result in a longer
          > address (is that what you're referring to with '80 bytes'?)
          >
          
          I considered defining an additional path level for deterministic m-of-n
          multisig and adding a few bytes to the payment code to express those
          parameters, but thought it would be too limiting since it would preclude
          multisig with truly independent keys. It is a thing that could be done,
          however.
          
          > Exchanges could restrict bitcoin withdrawals to a single payment code
          > known to be associated with their identified customer.
          > > In some jurisdictions the ability to prove that withdrawals are sent to
          > a positively-identified party, rather than arbitrary third parties, might
          > move some Bitcoin businesses out of money transmitter territory into less
          > onerous regulatory situations.
          >
          > But this mandates horrible key management practices, reliance on a
          > single "hardcoded" private key which you cannot change; even if it
          > might be compromised or lost to the wind. It's less horrible than
          > sticking to a single address because it doesn't wedge privacy, I
          > agree; but care should be taken that a tortured dance for confused
          > regulatory cargo-cult reasons doesn't mandate people not engage in
          > sound practices like periodic key rotation. :)
          >
          
          Cold storage is still available (if admittedly less convenient than in
          traditional wallets).
          
          I would expect exchanges in practice to allow for payment codes to be
          changed, just with non-trivial waiting periods and plenty of human
          overview. It would be an infrequent event compared to the frequency of
          withdrawals.
          
          Various schemes which use public key authentication instead of passwords
          for web site authentication could be used to continually verify that the
          user hasn't lost access to the key.
          
          [-- Attachment #2: Type: text/html, Size: 6968 bytes --]
          
          ^ permalink raw reply	[flat|nested] 17+ messages in thread

        • • * Re: [Bitcoin-development] Fwd: Reusable payment codes
              2015-04-25  2:34         ` Justus Ranvier
            @ 2015-04-26 12:58           ` Mike Hearn
              2015-04-26 14:50             ` Justus Ranvier
              0 siblings, 1 reply; 17+ messages in thread
            From: Mike Hearn @ 2015-04-26 12:58 UTC (permalink / raw)
              To: Justus Ranvier; +Cc: Bitcoin Dev
            
            [-- Attachment #1: Type: text/plain, Size: 158 bytes --]
            
            Could you maybe write a short bit of text comparing this approach to
            extending BIP70 and combining it with a simple Subspace style
            store-and-forward network?
            
            [-- Attachment #2: Type: text/html, Size: 210 bytes --]
            
            ^ permalink raw reply	[flat|nested] 17+ messages in thread

          • • * Re: [Bitcoin-development] Fwd: Reusable payment codes
                2015-04-26 12:58           ` Mike Hearn
              @ 2015-04-26 14:50             ` Justus Ranvier
                0 siblings, 0 replies; 17+ messages in thread
              From: Justus Ranvier @ 2015-04-26 14:50 UTC (permalink / raw)
                To: Mike Hearn; +Cc: Bitcoin Dev
              
              [-- Attachment #1: Type: text/plain, Size: 787 bytes --]
              
              Payment codes establish the identity of the payer and allow for simpler
              methods for identifying the payee, and automatically provide the payee with
              the information they need to send a refund.
              
              If merchants and customers were using payment codes, they would not need
              the BIP70 equivalents.
              
              I think the best way to explain payment codes is that they add the missing
              "from address" to transactions which users want, but we've had to tell them
              they can't have.
              
              A payment code behaves much more like an email address than a traditional
              Bitcoin address.
              
              On Sun, Apr 26, 2015 at 2:58 PM, Mike Hearn <mike@plan99•net> wrote:
              
              > Could you maybe write a short bit of text comparing this approach to
              > extending BIP70 and combining it with a simple Subspace style
              > store-and-forward network?
              >
              
              [-- Attachment #2: Type: text/html, Size: 1158 bytes --]
              
              ^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] Reusable payment codes
    2015-04-24 20:00 [Bitcoin-development] Reusable payment codes Justus Ranvier
    2015-04-24 20:58 ` Gregory Maxwell
         [not found] ` <1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>
  @ 2015-06-16 16:26 ` odinn
    2015-06-16 17:46   ` Peter Todd
    2 siblings, 1 reply; 17+ messages in thread
  From: odinn @ 2015-06-16 16:26 UTC (permalink / raw)
    To: Justus Ranvier, Bitcoin Dev
  
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  This is very well done.
  
  Have you seen this discussion that I started regarding BIP 63?
  
  https://bitcointalk.org/index.php?topic=1083961.0
  
  I have no response from Peter Todd back on it other than "my time is
  better spent focusing on more fundemental issues" and "I've also got
  no-one interested in funding stealth address development right now,"
  when several people (myself included) offered to send donations to see
  the BIP (63) advance, no donation address was posted, so... waiting
  for him to act on that.
  
  I'm definitely supportive of seeing what you've written up here as
  Reusable payment codes move to draft in https://github.com/bitcoin/bips
  When you can, please write up something on bitcointalk as well.
  
  
  On 04/24/2015 01:00 PM, Justus Ranvier wrote:
  > Hash: SHA1
  > 
  > 
  > https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.m
  ediawiki
  >
  > 
  > 
  > This link contains an RFC for a new type of Bitcoin address called
  > a "payment code"
  > 
  > 
  > Payment codes are SPV-friendly alternatives to DarkWallet-style
  > stealth addresses which provide useful features such as positively
  > identifying senders to recipients and automatically providing for
  > transaction refunds.
  > 
  > 
  > Payment codes can be publicly advertised and associated with a
  > real-life identity without causing a loss of financial privacy.
  > 
  > 
  > Compared to stealth addresses, payment codes require less
  > blockchain data storage.
  > 
  > 
  > Payment codes require 65 bytes of OP_RETURN data per
  > sender-recipient pair, while stealth addresses require 40 bytes per
  > transaction.
  > 
  > 
  > 
  > 
  > 
  > ----------------------------------------------------------------------
  - --------
  >
  > 
  One dashboard for servers and applications across Physical-Virtual-Cloud
  > Widest out-of-the-box monitoring support with 50+ applications 
  > Performance metrics, stats and reports that give you Actionable
  > Insights Deep dive visibility with transaction tracing using APM
  > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
  > 
  > 
  > 
  > _______________________________________________ Bitcoin-development
  > mailing list Bitcoin-development@lists•sourceforge.net 
  > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  > 
  
  - -- 
  http://abis.io ~
  "a protocol concept to enable decentralization
  and expansion of a giving economy, and a new social good"
  https://keybase.io/odinn
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1
  
  iQEcBAEBAgAGBQJVgE4fAAoJEGxwq/inSG8CjgkH/i0aX4aJaOjrbI2xzWbPeL1T
  /APSvSqV0D610ljbw/MuRRFVagnK3lCs73fYolKw9uFG0cnwhIWJ53mCqPWhM5nL
  kIejDTHr9jQ2tbXrU2L481Oat1Z6vtdQj7LolXFfD3Ktqz+sqp//gBaC9EEZ5nOq
  4oz71Am58pf8+XGhtJk0+4XDXzFNd71bKKY+nMf9f3bwqNX93jHiF48hXwijFPC4
  MOZmYRh3Sf5LAVP5p1JY3aJRQv4M/W0L2RDC+GW8Ol997etQSGGLhESihNNPw1m8
  GEqJLBmUBkavzsRpZ009czfzL7EiCwsMbOrVw918o2Y9NnVpY9a9cBNB+UJgCmk=
  =wAGz
  -----END PGP SIGNATURE-----
  
  
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• • * Re: [Bitcoin-development] Reusable payment codes
      2015-06-16 16:26 ` [Bitcoin-development] " odinn
    @ 2015-06-16 17:46   ` Peter Todd
      2015-06-17  5:34     ` odinn
      0 siblings, 1 reply; 17+ messages in thread
    From: Peter Todd @ 2015-06-16 17:46 UTC (permalink / raw)
      To: odinn; +Cc: Justus Ranvier, Bitcoin Dev
    
    [-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
    
    On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
    > This is very well done.
    > 
    > Have you seen this discussion that I started regarding BIP 63?
    > 
    > https://bitcointalk.org/index.php?topic=1083961.0
    > 
    > I have no response from Peter Todd back on it other than "my time is
    > better spent focusing on more fundemental issues" and "I've also got
    > no-one interested in funding stealth address development right now,"
    > when several people (myself included) offered to send donations to see
    > the BIP (63) advance, no donation address was posted, so... waiting
    > for him to act on that.
    
    Sorry, but I'm looking at the huge amount of work that I'll likely have
    responding to the blocksize issue, so I think I'm inclined to shelve
    work on BIP63 for now.
    
    Feel free to take it up; a (>=2)-part standard describing the resuable
    codes aspect, and separately how the ephemeral key is transmitted to the
    recipient makes sense to me.
    
    -- 
    'peter'[:-1]@petertodd.org
    0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
    
    [-- Attachment #2: Digital signature --]
    [-- Type: application/pgp-signature, Size: 650 bytes --]
    
    ^ permalink raw reply	[flat|nested] 17+ messages in thread

  • • * Re: [Bitcoin-development] Reusable payment codes
        2015-06-16 17:46   ` Peter Todd
      @ 2015-06-17  5:34     ` odinn
        0 siblings, 0 replies; 17+ messages in thread
      From: odinn @ 2015-06-17  5:34 UTC (permalink / raw)
        To: Peter Todd; +Cc: Justus Ranvier, Bitcoin Dev
      
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1
      
      Peter, my response below
      
      On 06/16/2015 10:46 AM, Peter Todd wrote:
      > On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote:
      >> This is very well done.
      >>
      >> Have you seen this discussion that I started regarding BIP 63?
      >>
      >> https://bitcointalk.org/index.php?topic=1083961.0
      >>
      >> I have no response from Peter Todd back on it other than "my time is
      >> better spent focusing on more fundemental issues" and "I've also got
      >> no-one interested in funding stealth address development right now,"
      >> when several people (myself included) offered to send donations to se
      e
      >> the BIP (63) advance, no donation address was posted, so... waiting
      >> for him to act on that.
      > 
      > Sorry, but I'm looking at the huge amount of work that I'll likely hav
      e
      > responding to the blocksize issue, so I think I'm inclined to shelve
      > work on BIP63 for now.
      
      
      I seriously find this pretty sad... you said that paying rent was an
      issue and your time was better spent on "more fundamental issues..." but
      the very least you could do is post a donation address... Is there
      someone who was working with you closely on the concept who could take
      it up since you are not going to be working on it?
      
      > 
      > Feel free to take it up; a (>=2)-part standard describing the resuable
      > codes aspect, and separately how the ephemeral key is transmitted to t
      he
      > recipient makes sense to me.
      > 
      
      I don't want to camp on Justus's thread on reusable payment codes ~ but
      on the subject of BIP 63, it just did make sense to mention... so if
      someone does have interest in working on it... please go to
      https://bitcointalk.org/index.php?topic=1083961.0
      and reply there.
      
      
      - -- 
      http://abis.io ~
      "a protocol concept to enable decentralization
      and expansion of a giving economy, and a new social good"
      https://keybase.io/odinn
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1
      
      iQEcBAEBAgAGBQJVgQbMAAoJEGxwq/inSG8CD8gH/3jV+mLO9qv3t6JFxIvLMPtr
      slGbymQtuqfAC09b6ybx3p6u9I1o1Nb3IgK1riu/Z3AzHxlnuYVUxN3N5ns0zGnx
      F2WXs2suEa20YJkQ6dxZWLdNBjnUIEGGgXAit8X21LqVsqPfeZcocOWSeRDlePhk
      /HRFLVtMehqfqjbuFAaAewVZUyT4Bn+3IU74krqR3e3YA00/ym1C5xCE3/kHvKIL
      UF8EW9GgVYKuoyQdH3ICDwjiudwPOwIC4Ry0huaJgla43122RkwqYB+5kVr1583u
      dx3VW8vW8HyQZJF+vb8d3F57R6FC6zYtFhCe0IzDIh+6xQxStk5zosMNIrtPKp4=
      =h8Ib
      -----END PGP SIGNATURE-----
      
      
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Bitcoin-development] Reusable payment codes
@ 2015-04-27 14:53 Brian Deery
  2015-04-27 15:54 ` Justus Ranvier
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Brian Deery @ 2015-04-27 14:53 UTC (permalink / raw)
  To: bitcoin-development; +Cc: Justus Ranvier

[-- Attachment #1: Type: text/plain, Size: 2866 bytes --]

Hi Justus:

CC'ing mailing list because more bloom filter and HD wallet experts there
can chime in for some of these thoughts.  I refined some ideas we went over
earlier.

Here are some critiques/worries about the payment codes.

With identities explicitly tied to a payment code, bloom filter clients can
have identities tied to them.

1. There will be a 1:1 relationship between a payment code owner and their
identity.  Presumably the payment code would be strongly and publicly tied
to the identity.  This makes the notification address strongly tied to the
user.  An SPV client connecting to a full node who has a list of
notification address can tie an identity to a bloom filter and connecting
IP.

2. The client can use a bloom filter with a higher false positive rate.  An
active attacker can counter that by sending several payment codes to an
individual user.  The user would then add to their bloom filter all the
shared addresses between them and the attacker.  Even with a high false
positive filter, always matching all the attacker's payment codes would
strongly tie the user to the filter.



Here are some data savings and privacy addition ideas:

65 bytes -> 0 bytes extra.

1. Can you choose only even or odd DER encoding?  That would save you 1
byte.  This would probably throw out 50% of possible addresses though.
2. Can the chain code be fixed or derived from the x value?  Could the
chain value be the x value itself?  (The main question is can a
deterministic public seed be represented as a single 32 bit number?  Maybe
the chain code can be a constant.  Maybe it is ok since subsequent pubkeys
are derived from this.  I only know enough crypto to be dangerous.) That
would save you 32 bytes.  Someone who understands HD wallets would be
better to look at this one.  it would probably be a non-standard derivation.

That leaves you with 32 bytes to communicate to bootstrap the channel.

3: Since you are already looking at the pubkey of the transaction sending
the notification transaction, then you are assuming control of the sending
mechanism.  If you can be sure to use a disposable bitcoin address to send
the notification, then 1 more savings might be possible.  Also assuming the
above two points are possible.

Can you encode the "x value" into the signature's R value?  This would
basically make this transaction look like a standard bitcoin transaction
and gets rid of the op_return completely.



I still like the idea of a common meeting point, a la bitmessage.  The
receiver of the payment code would trial-decode all payment codes sent to a
common pre-specified dead drop address (perhaps a charity address).  "to
send me money, first donate to this charity of my choice."  This trades off
more work on the receivers part to get some privacy as to the number of
people interacting with that receiver.


-cheers
-Brian Deery

[-- Attachment #2: Type: text/html, Size: 3364 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] Reusable payment codes
    2015-04-27 14:53 Brian Deery
  @ 2015-04-27 15:54 ` Justus Ranvier
    2015-04-27 16:46 ` Mike Hearn
    2015-04-29 23:44 ` Justus Ranvier
    2 siblings, 0 replies; 17+ messages in thread
  From: Justus Ranvier @ 2015-04-27 15:54 UTC (permalink / raw)
    To: bitcoin-development; +Cc: Brian Deery
  
  [-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
  
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  On 04/27/2015 02:53 PM, Brian Deery wrote:
  > 1. There will be a 1:1 relationship between a payment code owner
  > and their identity.  Presumably the payment code would be strongly
  > and publicly tied to the identity.  This makes the notification
  > address strongly tied to the user.  An SPV client connecting to a
  > full node who has a list of notification address can tie an
  > identity to a bloom filter and connecting IP.
  
  SPV clients that connect exclusively to hidden services through Tor
  could mitigate this, especially if those clients broadcast their
  transactions through different peers than the ones they use for
  checking their balance.
  
  Maybe they should even go the opposite way in terms of the false
  positive rate.
  
  A client could create a filter that *only* matches their notification
  address and use that filter with a selected peer.
  
  All the rest of their addresses would be contained in a different
  filter that is never sent to the same full node which is watching
  their notification address.
  
  > 2. The client can use a bloom filter with a higher false positive
  > rate.  An active attacker can counter that by sending several
  > payment codes to an individual user.  The user would then add to
  > their bloom filter all the shared addresses between them and the
  > attacker.  Even with a high false positive filter, always matching
  > all the attacker's payment codes would strongly tie the user to the
  > filter.
  
  I'm not sure this problem is solvable in general.
  
  Any entity which has sent bitcoins to a known user could use that
  knowledge to attempt to find their bloom filter (if they use one).
  
  I think that for SPV to have any privacy at all clients need to get a
  lot smarter about how they use bloom filters overall, such as by
  connecting to more than one peer, only putting a subset of their
  addresses in a single filter, and temporally varying the addresses
  which they watch.
  
  
  - -- 
  Justus Ranvier                   | Monetas <http://monetas.net/>
  <mailto:justus@monetas•net>      | Public key ID : C3F7BB2638450DB5
                                   | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v2
  
  iQIcBAEBAgAGBQJVPlu8AAoJECpf2nDq2eYj/cAP/iL9qlIkk/jz2N3mT4dIdrSn
  rQ+m7dHOSeucUhePrjdM79VzDUQWGmewdi5a1e8wCL2PCBeq/7mapEpHrvWu3xUU
  g0qtCa6CbSceW5pO1/BGnKpt298wrBIueeweR3/BPum90RrXT+T/ssQvjGvlY4Jg
  ADFeH4axalmCkc87OsJhsEbAAbP9i/u96rItV9ECpOET9pRxp4PzNT/7nz/x5n+q
  Lm/vuWy1yoWLUjXiAmXWJVzPs8+Pzf1liy3SEzkam156kUwTj/CqjI/uhf7heSx2
  FYSswBc/R1fga7eu++Bm449KUTmyTnnEIT4109A1w18fidY2Dg6PpKYp5CGug96t
  aHit1hqLfc8HpNUVWLrBrHsC7riy+QGta4Ie7fAl9SvFcNturkXBFxZLO8f34WMb
  HFuWkcCAgZcS3hb1ShmyodMjnOWvHQo/dXAoUc+zI8yuiH9wAD6T4LOTkSwCjvvv
  9y4Ia4Mr6v6oHQpUM8ddCMU4AyAYvZXFb68SsnWMZCCio3Ff9wqp2d690oSq36G7
  jdjmxot7LrPMnJjNKwTl2jndDTB9Huh9sjWyE9gGBkkIib1purOYtucDsY3h6z7i
  5ppG1KTph+xaOLMEvyJZyDNvPhrQGk1ll1kMoD2k7P/5OGV7QwQ0IxpoAqZ1uxJG
  44rCXd7P+2R+Bza9qHSH
  =d2l3
  -----END PGP SIGNATURE-----
  
  [-- Attachment #2: 0xEAD9E623.asc --]
  [-- Type: application/pgp-keys, Size: 18686 bytes --]
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] Reusable payment codes
    2015-04-27 14:53 Brian Deery
    2015-04-27 15:54 ` Justus Ranvier
  @ 2015-04-27 16:46 ` Mike Hearn
    2015-04-27 17:02   ` Justus Ranvier
    2015-04-29 23:44 ` Justus Ranvier
    2 siblings, 1 reply; 17+ messages in thread
  From: Mike Hearn @ 2015-04-27 16:46 UTC (permalink / raw)
    To: Brian Deery; +Cc: Bitcoin Dev, Justus Ranvier
  
  [-- Attachment #1: Type: text/plain, Size: 367 bytes --]
  
  >
  > 1. There will be a 1:1 relationship between a payment code owner and their
  > identity.
  >
  
  Bear in mind, the spec defines "identity" to mean:
  
       *Identity is a particular extended public/private key pair. *
  
  So that's not quite what is meant normally by identity. It's not a
  government / real name identity or an email address or phone number kind of
  identity.
  
  [-- Attachment #2: Type: text/html, Size: 757 bytes --]
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

• • * Re: [Bitcoin-development] Reusable payment codes
      2015-04-27 16:46 ` Mike Hearn
    @ 2015-04-27 17:02   ` Justus Ranvier
      2015-04-28 13:53     ` Justus Ranvier
      0 siblings, 1 reply; 17+ messages in thread
    From: Justus Ranvier @ 2015-04-27 17:02 UTC (permalink / raw)
      To: bitcoin-development
    
    [-- Attachment #1: Type: text/plain, Size: 1967 bytes --]
    
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    On 04/27/2015 04:46 PM, Mike Hearn wrote:
    > So that's not quite what is meant normally by identity. It's not a 
    > government / real name identity or an email address or phone number
    > kind of identity.
    
    I expect that mappings would begin to develop between payment codes
    and government / real name identities, at least as far as that
    businesses which are required to collect that kind of information
    would associate it with the payment code(s) known to be used by their
    customers for their own use.
    
    I proposed payment codes in this form because I'd rather see that kind
    of mapping be limited to the application layer and kept away from the
    blockchain/network layer.
    
    Even if it makes certain kind of application-layer distasteful
    behavior easier, it's a good trade if doing so can simultaneously
    provide resistance to graph analysis and make transaction-level
    censorship more difficult.
    
    - -- 
    Justus Ranvier                   | Monetas <http://monetas.net/>
    <mailto:justus@monetas•net>      | Public key ID : C3F7BB2638450DB5
                                     | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2
    
    iQIcBAEBAgAGBQJVPmusAAoJECpf2nDq2eYjhxIP/3Jw9f6kcEsdFTXouQ5+D5gb
    MjM8AW7EEA6KXj2PqrPv/H/brorW9/Ugcc8KweCjEdJAKOJV/Bl6sP5ydSZT6pmj
    A0IFIkbdxKLY9JC3BbmVHuiAFrsL1u2EX5arUC3WNAWeWlVEmAL92cSlAka4BBxy
    P/wh8xN0b4hsgA602Y4Btkv2fBHLQI9NMxW3AsujP3/S78mSxwKQZz4lYAMCowu8
    NL/3toaFhrUsdHsH301jNAnxEEOodMVGmgjg/ZSdvWeHwdsE2J8Q9AJqiFDswjU5
    q2kZuKmuJ6EXcGDlhelUuUpfHO34qS3/dyTydcqFrYB6eynZ8nV6S1SHaSlDEM10
    b95+EpfIENtYdgAqJxwfbqpibpSEIW7cxCAopF0sSbQ2qv8rwRrcIah7KeARCrc0
    e+HDcyLhYkrWrlK28vVmIxkEiQ/nmkTu9dOfoVJgXxcVl9AkiHGjo7QICOZHqfRB
    TOupk9UUHMmdfZC5vpj9rd+VSXJJEF19ZbGF1QsFSMuxjKTb9jAy7Dk6U/9/xK9Q
    +mH6QHhKzNKb8GsiowZJq3bF2mEYqmh/BPyQ06gfDLM4yvlTb+k4R6brFzm7tkWG
    49hREmHK9w/wZXnH0lMCqMHRY/YqQF5bR3ujq7pB0WHLvbvDoSvyWvGQ9cVrRA24
    ASb47sR77R1LlZntoSyy
    =b7HG
    -----END PGP SIGNATURE-----
    
    [-- Attachment #2: 0xEAD9E623.asc --]
    [-- Type: application/pgp-keys, Size: 18686 bytes --]
    
    ^ permalink raw reply	[flat|nested] 17+ messages in thread

  • • * Re: [Bitcoin-development] Reusable payment codes
        2015-04-27 17:02   ` Justus Ranvier
      @ 2015-04-28 13:53     ` Justus Ranvier
        0 siblings, 0 replies; 17+ messages in thread
      From: Justus Ranvier @ 2015-04-28 13:53 UTC (permalink / raw)
        To: bitcoin-development
      
      [-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
      
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1
      
      The notification transactions are a pain point when it comes to
      privacy, and yet they must exist in order to to ensure that nobody can
      lose their money as long as they back up their wallet seed.
      
      They could be treated as a backup, however, that clients would not
      normally rely upon
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v2
      
      iQIcBAEBAgAGBQJVP5DDAAoJECpf2nDq2eYjdLsQAJ/nZKFavcJnCMUQ8hKp6dRq
      2+7bAVIWYHuOV6sv/hvG2NaP3u24NYZ/Ji0oD3UAmkJxw9lsZuowwBBs+YAs6JAW
      KHTl3QtwBh0IP/V90JOZ5Yn72YWXDsNbqy7R3JhEDKOu2wVeiLqWZ2EDgGwiZ0/k
      aXFJbcVZEKttWYCNoZi0yRMH+S9gbi0LgOwvK9mRzF9IRz07SM1iKQeKPsW1X1UM
      KNeikFROMS7dHTO5HRGyFcTSwhUf8RJq2kea+4sJtj8Vlb5rURuJanL3Fav+ZZjr
      RWYubLp9EUrDMm9bciygL8+MKPas8hedHSW2JhjkshWYC/NoCXLBT6SGrrbj2SKL
      zGGeLYknjwgLTCstKSQlXW3J/xcSFwBztr//o95SwRoIKI7jpuOE6cPfUZVEuTsU
      Zm7IWuRw/1MMDF89gCtDkBJcX2mTARjiii1Hg0+7vCv6Q/fVgTNUvWEKeNtCNZjh
      wOiwd4eP1gY4CwX68c+8CfF+NOSXImJTspZJvDQcTge1/bQJNOBn+cMYxjBcJsqL
      ZUOvkWJqwiFERW7vjMhOVpqIyO38UluwsWgp7nlMl/npfv0ZDIrOqZrswHSTqfdc
      P8gSaqvpc6cMaLL/ijvOtORkVB9ZlLmlTv6mIYWHeKEf6PjIOZEb2B75zPHFAvrz
      TKLxjvWgvSJ4l5PrkCFA
      =1Id2
      -----END PGP SIGNATURE-----
      
      [-- Attachment #2: 0xEAD9E623.asc --]
      [-- Type: application/pgp-keys, Size: 18686 bytes --]
      
      ^ permalink raw reply	[flat|nested] 17+ messages in thread

• * Re: [Bitcoin-development] Reusable payment codes
    2015-04-27 14:53 Brian Deery
    2015-04-27 15:54 ` Justus Ranvier
    2015-04-27 16:46 ` Mike Hearn
  @ 2015-04-29 23:44 ` Justus Ranvier
    2 siblings, 0 replies; 17+ messages in thread
  From: Justus Ranvier @ 2015-04-29 23:44 UTC (permalink / raw)
    To: bitcoin-development; +Cc: Brian Deery
  
  [-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
  
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  On 04/27/2015 02:53 PM, Brian Deery wrote:
  
  > 1. There will be a 1:1 relationship between a payment code owner
  > and their identity.  Presumably the payment code would be strongly
  > and publicly tied to the identity.  This makes the notification
  > address strongly tied to the user.  An SPV client connecting to a
  > full node who has a list of notification address can tie an
  > identity to a bloom filter and connecting IP.
  
  I've updated the proposal to provide for alternate methods of
  notification that can be used *in addition to* notification transactions.
  
  This frees the sender from constantly monitoring an address known to
  be associated with their identity, although they should check it
  periodically since not all senders will be capable of using every type
  of alternate notification method.
  
  I defined a Bitmessage notification method as an example; more can be
  added if required.
  
  https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v2
  
  iQIcBAEBAgAGBQJVQWzPAAoJECpf2nDq2eYj8uAP/RsP050K9z8oDGy0KO+zjFwM
  iNzlsQaPY8kmR2k2oLXJp1n4QZIQAZly+vxjBZnOWXwAhrBcvnhNBvqdigwZYg3B
  oGyvGvArzkve86Ke1WF1hZEAvml3cmQ5jxYKMlwhzRPcHq2kwznw+5jRuTbf1JbE
  PxY5pOfnZ9ADVF5FkLR2KwBNvGA83Cle01hKd0eB6Omlb6azKDBXUqfzPPpB4lmp
  A8D0P3zkayzBYIiybUExfPJHUthd5wXL/TLwFkysPV7SnJE64C6Q2StD4wUtNQRS
  LDOw37RwhMx2Oz2YH3Ywi6w5tqYQP4LEWBuFb+LOqqphpV/FpFDl/Uznos00pz61
  V9x2wrfg+MQnYk5/VIjPQxqvRsiu8yg4c2x0v+KIIMsuXKEPRFxaSS3DoaWUa1Jy
  +WDobHndIDw1TDqctP8LIiZ7zbWNYKJ4HgUaacHvTiA7TrJXi1KHo2b1pmnTbKhv
  fdHbjzd8UiMED6qeyrz1gGhjC2uSTwjZAmbBkCJccOGsrILoV1fifUW+de8qsBMH
  6w6RiDwfeY2fHJHBS6O2Nhfk3OE5JaCWvy727ZXEq8lQ6dW0GOZvXg7INaktLagC
  tqvg85J5eCm7X8xQ33vgx8q2xt+IriMI2UnTILtb2H8XSiMRQSP7XfWDMfVGu4pb
  xbGZKbNS4WS+2FFKM4DK
  =6l99
  -----END PGP SIGNATURE-----
  
  [-- Attachment #2: 0xEAD9E623.asc --]
  [-- Type: application/pgp-keys, Size: 18399 bytes --]
  
  ^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2015-06-17  5:34 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-24 20:00 [Bitcoin-development] Reusable payment codes Justus Ranvier
2015-04-24 20:58 ` Gregory Maxwell
     [not found]   ` <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
2015-04-25  0:20     ` [Bitcoin-development] Fwd: " Justus Ranvier
     [not found]     ` <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
2015-04-25  0:21       ` Justus Ranvier
     [not found] ` <1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>
     [not found]   ` <CAHabJ+NDqMN-rQ1BN1TfOjGLQHH-3Wd28LdoF95Agn4HdRrThg@mail.gmail.com>
2015-04-25  0:22     ` Justus Ranvier
     [not found]       ` <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
2015-04-25  2:34         ` Justus Ranvier
2015-04-26 12:58           ` Mike Hearn
2015-04-26 14:50             ` Justus Ranvier
2015-06-16 16:26 ` [Bitcoin-development] " odinn
2015-06-16 17:46   ` Peter Todd
2015-06-17  5:34     ` odinn
2015-04-27 14:53 Brian Deery
2015-04-27 15:54 ` Justus Ranvier
2015-04-27 16:46 ` Mike Hearn
2015-04-27 17:02   ` Justus Ranvier
2015-04-28 13:53     ` Justus Ranvier
2015-04-29 23:44 ` Justus Ranvier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox