Mixed mode for SegWit wallets

[Giszmo]

In the migration to SegWit and bech32, one usability obstacle was, what to do in order to transition from legacy to segwit accounts and how to phase in bech32 when almost no wallets support it.

Create accounts per type (hardware wallets do this)

This approach would mean that the user would keep using his legacy accounts as defined by BIP44 and when creating a new account, it would default to BIP49 (segWit compatibility mode) and the user could also create accounts according to BIP84 (segwit bech32) or BIP44 (legacy).

Advantages:

• Compatibility with the existing standards (BIP44, 49 and 84). The change output goes into the same and only content type as the funds were in before and thus no change goes to unused accounts or even unused accounts creating gaps.
• Hardware wallets don't show scary messages, as the change output is treated as a second "send", although the device might mark it as going to the device. Anyone but very tech savvy users will get scared when paying a $5 coffee with their trezor and get asked if they really want to send $5000 to "1xyz... Trezor#1".
• No extra addresses to scan per account, as the look-ahead of all three types would be tracked per account as per the user's use of these.

Mix account types

Here, "Account 1" would actually encompass account 1 as defined by all relevant bips (44, 49 and 84). The user would be able to receive on either segwit (P2SH is compatible with all existing wallets) or bech32 into the "same" account. When sending funds to any address, change could get received into the sub-account of the according type.

Advantages:

• The user would not have to switch to a completely different account to make use of the new features and when the counter party doesn't support that type, switch back to a compatible account.
• Chain analysis would have an harder time figuring out which is the change output as not the input dictates the change output type but the spend output.

Status

In our (still private) segwit branch we took the mixed mode approach, valuing ease of use and privacy higher than slightly higher resource consumption and potentially harder migration to other standard wallets, especially as other wallets seam to also have taken this approach. Our main obstacle is hardware wallets and we are evaluating if there was a way to both have the privacy benefits and the change output not scare the user.

[Giszmo]

This issue depends on #379 and #425

[Giszmo]

Here is how Trezor and Keepkey deal with change outputs in the different scenarios.
(Sorry for the poor quality but I guess the gist of it is easy to read.)

• Send from p2sh to p2sh with change to p2sh: No problem
• Send from one type (or a mix of types) to another type: User gets scared

Actually I'm surprised that in the Trezor software (chrome plugin) bech32/BIP84 seams not to be supported. The tb1 transactions have 2 outputs, sending all the funds. Or is this a bug in our software and these transactions went to the wrong bip32 path (m/84'/1'/1'/1/0)?

[Giszmo]

@slush0 @prusnak @pollastri-pierre @keepkeyjon any ideas how to give our users the mentioned privacy while still not scaring them with "Really send 2.8BTC from your wallet" when sending $5 as in the center column above?

[prusnak]

"Really send 2.8BTC from your wallet" - this is correct. You are sending 2.8BTC from your account to another account. If you don't want to show it, don't send coins across accounts (i.e. don't use mixed transactions).

[sergeylappo]

@prusnak, "You are sending 2.8 BTC from your account" is correct according to the current account implementation. But what if we could merge different address/accounts types into one account? Thus we would (Simplifying what has been said by @Giszmo):

1. Increase privacy by sending change to corresponding "sub-account". It becomes harder to track funds, for instance, according to the current implementation of BIP if you sent funds from bip44 to bech32 - change must be on the bip44 branch. But if there are only one input and one output + change it becomes clear where change goes.
2. Prevent user misunderstanding: why should user really care which type of address he want to import? What does it mean legacy? Do end user should really care about protocol improvements? I mean he should feel that things become better, but he shouldn't after updating app see something like "your funds are on legacy". If we want to bring cryptocurrencies to wide masses we must keep things simple.
   The goal of this mixed mode is increased privacy while keeping things simple.

[keepkeyjon]

Incompatibility with the existing standards (BIP44, 49 and 84).

It doesn't seem too bad to have this be "enforced" client-side, i.e. only create upgraded/downgraded change outputs when the account exists according to the gap account rules. Device-side, I'd only consider such an output to be change if:

• It goes to the same account number
• On an equal or greater account type BIP44 <= BIP49 <= BIP84
• It goes to the change chain
• It is the 1st and only change output

We must consider though, how could this be used maliciously (if at all)? My first thought is that it could be used to hide funds from a user since it sends funds to a place not all vendors support. This seems no worse than the current state of client-side segwit support, and feels similar to another case which we can't protect against: sending to a change address well beyond the standard address gap limit. Since both cases need client-side cooperation to DTRT, and given the other benefits, I'm in favor of making this change in our wallet (pun intended).

Edit: correction, I meant BIP84.

[DanielWeigl]

From a user-perspective the best thing would be to transparently switch over to different transaction- and address types, but my main consideration while defining BIP49 (which was back then when I worked for mycelium) was to also make it simple for different wallet implementation to have the same idea what an account is and also take care about future new address formats.

My main fear was, if we include different address types into one logical account that many wallet will implement a certain sub-set and it will mostly work, but if you move your masterseed (or xPriv) from one wallet which implements (a,b,c) into a wallet wich implements (b,c,d), then you will miss your "a"-UTXOs, but might not notice it.

Im not ultimately happy about it and also not sure what is more important, to be able to move seeds/xPrivs accross wallets and/or to easily migrate to new address formats, but I think the scenario which might lead to monetary loss weights more...

i.e. im rooting for keeping accounts seperated according to their address-type and maybe offer the user a migration assistant that helps you to move your funds to a new account by sending them over.

[keepkeyjon]

@Giszmo another option, which should work on existing KeepKey firmware, would be to use OutputAddressType_TRANSFER on those change outputs. Less ideal than treating them as change, but you'll at least get the easily grokkable "Transfer 0.0034 TEST to Testnet account #0".

[prusnak]

Let's face it: Mycelium came late to the Segwit party. If you wanted to shape the future of Segwit-enabled HD accounts, there was a discussion taking place 12-18 months ago, but you were too busy implementing crappy tokens into your wallet back then. You are free to implement whatever strategy you desire, but we won't be changing behavior of Trezor wallet now. Funnily enough, the idea for separated accounts came from Daniel working in Mycelium back then.

[sergeylappo]

@keepkeyjon, why do you want to set such a limitation?

On an equal or greater account type BIP44 <= BIP49 <= BIP89

My main concern is that BIP84 is not so widely used and might be not so good in terms of privacy. IMO it might be better to allow wallet to mask change to at least BIP49.
P.S. thank you for the reference.

OutputAddressType_TRANSFER

We would definitely use it, at least for initial release.

[keepkeyjon]

@keepkeyjon, why do you want to set such a limitation?

On an equal or greater account type BIP44 <= BIP49 <= BIP84

I'm inclined to slightly discourage the downgrade-via-change path, though I'm open to persuasion either way if you think it's a valuable use case.

Edit: correction and clarification: I mean that if the vin's have BIP49 paths, then a BIP44 path output would not be considered as a change output. Likewise if all the vin's have BIP84 paths, then a BIP49 or BIP44 path output would not be considered as change.

[Giszmo]

@keepkeyjon the change having to go to a higher or equal standard than what? If I have UTXOs in all 3 types of addresses, would I be allowed to send change to legacy/BIP44 when sending to legacy according to your idea? I don't understand this limitation as it won't lead to coins accumulate in higher types as long as I can get paid on the external chain using lower types. The privacy benefit depends on being able to pick the change type based on the recipient type, not the sender type.

[keepkeyjon]

Ohh, I see what you mean now. Yeah, in light of that, that proposed limitation does more harm than good.