paulmillr

Fun parts of developing noble-hashes and scure-base

• Base58 is quadratic (O(n^2)). Basically you can’t encode 1MB of data with it. This has been found with our DoS tests, which we employ for scure-base and noble-hashes. See README for more details
• Hashes are additionally tested against huge multi-gig inputs, scrypt/pbkdf2 are tested against all possible combination of options. They take 2 hours to run on a decent machine
• Hashes are actually faster than many wasm alternatives. A single sha256 hashing of 32 bytes of data takes 888 nanoseconds on mac with M1
• The last fact is extremely remarkable, because we do not employ loop unrolls in the code. A loop unroll is when you’re writing code which could have been executed in loop like for (let step = 0; step < 64), but instead, you’re writing every iteration step-by-step. Which incr

markodayan

{
"main": "index.js",
  "scripts": {
    "clean": "rimraf dist",
    "start": "NODE_ENV=production node -r ts-node/register/transpile-only -r tsconfig-paths/register ./dist/index.js",
    "build": "npm run clean && tsc",
    "dev": "NODE_ENV=development ts-node-dev -r tsconfig-paths/register ./src/index.ts",
    "test": "mocha -r ts-node/register \"src/test/**/*.spec.ts\"",
    "pm2:dev": "npm run build && pm2 start pm2_dev.config.js",
    "pm2:prod": "npm run build && pm2 start pm2_prod.config.js",

yorickdowne

Note: PBSS in Geth >=1.13.0 removes the need to prune manually.

---

Old content for reference

Overview

Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 14 GiB/week with default cache, ~ 8 GiB/week with more cache.

lucas-manuel

[
    {
        "name": "Priority: Critical",
        "description": null,
        "color": "b60205"
    },
    {
        "name": "Priority: High",
        "description": null,
        "color": "d93f0b"

HichamBenjelloun

const memoizeFactory = hashFn => fn => {
  const memoize = fn => {
    const cache = {};

    return (...args) => {
      const key = hashFn(args);
      if (key in cache) {
        return cache[key];
      }

Ryanb58

>>> docker exec -it CONTAINERID /bin/sh
/app # telnet
/bin/sh: telnet: not found

/app # apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
v3.7.0-243-gf26e75a186 [http://dl-cdn.alpinelinux.org/alpine/v3.7/main]
v3.7.0-229-g087f28e29d [http://dl-cdn.alpinelinux.org/alpine/v3.7/community]

MauricioMoraes

You have to do 2 things in order to allow your container to access your host's postgresql database

1. Make your postgresql listen to an external ip address
2. Let this client ip (your docker container) access your postgresql database with a given user

Obs: By "Host" here I mean "the server where docker is running on".

Make your postgresql listen to an external ip address

Find your postgresql.conf (in case you don't know where it is)

$ sudo find / -type f -name postgresql.conf

JPvRiel

A quick set of notes looking into Ubuntu mirror locations for South Africa from my home fiber (Vumatel). The examples should apply in general.

Debian Package Info and Downloads

There are two phases

1. Getting lists of packages
2. The actual package download

When testing performance of package list info downloads via upt-get update, clear previous package info downloaded. If this isn't done, cached package info could skew results.

eyecatchup

// ABC - a generic, native JS (A)scii(B)inary(C)onverter.
// (c) 2013 Stephan Schmitz <eyecatchup@gmail.com>
// License: MIT, http://eyecatchup.mit-license.org
// URL: https://gist.github.com/eyecatchup/6742657
var ABC = {
  toAscii: function(bin) {
    return bin.replace(/\s*[01]{8}\s*/g, function(bin) {
      return String.fromCharCode(parseInt(bin, 2))
    })
  },