Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Jeremy Spilman]

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

If you have two parties who want to form a persistent relationship, by exchanging and verifying public keys beforehand, then I think the canonical way to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.

I don’t understand the use case for handing out individual multipliers, if what you desire is a persistent relationship. If each party dedicates a child-wallet for receiving coins, and saves a PubKey/ChainCode for sending coins, the two parties can transaction securely forever without ever exchanging any more information, and without any address reuse.

I think ideally, the default behavior is that wallets always dedicate a new child node {PubKey, ChainCode} to each party they transact with. At the presentation layer, you have a “contact” and each contact has a transaction history. You can send coins to a contact at any time, and internally the wallet picks the next address in their sequence. Any funds received on pubkeys from contact’s sequence are attributed to that contact. The wallet can organize the contacts, and roll-up the transaction history into ‘ledgers’ and ‘balances’ however they want – it could be based on the underlying BIP32 hierarchy or perhaps not. The cost of watching large a number of pubkeys, even if you ‘look ahead’ 100 pubkeys for each contact, is relatively small versus the benefits.

What might be nice is a ‘Contact Request’ protocol, basically the same as a PaymentRequest but no actual payments are sent, just child wallets created:

message Contact {
    optional uint32 contact_version = 1 [default = 1];
    optional string pki_type = 2 [default = "none"];
    optional bytes pki_data = 3;
    required bytes serialized_contact_details = 4;
    optional bytes signature = 5;
}

message ContactDetails {
    optional string network = 1 [default = "main"];
    required bytes pubkey = 2;
    required bytes chaincode = 3;
    optional string memo = 4;
    optional string response_url = 5;
}

Alice sends a Contact+ContactDetails to Bob.  If Bob accepts, he sends his own Contact+ContactDetails (without a response_url) back to Alice. Basically just like adding a contact to your IM contacts.

Alice could send a Contact+ContactDetails to Bob without a response_url, in which case after accepting the contact, Bob could send funds to Alice, but not receive funds.

You could probably pack the whole message inside a bitcoin:// URI if you wanted to.

Thanks,
--Jeremy

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Alan Reiner]

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

On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
> If you have two parties who want to form a persistent relationship, by
> exchanging and verifying public keys beforehand, then I think the
> canonical way to do this with BIP32 is for the parties to exchange
> PubKey and *ChainCode*.
>  
> I don't understand the use case for handing out individual
> multipliers, if what you desire is a persistent relationship. If each
> party dedicates a child-wallet for receiving coins, and saves a
> PubKey/ChainCode for sending coins, the two parties can transaction
> securely forever without ever exchanging any more information, and
> without any address reuse.
>  
> I think ideally, the default behavior is that wallets always dedicate
> a new child node {PubKey, ChainCode} to each party they transact with.
> At the presentation layer, you have a "contact" and each contact has a
> transaction history. You can send coins to a contact at any time, and
> internally the wallet picks the next address in their sequence. Any
> funds received on pubkeys from contact's sequence are attributed to
> that contact. The wallet can organize the contacts, and roll-up the
> transaction history into 'ledgers' and 'balances' however they want --
> it could be based on the underlying BIP32 hierarchy or perhaps not.
> The cost of watching large a number of pubkeys, even if you 'look
> ahead' 100 pubkeys for each contact, is relatively small versus the
> benefits.
>  
>

What you just described is complimentary to what I am proposing.  There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances.  BIP 32 does not prescribe a way to
use multiple chains like you described with the convenient type-2
derivation (though we could create a variant that does).  And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory. 

So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts.  For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity.   If I
don't want that, I use your method.  If I do want that, I use my
method.  Given its simplicity, I don't know why both can't be options.

Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.

-Alan

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Jeremy Spilman]

Hi Alan,

> “BIP 32 does not prescribe a way to use multiple chains like you described 
> with the convenient type-2 derivation (though we could create a variant 
> that does)”

What do you think is missing from BIP32 for this? A wallet creates a 
child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, 
and then generally expects transactions to come in starting at /0 and 
incrementing monotonically.

Also, I'm not sure I follow your point about the 128kB hardware wallet --  
it's a signing device, so assuming it's even validating output amounts, at 
worst it cares about the number of inputs to the outputs being spent, but in 
many cases you're just handing it a sighash and the BIP32 "path" 
(/1/54/27/0) to generate the right private key for signing. The hardware 
wallet is not actually listening on the P2P network and detecting payments, 
so it's unaffected by dedicating child-nodes to each contact.

Consider the benefits of gaining critical mass of support for a technique 
which [I think] can be used in all cases, and increases security and privacy 
for everyone. I think there are huge benefits to leaving the age of 'single 
address generation' behind us...

Thanks,
--Jeremy 

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Alan Reiner]

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

On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
> Hi Alan,
>
>> “BIP 32 does not prescribe a way to use multiple chains like you described 
>> with the convenient type-2 derivation (though we could create a variant 
>> that does)”
> What do you think is missing from BIP32 for this? A wallet creates a 
> child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, 
> and then generally expects transactions to come in starting at /0 and 
> incrementing monotonically.
>


You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting.  I
disagree.  I am okay with using different wallets for different parties
*/if the user wants to/*.  But there are orthogonal use-cases to having
a single wallet serve as a single identity that can be used across
multiple transactions or services.  And doing so is much simpler
conceptually for the user, and simpler in implementation for the app
developer.

BIP 32 already specifies how to use the first three tree levels: 
M/i/j/k, i~wallet, j~Internal/External, k~address.  The first level is
actually type-1 derived, and thus we cannot create an arbitrary number
of them without pre-computing them from the offline wallet.  So it's not
"free" to create new wallets unless we redefine how the levels work. 
Even if we assume the simplest case where the first level is actually
type-2 derived and it costs nothing to create separate wallets for each
contact/party:
 
-- Do these extra wallet chains behave as different wallets, or
sub-wallets? 
-- Should their balances be bundled into a single wallet or displayed
separately?
-- When a user tries to spend, does he have to specify which wallet(s)
he's spending from?
-- Should the app developer be required to implement a multiple-wallet
interface, and handle cross-wallet spending just to achieve this simple
mechanism?  Sure, they could instead implement a tiered wallet hierarchy
with primary wallets and sub-wallets... wait this just got complicated.

All that complexity just to support this identity mechanism that can be
included purely as an alternative address encoding with a single
wallet.  With my request, the user can't have one wallet and distribute
most of his addresses the normal/anonymous way, but certain apps would
choose to use the alternate encoding as a form of identity.  If the user
feels the need to create a separate wallet for certain operations to
separate his identities, that is his option if the software supports
multiple wallets.  But it's not the only way.

To achieve what I'm suggesting is useful and trivial to implement even
in the simplest wallet applications. 

-Alan

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Jeremy Spilman]

> BIP 32 already specifies how to use the first three tree levels:  M/i/j/k, 
> i~wallet, j~Internal/External, k~address.  The first level is actually 
> type-1 derived, and thus we cannot create an arbitrary number of them 
> without pre-computing them from the offline wallet.  So it's not "free" to 
> create new wallets unless we redefine how the levels work.

Initially I was thinking that you would share the public key and chain code 
from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique 
value of 'i' for each receive chain.

For the case of generating new receive chains from a *watch-only* wallet, as 
you say, the options are to either keep a cache of PubKey/ChainCode for 
unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] -- the 
concept of 'internal/'external' and change addresses at Depth=2 don't make 
sense for handing out receive chains to lots of people anyway, and certainly 
BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j' is the way 
to go here...

The "default" layout of BIP32 does NOT mean that implementations should not 
check for transactions with j > 1. That would be a useless constraint and 
obviously self-limiting. It might be helpful to add to the 'Compatibility' 
section some minimum expectations about how a wallet should be 'probed' when 
imported. If you don't feel completely free to monotonically increment 'j' 
to your hearts content to achieve major usability benefits, then I say BIP32 
could use some clarifying.

BTW - the spec calls for addition not multiplication now, so we should call 
it the 'Addend' not the 'Multiplier' :-)

> Do these extra wallet chains behave as different wallets, or sub-wallets?

They could, but they certainly don't need to!  A single-wallet 
implementation treats this merely as an address-generation algorithm, and 
does not expose any hierarchy to the user interface.  The user just 
“magically” gets the ability to send multiple payments to their contacts 
without immediately sacrificing their privacy 
(http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything 
goes into the same ledger, balance, coin pool, etc. Most of the code base is 
unaware BIP32 is even in use.

While it is *possible* to support separate ledgers, balances, etc. it is 
certainly not required, and you get all the benefits either way.

I think, since your proposal generates and receives payments into 
BIP32-style addresses, we both need similar underlying wallet code. The only 
difference is that you are passing the Kpar for [m/i'/0/k] and the *result* 
of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, and 
leaving 'k' out of it, letting the receive choose 'k'.

> For instance, maybe there's a benefit to using the same parent pubkey 
> across multiple services, as a form of identity.   If I don't want that, I 
> use your method.  If I do want that, I use my method.

I think it's a interesting idea using static public keys as a means for 
persistent identity and hence security from MitM. If you want a shared 
public key across multiple services we could just combine both ideas and get 
all the benefits, by making the data structure { ParentPubKey, Addend, 
ChainCode }:

   ParentPubKey: Public key of m/i' -- 33 bytes
   Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
   ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes

All that remains secret is the ChainCode from [m/i'] -- and of course the 
private keys.  The ParentPubKey is a common value across multiple services, 
corresponding to user's identity rooted in [m/i'].  Each service gets their 
own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].  With the 
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically 
increasing 'k'. Again, from the user perspective all transactions under 
[m/i'] can be presented in a single ledger, or not.

Anyway, fundamentally my feedback is if you are designing for persistent 
long-term relationships, you could build in a mechanism for generating 
address chains so you don't need any further communication after the initial 
exchange, and it need not complicate the wallet.

Thanks,
--Jeremy 

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Mike Hearn]

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

Agree with Jeremy and once the payment protocol work is further along I'd
like to see us define an extension that lets you send payment requests
containing public keys+chain codes, so further payments can be made
push-style with no recipient interaction (e.g. for repeated billing). How
apps choose to arrange their chains internally seems like an area for
experimentation. I definitely want to implement HD wallets in bitcoinj to
allow this and if that means not using the same tree structure as in the
BIP then so be it.


On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co> wrote:

> > BIP 32 already specifies how to use the first three tree levels:
>  M/i/j/k,
> > i~wallet, j~Internal/External, k~address.  The first level is actually
> > type-1 derived, and thus we cannot create an arbitrary number of them
> > without pre-computing them from the offline wallet.  So it's not "free"
> to
> > create new wallets unless we redefine how the levels work.
>
> Initially I was thinking that you would share the public key and chain code
> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique
> value of 'i' for each receive chain.
>
> For the case of generating new receive chains from a *watch-only* wallet,
> as
> you say, the options are to either keep a cache of PubKey/ChainCode for
> unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] --
> the
> concept of 'internal/'external' and change addresses at Depth=2 don't make
> sense for handing out receive chains to lots of people anyway, and
> certainly
> BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j' is the
> way
> to go here...
>
> The "default" layout of BIP32 does NOT mean that implementations should not
> check for transactions with j > 1. That would be a useless constraint and
> obviously self-limiting. It might be helpful to add to the 'Compatibility'
> section some minimum expectations about how a wallet should be 'probed'
> when
> imported. If you don't feel completely free to monotonically increment 'j'
> to your hearts content to achieve major usability benefits, then I say
> BIP32
> could use some clarifying.
>
> BTW - the spec calls for addition not multiplication now, so we should call
> it the 'Addend' not the 'Multiplier' :-)
>
> > Do these extra wallet chains behave as different wallets, or sub-wallets?
>
> They could, but they certainly don't need to!  A single-wallet
> implementation treats this merely as an address-generation algorithm, and
> does not expose any hierarchy to the user interface.  The user just
> “magically” gets the ability to send multiple payments to their contacts
> without immediately sacrificing their privacy
> (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
> goes into the same ledger, balance, coin pool, etc. Most of the code base
> is
> unaware BIP32 is even in use.
>
> While it is *possible* to support separate ledgers, balances, etc. it is
> certainly not required, and you get all the benefits either way.
>
> I think, since your proposal generates and receives payments into
> BIP32-style addresses, we both need similar underlying wallet code. The
> only
> difference is that you are passing the Kpar for [m/i'/0/k] and the *result*
> of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, and
> leaving 'k' out of it, letting the receive choose 'k'.
>
> > For instance, maybe there's a benefit to using the same parent pubkey
> > across multiple services, as a form of identity.   If I don't want that,
> I
> > use your method.  If I do want that, I use my method.
>
> I think it's a interesting idea using static public keys as a means for
> persistent identity and hence security from MitM. If you want a shared
> public key across multiple services we could just combine both ideas and
> get
> all the benefits, by making the data structure { ParentPubKey, Addend,
> ChainCode }:
>
>    ParentPubKey: Public key of m/i' -- 33 bytes
>    Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>    ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>
> All that remains secret is the ChainCode from [m/i'] -- and of course the
> private keys.  The ParentPubKey is a common value across multiple services,
> corresponding to user's identity rooted in [m/i'].  Each service gets their
> own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].  With the
> ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
> increasing 'k'. Again, from the user perspective all transactions under
> [m/i'] can be presented in a single ledger, or not.
>
> Anyway, fundamentally my feedback is if you are designing for persistent
> long-term relationships, you could build in a mechanism for generating
> address chains so you don't need any further communication after the
> initial
> exchange, and it need not complicate the wallet.
>
> Thanks,
> --Jeremy
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

[Alan Reiner]

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

Although I'd still prefer my original request, I get much of what I want
from your guys' recommendation.  It complicates the wallet design,
because it requires tracking and associating a matrix of addresses for
each wallet, instead of a single linear list.  But if this is what it's
going to take then I will go along. 

Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
used for distributing addresses, and j=1 is the "internal" chain for
sending change.  The CONOPs (concept of operations) for the extended
wallet would be like Jeremy described:

- Chains with j>=2 would be independent address chains carved out for
individuals relationships
- Add wallet code to individually associate each j-value with a
particular identity
- Update the wallet code to pool all the addresses in all j-chains when
calculating the balance of the wallet and/or creating transactions
- When choosing to generically "Receive Bitcoins", will pick the next
address from the j=0 chain
- Will have to add extra function to "Receive Bitcoins" button to allow
creation of new contacts/identities.
- Change will always go to the next address in j=1, no matter which
chains are used to provide inputs.
- Add code to figure out lookaheads for each alternate chain.  Not just
each chain, but looking ahead a couple chains, too.  Luckily, the
lookahead doesn't have to be very big for chains j>=1 
- Add an interface to display and choose the different chains in your
wallet, and export the pubkey&chaincode in some soon-to-be-standardized
format. 
- Add code and interface to receive and track alternate j-chains from
other clients/users, and maintain those.  Should we try associating
incoming and outgoing chains?  What happens if they do it wrong?  Meh...

Just as one final swipe at this idea, you can see that I gotta do quite
a bit of work to support the multi-chain idea, and adds a little extra
burden on the user to maintain the organization of the wallet.  This
would all be totally unnecessary with a simple alternate encoding. 
Granted, I think the multi-chain idea is good, and one that I will
probably implement anyway, but it seems like overkill in terms of
developer complexity, and interface complexity to achieve something much
simpler.  Developers of much simpler/lightweight clients would probably
find this prohibitive.

On another note:  I thought we weren't encouraging automatic payments
without requesting from the other party...?  It makes me uneasy, but it
sounds like group thought has converged on that being acceptable.  I
bring it up, because there are situations where it makes sense, but it
sounds unsafe for general users.   Alice will give Bob his own chain for
sending Alice money, then a year later Bob will send money automatically
to Alice not realizing that the wallet was lost, retired or
compromised.  It's not that Bob can't ask for a new address, it's that
if the interface says "Send Money to Alice", that looks legit enough
that Bob may not feel it necessary to check with Alice first.   That's
more of an interface issue though.  We can add a warning to "check with
the recipient that they still have access to wallet 3cQ398x", etc.   But
I just know someone is going to lose money anyway...

-Alan





On 06/20/2013 03:32 AM, Mike Hearn wrote:
> Agree with Jeremy and once the payment protocol work is further along
> I'd like to see us define an extension that lets you send payment
> requests containing public keys+chain codes, so further payments can
> be made push-style with no recipient interaction (e.g. for repeated
> billing). How apps choose to arrange their chains internally seems
> like an area for experimentation. I definitely want to implement HD
> wallets in bitcoinj to allow this and if that means not using the same
> tree structure as in the BIP then so be it.
>
>
> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co
> <mailto:jeremy@taplink.co>> wrote:
>
>     > BIP 32 already specifies how to use the first three tree levels:
>      M/i/j/k,
>     > i~wallet, j~Internal/External, k~address.  The first level is
>     actually
>     > type-1 derived, and thus we cannot create an arbitrary number of
>     them
>     > without pre-computing them from the offline wallet.  So it's not
>     "free" to
>     > create new wallets unless we redefine how the levels work.
>
>     Initially I was thinking that you would share the public key and
>     chain code
>     from [m/i'/0] so that you can receive payments at [m/i'/0/k], for
>     a unique
>     value of 'i' for each receive chain.
>
>     For the case of generating new receive chains from a *watch-only*
>     wallet, as
>     you say, the options are to either keep a cache of
>     PubKey/ChainCode for
>     unused [m/i'] or simply increment 'j' past 1 for an existing
>     [m/i'/j] -- the
>     concept of 'internal/'external' and change addresses at Depth=2
>     don't make
>     sense for handing out receive chains to lots of people anyway, and
>     certainly
>     BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j'
>     is the way
>     to go here...
>
>     The "default" layout of BIP32 does NOT mean that implementations
>     should not
>     check for transactions with j > 1. That would be a useless
>     constraint and
>     obviously self-limiting. It might be helpful to add to the
>     'Compatibility'
>     section some minimum expectations about how a wallet should be
>     'probed' when
>     imported. If you don't feel completely free to monotonically
>     increment 'j'
>     to your hearts content to achieve major usability benefits, then I
>     say BIP32
>     could use some clarifying.
>
>     BTW - the spec calls for addition not multiplication now, so we
>     should call
>     it the 'Addend' not the 'Multiplier' :-)
>
>     > Do these extra wallet chains behave as different wallets, or
>     sub-wallets?
>
>     They could, but they certainly don't need to!  A single-wallet
>     implementation treats this merely as an address-generation
>     algorithm, and
>     does not expose any hierarchy to the user interface.  The user just
>     "magically" gets the ability to send multiple payments to their
>     contacts
>     without immediately sacrificing their privacy
>     (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/).
>     Everything
>     goes into the same ledger, balance, coin pool, etc. Most of the
>     code base is
>     unaware BIP32 is even in use.
>
>     While it is *possible* to support separate ledgers, balances, etc.
>     it is
>     certainly not required, and you get all the benefits either way.
>
>     I think, since your proposal generates and receives payments into
>     BIP32-style addresses, we both need similar underlying wallet
>     code. The only
>     difference is that you are passing the Kpar for [m/i'/0/k] and the
>     *result*
>     of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and
>     cpar, and
>     leaving 'k' out of it, letting the receive choose 'k'.
>
>     > For instance, maybe there's a benefit to using the same parent
>     pubkey
>     > across multiple services, as a form of identity.   If I don't
>     want that, I
>     > use your method.  If I do want that, I use my method.
>
>     I think it's a interesting idea using static public keys as a
>     means for
>     persistent identity and hence security from MitM. If you want a shared
>     public key across multiple services we could just combine both
>     ideas and get
>     all the benefits, by making the data structure { ParentPubKey, Addend,
>     ChainCode }:
>
>        ParentPubKey: Public key of m/i' -- 33 bytes
>        Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>        ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>
>     All that remains secret is the ChainCode from [m/i'] -- and of
>     course the
>     private keys.  The ParentPubKey is a common value across multiple
>     services,
>     corresponding to user's identity rooted in [m/i'].  Each service
>     gets their
>     own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].
>      With the
>     ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
>     increasing 'k'. Again, from the user perspective all transactions
>     under
>     [m/i'] can be presented in a single ledger, or not.
>
>     Anyway, fundamentally my feedback is if you are designing for
>     persistent
>     long-term relationships, you could build in a mechanism for generating
>     address chains so you don't need any further communication after
>     the initial
>     exchange, and it need not complicate the wallet.
>
>     Thanks,
>     --Jeremy
>
>
>
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by Windows:
>
>     Build for Windows Store.
>
>     http://p.sf.net/sfu/windows-dev2dev
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

[Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

[Alan Reiner]

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

Guys,

I'd like to reiterate my previous request to support this alternate
address serialization in the payment protocol.  We got caught up in the
specifics of one use case, but didn't acknowledge that it's still a
valid address representation that will provide value to those who wish
to use it and can be safely ignored by others.

Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
checksum)
Alternate format:         binary_to_base58( idbyte + parentpubkey +
multiplier + checksum)

The receiving party will multiply the pubkey by the multiplier, and then
hash it to get the 20-byte address to send to.  The idea is that you use
your BIP 32 parent public key, and then you generate whatever child you
want, and only send them the multiplier used (not the chaincode).  This
preserves privacy, but if the recipient has your parent public key
already, they can identify that address being linked to you, but cannot
determine any other addresses in your wallet.

This form has no drawbacks to the existing address format except for
being longer and requiring an extra EC multiplication by the person
sending to that address.  But the advantage is that it optionally allows
the sender to provide more information than currently contained in the
25-byte hash160 form.  The discussion about this got side-tracked with
the use case I presented, but I believe there are plenty of other uses
for this.

The particular use case I had in mind was that certain services could be
setup (pre-arranged), say between wallet software and a
business/exchange.  The exchange would like to be able to reliably send
addresses to the user for deposit, without risk of MITM, or even if
their own public server is compromised.  The author of wallet software
pre-verifies the public key portion of the service, and either hardcodes
it into the software, or hardcodes their own public key into the
software and makes the service's signed public key available through
query server (allowing the software author to offline-sign replacement
keys, or add keys for new service providers, as needed). 

When the user's software receives a payment address, the software can
verify it belongs to that service.  You can't use dedicated chain
technique, because it would either have to be exchanged with the user on
first transaction which half defeats the purpose, or they give them the
full public key and chaincode which allows the user to see /all
/addresses ever used by the service.  Neither one is a reasonable solution.

This use case doesn't necessarily scale, but it doesn't have to.  It
simply allows service providers to skip the SSL and go right to public
key exchange/verification for a few of the important services they
provide access to, and will provide better security than relying on
SSL/PKI.  This would simply be one, coexisting option for providing
payment details in the absence (or in addition to) SSL/PKI infrastructure.

I'm sure there's other use cases, but it seems simple enough and
non-disruptive enough that it could be supported easily for no other
reason than to support that use case (which I intend to implement in
Armory to help verify high-volume services).

-Alan





On 06/26/2013 11:29 AM, Alan Reiner wrote:
> Although I'd still prefer my original request, I get much of what I
> want from your guys' recommendation.  It complicates the wallet
> design, because it requires tracking and associating a matrix of
> addresses for each wallet, instead of a single linear list.  But if
> this is what it's going to take then I will go along. 
>
> Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
> used for distributing addresses, and j=1 is the "internal" chain for
> sending change.  The CONOPs (concept of operations) for the extended
> wallet would be like Jeremy described:
>
> - Chains with j>=2 would be independent address chains carved out for
> individuals relationships
> - Add wallet code to individually associate each j-value with a
> particular identity
> - Update the wallet code to pool all the addresses in all j-chains
> when calculating the balance of the wallet and/or creating transactions
> - When choosing to generically "Receive Bitcoins", will pick the next
> address from the j=0 chain
> - Will have to add extra function to "Receive Bitcoins" button to
> allow creation of new contacts/identities.
> - Change will always go to the next address in j=1, no matter which
> chains are used to provide inputs.
> - Add code to figure out lookaheads for each alternate chain.  Not
> just each chain, but looking ahead a couple chains, too.  Luckily, the
> lookahead doesn't have to be very big for chains j>=1 
> - Add an interface to display and choose the different chains in your
> wallet, and export the pubkey&chaincode in some
> soon-to-be-standardized format. 
> - Add code and interface to receive and track alternate j-chains from
> other clients/users, and maintain those.  Should we try associating
> incoming and outgoing chains?  What happens if they do it wrong?  Meh...
>
> Just as one final swipe at this idea, you can see that I gotta do
> quite a bit of work to support the multi-chain idea, and adds a little
> extra burden on the user to maintain the organization of the wallet. 
> This would all be totally unnecessary with a simple alternate
> encoding.  Granted, I think the multi-chain idea is good, and one that
> I will probably implement anyway, but it seems like overkill in terms
> of developer complexity, and interface complexity to achieve something
> much simpler.  Developers of much simpler/lightweight clients would
> probably find this prohibitive.
>
> On another note:  I thought we weren't encouraging automatic payments
> without requesting from the other party...?  It makes me uneasy, but
> it sounds like group thought has converged on that being acceptable. 
> I bring it up, because there are situations where it makes sense, but
> it sounds unsafe for general users.   Alice will give Bob his own
> chain for sending Alice money, then a year later Bob will send money
> automatically to Alice not realizing that the wallet was lost, retired
> or compromised.  It's not that Bob can't ask for a new address, it's
> that if the interface says "Send Money to Alice", that looks legit
> enough that Bob may not feel it necessary to check with Alice first.  
> That's more of an interface issue though.  We can add a warning to
> "check with the recipient that they still have access to wallet
> 3cQ398x", etc.   But I just know someone is going to lose money anyway...
>
> -Alan
>
>
>
>
>
> On 06/20/2013 03:32 AM, Mike Hearn wrote:
>> Agree with Jeremy and once the payment protocol work is further along
>> I'd like to see us define an extension that lets you send payment
>> requests containing public keys+chain codes, so further payments can
>> be made push-style with no recipient interaction (e.g. for repeated
>> billing). How apps choose to arrange their chains internally seems
>> like an area for experimentation. I definitely want to implement HD
>> wallets in bitcoinj to allow this and if that means not using the
>> same tree structure as in the BIP then so be it.
>>
>>
>> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co
>> <mailto:jeremy@taplink.co>> wrote:
>>
>>     > BIP 32 already specifies how to use the first three tree
>>     levels:  M/i/j/k,
>>     > i~wallet, j~Internal/External, k~address.  The first level is
>>     actually
>>     > type-1 derived, and thus we cannot create an arbitrary number
>>     of them
>>     > without pre-computing them from the offline wallet.  So it's
>>     not "free" to
>>     > create new wallets unless we redefine how the levels work.
>>
>>     Initially I was thinking that you would share the public key and
>>     chain code
>>     from [m/i'/0] so that you can receive payments at [m/i'/0/k], for
>>     a unique
>>     value of 'i' for each receive chain.
>>
>>     For the case of generating new receive chains from a *watch-only*
>>     wallet, as
>>     you say, the options are to either keep a cache of
>>     PubKey/ChainCode for
>>     unused [m/i'] or simply increment 'j' past 1 for an existing
>>     [m/i'/j] -- the
>>     concept of 'internal/'external' and change addresses at Depth=2
>>     don't make
>>     sense for handing out receive chains to lots of people anyway,
>>     and certainly
>>     BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j'
>>     is the way
>>     to go here...
>>
>>     The "default" layout of BIP32 does NOT mean that implementations
>>     should not
>>     check for transactions with j > 1. That would be a useless
>>     constraint and
>>     obviously self-limiting. It might be helpful to add to the
>>     'Compatibility'
>>     section some minimum expectations about how a wallet should be
>>     'probed' when
>>     imported. If you don't feel completely free to monotonically
>>     increment 'j'
>>     to your hearts content to achieve major usability benefits, then
>>     I say BIP32
>>     could use some clarifying.
>>
>>     BTW - the spec calls for addition not multiplication now, so we
>>     should call
>>     it the 'Addend' not the 'Multiplier' :-)
>>
>>     > Do these extra wallet chains behave as different wallets, or
>>     sub-wallets?
>>
>>     They could, but they certainly don't need to!  A single-wallet
>>     implementation treats this merely as an address-generation
>>     algorithm, and
>>     does not expose any hierarchy to the user interface.  The user just
>>     "magically" gets the ability to send multiple payments to their
>>     contacts
>>     without immediately sacrificing their privacy
>>     (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/).
>>     Everything
>>     goes into the same ledger, balance, coin pool, etc. Most of the
>>     code base is
>>     unaware BIP32 is even in use.
>>
>>     While it is *possible* to support separate ledgers, balances,
>>     etc. it is
>>     certainly not required, and you get all the benefits either way.
>>
>>     I think, since your proposal generates and receives payments into
>>     BIP32-style addresses, we both need similar underlying wallet
>>     code. The only
>>     difference is that you are passing the Kpar for [m/i'/0/k] and
>>     the *result*
>>     of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and
>>     cpar, and
>>     leaving 'k' out of it, letting the receive choose 'k'.
>>
>>     > For instance, maybe there's a benefit to using the same parent
>>     pubkey
>>     > across multiple services, as a form of identity.   If I don't
>>     want that, I
>>     > use your method.  If I do want that, I use my method.
>>
>>     I think it's a interesting idea using static public keys as a
>>     means for
>>     persistent identity and hence security from MitM. If you want a
>>     shared
>>     public key across multiple services we could just combine both
>>     ideas and get
>>     all the benefits, by making the data structure { ParentPubKey,
>>     Addend,
>>     ChainCode }:
>>
>>        ParentPubKey: Public key of m/i' -- 33 bytes
>>        Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>>        ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>>
>>     All that remains secret is the ChainCode from [m/i'] -- and of
>>     course the
>>     private keys.  The ParentPubKey is a common value across multiple
>>     services,
>>     corresponding to user's identity rooted in [m/i'].  Each service
>>     gets their
>>     own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].
>>      With the
>>     ChainCode, the receiver then can generate [m/i'/j/k] for
>>     monotonically
>>     increasing 'k'. Again, from the user perspective all transactions
>>     under
>>     [m/i'] can be presented in a single ledger, or not.
>>
>>     Anyway, fundamentally my feedback is if you are designing for
>>     persistent
>>     long-term relationships, you could build in a mechanism for
>>     generating
>>     address chains so you don't need any further communication after
>>     the initial
>>     exchange, and it need not complicate the wallet.
>>
>>     Thanks,
>>     --Jeremy
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     This SF.net email is sponsored by Windows:
>>
>>     Build for Windows Store.
>>
>>     http://p.sf.net/sfu/windows-dev2dev
>>     _______________________________________________
>>     Bitcoin-development mailing list
>>     Bitcoin-development@lists.sourceforge.net
>>     <mailto:Bitcoin-development@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


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

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

[Mike Hearn]

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

Payment protocol is locked down for v1 already. But did you read it? It
doesn't use addresses anywhere. Payments are specified in terms of a list
of outputs which can contain any script. Of course it could be a
pay-to-address script, but pay-to-address uses more bytes in the chain and
there isn't any typeability benefit.

The multiplication trick for deterministic keys is a nice one and worth
doing, but it has to be a v2 feature by this point. It's more important to
get v1 widely implemented and deployed first.


On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner <etotheipi@gmail.com> wrote:

>  Guys,
>
> I'd like to reiterate my previous request to support this alternate
> address serialization in the payment protocol.  We got caught up in the
> specifics of one use case, but didn't acknowledge that it's still a valid
> address representation that will provide value to those who wish to use it
> and can be safely ignored by others.
>
> Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
> checksum)
> Alternate format:         binary_to_base58( idbyte + parentpubkey +
> multiplier + checksum)
>
> The receiving party will multiply the pubkey by the multiplier, and then
> hash it to get the 20-byte address to send to.  The idea is that you use
> your BIP 32 parent public key, and then you generate whatever child you
> want, and only send them the multiplier used (not the chaincode).  This
> preserves privacy, but if the recipient has your parent public key already,
> they can identify that address being linked to you, but cannot determine
> any other addresses in your wallet.
>
> This form has no drawbacks to the existing address format except for being
> longer and requiring an extra EC multiplication by the person sending to
> that address.  But the advantage is that it optionally allows the sender to
> provide more information than currently contained in the 25-byte hash160
> form.  The discussion about this got side-tracked with the use case I
> presented, but I believe there are plenty of other uses for this.
>
> The particular use case I had in mind was that certain services could be
> setup (pre-arranged), say between wallet software and a business/exchange.
> The exchange would like to be able to reliably send addresses to the user
> for deposit, without risk of MITM, or even if their own public server is
> compromised.  The author of wallet software pre-verifies the public key
> portion of the service, and either hardcodes it into the software, or
> hardcodes their own public key into the software and makes the service's
> signed public key available through query server (allowing the software
> author to offline-sign replacement keys, or add keys for new service
> providers, as needed).
>
> When the user's software receives a payment address, the software can
> verify it belongs to that service.  You can't use dedicated chain
> technique, because it would either have to be exchanged with the user on
> first transaction which half defeats the purpose, or they give them the
> full public key and chaincode which allows the user to see *all *addresses
> ever used by the service.  Neither one is a reasonable solution.
>
> This use case doesn't necessarily scale, but it doesn't have to.  It
> simply allows service providers to skip the SSL and go right to public key
> exchange/verification for a few of the important services they provide
> access to, and will provide better security than relying on SSL/PKI.  This
> would simply be one, coexisting option for providing payment details in the
> absence (or in addition to) SSL/PKI infrastructure.
>
> I'm sure there's other use cases, but it seems simple enough and
> non-disruptive enough that it could be supported easily for no other reason
> than to support that use case (which I intend to implement in Armory to
> help verify high-volume services).
>
> -Alan
>
>
>
>
>
> On 06/26/2013 11:29 AM, Alan Reiner wrote:
>
> Although I'd still prefer my original request, I get much of what I want
> from your guys' recommendation.  It complicates the wallet design, because
> it requires tracking and associating a matrix of addresses for each wallet,
> instead of a single linear list.  But if this is what it's going to take
> then I will go along.
>
> Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain used
> for distributing addresses, and j=1 is the "internal" chain for sending
> change.  The CONOPs (concept of operations) for the extended wallet would
> be like Jeremy described:
>
> - Chains with j>=2 would be independent address chains carved out for
> individuals relationships
> - Add wallet code to individually associate each j-value with a particular
> identity
> - Update the wallet code to pool all the addresses in all j-chains when
> calculating the balance of the wallet and/or creating transactions
> - When choosing to generically "Receive Bitcoins", will pick the next
> address from the j=0 chain
> - Will have to add extra function to "Receive Bitcoins" button to allow
> creation of new contacts/identities.
> - Change will always go to the next address in j=1, no matter which chains
> are used to provide inputs.
> - Add code to figure out lookaheads for each alternate chain.  Not just
> each chain, but looking ahead a couple chains, too.  Luckily, the lookahead
> doesn't have to be very big for chains j>=1
> - Add an interface to display and choose the different chains in your
> wallet, and export the pubkey&chaincode in some soon-to-be-standardized
> format.
> - Add code and interface to receive and track alternate j-chains from
> other clients/users, and maintain those.  Should we try associating
> incoming and outgoing chains?  What happens if they do it wrong?  Meh...
>
> Just as one final swipe at this idea, you can see that I gotta do quite a
> bit of work to support the multi-chain idea, and adds a little extra burden
> on the user to maintain the organization of the wallet.  This would all be
> totally unnecessary with a simple alternate encoding.  Granted, I think the
> multi-chain idea is good, and one that I will probably implement anyway,
> but it seems like overkill in terms of developer complexity, and interface
> complexity to achieve something much simpler.  Developers of much
> simpler/lightweight clients would probably find this prohibitive.
>
> On another note:  I thought we weren't encouraging automatic payments
> without requesting from the other party...?  It makes me uneasy, but it
> sounds like group thought has converged on that being acceptable.  I bring
> it up, because there are situations where it makes sense, but it sounds
> unsafe for general users.   Alice will give Bob his own chain for sending
> Alice money, then a year later Bob will send money automatically to Alice
> not realizing that the wallet was lost, retired or compromised.  It's not
> that Bob can't ask for a new address, it's that if the interface says "Send
> Money to Alice", that looks legit enough that Bob may not feel it necessary
> to check with Alice first.   That's more of an interface issue though.  We
> can add a warning to "check with the recipient that they still have access
> to wallet 3cQ398x", etc.   But I just know someone is going to lose money
> anyway...
>
> -Alan
>
>
>
>
>
> On 06/20/2013 03:32 AM, Mike Hearn wrote:
>
> Agree with Jeremy and once the payment protocol work is further along I'd
> like to see us define an extension that lets you send payment requests
> containing public keys+chain codes, so further payments can be made
> push-style with no recipient interaction (e.g. for repeated billing). How
> apps choose to arrange their chains internally seems like an area for
> experimentation. I definitely want to implement HD wallets in bitcoinj to
> allow this and if that means not using the same tree structure as in the
> BIP then so be it.
>
>
> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co> wrote:
>
>> > BIP 32 already specifies how to use the first three tree levels:
>>  M/i/j/k,
>> > i~wallet, j~Internal/External, k~address.  The first level is actually
>> > type-1 derived, and thus we cannot create an arbitrary number of them
>> > without pre-computing them from the offline wallet.  So it's not "free"
>> to
>> > create new wallets unless we redefine how the levels work.
>>
>>  Initially I was thinking that you would share the public key and chain
>> code
>> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique
>> value of 'i' for each receive chain.
>>
>> For the case of generating new receive chains from a *watch-only* wallet,
>> as
>> you say, the options are to either keep a cache of PubKey/ChainCode for
>> unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] --
>> the
>> concept of 'internal/'external' and change addresses at Depth=2 don't make
>> sense for handing out receive chains to lots of people anyway, and
>> certainly
>> BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j' is the
>> way
>> to go here...
>>
>> The "default" layout of BIP32 does NOT mean that implementations should
>> not
>> check for transactions with j > 1. That would be a useless constraint and
>> obviously self-limiting. It might be helpful to add to the 'Compatibility'
>> section some minimum expectations about how a wallet should be 'probed'
>> when
>> imported. If you don't feel completely free to monotonically increment 'j'
>> to your hearts content to achieve major usability benefits, then I say
>> BIP32
>> could use some clarifying.
>>
>> BTW - the spec calls for addition not multiplication now, so we should
>> call
>> it the 'Addend' not the 'Multiplier' :-)
>>
>> > Do these extra wallet chains behave as different wallets, or
>> sub-wallets?
>>
>>  They could, but they certainly don't need to!  A single-wallet
>> implementation treats this merely as an address-generation algorithm, and
>> does not expose any hierarchy to the user interface.  The user just
>> “magically” gets the ability to send multiple payments to their contacts
>> without immediately sacrificing their privacy
>> (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
>> goes into the same ledger, balance, coin pool, etc. Most of the code base
>> is
>> unaware BIP32 is even in use.
>>
>> While it is *possible* to support separate ledgers, balances, etc. it is
>> certainly not required, and you get all the benefits either way.
>>
>> I think, since your proposal generates and receives payments into
>> BIP32-style addresses, we both need similar underlying wallet code. The
>> only
>> difference is that you are passing the Kpar for [m/i'/0/k] and the
>> *result*
>> of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar,
>> and
>> leaving 'k' out of it, letting the receive choose 'k'.
>>
>> > For instance, maybe there's a benefit to using the same parent pubkey
>>  > across multiple services, as a form of identity.   If I don't want
>> that, I
>> > use your method.  If I do want that, I use my method.
>>
>>  I think it's a interesting idea using static public keys as a means for
>> persistent identity and hence security from MitM. If you want a shared
>> public key across multiple services we could just combine both ideas and
>> get
>> all the benefits, by making the data structure { ParentPubKey, Addend,
>> ChainCode }:
>>
>>    ParentPubKey: Public key of m/i' -- 33 bytes
>>    Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>>    ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>>
>> All that remains secret is the ChainCode from [m/i'] -- and of course the
>> private keys.  The ParentPubKey is a common value across multiple
>> services,
>> corresponding to user's identity rooted in [m/i'].  Each service gets
>> their
>> own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].  With
>> the
>> ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
>> increasing 'k'. Again, from the user perspective all transactions under
>> [m/i'] can be presented in a single ledger, or not.
>>
>> Anyway, fundamentally my feedback is if you are designing for persistent
>> long-term relationships, you could build in a mechanism for generating
>> address chains so you don't need any further communication after the
>> initial
>> exchange, and it need not complicate the wallet.
>>
>> Thanks,
>> --Jeremy
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
> http://p.sf.net/sfu/windows-dev2dev
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

[Alan Reiner]

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

That's fine.  I just want to make sure it's considered for inclusion at
some point, because I really hope to leverage the "identity" mechanism I
just described, and it's much easier if it's part of a standard instead
of convincing others to go around the standard with us.

I have not spent much time looking at the payment protocol itself.  I
didn't feel like I'd have much to contribute (besides requesting a
feature I know isn't there).  I was planning to wait until it was
complete before fully grokking and implementing it in Armory.


On 08/09/2013 03:58 PM, Mike Hearn wrote:
> Payment protocol is locked down for v1 already. But did you read it?
> It doesn't use addresses anywhere. Payments are specified in terms of
> a list of outputs which can contain any script. Of course it could be
> a pay-to-address script, but pay-to-address uses more bytes in the
> chain and there isn't any typeability benefit.
>
> The multiplication trick for deterministic keys is a nice one and
> worth doing, but it has to be a v2 feature by this point. It's more
> important to get v1 widely implemented and deployed first.
>
>
> On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner <etotheipi@gmail.com
> <mailto:etotheipi@gmail.com>> wrote:
>
>     Guys,
>
>     I'd like to reiterate my previous request to support this
>     alternate address serialization in the payment protocol.  We got
>     caught up in the specifics of one use case, but didn't acknowledge
>     that it's still a valid address representation that will provide
>     value to those who wish to use it and can be safely ignored by others.
>
>     Current address format:   binary_to_base58( idbyte +
>     hash160(pubkey) + checksum)
>     Alternate format:         binary_to_base58( idbyte + parentpubkey
>     + multiplier + checksum)
>
>     The receiving party will multiply the pubkey by the multiplier,
>     and then hash it to get the 20-byte address to send to.  The idea
>     is that you use your BIP 32 parent public key, and then you
>     generate whatever child you want, and only send them the
>     multiplier used (not the chaincode).  This preserves privacy, but
>     if the recipient has your parent public key already, they can
>     identify that address being linked to you, but cannot determine
>     any other addresses in your wallet.
>
>     This form has no drawbacks to the existing address format except
>     for being longer and requiring an extra EC multiplication by the
>     person sending to that address.  But the advantage is that it
>     optionally allows the sender to provide more information than
>     currently contained in the 25-byte hash160 form.  The discussion
>     about this got side-tracked with the use case I presented, but I
>     believe there are plenty of other uses for this.
>
>     The particular use case I had in mind was that certain services
>     could be setup (pre-arranged), say between wallet software and a
>     business/exchange.  The exchange would like to be able to reliably
>     send addresses to the user for deposit, without risk of MITM, or
>     even if their own public server is compromised.  The author of
>     wallet software pre-verifies the public key portion of the
>     service, and either hardcodes it into the software, or hardcodes
>     their own public key into the software and makes the service's
>     signed public key available through query server (allowing the
>     software author to offline-sign replacement keys, or add keys for
>     new service providers, as needed). 
>
>     When the user's software receives a payment address, the software
>     can verify it belongs to that service.  You can't use dedicated
>     chain technique, because it would either have to be exchanged with
>     the user on first transaction which half defeats the purpose, or
>     they give them the full public key and chaincode which allows the
>     user to see /all /addresses ever used by the service.  Neither one
>     is a reasonable solution.
>
>     This use case doesn't necessarily scale, but it doesn't have to. 
>     It simply allows service providers to skip the SSL and go right to
>     public key exchange/verification for a few of the important
>     services they provide access to, and will provide better security
>     than relying on SSL/PKI.  This would simply be one, coexisting
>     option for providing payment details in the absence (or in
>     addition to) SSL/PKI infrastructure.
>
>     I'm sure there's other use cases, but it seems simple enough and
>     non-disruptive enough that it could be supported easily for no
>     other reason than to support that use case (which I intend to
>     implement in Armory to help verify high-volume services).
>
>     -Alan
>
>
>
>
>
>     On 06/26/2013 11:29 AM, Alan Reiner wrote:
>>     Although I'd still prefer my original request, I get much of what
>>     I want from your guys' recommendation.  It complicates the wallet
>>     design, because it requires tracking and associating a matrix of
>>     addresses for each wallet, instead of a single linear list.  But
>>     if this is what it's going to take then I will go along. 
>>
>>     Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external"
>>     chain used for distributing addresses, and j=1 is the "internal"
>>     chain for sending change.  The CONOPs (concept of operations) for
>>     the extended wallet would be like Jeremy described:
>>
>>     - Chains with j>=2 would be independent address chains carved out
>>     for individuals relationships
>>     - Add wallet code to individually associate each j-value with a
>>     particular identity
>>     - Update the wallet code to pool all the addresses in all
>>     j-chains when calculating the balance of the wallet and/or
>>     creating transactions
>>     - When choosing to generically "Receive Bitcoins", will pick the
>>     next address from the j=0 chain
>>     - Will have to add extra function to "Receive Bitcoins" button to
>>     allow creation of new contacts/identities.
>>     - Change will always go to the next address in j=1, no matter
>>     which chains are used to provide inputs.
>>     - Add code to figure out lookaheads for each alternate chain. 
>>     Not just each chain, but looking ahead a couple chains, too. 
>>     Luckily, the lookahead doesn't have to be very big for chains j>=1 
>>     - Add an interface to display and choose the different chains in
>>     your wallet, and export the pubkey&chaincode in some
>>     soon-to-be-standardized format. 
>>     - Add code and interface to receive and track alternate j-chains
>>     from other clients/users, and maintain those.  Should we try
>>     associating incoming and outgoing chains?  What happens if they
>>     do it wrong?  Meh...
>>
>>     Just as one final swipe at this idea, you can see that I gotta do
>>     quite a bit of work to support the multi-chain idea, and adds a
>>     little extra burden on the user to maintain the organization of
>>     the wallet.  This would all be totally unnecessary with a simple
>>     alternate encoding.  Granted, I think the multi-chain idea is
>>     good, and one that I will probably implement anyway, but it seems
>>     like overkill in terms of developer complexity, and interface
>>     complexity to achieve something much simpler.  Developers of much
>>     simpler/lightweight clients would probably find this prohibitive.
>>
>>     On another note:  I thought we weren't encouraging automatic
>>     payments without requesting from the other party...?  It makes me
>>     uneasy, but it sounds like group thought has converged on that
>>     being acceptable.  I bring it up, because there are situations
>>     where it makes sense, but it sounds unsafe for general users.  
>>     Alice will give Bob his own chain for sending Alice money, then a
>>     year later Bob will send money automatically to Alice not
>>     realizing that the wallet was lost, retired or compromised.  It's
>>     not that Bob can't ask for a new address, it's that if the
>>     interface says "Send Money to Alice", that looks legit enough
>>     that Bob may not feel it necessary to check with Alice first.  
>>     That's more of an interface issue though.  We can add a warning
>>     to "check with the recipient that they still have access to
>>     wallet 3cQ398x", etc.   But I just know someone is going to lose
>>     money anyway...
>>
>>     -Alan
>>
>>
>>
>>
>>
>>     On 06/20/2013 03:32 AM, Mike Hearn wrote:
>>>     Agree with Jeremy and once the payment protocol work is further
>>>     along I'd like to see us define an extension that lets you send
>>>     payment requests containing public keys+chain codes, so further
>>>     payments can be made push-style with no recipient interaction
>>>     (e.g. for repeated billing). How apps choose to arrange their
>>>     chains internally seems like an area for experimentation. I
>>>     definitely want to implement HD wallets in bitcoinj to allow
>>>     this and if that means not using the same tree structure as in
>>>     the BIP then so be it.
>>>
>>>
>>>     On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman
>>>     <jeremy@taplink.co <mailto:jeremy@taplink.co>> wrote:
>>>
>>>         > BIP 32 already specifies how to use the first three tree
>>>         levels:  M/i/j/k,
>>>         > i~wallet, j~Internal/External, k~address.  The first level
>>>         is actually
>>>         > type-1 derived, and thus we cannot create an arbitrary
>>>         number of them
>>>         > without pre-computing them from the offline wallet.  So
>>>         it's not "free" to
>>>         > create new wallets unless we redefine how the levels work.
>>>
>>>         Initially I was thinking that you would share the public key
>>>         and chain code
>>>         from [m/i'/0] so that you can receive payments at
>>>         [m/i'/0/k], for a unique
>>>         value of 'i' for each receive chain.
>>>
>>>         For the case of generating new receive chains from a
>>>         *watch-only* wallet, as
>>>         you say, the options are to either keep a cache of
>>>         PubKey/ChainCode for
>>>         unused [m/i'] or simply increment 'j' past 1 for an existing
>>>         [m/i'/j] -- the
>>>         concept of 'internal/'external' and change addresses at
>>>         Depth=2 don't make
>>>         sense for handing out receive chains to lots of people
>>>         anyway, and certainly
>>>         BIP32 doesn't *require* 0 <= j <= 1.  So I think
>>>         incrementing 'j' is the way
>>>         to go here...
>>>
>>>         The "default" layout of BIP32 does NOT mean that
>>>         implementations should not
>>>         check for transactions with j > 1. That would be a useless
>>>         constraint and
>>>         obviously self-limiting. It might be helpful to add to the
>>>         'Compatibility'
>>>         section some minimum expectations about how a wallet should
>>>         be 'probed' when
>>>         imported. If you don't feel completely free to monotonically
>>>         increment 'j'
>>>         to your hearts content to achieve major usability benefits,
>>>         then I say BIP32
>>>         could use some clarifying.
>>>
>>>         BTW - the spec calls for addition not multiplication now, so
>>>         we should call
>>>         it the 'Addend' not the 'Multiplier' :-)
>>>
>>>         > Do these extra wallet chains behave as different wallets,
>>>         or sub-wallets?
>>>
>>>         They could, but they certainly don't need to!  A single-wallet
>>>         implementation treats this merely as an address-generation
>>>         algorithm, and
>>>         does not expose any hierarchy to the user interface.  The
>>>         user just
>>>         “magically” gets the ability to send multiple payments to
>>>         their contacts
>>>         without immediately sacrificing their privacy
>>>         (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/).
>>>         Everything
>>>         goes into the same ledger, balance, coin pool, etc. Most of
>>>         the code base is
>>>         unaware BIP32 is even in use.
>>>
>>>         While it is *possible* to support separate ledgers,
>>>         balances, etc. it is
>>>         certainly not required, and you get all the benefits either way.
>>>
>>>         I think, since your proposal generates and receives payments
>>>         into
>>>         BIP32-style addresses, we both need similar underlying
>>>         wallet code. The only
>>>         difference is that you are passing the Kpar for [m/i'/0/k]
>>>         and the *result*
>>>         of CKD'((Kpar, cpar), k), and instead I proposed passing
>>>         Kpar and cpar, and
>>>         leaving 'k' out of it, letting the receive choose 'k'.
>>>
>>>         > For instance, maybe there's a benefit to using the same
>>>         parent pubkey
>>>         > across multiple services, as a form of identity.   If I
>>>         don't want that, I
>>>         > use your method.  If I do want that, I use my method.
>>>
>>>         I think it's a interesting idea using static public keys as
>>>         a means for
>>>         persistent identity and hence security from MitM. If you
>>>         want a shared
>>>         public key across multiple services we could just combine
>>>         both ideas and get
>>>         all the benefits, by making the data structure {
>>>         ParentPubKey, Addend,
>>>         ChainCode }:
>>>
>>>            ParentPubKey: Public key of m/i' -- 33 bytes
>>>            Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>>>            ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>>>
>>>         All that remains secret is the ChainCode from [m/i'] -- and
>>>         of course the
>>>         private keys.  The ParentPubKey is a common value across
>>>         multiple services,
>>>         corresponding to user's identity rooted in [m/i'].  Each
>>>         service gets their
>>>         own 'j'.  ParentPubKey + Addend gives you the PubKey of
>>>         [m/i'/j].  With the
>>>         ChainCode, the receiver then can generate [m/i'/j/k] for
>>>         monotonically
>>>         increasing 'k'. Again, from the user perspective all
>>>         transactions under
>>>         [m/i'] can be presented in a single ledger, or not.
>>>
>>>         Anyway, fundamentally my feedback is if you are designing
>>>         for persistent
>>>         long-term relationships, you could build in a mechanism for
>>>         generating
>>>         address chains so you don't need any further communication
>>>         after the initial
>>>         exchange, and it need not complicate the wallet.
>>>
>>>         Thanks,
>>>         --Jeremy
>>>
>>>
>>>
>>>         ------------------------------------------------------------------------------
>>>         This SF.net email is sponsored by Windows:
>>>
>>>         Build for Windows Store.
>>>
>>>         http://p.sf.net/sfu/windows-dev2dev
>>>         _______________________________________________
>>>         Bitcoin-development mailing list
>>>         Bitcoin-development@lists.sourceforge.net
>>>         <mailto:Bitcoin-development@lists.sourceforge.net>
>>>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>>     ------------------------------------------------------------------------------
>>>     This SF.net email is sponsored by Windows:
>>>
>>>     Build for Windows Store.
>>>
>>>     http://p.sf.net/sfu/windows-dev2dev
>>>
>>>
>>>     _______________________________________________
>>>     Bitcoin-development mailing list
>>>     Bitcoin-development@lists.sourceforge.net <mailto:Bitcoin-development@lists.sourceforge.net>
>>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>     ------------------------------------------------------------------------------
>     Get 100% visibility into Java/.NET code with AppDynamics Lite!
>     It's a free troubleshooting tool designed for production.
>     Get down to code-level detail for bottlenecks, with <2% overhead.
>     Download for free and get started troubleshooting in minutes.
>     http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


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

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

[Mike Hearn]

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

It's BIP specified and implemented in Bitcoin-Qt so now is the time to
start :) I'm hoping that most wallets can announce support near
simultaneously ....


On Fri, Aug 9, 2013 at 10:12 PM, Alan Reiner <etotheipi@gmail.com> wrote:

>  That's fine.  I just want to make sure it's considered for inclusion at
> some point, because I really hope to leverage the "identity" mechanism I
> just described, and it's much easier if it's part of a standard instead of
> convincing others to go around the standard with us.
>
> I have not spent much time looking at the payment protocol itself.  I
> didn't feel like I'd have much to contribute (besides requesting a feature
> I know isn't there).  I was planning to wait until it was complete before
> fully grokking and implementing it in Armory.
>
>
>
> On 08/09/2013 03:58 PM, Mike Hearn wrote:
>
> Payment protocol is locked down for v1 already. But did you read it? It
> doesn't use addresses anywhere. Payments are specified in terms of a list
> of outputs which can contain any script. Of course it could be a
> pay-to-address script, but pay-to-address uses more bytes in the chain and
> there isn't any typeability benefit.
>
>  The multiplication trick for deterministic keys is a nice one and worth
> doing, but it has to be a v2 feature by this point. It's more important to
> get v1 widely implemented and deployed first.
>
>
> On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner <etotheipi@gmail.com> wrote:
>
>>  Guys,
>>
>> I'd like to reiterate my previous request to support this alternate
>> address serialization in the payment protocol.  We got caught up in the
>> specifics of one use case, but didn't acknowledge that it's still a valid
>> address representation that will provide value to those who wish to use it
>> and can be safely ignored by others.
>>
>> Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
>> checksum)
>> Alternate format:         binary_to_base58( idbyte + parentpubkey +
>> multiplier + checksum)
>>
>> The receiving party will multiply the pubkey by the multiplier, and then
>> hash it to get the 20-byte address to send to.  The idea is that you use
>> your BIP 32 parent public key, and then you generate whatever child you
>> want, and only send them the multiplier used (not the chaincode).  This
>> preserves privacy, but if the recipient has your parent public key already,
>> they can identify that address being linked to you, but cannot determine
>> any other addresses in your wallet.
>>
>> This form has no drawbacks to the existing address format except for
>> being longer and requiring an extra EC multiplication by the person sending
>> to that address.  But the advantage is that it optionally allows the sender
>> to provide more information than currently contained in the 25-byte hash160
>> form.  The discussion about this got side-tracked with the use case I
>> presented, but I believe there are plenty of other uses for this.
>>
>> The particular use case I had in mind was that certain services could be
>> setup (pre-arranged), say between wallet software and a business/exchange.
>> The exchange would like to be able to reliably send addresses to the user
>> for deposit, without risk of MITM, or even if their own public server is
>> compromised.  The author of wallet software pre-verifies the public key
>> portion of the service, and either hardcodes it into the software, or
>> hardcodes their own public key into the software and makes the service's
>> signed public key available through query server (allowing the software
>> author to offline-sign replacement keys, or add keys for new service
>> providers, as needed).
>>
>> When the user's software receives a payment address, the software can
>> verify it belongs to that service.  You can't use dedicated chain
>> technique, because it would either have to be exchanged with the user on
>> first transaction which half defeats the purpose, or they give them the
>> full public key and chaincode which allows the user to see *all *addresses
>> ever used by the service.  Neither one is a reasonable solution.
>>
>> This use case doesn't necessarily scale, but it doesn't have to.  It
>> simply allows service providers to skip the SSL and go right to public key
>> exchange/verification for a few of the important services they provide
>> access to, and will provide better security than relying on SSL/PKI.  This
>> would simply be one, coexisting option for providing payment details in the
>> absence (or in addition to) SSL/PKI infrastructure.
>>
>> I'm sure there's other use cases, but it seems simple enough and
>> non-disruptive enough that it could be supported easily for no other reason
>> than to support that use case (which I intend to implement in Armory to
>> help verify high-volume services).
>>
>> -Alan
>>
>>
>>
>>
>>
>> On 06/26/2013 11:29 AM, Alan Reiner wrote:
>>
>> Although I'd still prefer my original request, I get much of what I want
>> from your guys' recommendation.  It complicates the wallet design, because
>> it requires tracking and associating a matrix of addresses for each wallet,
>> instead of a single linear list.  But if this is what it's going to take
>> then I will go along.
>>
>> Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
>> used for distributing addresses, and j=1 is the "internal" chain for
>> sending change.  The CONOPs (concept of operations) for the extended wallet
>> would be like Jeremy described:
>>
>> - Chains with j>=2 would be independent address chains carved out for
>> individuals relationships
>> - Add wallet code to individually associate each j-value with a
>> particular identity
>> - Update the wallet code to pool all the addresses in all j-chains when
>> calculating the balance of the wallet and/or creating transactions
>> - When choosing to generically "Receive Bitcoins", will pick the next
>> address from the j=0 chain
>> - Will have to add extra function to "Receive Bitcoins" button to allow
>> creation of new contacts/identities.
>> - Change will always go to the next address in j=1, no matter which
>> chains are used to provide inputs.
>> - Add code to figure out lookaheads for each alternate chain.  Not just
>> each chain, but looking ahead a couple chains, too.  Luckily, the lookahead
>> doesn't have to be very big for chains j>=1
>> - Add an interface to display and choose the different chains in your
>> wallet, and export the pubkey&chaincode in some soon-to-be-standardized
>> format.
>> - Add code and interface to receive and track alternate j-chains from
>> other clients/users, and maintain those.  Should we try associating
>> incoming and outgoing chains?  What happens if they do it wrong?  Meh...
>>
>> Just as one final swipe at this idea, you can see that I gotta do quite a
>> bit of work to support the multi-chain idea, and adds a little extra burden
>> on the user to maintain the organization of the wallet.  This would all be
>> totally unnecessary with a simple alternate encoding.  Granted, I think the
>> multi-chain idea is good, and one that I will probably implement anyway,
>> but it seems like overkill in terms of developer complexity, and interface
>> complexity to achieve something much simpler.  Developers of much
>> simpler/lightweight clients would probably find this prohibitive.
>>
>> On another note:  I thought we weren't encouraging automatic payments
>> without requesting from the other party...?  It makes me uneasy, but it
>> sounds like group thought has converged on that being acceptable.  I bring
>> it up, because there are situations where it makes sense, but it sounds
>> unsafe for general users.   Alice will give Bob his own chain for sending
>> Alice money, then a year later Bob will send money automatically to Alice
>> not realizing that the wallet was lost, retired or compromised.  It's not
>> that Bob can't ask for a new address, it's that if the interface says "Send
>> Money to Alice", that looks legit enough that Bob may not feel it necessary
>> to check with Alice first.   That's more of an interface issue though.  We
>> can add a warning to "check with the recipient that they still have access
>> to wallet 3cQ398x", etc.   But I just know someone is going to lose money
>> anyway...
>>
>> -Alan
>>
>>
>>
>>
>>
>> On 06/20/2013 03:32 AM, Mike Hearn wrote:
>>
>> Agree with Jeremy and once the payment protocol work is further along I'd
>> like to see us define an extension that lets you send payment requests
>> containing public keys+chain codes, so further payments can be made
>> push-style with no recipient interaction (e.g. for repeated billing). How
>> apps choose to arrange their chains internally seems like an area for
>> experimentation. I definitely want to implement HD wallets in bitcoinj to
>> allow this and if that means not using the same tree structure as in the
>> BIP then so be it.
>>
>>
>> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co>wrote:
>>
>>> > BIP 32 already specifies how to use the first three tree levels:
>>>  M/i/j/k,
>>> > i~wallet, j~Internal/External, k~address.  The first level is actually
>>> > type-1 derived, and thus we cannot create an arbitrary number of them
>>> > without pre-computing them from the offline wallet.  So it's not
>>> "free" to
>>> > create new wallets unless we redefine how the levels work.
>>>
>>>  Initially I was thinking that you would share the public key and chain
>>> code
>>> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a
>>> unique
>>> value of 'i' for each receive chain.
>>>
>>> For the case of generating new receive chains from a *watch-only*
>>> wallet, as
>>> you say, the options are to either keep a cache of PubKey/ChainCode for
>>> unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] --
>>> the
>>> concept of 'internal/'external' and change addresses at Depth=2 don't
>>> make
>>> sense for handing out receive chains to lots of people anyway, and
>>> certainly
>>> BIP32 doesn't *require* 0 <= j <= 1.  So I think incrementing 'j' is the
>>> way
>>> to go here...
>>>
>>> The "default" layout of BIP32 does NOT mean that implementations should
>>> not
>>> check for transactions with j > 1. That would be a useless constraint and
>>> obviously self-limiting. It might be helpful to add to the
>>> 'Compatibility'
>>> section some minimum expectations about how a wallet should be 'probed'
>>> when
>>> imported. If you don't feel completely free to monotonically increment
>>> 'j'
>>> to your hearts content to achieve major usability benefits, then I say
>>> BIP32
>>> could use some clarifying.
>>>
>>> BTW - the spec calls for addition not multiplication now, so we should
>>> call
>>> it the 'Addend' not the 'Multiplier' :-)
>>>
>>> > Do these extra wallet chains behave as different wallets, or
>>> sub-wallets?
>>>
>>>  They could, but they certainly don't need to!  A single-wallet
>>> implementation treats this merely as an address-generation algorithm, and
>>> does not expose any hierarchy to the user interface.  The user just
>>> “magically” gets the ability to send multiple payments to their contacts
>>> without immediately sacrificing their privacy
>>> (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/).
>>> Everything
>>> goes into the same ledger, balance, coin pool, etc. Most of the code
>>> base is
>>> unaware BIP32 is even in use.
>>>
>>> While it is *possible* to support separate ledgers, balances, etc. it is
>>> certainly not required, and you get all the benefits either way.
>>>
>>> I think, since your proposal generates and receives payments into
>>> BIP32-style addresses, we both need similar underlying wallet code. The
>>> only
>>> difference is that you are passing the Kpar for [m/i'/0/k] and the
>>> *result*
>>> of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar,
>>> and
>>> leaving 'k' out of it, letting the receive choose 'k'.
>>>
>>> > For instance, maybe there's a benefit to using the same parent pubkey
>>>  > across multiple services, as a form of identity.   If I don't want
>>> that, I
>>> > use your method.  If I do want that, I use my method.
>>>
>>>  I think it's a interesting idea using static public keys as a means for
>>> persistent identity and hence security from MitM. If you want a shared
>>> public key across multiple services we could just combine both ideas and
>>> get
>>> all the benefits, by making the data structure { ParentPubKey, Addend,
>>> ChainCode }:
>>>
>>>    ParentPubKey: Public key of m/i' -- 33 bytes
>>>    Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
>>>    ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>>>
>>> All that remains secret is the ChainCode from [m/i'] -- and of course the
>>> private keys.  The ParentPubKey is a common value across multiple
>>> services,
>>> corresponding to user's identity rooted in [m/i'].  Each service gets
>>> their
>>> own 'j'.  ParentPubKey + Addend gives you the PubKey of [m/i'/j].  With
>>> the
>>> ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
>>> increasing 'k'. Again, from the user perspective all transactions under
>>> [m/i'] can be presented in a single ledger, or not.
>>>
>>> Anyway, fundamentally my feedback is if you are designing for persistent
>>> long-term relationships, you could build in a mechanism for generating
>>> address chains so you don't need any further communication after the
>>> initial
>>> exchange, and it need not complicate the wallet.
>>>
>>> Thanks,
>>> --Jeremy
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>> http://p.sf.net/sfu/windows-dev2dev
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

[Gavin Andresen]

As Mike said: the payment protocol doesn't use bitcoin addresses under
the covers.

It is also designed to be easily extensible, so if you want the server
to send the wallet software a public key and multiplier, then add
"publickey" and "multiplier" optional fields to the PaymentDetails (or
maybe Output) message.

-- 
--
Gavin Andresen