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 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 >>> > 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 list >>> 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 > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >