Chaser324

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

metacoin

Alexandria

Keeping History Honest

Joseph Fiscella

joseph@blocktech.com

Introduction

taariq

Hi all,

Tadge Dryja's Discreet Log Contracts (DLC) can be combined with Andrew Poelstra's Adaptor Signatures (AS). I'm simply describing the combination of the two existing concepts without any fundamental changes, but I thought it was worth writing out explicitly since I haven't seen any write-up. Hopefully it doesn't contain any errors.

Starting from Schnorr signature [R, s].

In DLC, the oracle will reveal one of multiple possible s values as part of signing the outcome of an event. This s is essentially a private key for which the public key S can be calculated ahead of time (because R is committed to in advance).

In AS, instead of just R (essentially a public key), you add a second public key P of which the payer wishes to obtain the private key p from the payee. Only by revealing p can the payee make the signature valid, and thus receive the payment.

AdamISZ

Looking for optimally minimal data transfer to send a transaction.

Just throwing this out there; I'm sure we can do better.

Some stuff should be pre-agreed by anyone following this protocol. For example:

• Preagreed: script type (say legacy P2PKH)
• Preagreed: version 1, locktime 0, sequence maxint-1, fee 10K sats (tweak this later)

Receiver has address AR, requests X sats.

fiatjaf

venv
*.swo
*.swp
__pycache__

elichai

cmake_minimum_required(VERSION 2.8.4)
project(bitcoin)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

file(GLOB_RECURSE SOURCES_FILES CONFIGURE_DEPENDS src/*.cpp src/*.c src/*.h)

include_directories(SYSTEM src
        src/bench
        src/compat

jachiang

from test_framework.test_framework import BitcoinTestFramework
from test_framework.address import program_to_witness
from test_framework.script import CScriptOp, CScript, TaprootSignatureHash, taproot_construct
from test_framework.script import OP_DUP, OP_HASH160, OP_EQUAL, OP_EQUALVERIFY, OP_CHECKSIG, OP_CHECKSIGADD
from test_framework.messages import CTxInWitness, CScriptWitness, COutPoint, CTxIn, CTxOut, CTransaction, sha256 
from test_framework.util import hex_str_to_bytes

from test_framework.key import ECKey
import hashlib 
import itertools 

jachiang

from test_framework.test_framework import BitcoinTestFramework
from test_framework.address import program_to_witness
from test_framework.script import CScript, TaprootSignatureHash, taproot_construct
from test_framework.script import OP_DUP, OP_HASH160, OP_EQUALVERIFY, OP_CHECKSIG
from test_framework.messages import CTxInWitness, CScriptWitness, COutPoint, CTxIn, CTxOut, CTransaction, sha256 
from test_framework.util import hex_str_to_bytes
from test_framework.key import ECKey

import hashlib 
from io import BytesIO

fjahr

Rolling UTXO Set Hash proposal

TL;DR

I have picked up Pieter Wuille's proposal from 2017 to use a rolling hash for the UTXO set hash. It deals with the problem of a long computation time of the UTXO set hash which results in a slow RPC call gettxoutsetinfo (can take several minutes depending on hardware). I investigated three hash functions: MuHash, ECMH and LtHash and started implementing them in Bitcoin Core for comparison. However only MuHash has a rolling hash implementation

roconnor-blockstream

{
  "txid": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750",
  "hash": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750",
  "wtxid": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750",
  "withash": "ab3393f4fb64685a4de07ac89c6903d6a0ba107c87fff33c9a981a7590bae48e",
  "version": 2,
  "size": 240,
  "vsize": 240,
  "weight": 960,
  "locktime": 0,