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

[Alan Reiner]

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  > 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 associatin

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

--
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

Re: [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  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  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 req

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

[Mike Hearn]

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  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 Bitc