theStack

$ git clone https://github.com/BlockstreamResearch/bip-frost-dkg secp256k1proto-extract-history
$ cd secp256k1proto-extract-history
$ git filter-repo --path-rename reference/secp256k1ref:python/secp256k1proto
$ git filter-repo --path-rename python/secp256k1ref:python/secp256k1proto
$ git filter-repo --path python/secp256k1proto
$ git filter-repo --path-rename python/secp256k1proto:src/secp256k1proto
$ uv init --package --lib --name secp256k1proto --python 3.11
$ git add . && git commit -m 'initialized package via "uv init"'
$ git remote add origin https://github.com/theStack/secp256k1proto-playground
$ git push origin master:with_history2

theStack

considerations for a possible secp256k1 hazmat module

- exposed data types
  * as discussed at coredev lisbon: provide scalar and point types in the
    first version, field element type can still be added later if needed
  * responsibility for allocating space for the types?
    the PoC secp-zkp pr #153 [1] provides a function _scalar_size and forces
    the user to allocate dynamic memory, which seems not ideal, especially
    in embedded systems where malloc usage is often strongly discouraged
    (or not even possible); it seems better to know the size already at

theStack

summary for #28970:

let's assume we have a 1p1c-package consisting of low-feerate parent tx_p
and high-feerate child tx_c. a node receives this package in form of two
single tx messages, tx_p and then tx_c.

to my current understanding, the following happens on this receiving node:

on master:

theStack

configure:6211: checking whether C++ supports the ISO C++ standard includes
configure:6231: clang++ -m64 -c -pipe -std=c++20 -O2   -I/home/thestack/bitcoin/depends/amd64-unknown-openbsd7.4/include -D_XOPEN_SOURCE=600  conftest.cpp >&5
In file included from conftest.cpp:10:
In file included from /usr/include/c++/v1/iostream:37:
In file included from /usr/include/c++/v1/ios:214:
In file included from /usr/include/c++/v1/__locale:37:
In file included from /usr/include/c++/v1/__support/openbsd/xlocale.h:13:
/usr/include/c++/v1/__support/xlocale/__strtonum_fallback.h:23:64: error: unknown type name 'locale_t'
                                                char **endptr, locale_t) {
                                                               ^

theStack

# Running Bitcoin Core on an emulated 32-bit ARM system using qemu (for reproducing issue #28906 and testing the fix PR #28913)
# guide based on https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/
# tested on Ubuntu 22.04 LTS

$ sudo apt-get install qemu-system-arm libguestfs-tools
$ wget -O installer-vmlinuz http://http.us.debian.org/debian/dists/bookworm/main/installer-armhf/current/images/netboot/vmlinuz
$ wget -O installer-initrd.gz http://http.us.debian.org/debian/dists/bookworm/main/installer-armhf/current/images/netboot/initrd.gz
$ qemu-img create -f qcow2 myarmdisk.qcow2 80G
$ qemu-system-arm -M virt -m 2048 -kernel installer-vmlinuz -initrd installer-initrd.gz \
    -drive if=none,file=myarmdisk.qcow2,format=qcow2,id=hd \

theStack

#!/usr/bin/env python3
from Crypto.Cipher import ChaCha20, ChaCha20_Poly1305

def nonce_bytes(nonce32, nonce64):
    return nonce32.to_bytes(4, 'little') + nonce64.to_bytes(8, 'little')

#############################################################################################
### PR #28008, commit 2/8 "crypto: add the ChaCha20Poly1305 AEAD as specified in RFC8439" ###
#############################################################################################
def test_chacha20poly1305(plain, aad, key, nonce96, cipher_with_tag_expected):

theStack

package main

import (
    "crypto/sha256"
    "fmt"
    "github.com/utreexo/utreexo"
    "os"
)

func main() {

theStack

Keybase proof

I hereby claim:

• I am theStack on github.
• I am thestack (https://keybase.io/thestack) on keybase.
• I have a public key whose fingerprint is 6A8F 9C26 6528 E25A EB1D 7731 C237 1D91 CB71 6EA7

To claim this, I am signing this object:

theStack

============================================================================================================================
============================ benchmark results with boost::multiprecision (original) =======================================
============================================================================================================================
~/evmone/build$ ./bin/evmone-bench ~/aleth/build/libaleth-interpreter/libaleth-interpreter.so ../test/benchmarks/
Benchmarking /home/honey/aleth/build/libaleth-interpreter/libaleth-interpreter.so

2019-09-23 15:37:17
Running ./bin/evmone-bench
Run on (8 X 1917.61 MHz CPU s)
-----------------------------------------------------------------------------------------------