[Bitcoin-development] Optional wallet-linkable address format (Re-request)
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 pubkeychaincode 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
Re: [Bitcoin-development] Optional wallet-linkable address format (Re-request)
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 etothe...@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
Re: [Bitcoin-development] Optional wallet-linkable address format (Re-request)
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 etothe...@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 etothe...@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
