emre etherx-dev

What we know:

the fork was caused by a block that needed over 10,000 BDB locks to be confirmed
A conservative estimate of the number of locks needed to confirm a block is: (#unique txids referenced)*2.03 + 100, where unique txids referenced is number of transactions created in the block plus the number of previous transactions referenced by those transaction's inputs
A majority of hashing power was running version 0.8, and most miners are motivated to upgrade
BDB lock settings can be configured at runtime, by putting a file called DB_CONFIG in the data directory. DB_CONFIG overrides compiled-in settings.
Chain re-orgs can also trip the "too many locks" problem, depending on how many unique txids are involved. Since transactions tend to overlap between chains during a re-org, this is not as large a problem as one might think.
We would have a problem even if the network was all 0.7 nodes, because 0.7 could theoretically "self-fork" : the exact number of locks taken depends on the blkindex.d

The standard library of every programming language has at least one pseudo-random number generator. C has rand(), Javascript has math.Random()... and if you're writing code that needs good randomness you shouldn't use those.

There could be a series of github projects that generate bad random datastreams using those old, deprecated generators and "typical" starting seeds (e.g. 0, current Unix time, small integers that might be process ids) and feeds the results in to the rest.randomsanity.org database.

That only does some good if programmers start inserting checks to randomsanity.org into their C or Javascript applications... and if they don't know enough to use RAND_bytes() or crypto.RandomBytes()

Issues with the Blockchain Info API

The blockchain.info API for XPUBs only works with Legacy Bitcoin XPUBs, whereas their web interface confusingly works with Segwit as well.

I provide a couple solutions at the end, and we end up with three useful functions:

legacy_wallet_balance
segwit_wallet_balance
segwit_wallet_balance_hack

Introduction

It would be spiffy to use the balanced merkle forest idea for ethereum tokens or to store unspent transaction outputs.

Tadge Dryja has been working on 'utreexo' (presentation) for storing unspent transaction outputs in log(n) space; this gist is inspired by, and is very similar to, that work.

So my previous gist describes really simple algorithms for adding and removing items from a balanced merkle forest. This gist extends those operations to create

To Catch a Hacker - NPM Event Stream

(Note: this post is from a legacy blog dated 12/14/2018 and some content or links may have changed)

A few weeks ago, this issue was opened on a popular Node NPM package called Event Stream. This package enables Node streams to be simpler and streamlines many I/O operations within Node. Regardless, this package is a key dependency for many other Node packages and has over 1 million downloads per week from NPM. The newly opened issue initially questioned a new, suspicious dependency that was pushed by a new, unknown maintainer. I was lucky enough to follow the community's investigation into this issue and now, I hope to present the findings here. My goal with this piece is to hopefully shed some light on how easy it is for somebody to inject malicious code into NPM packages, the responsibility of open source maintainers, and the responsibility of the community.

The Malicious Code

A Github user noticed that

	This document is an attempt to define metrics quantifying the degree of privacy provided by a bitcoin transaction.


	Objectives

	Definition of metrics measuring the resistance of a transaction to a set of attacks against users privacy.

	Attacks considered in the scope of these metrics are:
	- Merged Inputs Heuristic: methods identifying the inputs controlled by a same entity
	- Coinjoin Sudoku: methods identifying the links existing between the inputs and outputs of a transaction

	// webcrack, a script that allows you to break webpack.js's sandbox and randomization easily
	// made by @NO_BOOT_DEVICE
	// licensed under the trust that you will credit me for my work visibly and other than that you can go have fun with this

	// window.wc is the webcrack object
	// wc.get gives you the module attached to the id you give it.
	// literally just what webpack functions use. not much to it
	// this is the basic part of all this, everything else is just to allow you to updateproof your code

	// both find functions return modules in this format:

	#what is the value Pp1d4 in the repos at https://github.com/Sean-Bradley/ECDSA_secp256k1_JordonMatrix_nodejs
	#it's used to get the modular cubed root

	#I want to find y in equation y² = x³ + 7 in a finite field P
	P = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
	Pp1d4 = 0x3fffffffffffffffffffffffffffffffffffffffffffffffffffffffbfffff0c
	#Pp1d4 = P plus 1 divided by 4

	#getting cubed root in a finite field
	print(pow(16, Pp1d4, P)) # = 4

	# First, we need to find our device. BEFORE inserting your USB drive, run the
	# following:
	diskutil list

	# This will output a bunch of info about all of the disk drives connected to
	# your Mac. Each entry will have a header in the form "/dev/diskX", where X is
	# some number starting at 0. Now, insert your USB drive and run the command
	# again. You should see a new entry. Make note of the name (ie, /dev/diskX).
	diskutil list

	from subprocess import Popen, PIPE, STDOUT
	from multiprocessing import Process, Queue
	import queue
	import os
	import re
	from termcolor import colored
	import argparse
	import time
	from datetime import datetime
	from dataclasses import dataclass