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

[Mike Hearn]

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 at 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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130809/7674fec9/attachment.html>