Skip to content

Instantly share code, notes, and snippets.

Last active August 18, 2020 21:29
Show Gist options
  • Save tynes/6e94596455a6b72d6630df1b9bd944a9 to your computer and use it in GitHub Desktop.
Save tynes/6e94596455a6b72d6630df1b9bd944a9 to your computer and use it in GitHub Desktop.
Potential Hackathon Projects

Handshake Hackathon Projects

Handshake Browser

Using hdns, it is possible to build an electron based web browser that is able to natively resolve Handshake names. The hdns library can be dropped into existing Node.js applications and enable Handshake names to be resolved, along with doing SIG0 DNS message authentication. DANE/TLSA could also be added, so that Certificate Authorities are not needed for the "green checkbox" user experience.

DNS Based Peer Discovery

The Lightning Network bolt #10 defines a DNS based way to find peers. A client and server could be built out in a general way, enabling any p2p system to discover peers. The authentication through DNS is very important.

Zcash Seed Nodes

This involves running some Zcash nodes that are addressable by Handshake names and seeing if they could be added as seeder nodes. It would add resiliancy to the network.

Node.js HTTP Client + Command line curl like tool

There are many HTTP client libraries in JavaScript that give nice interfaces to the lower level HTTP capabilities. None of these currently include Handshake support, so releasing a package on npm that is well maintained would be useful.

It could include a curl like tool that utilizes the HTTP client library.

Ports of hdns to other languages

The hdns library is a drop in replacement for the Node.js DNS module and can be dropped into an HTTP client to be used as a custom DNS lookup function. This allows an app to include the library and instantly have access to the ability to resolve Handshake names.

It would be useful if the library was ported to other languages so that applications not written in JavaScript can take advantage of this type of functionality.


Copy link

pinheadmz commented Jun 3, 2020

(I'll delete this comment after "merge")

Auto-reveal watchtower

REVEALs are required to be confirmed on the blockchain within a specific window of time, or the money is locked forever! Users who BID may not be online during that time, or simply forget. Exchanges and centralized registrars can provide this service for their customers but what about individual full node users like Bob? REVEALs can be pre-signed and sent to a third party watchtower service. The TX can even include an extra output that pays a fee to the watchtower. The watchtower can earn their fee simply by broadcasting the pre-signed REVEAL at the right time.

Recover encrypted blind values from blockchain data

See handshake-org/hsd#378 and especially the comment by pinheadmz at the bottom. Bids are blinded, meaning their actual value is secret and only known to the user. This breaks recoverability by the BIP44 standard which is supposed to only require a mnemonic seed and whatever transaction history is available on the blockchain. Can the secret BID value be encrypted with the user's wallet keys in such a way that the secret nonce (pre-image to the BLIND) can be regenerated?

Federated subdomain management

Everyone wants to know how we can use sidechains on Handshake to decentralize subdomains. Is it possible? We know that Handshake names can be owned by a robust multisig script (like 15-of-20). But what about the zone data itself? is there a cryptographic construction whereby a federation of untrusted nodes can collaborate to create a single DNSKEY that signs a zone?

Nameserver that generates BTC / HNS addresses

An authenticated nameserver that is authoritative over a HNS TLD zone should be able to generate BTC or HNS receive addresses and return them as TXT records when queried. They could be resolved as a pseudo subdomain like _btc.domain. TXT or _hns.domain. TXT. When a new address is generated by request, it should also be saved to some kind of log file on the server so the user knows how deep the wallet depth is (see BIP44). The server should be a watch-only wallet with an xpub so it only has access to public keys.

BTC-HNS cross-chain atomic swaps

See Create a decentralized exchange where users can propose HNS-BTC trades and accept them without trust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment