Skip to content

Instantly share code, notes, and snippets.

public MainPage()
{
this.InitializeComponent();
Loaded += MainPage_Loaded;
}
private async void MainPage_Loaded(object sender, RoutedEventArgs e)
{
string url = "https://p.bigstockphoto.com/GeFvQkBbSLaMdpKXF1Zv_bigstock-Aerial-View-Of-Blue-Lakes-And--227291596.jpg";
var file = await Windows.Storage.ApplicationData.Current.LocalFolder.CreateFileAsync("photo.jpg");
@etherx-dev
etherx-dev / balanced_merkle_path_update.md
Created November 14, 2021 19:03 — forked from gavinandresen/balanced_merkle_path_update.md
Updating old paths (witnesses) for a balanced merkle forest accumulator

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

@etherx-dev
etherx-dev / gist:e0763150e0f95096051bb83dd8396449
Created October 24, 2021 22:09 — forked from LaurentMT/gist:e758767ca4038ac40aaf
Bitcoin Transactions & Privacy (part 1)
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
{
"0xe3ffc9a3": [
"sendEtherToOwner()"
],
"0x5629c6d9": [
"doExecution(address)"
],
"0xe2deaa81": [
"set_reference(uint256,uint256,uint256)"
],
@etherx-dev
etherx-dev / messages.c
Last active April 3, 2021 06:18 — forked from taviso/messages.c
Enumerating Windows Messages ( PROOF OF CONCEPT) - (i guess, this is so weired)... https://googleprojectzero.blogspot.com/2019/08/down-rabbit-hole.html#ftnt1 <-- "plain text" file RCE exploit in windows.
#include <windows.h>
#include <stdio.h>
#include <stdint.h>
#pragma comment(lib, "USER32")
FARPROC NtUserPostMessage;
BOOL CALLBACK QueryWindowMessageProc(HWND Window, LPARAM Param)
{

Hal Finney's explanation of secp256k1 "efficiently computable endomorphism" parameters used secp256k1 libraries, archived from source.

The same optimization could be applied to any Koblitz curve (e.g. Short Weistrass curve with a=0).


I implemented an optimized ECDSA verify for the secp256k1 curve, based on pages 125-129 of the Guide to Elliptic Curve Cryptography, by Hankerson, Menezes and Vanstone. I own the book but I also found a PDF on a Russian site which is more convenient.

secp256k1 uses the following prime for its x and y coordinates:

@etherx-dev
etherx-dev / P2EP-for-JM.md
Created February 15, 2021 03:45 — forked from AdamISZ/P2EP-for-JM.md
Basic payjoin/p2ep protocol for Joinmarket wallets

Described here is a variant of what has previously been published under the name "P2EP" or Pay-to-endpoint, in which A pays B but B contributes utxos, i.e. it's a coinjoin-payment.

I'm using the term "payjoin" here to refer to using that idea, but not including a URI/endpoint specific to B, and not allowing (as a merchant would) arbitrary payments, which opens up certain problems around snooping attackers (more on this below). So payjoin just means "A pays B but B actively participates and passes across utxos as extra inputs".

I'll defer a more features-focused and non-tech friendly description of what this means to a later blogpost.