Fast-Forwardable Wallet Seeds

[RHavar]

More just a shower thought, rather than something I imagine will ever get implemented. But one of the things I dislike about my bitcoin wallets, is the long history they have accumulated over the years. At a certain point it just becomes a liability, and yet moving to a new wallet is rather annoying (not least because of the large consolidation that would take place).


To generate the ith address, an HD wallet does something along the lines of hash(seed + i)   -- while what I'd like is something along the lines of  `seed = hash(seed)` i times.


This would have the property of being able to fast-forward the seed a certain amount of slots, in order to forget the previous history. For instance in one of my wallets, I could safely fast foward the seed 130 slots without losing anything of value (and in fact, only losing information I'd rather lose).

[1714019215]

1714019215

[1714019215]

1714019215

[1714019215]

1714019215

[pereira4]

I agree that having your entire transaction history in there isn't smart in some cases, but what you want is too risky IMO... In order to avoid output consolidation in a tx thus decreasing privacy and in order to avoid fees due manual tx's separately with Coin Control in separate addresses to keep privacy... can't you just export the private keys you want and export them into a new wallet without any tx's involved? Or when you import the private key in a new wallet it exports the entire history related to that address too? I don't think so, I reckon doing this once to dump forks, but it was annoying af doing it one by one.. what can you do?

Maybe we could have a command that goes like "drumpprivkey from X to Y" so you get them in a batch and then import this also in a batch to save time?

[Dabs]

Moving to a new wallet once a year? Something like that? Or however long it takes to accumulate too many transactions that it bothers you?

What wallet are you talking about, Bitcoin Core? Yeah, I would just create a new wallet after some time. Works similarly with Electrum.

I understand because you could have hundreds or thousands of transactions, like if you deal with game sites (probably) or even exchanges and you use their api to do automatic trades / withdrawals / deposits according to some programming of your own.

A clean wallet is a brand new one. Moving count of the same seed, ... could get messy. In theory it should work, but until they actually implement some sort of variable you can specify ... plus you have to remember each time you "move" to a different set of addresses or transactions.

Once in awhile, I'd import all my old wallets into one big giant wallet and let it rescan, see if anything appears. If it's dust, I just ignore it, probably sent by some dust spammer. But to date, I have not seen any incoming transactions for several years unless I had something to do with it.

Might be different in your case since you operate a bunch of different sites.

[RHavar]

If you simply don't want to see long transaction history on your wallet (without change to new wallet and make 1 big transaction), then simply generate address from i^th would solve the problem.

Just to be clear, the point isn't that I want to "not show" my old transactions, it's that I no longer want to have access to it. Willful ignorance, if you may. For example  I can legally be compelled to provide information, yet don't have any obligations to keep such records.  So by fast-forwarding my seeds once I'm confident I don't need the old information, I can lower my potential liability.

[Coding Enthusiast]

To generate the ith address, an HD wallet does something along the lines of hash(seed + i)   -- while what I'd like is something along the lines of  `seed = hash(seed)` i times.

This would make derivation exponentially hard. Right now if you want to get your i^th key you perform 1 hash: HMACSHA512(data || i) so if you want 100^th key you still do 1 hash. If you change that, in order to get the 100^th key you have to do 100 hashes.

This would have the property of being able to fast-forward the seed a certain amount of slots, in order to forget the previous history. For instance in one of my wallets, I could safely fast foward the seed 130 slots without losing anything of value (and in fact, only losing information I'd rather lose).

I suppose there are two easy ways of implementing this:
1. Giving the user the option to set an integer as the "starting point" of his key derivation and start getting keys from that int and discard everything (keys and tx history) before that. You could always get them back by lowering that int and you can always discard more by increasing it.

2. Going to another "branch". That could also help with "hiding the history" that you are looking for. For instance the starting point of the wallet could be m/1'/0'/0' and after reaching 100 keys the user switches to another path: m/1'/0'/1' so the first 100 keys would be at m/1'/0'/0'/0, m/1'/0'/0'/1,... branch and the second 100 would be at m/1'/0'/1'/0, m/1'/0'/1'/1, ... branch. This way you still use the same seed and start from 0 each time but have a hidden history that could only be accessed if the correct derivation path was given, the range of which is from 0 to 2³²-1 so hiding the "branches" is easy too.

[gmaxwell]

To generate the ith address, an HD wallet does something along the lines of hash(seed + i)   -- while what I'd like is something along the lines of  `seed = hash(seed)` i times.

Doesn't have the property that an old lost backup that you forgot existed can't be used to steal your money... while the simpler expedient of a wallet that can add an additional seeds and, eventually, forget old ones has both the property you were looking for and this leakage resistance property too.

Separately, the chained computation has a somewhat unfortunate property that it's fragile.  E.g. if a cosmic ray rains on your day when you compute step 37 then all further steps will be irreparably corrupted.    Armory's wallet scheme worked like that while BIP32 intentionally did not, and the chained behavior has lead to at least one major funds loss incident.

Perhaps this last point isn't a big deal because you can and you should use really aggressive double checking of all computation related to generating keys ... but the point that the simpler seed-rotation mechanism gets you both forward and backward security (and bonus, the backward security is better, since if you leave an old backup around it doesn't get all the future keys that you'd already forgotten), I think is perhaps enough of a reason to not use the more complicated thing.

[LoyceV]

Just to be clear, the point isn't that I want to "not show" my old transactions, it's that I no longer want to have access to it.

What if someone accidentally sends funds to an old address? Allow me to quote satoshi:

You should never delete a wallet.

[Dabs]

For example  I can legally be compelled to provide information, yet don't have any obligations to keep such records.  So by fast-forwarding my seeds once I'm confident I don't need the old information, I can lower my potential liability.

They know you used a fast forwarded seed to say 100 and may compel you to provide the full seed, and just go back to number 1, so it won't make a difference that way since you technically can still access the information.

If you do your existing method to use a brand new wallet and transfer there, you could say you deleted the old wallet and that old wallet is no longer recoverable.

"I dropped my gold bars while on a boat over the marianna's trench."

[RHavar]

This would make derivation exponentially hard. Right now if you want to get your i^th key you perform 1 hash: HMACSHA512(data || i) so if you want 100^th key you still do 1 hash. If you change that, in order to get the 100^th key you have to do 100 hashes.

It's actually linear, not exponential. To get N addresses, it takes O(MAX(index)) time. But I don't think performance is a realistic concern, as indexes are generally just a counter you bump not some large randomly generated value.

Doesn't have the property that an old lost backup that you forgot existed can't be used to steal your money... while the simpler expedient of a wallet that can add an additional seeds and, eventually, forget old ones has both the property you were looking for and this leakage resistance property too.

That's a reasonable point.

but the point that the simpler seed-rotation mechanism gets you both forward and backward security (and bonus, the backward security is better, since if you leave an old backup around it doesn't get all the future keys that you'd already forgotten), I think is perhaps enough of a reason to not use the more complicated thing.

While seed-rotation is conceptually simpler, in practice it's a pain in the ass. Unless of course you do a big consolidation from your old wallet to your new wallet, which is unideal from multiple perspectives.

I guess ideally you'd have some sort of first-class wallet support for wallet rotation, where it would temporarily load both wallet and preferentially spend from the old wallet and put the change in the new wallet, and then eventually you can unload the old wallet and delete it if you will.

[RHavar]

They know you used a fast forwarded seed to say 100 and may compel you to provide the full seed, and just go back to number 1, so it won't make a difference that way since you technically can still access the information.

Given a seed, you wouldn't be able to tell how fast-forwarded it was. Besides, the request boils down to finding a preimage of a cryptographic hash (N times), so I would tell them they can check back with me in a few trillion years while I'm spending the time required to calculate it. 

[RHavar]

No offense, but IMO your idea is half-hearted solution.

Yeah. It's definitely pretty weak, but I guess my point is that if wallets used a "Fast-Fowardable Wallet Seed", they would have pretty much no downside for using them normally (maybe slightly slower deriv, or slight extra risk from gmaxwell's cosmic rays) but it gives you one (possibly catastrophically dangerous) "fast-forward" operation which can you use, if you want.

Or looked at another way: if Fast-Fowardable Wallet Seed were the norm, would anyone be wanting to use the current deriv scheme? 

Like I said in my OP, I don't think anyone will implement it, nor do I think it's worth diverging from norms for. But it's just an idea I wanted to write down, and wish my wallet supported it  

[Dabs]

They know you used a fast forwarded seed to say 100 and may compel you to provide the full seed, and just go back to number 1, so it won't make a difference that way since you technically can still access the information.

Given a seed, you wouldn't be able to tell how fast-forwarded it was. Besides, the request boils down to finding a preimage of a cryptographic hash (N times), so I would tell them they can check back with me in a few trillion years while I'm spending the time required to calculate it. 

They don't need to be able to tell how fast-forwarded it was, if, it has some sort of standardized protocol it follows or some BIP. They just will try to fast forward a few hundred or a few thousand, or whatever is the standard and look from there.

If it were some tax agency or compliance company or other audit, they will spend the several hours to look how fast forwarded the next usable wallet address is.

A brand new seed or brand new wallet is ... well ... different.

[RHavar]

They don't need to be able to tell how fast-forwarded it was, if, it has some sort of standardized protocol it follows or some BIP. They just will try to fast forward a few hundred or a few thousand, or whatever is the standard and look from there.

If it were some tax agency or compliance company or other audit, they will spend the several hours to look how fast forwarded the next usable wallet address is.

A brand new seed or brand new wallet is ... well ... different.

The failure is probably mine for not explaining well, but you are misunderstanding the concept. Fast-forwarding a seed is a destructive operation, it can't be undone even with all the computing power and time in the world.


A simple example:  I sha256'd something to get 0b63083dcbb3881c70a3f2693a07e27ea5e6f5926fef3c2c6517b78a107f3e11. There's no one in the world who's going to be able to figure out what I hashed. And I haven't saved what I used to get it, so there's no way to (successfully) compel me to giving it.

That's how a fast-forwardable wallet seed works. In the fast-forward operation, you replace the seed with a hashed version of the seed. Unless you have saved a copy of the old seed somewhere, that information is permanently lost.  And you would obviously only fast-forward the seed when you are OK with losing this information.

[Abdussamad]

if you simply want to create multiple wallets from the same seed then just use a different derivation path. bip44 lets you create separate hd accounts which can function like separate wallets. another option is to simply add a passphrase to your seed. this is also known as a bip39 passphrase, seed extension or 25th "word". different passphrases lead to different wallets. the passphrase need not be a secret. it can be something as simply as 1, 2 etc.

[HCP]

The failure is probably mine for not explaining well, but you are misunderstanding the concept. Fast-forwarding a seed is a destructive operation, it can't be undone even with all the computing power and time in the world.

A simple example:  I sha256'd something to get 0b63083dcbb3881c70a3f2693a07e27ea5e6f5926fef3c2c6517b78a107f3e11. There's no one in the world who's going to be able to figure out what I hashed. And I haven't saved what I used to get it, so there's no way to (successfully) compel me to giving it.

That's how a fast-forwardable wallet seed works. In the fast-forward operation, you replace the seed with a hashed version of the seed. Unless you have saved a copy of the old seed somewhere, that information is permanently lost.  And you would obviously only fast-forward the seed when you are OK with losing this information.

I don't quite understand how this "fast-forwardable seed" system is any different to simply deleting the old wallet and creating a new wallet?

You're just replacing one seed with another (granted in the fast-forwardable system it is a hash of the original seed)... but in both instances, there is no way to recover the old seed from the new seed.

Are you imaging a system where you can go "old seed -> new seed" in a repeatable way?