Seed Phrases, Derivation Paths, Private Keys, Signatures, & Accounts. BIP32, BIP39 & BIP44

Transcript

hello and welcome everyone my name is Peter Robinson and this is the ethereum Engineering Group Meetup today I'm going to talk about seed phrases and how we go from them to private Keys signatures EC recover the whole lot um this is a talk that I should have probably done years and years and years ago and in fact first started looking at back in 2017 so I'm going to share my screen and um yep and you should now be able to see my slides do we have a thumbs up from someone yep can see them brilliant okay all right um so

um some you have a hardware wallet you know and you've got the pin number that you bang in and you're thinking you know like is that the end you know have I arrived have I finally got everything done with crypto and um I I've had a Hardware security key um and like a also a USB stick like an encrypted USB stick thing years and years ago and it worked really well until the day that it suddenly stopped working and then it was a piece of plastic and I imagine these Ledges are going to be similar and that at the end of the day you're going to have some huge long um pass phrase and um I don't know about you but I know I

could get another um Ledger and I can you know bang in these um words but um I always like to have a backup way so a few months ago actually or several months ago now I then started looking at well how do I um how do I go from a past phrase to actually a private key because once we've got a private key I'm all good and you can there are online methods of doing it but I don't know about you but the idea of putting up my pass phrase that's got real money behind it into some online tool seems like a stupid idea because I can you know surely people must have automatic draining tools to quickly generate all

the keys and steal all your money so um I ended up creating my own tool to um deal with this but um so let let's talk about the overall process and so back in 2009 so Bitcoin white papers come out in late late 2008 and then the actual code gets released chains launched in 2009 and at this point you've got a you you're signing transactions with a private key and you're verifying them with a public key and um you're using the lipt curve cryptography with a curve set P 256 A1 and the idea is you've got in alytic

curve cryptography you have a base point and that's the point from which you can generate all the other points on the curve and the number of points you can generate is n and that's the order of the curve and so and once you go say from one point to another Point you'll actually wrap around so it's almost like modulo um numbers as far as you will wrap around so if you had the N minus one um number or point on the curve and you added three you'd have then the second point on the curve um and so the the private key is a is a large number which is less than n and the public key is the base Point um Scala multiplied by

the private key and so that ends up the public key ends up being a point on the curve and so the private key ends up being something like that so a big long number and if you've just got one it's not so bad but if you got a whole host of keys then it starts to become really problematic trying to store them and you know wouldn't it be great if there was a way of generating them all from one single number and so um Bitcoin had um or developed the Bitcoin Improvement proposal idea it it's a bit like rfc's if you're used to the ietf or um the EIP process in ethereum comes from the bip

process it was inspired by and so the idea is that you're going to document um the information and in a technical way so that other people can reproduce and create the feature you also have to explain why you're doing the feature so in 2012 bip32 was was created which was for hierarchical deterministic wallets so hierarchical means that you've got a hierarchy of keys deterministic means Based On A Single Seed you end up with a lot of um keys and they're always the same and so saying it um in you know the concept in one using a Single Seed

generate a tree of keys and generate them deterministically so with the same seed you end up with the same keys and the person who came up with this idea and wrote up the bip was Peter wer and that's a photo of him there ripped off um LinkedIn and so yeah so the idea is you have a master key uh or M entropy which um is your seed which generates um the master key and from there you're able to generate a whole host of keys and so you can have multiple accounts you know being generated from this single key and um you have these numbers M followed by

the slashes and numbers that's what's called a derivation path and if you're starting with lowercase M that means that it's a derivation path of private key whereas if it's capital M it's a derivation path of public keys and so the um set of keys can you know can be used for different things and they end up in different hierarchies and um you know you might want to have a new key pair for every transaction that was an idea from early on in Bitcoin where you'd have a different public key so that maybe to have a level of anonymity um when someone maybe sends you

money then it's harder for people to tie it all to One account um and so you then want to be able to drive a whole stack of keys from one single um set of keys and so in this diagram the leaf nodes of the actual keys and these internal nodes they're um P points from which you can generate a whole collection of keys and um so you can have extended private Keys uh can be used to generate all all of the so if you've got an extended private key here you can use that to generate all these Keys below it um and if you've got ex an extended public key then assuming that it's the right sort so

what's called a non-h hardened public key then you can generate all the public Keys as well which is pretty amazing there was also this idea back at the start that you'd have internal and external key Pairs and external would be used for new addresses for people sending in money and doing stuff and then these internal would be not for communication but like for um configuration stuff and I don't think this concept has actually flown much um so the idea for generating the master key the master private key was to um use the well have a whole hip of entropy go in so somewhere between 128 and 256 bits

and then you um use hmax sh 256 with the key Bitcoin seed and then the data is the seed and from there you generate a number I and then I gets split into um two parts so I the output of sh 2512 or sh yeah hmax sh 512 5112 is that you'll end up with a 512 bit which is a 64 byte key and the um so you've got the left and right components of that which are just 32 bytes long and so the ilil is the master secret whereas IR is what's called a chain code so that's not

to do with blockchains that's to do with the chains of keys and so hmac is a message authentication code scheme using hashes and so you can think of it like hash is like a fingerprint of the data that it's hashing whereas a hmac or a Mac algorithm you've got a symmetric key and the data combined to have a fingerprint that you can only verify if you have the key so if you don't have the key then you can't verify the hmac um but the other thing it does is it prevents length extension attack so you might know that in Bitcoin there's the double hashing where you use um sh 256 and

ripened 160 as a way of trying to get around length extension attack so all of this was fixed in ethereum by using kak 256 which is sort of the same as Sha 3 so in the diagram you see the CKD which is child key derivation function and so the idea is if you've got a um parent private parent key you can generate a private child key um and the child key can be either hardened or normal and if it's normal it's really other also known as non-h hardened and so if it's a nonh hardened private key then you can generate a public key from

that and in that circumstance you can go from one public key to a different public key so you can generate a whole series of child public Keys which is um you know very useful if you want to be able to hand out here's the child or rather here's the parent public key and from here you can generate a whole of um child private Keys child public key should I say which could use say to send money to um yeah and so one of the weaknesses um which isn't immediately obvious so this is text from the actual bip standard that was included after it was published there were multiple iterations of the standard and one of

the um nonobvious issues with this is that if you've got one of these parent extended public keys and you've got a non-hardened private key which is associated with a child private key then you might be then you could derive the private key associated with this parent public key so you know that's a pretty big issue so we're going to work through what does that mean and um is it a problem generally and how do how have people gotten around that problem so um so let's think so for to go from a private key to a public key whether it's

hardened or not just normal elliptic curve cryptography you've got the base Point time K is the point which is the public key um and um yeah so um to derive a private key um private parent key or private child private child key from a private parent key um you use this algorithm here so with the numbers so if you looked here you um have indexes um but the indexes if um the number defines whether it is a um hardened key or a non-h hardened key and

if it's above essentially if the top bit is one then it's a hardened key so if it's a hard and child key you do H Max sh 256 and you use as the key the parents um chain ID chain code and then you um use the K of the parent um and the index and um zero so you essentially append these numbers and then you bang that into sh hmx sh 256 if on the other hand um your just using um a normal so non-h hardened then it comes down to you've got the um chain

code of the parent and the K the public key so the um of the parent um and um combined with I the index and then you split off your output again just like you did for the master key where the key so the private key is um the left part um plus the um K the parent K parent um which is the private key of the parent mod in and then the chain code of CI is the IR part so the right part and so you're thinking here we you've got the

private care of the parent and the public care of the parent are being used to generate the private key of the child so for public key to public key so this is own if it if the index indicates a Harden key then it fails because you can't do that but if it's just a child then the idea is that we go in with the um the chain code of the parent which we've got because it's an extended key and the public key of the parent and then we use that as I and then we can um then go in split it up as per normal and and then we um do the same thing where

we generate the key the public key of the um child is the public here the parent plus I point um and then the chain code is the same so if we flip back so we can see we've got the private key going in um whereas and um here you're pointing essentially the public keys in so and how you can think about this and I'm I'm sort of taking a bit of artistic license but so the private keys don't forget are just integers so you've got the parent private key mod n um so you know it's there and then you've got

um the point on the curve rather actually that's wrong there that shouldn't be Point L that should just be plain I sorry about that so you've got plain iil there and so if you add those together mod n then you're going to come back to KI which is the private key and how you can think of it is with these elliptic curves you're going to have capital K is the um parent public key and then you're going to have point I at a point on the curve and when you add these two points they essentially do a modular arithmetic to come up to a point on the curve and so you've got the two things happening in essentially modular

arithmetic but in different projections um of different spaces and so what that means is that they stay in sync um so that so essentially you can then say if you knew ilil you could subtract it from Ki to get K parent and then similarly if you knew Ki the private key you could subtract you could subtract IL if you could derive it and get K parent so it's all a matter of can you work workout iil and so we've said that if you've got the extended public key of the parent um then you can go in generate I and you

will be able to generate IL so it is a problem so I've drawn these um elliptic curves like this as if they're real number curves but don't forget they're um not real numbers they're using modular arithmetic and they're just integers so you end up with um curves that actually look like there so their points but notice there is a quite a degree of s symmetry in the curve so that's something to keep in mind so let's go over this again so if you have the parent extended public key so say the the parent the parent of the parent one of the parents way back and it's a public key and you have the non-h

hardened private key associated with one of the children of that or great grandchildren of that then um you can then go backwards to the private key of that extended public key parent um assuming it's non hardened and um so hence you've got to really um be careful where you're using these non-h Harden keys and so typically you only use them at the leaf level so um then we've got B bip39 which is um which was created in 2013 and so it's the seed phrase in

pneumonic code for generating deterministic seeds and um there was a quite a group of people who work together on this technology and um you know so the idea of this Improvement bip was to as I said come up with easy to remember words for generating determin wallets and so there are two parts to the standard so one is generating the pneumonic and the other one is converting it into a binary seed and so there are actually Lang um sets of words in a whole range of languages um however the authors pointed out at the time that you know though you

could have it in a whole range of languages you really should just use English because um the you know majority of the hardware wallets only supported English so whether that's changed or not in the last decade I'm not sure but um so it's worth noting that there is and they actually had a whole heap of information if you look at that BP 039 word list. MD they got a lot of information about what how you might want to go about thinking about word lists and how you should be careful when you're creating a word list for a different language and the types of things you want to watch out for so in any of the word lists there are 200 24 48 possible words and so log 2 uh log base 2 of 2048 is 11 so if you

had 12 words and they've each got 11 bits per word then that gives you 132 bits so that actually then is used as 128 bits of entropy and four bits of check sum so the check sum is a truncated hash um so I think it's sh 256 so the idea is that that gives you four bits to try and check whether you know you've got all of the words are correct and maybe you've um mped you know one of the words in It's thinking you've typed in another word so 20 128 bits of security assuming um classical um Computing Crypt analysis should probably

be okay until the 240s um and if you've got a 24-word um seed phrase then that's actually 256 bits Plus 8 Bits of check sum and it's going to be long good for longer than the 240s which is even now quite a way off um yeah and so um the thing of course that you've got to think about is that um quantum computers might end up being a thing and might be a thing that's might powerful enough to actually um Implement Grover's algorithm maybe at some point and um at that point um if you've got um elliptic Curves in your um system um

actually the elliptic curves are broken by the other algorithm shn Shaw's algorithm but um Grover's algorithm affects um hash algorithms and essentially reduces their security strength by half so hence um going from 256 bits down to 128 bits of security strength uh would still put your system in a good place but if you're using using ECC based on the um seed then you still got problems anyway so um all right so pneumonics and Seed phrases so um to create a seed from the pneumonic you use pbkdf2 with hmax 2 5112 so pbkdf2 is essentially a password

hardening algorithm where you do lots and lots of um hming to um to try and turn your increase the security strength of your password and mix it up um so um the password has to be um in utf8 nfkd format and the salt is the pneumonic plus the P phrase so essentially you're using that past phrase twice um iteration counts actually really low so it's just 248 times so um yeah it's not you know these days you typically see iteration counts if you're doing um

password hardening you know into the hundreds of thousands or Millions for pbkdf2 but this is still okay because the idea is that this seed is random and you've you know it's not subject to guessing then um so and you're deriving 512 bits so um the um what nfkd stands for if you're interested in is Unicode normalization form and then KD is the type of form so bit 39 takes you from seed phrases to a seed value and then in 2014 there was bip 43

so it added a purpose field and so these guys here um they looked at it and they said look the problem with um bip 32 is that there are too many possibilities too many degrees of freedom and it means that nothing's interoperable and this is not a good place to be so we propose that there's a purpose field and um not only that um we're going to add in some so the fact that if you have this Dash here then that's signaling that it's a hardened um derivation rather than normal and so then in conjunction with bip 43 they release bip 44 at exactly

the same time and so what this does is it defines a logical hierarchy to go from that deterministic wallet um algorithm um based on bit 32 to um using that purpose scheme divined in bip 43 and um so this is could be deemed an application of bip 43 and so you end up with this um detailed um set of um um this detailed derivation path and so um your purpose is always 44 which I assume comes from bit 44

and then the coin type um there are hundreds probably thousands of coins defined e is 3C um which is decimal 60 so you've probably seen m44 60 as um in a derivation path and that essentially means ethereum or an evm based chain so though Etc has got their own um their their own value here and I think some other chains that are evm compatible have got their own value it's turned out to actually be not a good idea and because it means that you end up um not being um you know

having different keys that are incompatible even though you might want to use the same key for different chains and so um it's actually not been a good thing so yeah so for e and other evm chains generally you're going to go M 4460 0 and0 and0 and then the index um where notice the dashes indicate that those are um hardened keys so what about the public Keys addresses and signatures so um in ethereum just like in Bitcoin um the public key is a point on the curve and

so you have something big and long like that and the address is the truncated hash of the public key and so the signature um so we're using ecdsa with kick at 256 and so um you imagine e is the hash of the message and then you generate a random number which we can call K and then you calculate a point called r on the curve which is K this this random value times the base point and then you take the x intercept index of R so RX and you calculate um lowercase R and which is now going to be

an integer and so the signature proof so that's the r that you hear about in the signature and then the signature proof s is the inverse um of k um or and then brackets e are times K da Where Da is the private key mod n and um you've also because you can this will result in four possible points you have a recovery parameter which helps resolve that um and so um you can recover the address though from the signature so remember we've got this RS andv and we've also got e which

was the hash of the message and so um you can go all right so you use V to resolve the point R from R and then you calculate the candidate public key um you know with this so you go you know lowercase R to the invert and then s * R so that's going to be a scalar maltt minus E * G so that's going to end up giving you a point and um then you then that's your candidate address and then you um work out the you know do the same thing and then you can compare that address with the address that you're expecting to verify the signature and so

that's how you do that so putting all of that together you've got a seed phrase you use bip 39 to create the bip 39 seed you then use the bip 39 seed and a derivation path with bip 32 algorithm to generate a private key and then using the private key Scala Mt times the base Point gives you the public key and then the private key um combined with the kak of the message using the signature algorithm ecdsa uh will give you srnv and then with srnv and the hash of

the message you can use the EC recover message uh rather recover algorithm to generate the address and you can compare the address with the one you're expecting and if it's the same then you can say you verified the message so wow as I said I got a bit worried when I um picked up my or had my ledger delivered in the mail and thought I should be able to regenerate these keys but I don't want to upload my passphrase to the cloud so I wrote some Goan code um which leveraged a library which already exists and so if you clone the repo there um and then you um create an environment variable called words then

you can just go go run and then that will bang out the seed phrase the bip seed the address and the private key and if you uncomment a line of code you can also get the public key as well and then of course um I did a bit bit more work with Foundry and went oh I've always my time generating that code here's some code in um or a command line in Foundry which I can use to generate Keys um so this one here you just call cast wallet derive key and um or derive private key and give it the index and um you generate the private key so which is pretty cool as well it does assume an

ethereum um derivation path so if you wanted to use a non- ethereum derivation path you'd have to use my program otherwise you could use cast so in summary um putting all this together has been a bit enlightening for myself um I thought I knew a fair bit about it and I actually planned to really um get into this back in 2017 uh when I first encountered it all um and really tried to work out you know what these seed phrases were and how it what the path was to EC recovery and um anyway didn't do it then but I've done it now and um there are some t-shirts on sale at the store there are whole stack

of talks coming up next year including a talk that's not yet written there because it's in draft and um if you're watching this today it'll be on YouTube If you're looking at this on YouTube um turn up to the Meetup and you can ask tricky questions for the rust and solidity code there will be um example code and you can join slack as well so I have done a lot of talking um are there any [Music] questions hey Peter uh thank you great talk uh I did put a question in the chat ah and it's it's not particularly

on this talk but it's related and while I've got a couple of cryptographers online I thought I would ask it wondered about it for years okay I'm opening up chat um okay naive question for the cryptographers in the house when you choose a given elliptic curve is the exact curve known and by whom that is are you using a family of Curves in need to choose a specific one or are you entering the process with a specific curve so depend on the situation typically you to do cryptography and to do um litic curve cryptography you need to agree on the parameters of the curve which is the um

the um so a named curve typically but you don't you need to use a named curve you can generate curv parameters on the Fly um but generating curve parameters and then being sure that they're not a weak curve takes hours days weeks months or years and um even if you've used all sorts of processes to work out that it's not a weak curve someone might find a weakness in it anyway so um way back when certicom um gener or came up with a whole set of curved parameters and I think the thing is that they had some people on S condent or something anyway from the NSA who were helping them out when they were creting these curves and

um thing is that there are more cryptographers in the world anywhere in the world working at the sa than anywhere else so having some and they're really smart people so having some of them on board when you're trying to generate litic curve cryptography parameters you know like 25 30 years ago you know way back when probably a really good idea so some people have got all scared about those curves saying ah the NSA have put a back door in and stuff like that so my personal thought is that that seems unlikely so for ecd RBG you could view it as if um the NSA had a private key and there was a public key and the public key is essentially in the cdbg algorithm for generating random

numbers so only the NSA was able to you know like decode stuff essentially but for this this is a very different thing it's sort of like a um if if somehow or other someone was to be able to get that private key or you know like get it um or if there was some weakness in in that curve then would mean everything was vulnerable to attack um so it's more going to you know because it's going to be a a weakness in the underlying algorithm and so hence you'd be worried that the Chinese you know Chinese and Russians are going to be able to maybe break it at some point so hence I think they would have been trying to make that as strong as possible um also the algorithms or the

KE the um curves have been designed the prime curves so the um have been designed so that they've got lots of Z and that um means that they're computationally very efficient so I think trying to have something where you can do a back door into and make it hyper computationally efficient I reckon seems like a stretch um so the main curve that people use p256 is not the same as this one this one's um a um a different curve but it's from the same set of curves that um certicom came up with all those years ago there are other curves that people have come up with but um you you got to be really careful because someone comes up

with with some new curve type publishes it in a paper and you really want to wait till someone puts it in a standard then people try and busily create a PhD by finding a bug in the curve and so that could take a decade so you really want to use curves that have stood the test of time yeah thanks for that pet that's very helpful yeah um um I have few I'm just going to go back one step and then coming back from there I have a screen I have a picture in my in my my other screen I'm just referring to that uh so we have this pneumonic word creation that's what you do first and you created from the word you created this seat

phrase that seat phrase is used to create public key first yeah so the SE sh can I share this one so it may make more sense uh sure you share your slide and let's have a look uh yeah sorry oh you might not be able to share I'll have to allow you you're you should be now allowed to share have a go now excuse me so hope you can see the screen right so this is the part where you create the pneumonic word right and then you come come back here the seat phrase you

create the seat phrase and then here is where you have this seat phrase coming in and you create uh the private master key and there is two ways you can create one is using this private key private key you can create on the child children's this one is using the public hey to create the chart so this second one is the hardened one you're talking about right uh no the one where it's all just um using public Keys is the UNH hardened or normal whereas the one at the top is the hardened so when you're Genera private key yeah yeah when you're

using the private key is hardened and um yeah and so though in the original um standard it showed doing all of this the whole way from the master key as you could see um since about 2013 or 14 people have only been using this to derive hardened Keys up until um almost the leaf nodes simply because it's not secure um yeah yeah and the other part you talked about is is where this part here that using the derive derive function for each each blockchain will have its own address format through the derive function from here correct um yeah so

I think um so the private keys are all going to be the same so if they're following the standard they've all going to derive the private keys in the same way um yeah then from the from that going to the address is where the deriv function is been used correct Oh you mean how do you generate the the address from the public key um yeah that's going to depend so Bitcoin doesn't um drive an I mean actually I guess it does have addresses but it uses the public this is I think this is a Bitcoin one so it actually double hash and then yeah yeah that's a Bitcoin one and this is B 44 you talked about that derive function uses the you

know that's the correct right uh yeah for Bitcoin I I believe the chain is zero rather than 60 um yeah yeah yeah and then and but as you can see you've got um three levels of hardened keys with only the um very down to the leaf or the one off the leaf are non hardened um but normally I don't think I've seen any usage where that um second off the end isn't anything but zero anyway so there's only one um set of keys coming off there right so so that means so the wallet actually holds all these things and wallet can create

different addresses based on what network you are uh you wanted to deal with so one wallet can create multiple addresses yeah same thing enough right yeah yeah yeah you can generate almost an infinite number of addresses addresses so so if I say for example if I what what is actually included in the transaction so say for example sending a transaction so will my address is there or my wallet address is there or my public is there actually what is in what is included in the transaction yeah so in ethereum you've just got the RS andv

value and then you use then the um system uses essentially EC recover to verify that the um TX origin address matches that and so before um you even get included in the transaction pool it's going to be checking that this the signature is valid and the validity check is I mean one part of the validity check is to make sure that um the RS andv are correct so that means you are coming back and then pretty much verifying the public key yes yeah you're verifying the signature and how you verify the

signature is you derive the public key and hence the address from the RSV value and then you use that to check that TX origin equals that address and if it does then it means that the the private key associated with the the TX Origin account signed the message so signed the transaction so if we have multiple transactions that are all dealing with different addresses and if we can get all of them and then derve back the public key they all should be the same right um so if you've got a set of addresses so sorry can you take me if you've got a if I'm sending one

transaction to eum transferring say um W to something else or one to usdc so these are different transactions so if I take all this transaction and take the take back the public key you know anyway you need to verify the public key so if I take back the public key all of these public key should be same or they are the child publicy they showing oh yeah yeah yeah yeah yeah so could you derive all the child public Keys it depends on how it's been generated but assuming it's been generated as a normal public key yes you could you could generate all of the child public keys and they all should be the same they if they are

coming from one wallet they will be one same yeah but the issue you're going to have is you're going to yeah so you're going to need though you're going to be able to generate child um keys but you're assuming you've got the parent um yeah so you're going to need to have that parent um non-h hardened key to generate the child so if you let me if you unshare I'll share my slides again and I'll show you what I mean um okay so if we look at

the bit 32 algorithm here for the public key so this is public key to Public Child key so you're saying so we're let's assume that we've got um 44 603 and um so your so could we generate from public key 003 002 or 004 is the question really you've got and so if you look at this algorithm you need to have the um the the the um uh extended public key the

extended public key includes the chain code which you're not going to have and it also includes the public key of the parent so you you need so unless you've got that public key of the parent you're not going to be able to generate the child public key and the chain code is one thing which is missing as chain code never be exposed at right yeah yeah exactly so yeah so you need to publish this this chain code stuff and I don't think anyone's going to do that if that's the case right if so how do say say if I if I want to drop some money to your your wallet right yeah how can I do that because I do not have any no I have only

your public address I I do not have anything else so literally I need to so say for example I need to drop you w your wallet never created an address for that one and I actually create an address for you and then drop it in the wallet right so how how could I create that yeah so if you wanted to have Auto generating different address addes over the time um you would I would need to publish um somewhere my um or have a web service where you could get a public key for me um but uh public key public key is not enough to create a address we need chain code right yeah yeah I give you my chain code so the web service

would generate it yes so it' have to have the parent public key and the parent chain code but the thought would be though that I could have though that um chain code parent chain code and parent public key and they're both sort of public value so you know you're not assuming that you never get a private key it doesn't matter you can't like steal any of my money it's only if you get one of those private Keys um so but if you're like if you're an ethereum land though what I would do is I would give you my address and say you send the rap teeth to this address yeah yeah yeah but the thing is

that look if I send a transaction to you saying that look this is my sending address this is my receiving address both the things are there right but I didn't want it to include that in that transaction but you wanted to create it and then you know this is to somewhere hide where I am which is coming from the same address so this is some could technique would they you know people use is where I send you to service right and the service the incoming transaction doesn't have the recipients detail in there the service is actually creating that if service is creating a bunch of them we would not know which one is going where so they would automatically create address and

then they will give it to another wallet or somewhere else or this even even though this wallet is a different address they would not we would not be able to find out this connection so this is where I'm trying to trace back it where how can we trace it back to see whether this is coming from the same address ah okay yeah yeah trying to trying to connect different public cares to see if they're generated from the same seed phrase uh yeah yeah that's an interesting problem which goes back into your this this is called address clustering where we find out about many transaction or dealings yeah that be of the same uh same you know same uh coming of same because this days this days you

know rather than creating manually these all automated with Bots and then they create many addresses and they shift things around and if we able to Cluster them together we could see this is all from One Source yeah okay so what I how how you um H so how you could do this um you know is assuming you're um got a lot of money you know like um a enough to buy the odd nuclear power plant and that sort of thing is um so if you have a um if if you got a quantum computer that

can do Rover's algorithm so doing the search um so it's just gra algorithm is like a database lookup and it um I I think so if you could do that then what you could do is you could have a set of computers you know like hard diss that have got like two to the 256 I don't know that that's more atoms in than are in the universe though so it makes it very complicated yeah so trying to brute force it essentially but with the aid of a quantum computer but I even then I don't think it's going to work because you end up having more atom you know needing to have more um than the atoms in the universe and

that's just you know not practical yeah yeah I I can see where you're coming from actually we have a small search field right say say for example we were talking about peeling before right so we would see a peeling process happening right pealing process is where you know they have a big amount they peeling into small amounts yeah see appeeling process same pattern of addresses going in there you know so we could you know how do we identify this these are these are from the same address or same people if you cluster them together and then identify oh this is one source and coming for know so we our search space is quite small not the whole space but again to

to to check that now it maybe going into deeper into that to check it yeah I think what you could do is so if law enforcement um essentially get a seed phrase from someone you know from a criminal then you should be able to at least generate addresses yeah that's easy that's EAS so we potentially you know we have the public key that's clear and then from the public key whatever information can we can get it and then search it that's one step and then the the uh what is called the other one the uh chain Cod the next I think the other thing you could do would be to another thing you could

do is you could use the um you could use the IP address that people are using to connect to the um blockchain you know because they've got to submit the transaction at some point and when you there is no point in talking about because by the time the things are done this information is not there yeah be capture live right no we a lot of people talked about that one if you're capturing live and then we have to attach the IP address to that particular transaction and keep it once the that is gone the IP address information not there yeah so this is all happened right this is what happened we see some

pattern so probably year ago or six months ago or something like that so we are tracing back from that pattern so the IP information is not there at all yeah yeah yeah well that and then at that point you've got to try and talk to essentially um blockchain Gateway companies and get law enforcement to help you and if it's just trying to do data mining then it's not going to be good all right um are there any other thanks very much for diving into that not a problem at all um are there any other questions all right look um thank you everyone for coming along today see you all in the new year and I will aim to

try and get this up onto um YouTube in a sometime in the next 24 hours so yeah all right talk to you all later bye bye bye