This document proposes a new scheme to avoid address reuse while retaining some of the convenience of address reuse, keeping recoverability purely from Bitcoin time chain and avoiding visible fingerprint. The scheme has negligible average overhead.
This document outlines some of the upcoming Bitcoin Core 22.0 release changes and provides steps to help. This is meant to get you started on testing, but is in no way comprehensive! After running through the steps in this guide, you are encouraged to do your own testing.
This can be as simple as testing the same features in this guide, but trying it a different way. Even better, think of features you use regularly and test that they still work as expected in the release candidate. You can also read the release notes to find something not covered in this guide. This is a great way to be involved with Bitcoin's development and helps keep Bitcoin running smoothly and bug free! Your help in this endeavor is greatly appreciated.
Changes covered in this testing guide include:
| // npm i hypercore@next hyperswarm@next random-access-memory | |
| // Run `node resolve-hypercore.js <key you get from https://gist.github.com/Nazeh/60291b111f93928d8110ff0ae9ecea25> | |
| const Hypercore = require('hypercore'); | |
| const Hyperswarm = require('hyperswarm'); | |
| const ram = require('random-access-memory'); | |
| const resolveCore = async (key) => { | |
| const core = new Hypercore(ram, key, { valueEncoding: 'json' }); | |
| await core.ready(); |
| // npm i hypercore@10.0.0-alpha.24 hyperswarm@3.0.1 | |
| // Run `node create-hypercore.js` and pass the resulting key to https://gist.github.com/Nazeh/721368b93729dcfa00049c9de230f2ad | |
| const Hypercore = require('hypercore'); | |
| const Hyperswarm = require('hyperswarm'); | |
| const createCore = async () => { | |
| const core = new Hypercore('origin', { valueEncoding: 'json' }); | |
| await core.ready(); | |
| // Add blocks here if you want. |
Lightning Address is a very popular protocol that brings UX improvements that users love. We'd like to provide those UX benefits without its privacy and security drawbacks.
As described here, the lightning address protocol requires payment senders to make an HTTP request to the recipient's domain owner. This has some inconvenient side effects: