We will discuss some exciting Handshake applications and protocol improvements that at this time are merely theoretical discussions in developer chats. If you are an investor or developer looking for a project idea, this will be a good time to learn about things that are possible with Handshake but have never been tried. We will explore decentralized subdomains, lightweight resolver designs, and complex transaction scripting that can add serious power to the self-custodial user.
Transcript
(00:01) [Music] [Applause] [Music] kinetic is a blockchain crypto investment firm based in hong kong and puerto rico [Music] founded in 2016 they were the first fund in hong kong and one of the earliest in asia with a portfolio of over companies they were seed investors in such projects as ethereum parity and polka dot solana ftx and of course handshake in name base [Music] founder johan chu was an active investor and supporter of the handshake ecosystem over one hundred thousand domains co-founder of d-web foundation co-founder of handicon and sponsor of
(00:52) the handshake house at miami hack week 2022 [Music] [Applause] so [Music] [Applause] [Music] all right everybody welcome back uh we have a familiar face again matthew zipkin joining us uh he’s going to talk about the future and fantasy of handshake so theoretical ideas that have not been built but can be built or could be built so if you’re a developer and you need ideas for something to build or you want to get involved here you go here’s a bunch of ideas for
(01:55) you but with no further ado i’m going to let matt take it away thanks fist yeah i’m really excited about this talk i think it’s going to be fun and i hope to stir up everybody’s imagination and inspire people maybe developers will literally just take an idea i discuss and build it or an entrepreneur will put something together or i’ll give you some idea of a primitive that you can build something from everybody can get something out of this talk it’s not just for developers i just want to explain some like tools
(02:25) that we have to build on handshake and expand the protocol and then i’m going to discuss some ideas that that i’m aware of um from developers that i speak to every day um yeah so so let’s just jump into it this is the future and fantasy of handshake oh let me share my screen share screen screen one all right you guys can see that just somebody say what up in the chat so i know that you guys can see the slides um this is my usual starting place okay great thanks so um i i hang out in this telegram channel
(02:58) this is not the only uh think tank in handshake i don’t want to act like this is the core team or anything like that i just want you guys to know this is my perspective on the development community and the ideas that i’m going to discuss today come basically from this group of people and maybe hopefully i didn’t miss anybody but the people who are most active in the telegram dev chat this is the crew and if you like any of the ideas or if you have a new idea come and join us in in the dev chat and even
(03:24) if you’re not a developer if you’re a ui person or um or an entrepreneur or a domainer or a translator into some language come on into the dev chat and work with us and help us make some things happen now on the topic of ideas we have something called hips handshake improvement proposals you know we’ve based this off the bips bitcoin improvement proposals which i think in turn was actually based off a python improvement proposal system um and uh my one of my favorite quotes is from peter willa who basically said
(03:56) that the bip system is just to assign numbers to ideas that’s it they don’t have to be good ideas they don’t have to to um change you know we don’t have to actually develop them we don’t have to actually do what the idea says if it’s like a protocol change like a hard fork or something the idea is just to have some kind of reference and and a standard um we’re up to about nine so far and some of these have been discussed this week already this website that you’re looking at is actually sourced from a github repo
(04:24) which is really if you have a handshake improvement proposal to propose um this is you would open a pull request to this repository um and there’s some instructions here on how to do that there’s also this discussions tab um which i wanna i wanna display really quick and and these are like the half-baked ideas or or the the oven you know it’s a they’re not really formal proposals yet but some people have an idea or a question and they can start a discussion here or you know in the telegram chat
(04:53) bring you know flesh out the idea and then when it’s ready open a pull request with a formal document like one of these and um specify your ideas that everybody knows what it is we’ll give it a number and then we can talk about it named at handicon next year okay so let’s talk about some of the ideas um what i’m gonna do is is first the first couple slides i’m gonna talk about like the primitives um ingredients that we have to cook up um these ideas different elements of handshake to get you thinking about like oh
(05:23) maybe i can do a piece of this with a piece of that you know that’s how i want you to think about these ingredients here um these are the handshake covenant system um you’ve probably most people probably recognize most of the words on the screen this is a slide from other talks i’ve given introducing handshake um so i’m not going to spend too much time on it but you know there’s the the auction process on the left and then there’s the transfer system on the on the bottom right and the register update renew so we have
(05:48) these covenants and the covenants restrict the spending of a transaction you basically have to follow these arrows um and so that’s kind of an interesting um burden to put on on transactions on the on the handshake protocol so for example like um if you want a transaction that’s only valid for five days let’s say i’m going to send you money and i’ll send you this transaction and i only want you to be able to to to broadcast that transaction sometime in the next five days well one easy way to
(06:15) do that is to add a bid for some random name it doesn’t matter could be a bit of xero but everybody knows bidding is only allowed for five days right otherwise that transaction is not allowed in the blockchain it’s invalid so that’s the kind of thing i want you guys to think about like you already know how covenants work can you take a comment and do something wrong with it do something weird with it or or or incorporate it into some other system to apply these extra rules um in a way that maybe the founders
(06:42) didn’t expect oh and speaking of the founders one thing i definitely wanted to mention when i was talking about whoever you are come come join the dev chat um joseph poon one of the founders of of handshake and an important designer of the protocol is not a coder you’re not a developer but he has great ideas and you know invented the lightning network with the help of a developer so just be inspired by that whoever you are you can have ideas okay covenants great sorry um these are the the op codes so um when a you you create a transact when
(07:19) you spend a transaction you have to spend something you already own you either own hns coins and you want to spend them to somebody else or you own a name and you want to you know update it or transfer it or something like that and to do that you need to um write this little program into the output of your transaction output and your wallet will do this automatically sorry most of the time what our wallet is doing is it’s using op checksig which is in here somewhere right it’s in here somewhere i promise
(07:52) and that just means i give you a public key a signature and you check the signature and if it’s a valid signature then you’re allowed to transact but it doesn’t end there there’s you know i don’t know how many there are here maybe 100 opcodes um the ones they’re all from bitcoin except for the ones in green on the right these are new that jj added to the handshake protocol there’s a couple extra hash functions that we use in handshake that bitcoin does not use and we also have op type which is very
(08:19) important op type is an opcode that takes the covenant from the transaction output puts it on the stack and i’ll i’ll expand on that later and the ones i have colored in red here are actually disabled they were added to the protocol by satoshi nakamoto and then removed from the protocol by satoshi nakamoto because of different attack vectors so you know it’s not ethereum smart contracting there’s no loops there’s no like persistent memory or anything like that but there is a lot of stuff going on here you can do a lot
(08:50) of weird stuff with math and and moving pieces of data around and comparing numbers and hashing things and you can have if um you know if logic if then logic and you can add as many signature checks as you want and you can have a really interesting output script that’s not just publicly signature um sig hashes are super interesting and is a kind of a crazy subtlety of that we have inherited from the bitcoin system so this is a transaction a bitcoin transaction just because it was a convenient screenshot to take that has
(09:22) two inputs and three outputs the two coins on the left are being destroyed or spent the three coins on the right are being created you know take the money on the left and send it to the people on the right so um the signatures in this transaction you might not think about it but like what you actually sign when you sign a transaction and and the answer to that is it depends on what you want to sign when you sign a transaction oh my god look at all these colors there’s lots of different ways to sign different parts of the transaction you
(09:51) can see the big red square that says all most the time when you send a transaction on the on the network you’re going to sign the entire transaction but you don’t have to if you’ve ever used shakedex or if you’ve ever used the atomic swap feature in bob wallet you have used single reverse the weird orange one that signs the top on the left and the bottom on the right and there’s other weird constructions here too weird ingredients no input is one that was proposed for bitcoin but still does not exist on bitcoin but jj
(10:18) added it to handshake which is one of the kind of nice advantages we have of starting a brand new project um and the the reason you would sign different parts of the transaction instead of the whole thing is to collaborate with other people so you you know i could start it you know like i mentioned like the way shake decks works for the way atomic swaps work and bob wallet i can sign um you know the two one input and one output of a transaction and those cannot be mutated they are signed they’re done they are
(10:46) done and then give it to you and you can fill in the rest of the transaction by by either signing all or sending other pieces so just something else to keep in mind we can combine we can work collaboratively on a transaction by signing different parts of it um wallets wallets work like this um i love this diagram it’s from pip 32 back when hierarchical deterministic wallets were made don’t drool with this image don’t worry about it you know what this image is what this image is is your seed phrase the 24 c the 24 words
(11:18) that you wrote down when you installed bob wallet when you got your ledger that’s over here are the s little dots it says entropy 128 bits that’s your seed and what this diagram is showing you is basically that you can generate an infinite number of addresses that are subdivided into an infinite number of accounts um if you’re above wallet user you probably don’t realize that you’re doing this um you you get a different most people observe that they get a different address every time they use an address
(11:44) even on name base because name base uses this too this is how hsd works but you can also have accounts and and this is something that you wouldn’t notice by using hsd or bob wallet but if you are building a service like an exchange like if you are name base or purse.io um you with one seed phrase you can create accounts for billions of users and each of those billions of users can have billions of receive addresses that always work forever and they can get new ones every time so this is great just you know you back
(12:15) up one seed phrase and you have all these addresses um that can be organized in lots of different ways all right so the last thing i’ll mention as far as ingredients to these two new ideas are our protocol upgrades hard fork versus software these are words that we’re going to toss around a lot um if you want to change something about how the core protocol works something like about in general and when we talk about forks what we basically mean is we are changing the protocol rules um and there can be a hard fork or there can be a
(12:46) soft fork and uh they the difference between those two is basically backwards compatibility and what i mean by that is how many um like what kind of software that exists today will still work tomorrow after the fork and that’s the rule a hard fork 100 of all nodes must upgrade every exchange every registry every bob wallet user in some cases um if the hard enough hard fork users using fingertip h sd the bob chrome extension spv nodes iphone apps might also need to be upgraded a hard fork is hard to do bitcoin for example
(13:25) has never really arguably but basically never um had a hard fork um some other cryptocurrencies certainly have you know bitcoin turning into bitcoin cash that was a hard fork it’s an incompatible with with the existing system they they broke a rule so hard that it created a whole new chain and we can do that if we want to um examples would be increasing the money supply um extend or you know increasing the money supply i also you know um some people like to have the idea like why don’t we take icann’s uh whatever it
(13:55) is 24 million hms um tribute and just give that to developers or something that would be a hard fork it’s not technically increasing the money supply but we are taking money away from somebody you know that is breaking the protocol that would be a hard fork everybody would have to change their software otherwise that would look like a very invalid transaction which is a good thing um extending the reserve name claim period this is a hard fork that will probably happen if we um can write it and do this community organizing thing
(14:24) that is required so the reserve name claim period lasts four years google apple facebook com info org they can reserve their name they only have two years left to do so if we want to extend that and still let them claim their name that is a hard fork because because right now all the handshake software out there thinks that this name clean period is going to end after four years and if we start allowing them to claim after that the software that exists today is just going to barf no that’s invalid and then we have a chain split
(14:52) and then there’s two handshakes and it’s bad but we can organize and do it right um changing rules for existing cover covenants names and oracle tree data these are all hard consensus rules if you want the reveal to do something else or if you want to be able to um finalize a name without a transfer that’s hard fork the rules that exist have to stay put or we need to change everything soft work 50 of miners must upgrade basically what happens in a soft fork is that miners censor the network um you know and uh that could be a good it
(15:26) could be a good thing segregated witness on bitcoin is a soft fork tap root on bitcoin soft fork even paid a script hash on bitcoin was a soft fork sometimes it’s hard to think about how backwards comparality compatibility works um but that’s it and you basically just tell the miners to censor certain types of transactions and then everybody who runs full nodes keeps the miners in check make sure they’re doing that correctly um handshake has already had a soft work as jj mentioned the other night it was a
(15:51) covert softwork because it was fixing a very bad bug we didn’t want anybody to exploit so unfortunately we could not include the community in discussing the software because if we told anybody how the how the bug worked people could exploit it immediately um so this is kind of interesting okay so that was a soft fork that was that was designed by two engineers and deployed directly to the miners without including the community and um and i’m sorry we did that you know it’s like it’s that’s tough it was a
(16:26) tough thing for for for us to do um to to have to keep the secret from the community it’s hard stuff um but anyway ideally softworks involve the community we all decide that we want to do it and people don’t have to upgrade everything we just need to get the miners um to upgrade and then um like so all right so let’s talk about them so some name claim inflation bug fix is a software adding new covenants and witness versions are soft works so we already have our covenant set back here we all know these covenants let’s say
(16:56) you wanted to add a new covenant like update two bid two maybe you have another covenant type called pancake that does something weird or um whatever use your imagination please use it imagine something new covenants can be added to handshake as a soft fork that means that only upgraded software will know what to do when they see those covenants old software would simply ignore them okay that’s cool reducing the money supply again is a i don’t know why we’d want to do that but we could that would be a software old
(17:25) software wouldn’t care if the money supply was reduced they wouldn’t even realize something had happened all right um oh and finally dns records um i just put this in here because it’s another ingredient we have you know this is a cool diagram of all the main dns records a lot of them you’re already familiar with i hope a records tlsa we talk about a lot the dns sec families is over here on the bottom left and you know this is part of uh this is part of handshake is what can we do with dns as we come up with
(17:55) different ideas to expand handshake and stuff like that all right let’s start talking about some of these ideas i’ll check for questions real quick because i know that i was lecturing um okay and i’ll i’ll get to these later so um let’s talk about some of the ideas that uh the the developers that i’m aware of that i talked to have come up with again these are not all my ideas most of them aren’t at all they’re just ideas that i’m aware of that have not been made yet maybe you
(18:25) will make some of these um role-based wallets so it’s similar to multi-sig um you might be familiar with multi-sig already some of you might even have used it it’s kind of advanced but it’s possible to use multi-sig on handshake right now the idea is you own um a handshake balance an h s balance or a name that requires some multiple amount of signatures to um to spend or to update um and you know this is very common bitcoin and it’s a good security measure too you can imagine even having a multi-sig with your bob wallet
(18:57) and your ledger where you needed a signature from your laptop and your ledger device to move your own money so you could have a multi-sig just by yourself well we can expand that with op type which i mentioned on the um the opcode slide and you can and this is actually mentioned in the white paper which is why op type is is so cool and was an idea that jj and joseph had in the very beginning you can have um a wallet where um bob wallet on your laptop can update your dns records on the root zone but you still need your ledger to do things
(19:26) like transfer finalize revoke and this is what i mean by role based so you know or or if you’re if you’re a company and you have employees and you’re managing domains you know maybe you’re in circa maybe you have the tlds that you control transfer finalize revoke requires a three of five multisig from the board of directors and then you have supervisors that can do things like register names after winning auctions or update dns records and then you have another group of people like employees that can bid
(19:55) and reveal so you can have like you know a room of 20 people where 10 of those people are allowed to bid on auctions and reveal but only the two supervisors can actually register once the auction’s done and up and update the dns records and then finally there’s only like you know the ceo and the vp of tech they do a multi-sig if they ever need to actually transfer finalize or revoke um and um i don’t know i think that’s just like super cool we can we can build the software now nobody’s done it yet but
(20:21) it’s possible um what else do we got okay federated not quite decentralized tlds i’ve been pitching this everybody’s talking about decentralized slds or like things like how forever and bob and badass work how we want to have like decentralized zones and um it’s hard because you know right now we’re using ethereum to do that i thought luke byrne’s talk was great about using ipfs i also agree with him that uh dns records don’t belong on chain as as much as possible so i think that’s
(20:53) cool so we have this idea of when people keep suggesting like let’s use side chains for each tld and you have a side chain that manages the slds it’s getting complicated okay like it’s getting hard we want people to be able to to access these domains easily without having to verify the ethereum blockchain you know um so federated means that there is a large group um that control a tld and they may not have to trust each other at all so it’s not it’s i guess is it decentralized if you have a federation it’s it’s not really
(21:27) decentralized it’s distributed or anyway it’s federated um so imagine that we have a uh a name that’s owned by a multi-sig wallet let’s say it’s um i’m just gonna pick people from the questions it’s me aaron and a the three of us um form a multi-sig wallet that requires all three of our signatures we’ll call that a three of three um and we uh we bid on some names and we own some some tlds and we can update the root zone records all three of us have to sign now right off the bat something that’s
(21:53) interesting about this is that if somebody else wanted to join our company let’s say mike wants to join our company we can include him in a new multisig policy that’s four of four or maybe it’s two of four or three or four we can all decide and then we transfer all the assets to that new address and now um now mike is part of that group you know so what you can do is basically have like a co-op where everybody who owns an sld um owns the tld so you like okay you’ve got a great tld it’s it’s dot hot dog i want
(22:25) to own ketchup.hotdog i’ll pay you a thousand dollars for ketchup.hotdog and and i and that money gets split among the current owners of dot hotdog i get the sld catchup.hotdog but also my key becomes part of the multisig and i own part of that tld um so you can add people to the policy like that and then we’ll get where it gets really interesting and this is where i have to get a little hand wavy because the cryptography gets a little i don’t understand it entirely but i know that these ingredients are possible
(22:53) especially you know with like uh with store signatures and stuff like that um multisig dns sec okay so if five of us own a tld and we don’t trust each other we can each run our own name server and put ns records for all five of those name servers in the root zone and then even put ds records where each of us has a key and put all those in the root zone and all of us would have valid name servers and we’d all have a copy of the current zone file we could basically all keep each other in check and in that way
(23:26) a group of people who may or may not entirely trust each other can participate in the operation of a tld basically in a decentralized way in a trustless way that the sld owners don’t have to trust the tld owner because you are part of the tld ownership um and there’s ways to do this cryptography and and then to make it even more interesting so so what i have here threshold dc or snore or key edition like music is that instead of um multiple ns and multiple ds records there is a way to combine our keys and
(23:56) create a single public key and create a signal signature so we can have a zone file that’s signed by what appears to be one key but is really a combination of everybody’s keys um and that’s just awesome and if we ever get to something like merging tap root into handshake that kind of idea can get um can get much more interesting and maybe even simpler the other thing that’s part of this no i’m going to talk about that later okay um yeah okay cool federated tlds we can come back to some of this stuff too
(24:25) um slds on chain all right everybody loves to talk about second level domains on chain third level domains on chain i sort of um agree with jj’s kind of like uh i don’t really want to do that sort of reaction um i feel like you have the other night i mean like let’s see if we can get this root zone thing to work first the other thing to consider with all these protocol improvements is is scaling is super important to us the like client has to work we want people to be able to run full nodes like bob
(24:55) wallet or just you know full nodes on on on cloud servers keep in mind that some hard forks of bitcoin like bitcoin sv have like gigabyte blocks and basically nobody runs a full node so it’s just simply not um decentralized and that’s a spectrum you know if we allow too much data on chain then the burden of running a full node or validating the chain with a light node gets harder and so we need to be very careful about those trade-offs um but anyway so let’s talk about some ways we could put slts on chain like i
(25:22) said the idea doesn’t have to be good i just want to inspire some creativity here um a one way way to do it would be with a second set of covenants and a second oracle tree so right now we have like i said the set of covenants like bid reveal transfer finalize and there’s one urkel tree and we can’t really change anything about that without a hard fork but we can add a complete second set of covenants and a complete second urkel tree um and have a whole second auction system on chain parallel in addition to
(25:54) the existing one with new rules about how bids and reveals work and how transfers work um and how um whether the the auction winning price gets burned or sent to somebody these are kind of rules we can actually add and we can actually add a second urkel tree and because it’s a soft fork it could be opt in if you’re running bob wallet you don’t have to do this you could opt out you could not have that second urkel tree you can ignore the second set of covenants so that’s cool um hard fork so there’s
(26:25) one one proposal i think the user’s name was vlad and the dev chat and and he was talking about um how to add uh slds on on chain for tlds that are already on chain and one of the interesting parts of the hard fork is adding dot and handshake names so um dots are not allowed in handshake names it’s just letters numbers uh hyphens and underscores and heimits and underscores are not allowed in the beginning or end that’s the rule and 63 characters long that that is the those are the hard rules if we want to
(26:51) break any of those rules we’re talking about a hard fork and everybody’s got to basically reinstall a new software so if we’re going to do a hard fork you know what if we allow dots and handshake names and then the dot would have this special property where the string to the right of the dot would have to be a handshake tld that already exists and is already let’s say configured with the anyone can renew script the way badass and forever work and then people could open auction so i could open an auction
(27:21) for um matt zipkin.c that would happen on chain um that would require a hard four because dots are not allowed in handshake names uh problems yeah what do we do with the with the purchase price um in the hard fork example just i’m kind of waving my hand at it but those prices would probably be burned um scalability i already mentioned um okay slds on chain lots of other interesting ideas there bob wallet zone management is one that i’m um okay ten minutes thank you is one that i’m i’m really excited about and i hope somebody
(27:51) builds and i might i might build it uh myself maybe later this year because i think it’s it’s gonna be a really good idea um imagine if you could just configure your zone file in bob wallet um or people are always asking this it’s a frequently asked question how do i add slds in bob um how do i add my a records and bob um a lot of these users are asking that because they don’t realize they need a name server so okay what if there was a federation of available name server service providers let’s say services provided by kyokon
(28:21) name base simpa pelas hs hub impervious miami everyone who you know can offer the service for a small fee and the service is if you send me your signed zone file um and you know one dollar per month whatever uh i will serve it and you can put my name server uh in the root zone as your ns record um so that’s one component of this the other component is back when i was talking about how we can generate keys from um from your seed phrase you back up you already have your seed phrase back up right everyone’s got their seed phrase
(28:56) backed up already and that’ll generate all the addresses you’ll ever need in in bob wallet for the rest of your life well we can also use that seed phrase to generate dns set keys which means the the flow in bob could look like this you go to bob you go to the domain manager you pick a name um that you want to add slds to or add dns records like an a record to you get a window and you type the a record in or you say you know mattsipping.
(29:24) hotdog has this a record now and you you click go and what happens is bob derives the dns that key from your wallet seed signs the zone uploads the zone to impervious kyokan name-based simplest hs hub with a one h sv attached to each of those push the ds record and the ns record for each of those services in the root zone all in one click and and that’s it it’s like it could be just that simple ui um bob while users don’t need to understand dns sec they don’t need to run their own name server they can just be a window and bob to add records to the zone and
(29:57) um and this is also an income stream potentially for these service providers and it’s trustless because you’re signing your zone if one of the service providers go down you just don’t pay them the next month and you use one of the other service providers i mean we could have a free market there uh i wrote bob while it could even periodically do dns requests to your own zone to make sure that the records are being served by capella’s name base and kyoken and alert the user like hey name base is not serving your zone anymore
(30:21) i’m going to stop paying them automatically all right i’m really excited about that one okay turbo blinds lock up loans staking my friend anu in the dev channel has has taken point on this but it’s been a long discussion name based i think was discussing this thing called turbo blinds the idea is to thwart snipers by borrowing a huge amount of money so let’s say i’m bob and i’ve only got 100 hms to to bid on the name bob i don’t want to get sniped because that’s a good snipey range right there
(30:49) so i borrow a million h from alice she actually places the bid on chain and nobody bothers sniping because it looks like there’s a million hms bid um and then in the reveal it turns out that it’s really only my bid of what i say 100 hms and then alice gets her uh 100 000 or what did i say alice gets her million hms back plus a small fee um and uh and that’s that’s how we want it to work and one of the other frequently asked questions we get from people who kind of wander into the handshake space is like
(31:19) how do i stake this coin because everybody’s into defy this is kind of a way to do that if you have a bunch of hns you could loan it and make interest this way um it would be very easy to do this on a centralized platform uh fernando fauci described it as something he wanted to add i think it was yeah to sing papeles um we can also do this in a decentralized way using those cool transaction primitives i showed you earlier the way it would work is that um bob and alice would communicate a few rounds in advance and exchange some
(31:50) public private key public keys and then bob would make a transaction to alice on chain that just looks like somebody sending money and it would be his bid plus the the interest that he’s paying alice and that transaction just sits there and and looks um innocuous and then later on during the bidding phase of an auction another transaction appears on the network that is the huge bid and these transactions must not be linkable otherwise the game is up right what we’re trying to do is to trick snipers into to thinking that you know
(32:23) that this huge bit is being placed when really it’s it’s my tiny 100 you know hns and at the same time we need to protect both alice and bob bob needs to win his name alice needs to get her money back um so we need to do these interesting like lightning network type transactions with lock times and stuff like that and then in the end you know uh in the reveal um the outputs of those two transactions i mentioned get merged and everybody can see that it was a lock up loan but it doesn’t matter because we’re in the
(32:52) reveal phase alice gets paid her fee she gets her stake back bob either wins or loses the name but either way you know he’d never had access to alice’s um whale account and um anyway very cool could be decentralized um could be a staking method i hope somebody builds that um let’s see how much more time do i have left i got a couple minutes i’ll talk about dns stuff really quick um my colleague buffer has done some really cool stuff with uh with beacon you might not realize it but he’s he’s kind of invented something
(33:25) called powder proof of work dns over https um the way that fingertip works is that it does all the dns resolution locally on your on your computer it’s a recursive resolution but we’ve discovered that that that’s not always possible sometimes you’re at a hotel wi-fi or even your own internet service provider will just block port 53 and then you just can’t do dns resolution so um what buffer has done in beacon browser especially on mobile devices by the way it’s hard to add extra dns stuff
(33:55) on mobile devices so what buffer’s done is he’s invented this idea where you have hnsd and it doesn’t actually do the recursive resolution you have hnsd on your phone that’s true and it does sync the block headers that’s true but all it actually gets from the handshake root zone are those ds records the public keys the roots of trust then it can ask some external recursive resolver using legacy https with a legacy certificate for the a record of the website you want to go to and you know it’s it’s sneaky because
(34:27) it’s https it just looks like every other type of web traffic you don’t need to trust that recursive resolver because you have the ds record verified you verified the proof of work already this is already how beacon works and we’re already talking about ways to make this even cooler one way would be for the web server to actually provide proofs of their own ds record in the root zone what this would mean is that all the like clients out there would not need to burden full nodes as much they wouldn’t need to be requesting oracle
(34:57) proofs um the the downside to this is that people who run websites would need to um basically run some type of handshake node on their on their own web server they need to be able to obtain their own proofs to serve to the client and then i had an additional idea which is what if we serve the block headers too you basically wouldn’t need h and sd at all what i could do is give you the urkel proof with my ds record and then give you maybe 20 um handshake block headers that bury that proof and that’ll prove
(35:27) to you that it took some group of miners so much electricity to create this proof you know which creates the chain of trust that creates the dame blah blah blah blah blah blah and if that cost is acceptable to you you can assume that those headers are actually in the main chain i don’t think handshake mining activity is efficient enough for this to be totally safe but um it’s an interesting idea and i stole that idea from james prestwich who wrote an article about it a few years ago about um proving that a bitcoin
(36:00) transaction has occurred to an ethereum smart contract using the same kind of thing that’s just called stateless sbv proofs we also buffer and i have also discussed onion routing onion routing is tor recursive resolution maybe using um other hsd peers maybe you know as we’re connecting to um to other handshake full nodes we can ask them to do recursive resolution something like that um the interesting thing about okay i’m just looking at what how much stuff i want to try to get through here yeah okay all right lightning round i’m going
(36:32) to talk about i got a couple minutes left um fistful said i could go a couple minutes into the break so i’m gonna i’m gonna talk about these real quick and then maybe take a look at the questions um candle auctions we’re talking about randomizing the the way that auctions end so that nobody knows when the bidding phase ends that eliminates snipers not going to elaborate on that right now something about making an offer on chain some way to [Music] trustlessly send a transaction to a name owner without any preparation or communication
(37:02) from their end at all you just get a message in your wallet one day that’s like you know here’s an offer and they can click it and it’ll prove they won’t have to transfer names to shake decks or something first and on that note we could have wallets where all the addresses are shake decks wallets so if you’ve ever put a name on shake decks you know you need the two-day transfer to put a name on shakedex before you can actually sell it if all of your addresses are hip 1 addresses already you can bid reveal and
(37:26) register with hip 1 addresses you don’t have to transfer to shake decks you’re already in shake decks mode i have hip 6 which is which is similar to shake decks but the auction prices go up and finally this one is cool so hsd full nodes actually have identity keys and they have something called brontide where hsd full nodes can communicate over an encrypted channel using a static identity if you’ve ever run hsd you you’ve seen the identity key and and this is something that we basically have borrowed from the
(37:55) lightning network where individual nodes need to have identities because we’re going to send them encrypted messages well that got me thinking that means that our own hsd nodes can communicate with each other let you know we could have a lightning network built into hsd without even adding a layer 2 it could just be part of hsd because we already have this identity system set up also if we’re doing atomic swaps or multi-sig or any of the other ideas i mentioned like um federated tlds we could use hsd’s own transport mechanism
(38:26) which is encrypted and private to send messages to certain nodes on the network so if if if me and fistful of ass i have no idea who that guy is if he and i are collaborating on a tld together and we both run full nodes with these bronte keys which is the bronte stuff is already there it’s happening now it works it’s running but we can use that to send encrypted messages to each other so for example i prepare a transaction i sign it i send it to him over over hsd and then his name can sign it on that
(38:55) end we can do the multi-six stuff okay um man that was really fun i hope you i hope i inspired some people um i don’t know how much time i have left i know i have like negative two minutes um let me just take a quick look at the at the questions here um a few million spv clients yes i’m worried about the total number of spv clients um right now i run a full node that supports about a thousand like clients and so i’m not totally worried about the impact of light clients on the network but they will you know we will need to
(39:24) support it um okay sounds like proof of work has the governance problem is day zero interes illustrated um i don’t really understand that i might have to just discuss that offline because i think it’s going to take me a few minutes to understand the question for the group of names providers are the signed zones for each tld on chain no what you put on chain is if you saw my dane talk two nights ago what you put on chain is the ns record so you put the the ns record for kyokin’s name server and previous name server name basis name
(40:02) server and then the ds record is your own public key and that’s how people who verify the zone know that impervious isn’t sending me false data and that’s why you don’t have to trust those name servers because you sign the data you give it to them and then you put your public key on chain secured by proof of work um so the zone data does not go on chain the only thing that goes on chain is the trust anchor which is your public key that’s a ds record okay that was really fun um guys handicon was was awesome this was a
(40:35) great week all the talks have been really awesome and the hosts have been great um i just had a great time and uh and thanks thanks everybody uh for a great weekend and i hope you’re all inspired to build cool stuff on handshake fist uh yeah yeah we’re at time we’re a little bit in the break which is totally fine we’ll take a little 10 minute breather uh before daniel comes and talks about uh skynet and home screen um so yeah we’ll we’ll see you guys then all right thank you [Music] [Applause]
(41:10) [Music] kinetic is a blockchain crypto investment firm based in hong kong and puerto rico [Music] founded in 2016 they were the first fund in hong kong and one of the earliest in asia with a portfolio of over 220 companies they were seed investors in such projects as ethereum parity and polka dot solana ftx and of course handshake
(42:14) in name base [Music] founder johann chu was an active investor and supporter of the handshake ecosystem over one hundred thousand domains co-founder of d-web foundation co-founder of handicon and sponsor of the handshake house at miami hack week 2022 [Music] [Applause] [Music] so [Music] [Applause] [Music] [Applause] [Music] um [Music] [Applause]
(43:17) [Music] [Music] [Applause]