Keeping History Honest
Joseph Fiscella
Introduction
Keeping History Honest
Joseph Fiscella
Introduction
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.
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 |
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 |
[Fund Channel] | |
| | |
| | |
| | |
v | |
P=Musig(A,B)+scripts (for Taproot script-path spend) | |
Q=Musig(A,B) (for Taproot key-path spend) | |
OR ----------- [Cooperative Close] |
lightning | |
#!/bin/bash | |
export PATH=$PATH:/home/adam/data/openwrt/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-8.3.0_musl_eabi/bin | |
export STAGING_DIR=/home/adam/data/openwrt/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-8.3.0_musl_eabi | |
export target_host=arm-openwrt-linux-muslgnueabi | |
export AR=$target_host-ar | |
export AS=$target_host-as | |
export CC=$target_host-gcc | |
export CXX=$target_host-g++ |
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
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 |
{ | |
"txid": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750", | |
"hash": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750", | |
"wtxid": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750", | |
"withash": "ab3393f4fb64685a4de07ac89c6903d6a0ba107c87fff33c9a981a7590bae48e", | |
"version": 2, | |
"size": 240, | |
"vsize": 240, | |
"weight": 960, | |
"locktime": 0, |