dabit3

import { WebBundlr } from "@bundlr-network/client"
import { providers } from "ethers"

/* initialize some local state to store the bundlr instance */
const [bundlrInstance, setBundlrInstance] = useState(null)

/* connect to the user's wallet */
async function connect() {
    await window.ethereum.request({ method: 'eth_requestAccounts' })
    const provider = new providers.Web3Provider(window.ethereum)

FbN

// yarn add --dev @esbuild-plugins/node-globals-polyfill
import { NodeGlobalsPolyfillPlugin } from '@esbuild-plugins/node-globals-polyfill'
// yarn add --dev @esbuild-plugins/node-modules-polyfill
import { NodeModulesPolyfillPlugin } from '@esbuild-plugins/node-modules-polyfill'
// You don't need to add this to deps, it's included by @esbuild-plugins/node-modules-polyfill
import rollupNodePolyFill from 'rollup-plugin-node-polyfills'

export default {
    resolve: {
        alias: {

chris-belcher

Design for a CoinSwap Implementation for Massively Improving Bitcoin Privacy and Fungibility

25/5/2020

Abstract

Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B. But in reality her coins end up in address Z which is entirely unconnected to either A or B.

Now imagine another user, Carol, who isn't too bothered by privacy and sends her bitcoin using a regular wallet which exists today. But because Carol's transaction looks exactly the same as Alice's, anybody analyzing the blockchain must now deal with the possibility that Carol's transaction actually sent her coins to a totally unconnected address. So Carol's privacy is improved even though she didn't change her behaviour, and perhaps had never even heard of this software.

WebReflection

My FE/DOM Libraries

a gist to recap the current status, also available as library picker!

Minimalistic Libraries

do one thing only and do it well

• µhtml (HTML/SVG auto-keyed and manual keyed render)
• augmentor (hooks for anything)
• wickedElements (custom elements without custom elements ... wait, what?)

Rich-Harris

I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.

But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.

Svelte is a language.

Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

A few projects that have answered this question: