Bitcoin Forum
October 15, 2019, 07:55:47 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Fast-Forwardable Wallet Seeds  (Read 175 times)
RHavar
Legendary
*
Offline Offline

Activity: 1806
Merit: 1454



View Profile
October 04, 2019, 04:45:31 PM
Last edit: October 05, 2019, 12:28:24 AM by RHavar
Merited by Welsh (4), bones261 (4), LoyceV (2), ETFbitcoin (1)
 #1

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).
1571126147
Hero Member
*
Offline Offline

Posts: 1571126147

View Profile Personal Message (Offline)

Ignore
1571126147
Reply with quote  #2

1571126147
Report to moderator
1571126147
Hero Member
*
Offline Offline

Posts: 1571126147

View Profile Personal Message (Offline)

Ignore
1571126147
Reply with quote  #2

1571126147
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
pereira4
Legendary
*
Offline Offline

Activity: 1554
Merit: 1150


View Profile
October 04, 2019, 06:39:10 PM
 #2

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?
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1792
Merit: 2051

Use SegWit and enjoy lower fees.


View Profile WWW
October 04, 2019, 07:01:00 PM
 #3

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 ith would solve the problem.

From security perspective, the idea of seed = hash(seed) isn't bad, but you're required to backup newly generated seed (or backup firstly generated seed and remember the starting position).

Dabs
Staff
Legendary
*
Offline Offline

Activity: 2478
Merit: 1287


The Concierge of Crypto


View Profile
October 04, 2019, 07:34:06 PM
 #4

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
Legendary
*
Offline Offline

Activity: 1806
Merit: 1454



View Profile
October 05, 2019, 12:25:59 AM
 #5

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 ith 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
Hero Member
*****
Offline Offline

Activity: 690
Merit: 1095


Novice C♯ Coder


View Profile WWW
October 05, 2019, 04:27:32 AM
Merited by Foxpup (4), bones261 (4), LoyceV (2), ETFbitcoin (1)
 #6

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 ith key you perform 1 hash: HMACSHA512(data || i) so if you want 100th key you still do 1 hash. If you change that, in order to get the 100th 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 232-1 so hiding the "branches" is easy too.

Projects List+Suggestion box
Donation link using BIP21
Bech32 Donation link!
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (supporting SegWit) (3.1.0):  Ann - Source Code
SharpPusher (broadcast transactions) (0.10.0): Ann - Source Code

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2842
Merit: 2513



View Profile
October 05, 2019, 04:48:16 AM
Merited by Foxpup (4), bones261 (4), LoyceV (2)
 #7

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
Legendary
*
Offline Offline

Activity: 1638
Merit: 4806


Largest Merit Circle on BPIP!


View Profile WWW
October 05, 2019, 08:20:24 AM
 #8

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
Staff
Legendary
*
Offline Offline

Activity: 2478
Merit: 1287


The Concierge of Crypto


View Profile
October 05, 2019, 05:55:57 PM
 #9

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
Legendary
*
Offline Offline

Activity: 1806
Merit: 1454



View Profile
October 05, 2019, 06:11:32 PM
 #10

This would make derivation exponentially hard. Right now if you want to get your ith key you perform 1 hash: HMACSHA512(data || i) so if you want 100th key you still do 1 hash. If you change that, in order to get the 100th 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.


Quote
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
Legendary
*
Offline Offline

Activity: 1806
Merit: 1454



View Profile
October 05, 2019, 06:14:41 PM
 #11

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. 
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1792
Merit: 2051

Use SegWit and enjoy lower fees.


View Profile WWW
October 05, 2019, 06:32:50 PM
 #12

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.

If you're going that far to limit information you're legally required to give, why don't you use mixer/CoinJoin and configure address on newly generated wallet as the output address?

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

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.

At least for open multiple wallet at same is already possible with Electrum. But you need to specify the change address (from wallet with new seed) manually though, unless you're using sweep feature (which send all Bitcoin  to address on new wallet).

RHavar
Legendary
*
Offline Offline

Activity: 1806
Merit: 1454



View Profile
October 05, 2019, 08:24:32 PM
 #13

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?  Tongue

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  Grin
Dabs
Staff
Legendary
*
Offline Offline

Activity: 2478
Merit: 1287


The Concierge of Crypto


View Profile
October 06, 2019, 01:35:05 AM
 #14

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
Legendary
*
Offline Offline

Activity: 1806
Merit: 1454



View Profile
October 06, 2019, 03:46:58 AM
 #15

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
Legendary
*
Offline Offline

Activity: 2254
Merit: 1200



View Profile WWW
October 06, 2019, 09:15:06 AM
 #16

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.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 1792
Merit: 2051

Use SegWit and enjoy lower fees.


View Profile WWW
October 06, 2019, 06:13:31 PM
 #17

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.

If it's only alternative or giving users more options, then i'd welcome this idea (assuming it's properly implemented and user know pros/cons of each option)

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

I think majority Bitcoiner won't use both (Fast-Fowardable Wallet Seed or multiple derivation scheme) because it's too complicated, too annoying or they simply don't care about privacy.

For people who cares about privacy, they would use more complicated method.

HCP
Legendary
*
Offline Offline

Activity: 1120
Merit: 1837

<insert witty quote here>


View Profile
October 09, 2019, 10:27:35 PM
Merited by Abdussamad (2)
 #18

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? Huh

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? Huh

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!