On 09/04/2019 00.54, parm.sing...@gmail.com wrote: > Bitcoinj has skipped P2SH-P2WPKH, so I recommend using P2WPKH > for modern wallets and keep P2PKH as a fallback for compatibility. > > So when we are sending and receiving payments, can we used mixed UTXOs > with P2PKH and P2WPKH?
Yes. In the same transaction multiple inputs can spend from multiple types of script, including (but not limited to) P2PKH and P2WPKH. Same with outputs and spending *to*. > I believed P2PKH can't send transactions to > P2WPKH that is why P2SH-P2WPKH is used by other implementations for > backward and forward compatibility and it also allows mixed UTXOs. P2SH-P2WPKH exists only because old wallets/services cannot send to P2WPKH if Bech32 addresses are used (albeit if using the BIP70 payment protocol there is no such limitation because it avoids addresses altogether). > If we > are keeping them separate then Does that means we are keeping track of > two separate chains Yes, for now. At some point when we don't need the ability to receive to P2PKH any more I plan to skip creating the P2PKH chain. We'd need to increment the wallet version for that though. > hence multiple account scenario you mentioned > above which leads to scalability problem that bitcoinj inherits. I think there is not much difference between watching one chain with N addresses and two chains with say N/2 addresses each. The scalability is mainly affected by the number of relevant transactions received/sent, and that number is not dependent on any address type, or the number of address types that can be used in parallel. It mostly depends on user behaviour, e.g. how many Bitcoin pubs he/she visits. > The BIPs you mentioned don't fit well with the assumptions bitcoinj > makes. For example, bitcoinj only supports Bitcoin so the coin_type > field is of limited use. Also, the Wallet class doesn't have the > notion of "accounts" > > I did get your point regarding multiple accounts, its not very scalable > with bitcoinj implementation. Actually our reasoning for not supporting accounts is that it's too generic for users. We always wanted to support more concrete usecases, like separation into a savings account (backed by hardware wallet) and a spending account. We never got around to implementing that though. And those users who want truely independant wallets are better off by using multiple wallets. Or even better use multiple user accounts at OS level, that would separate your entire usecase and not just the payment. > My understanding is that most of the > wallets out there are using bip 44 already and if we start using it in > as default in bitcoinJ, then it'll make it easy for end users to migrate > from one wallet to another based on their use cases. Honestly I don't believe in compatibility between wallets, import/export and that kind of stuff. There are more parameters that just the derivation path(s), e.g. lookahead threshold/size. And all that stuff can go wrong. What do we gain? Use a Bitcoin transaction to transfer value; that's what Bitcoin is designed for and it does well. > Even Bisq is using > hacked up version to implement bip 44. we can still advise users to not > use bitcoinj for account purposed unless they want to have issues. we > can just have m/44H/0H/0H/0/0 instead of m/0H/[0,1], it'll serve that > same purpose but allow wallet compatibility. Except that if you only support account 0, Bitcoins on other accounts won't be visible and the user might think his/her wallet is empty so she/he can scrap it. This is why according to BIP44, support for accounts is mandatory. > Would it be worth submitting a PR that allow you to chose between bip 32 > or 44 defaults? The words "choose" and "defaults" in combination don't compute for me (-: You can already pick a derivation path when creating your key chain, and there is a BIP44_ACCOUNT_ZERO_PATH constant for your convenience. I wouldn't mind adding a similar constant for BIP84 and then maybe add a KeyChainGroupStructure implementation that combines the two if that makes sense to developers using bitcoinj with BIP44 right now. I would however object to changing the default structure. -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
