ysangkok

 % stack test
cryptonite> build (lib)
cryptonite> Preprocessing library for cryptonite-0.26..
cryptonite> Building library for cryptonite-0.26..
cryptonite> copy/register
cryptonite> Installing library in /home/janus/cacophony/cryptonite/.stack-work/install/x86_64-linux/cea844b868c590d10b37b5728a7e336c7370333160811b46a40f8c876de7433d/8.6.5/lib/x86_64-linux-ghc-8.6.5/cryptonite-0.26-JSfVoV20JFdAvxlU28K5eI
cryptonite> Registering library for cryptonite-0.26..
Received ExitFailure 1 when running
Raw command: /home/janus/.stack/programs/x86_64-linux/ghc-8.6.5/bin/ghc-pkg-8.6.5 --user --no-user-package-db --package-db /home/janus/cacophony/.stack-work/install/x86_64-linux/81bc190906f1d3056942b686693fd02c4a23529d049fe3dd58aa40b23280cb79/8.6.5/pkgdb describe --simple-output cryptonite --expand-pkgroot
Standard error:

ysangkok

(gdb) r
Starting program: /home/janus/cacophony/cryptonite/.stack-work/install/x86_64-linux/ef9a18e2ad1de7f274d595f5c85895cda63606dad70ef5ddd733ea6452fcc885/8.6.5/bin/Demo +RTS -V0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000b25d90 in secp256k1_nonce_function_default ()
(gdb) x/10i 0x0000000000b25d90
=> 0xb25d90 <secp256k1_nonce_function_default>:	cltd   
   0xb25d91 <secp256k1_nonce_function_default+1>:	adc    0x7ffff7(%rdx),%al

ysangkok

(ns hello-test (:require [secp256k1.core :as secp256k1] [clojure.test :as test]))

(def rs-pub
  (secp256k1/public-key "028d7500dd4c12685d1f568b4c2b5048e8534b873319f3a8daa612b469132ec7f7") )

(def ls-priv
  (secp256k1/private-key (hello/fromhex "1111111111111111111111111111111111111111111111111111111111111111")))

(= (seq (.getEncoded (secp256k1/public-key ls-priv) true))
   (seq (hello/fromhex "01034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa")))

ysangkok

 % strace dune build
execve("/home/janus/.opam/4.07.1/bin/dune", ["dune", "build"], 0x7ffc567998b8 /* 78 vars */) = 0
brk(NULL)                               = 0x5569048c3000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=160499, ...}) = 0
mmap(NULL, 160499, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4db5c16000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)

ysangkok

-22: TX rejected: failed to validate input eace631a89acb603bd8132d8e513ff0b9d3f18f1b0b895ff699c315353ef870e:6 which references output cacc27d34f9280efcd21b82877da71db181e99c7faad67d94d1cb228e343b2c3:1 - signature not empty on failed checksig (input witness [], input script bytes 47304402202041c3561fb6824302019b77b0f3c85d2b32a7d5b49cec7ef0a38d8ce958510102206f7d6459c1919ccff9184cf1db4ca4a80b5d0030ad1259af46b893cbe7bc3558012103941518fb527c286f2429e252cc8e016465bb21a80603f661dd798c9a7208c364, prev output script bytes 76a914d94ef28ade5e25db005a198aa4ffe99965f324ec88ac)

-22: TX rejected: failed to validate input eace631a89acb603bd8132d8e513ff0b9d3f18f1b0b895ff699c315353ef870e:4 which references output aa0a385bf94d15daafeda48b5ee5eb3ef5711138aafe610d232daf9bc3fbc3ef:1 - signature not empty on failed checksig (input witness [], input script bytes 473044022058ef633f6bed136db82d35d87d59ac5320e6b96e7f2abe89ee47a77700ba90e202200e38030062a57ec40211daeb8dc32b6e7ca2141d53c73f7b1fba278e4bfdd9dd0121034e66a1221b0c5e239fa67419

ysangkok

2019-02-15 06:05:06.544 [INF] SYNC: Syncing to block height 1457192 from peer 217.172.178.44:18333
2019-02-15 06:12:53.223 [INF] SYNC: Processed 1 block in the last 19m31.74s (129 transactions, height 1457193, 2019-02-15 06:12:41 +0100 CET)
2019-02-15 06:33:02.344 [INF] CHAN: Adding orphan block 00000000000fa89d8e3f1f594c58ee3d269661c35f3077db26060cfeef15a4f1 with parent 00000000000366ac6559456707eec35b673
c735b2b5b66461cf60eaa99ce5c77
2019-02-15 06:33:03.007 [INF] CHAN: FORK: Block 00000000000366ac6559456707eec35b673c735b2b5b66461cf60eaa99ce5c77 forks the chain at height 1457192/block 000000000000003
4ccc2c3b3aa4c3aceee23b2fd0527ba06f09dc1d4222d3929, but does not cause a reorganize
2019-02-15 06:33:03.013 [INF] CHAN: REORGANIZE: Block 00000000000fa89d8e3f1f594c58ee3d269661c35f3077db26060cfeef15a4f1 is causing a reorganize.
fatal error: sync: Unlock of unlocked RWMutex

goroutine 100 [running]:

ysangkok

Exception during reset or similar
Traceback (most recent call last):
  File "/home/janus/.local/lib/python3.6/site-packages/sqlalchemy/pool/base.py", line 671, in _finalize_fairy
    fairy._reset(pool)
  File "/home/janus/.local/lib/python3.6/site-packages/sqlalchemy/pool/base.py", line 858, in _reset
    pool._dialect.do_rollback(self)
  File "/home/janus/.local/lib/python3.6/site-packages/sqlalchemy/engine/default.py", line 496, in do_rollback
    dbapi_connection.rollback()
sqlite3.ProgrammingError: SQLite objects created in a thread can only be used in that same thread. The object was created in thread id 139864512661248 and this is thread id 139864716584768.

ysangkok

[Channel][lnchannel_2444db44] receive_revocation
[Peer][localhost:9735] Exception in wrapper_func : KeyError(2,)
Traceback (most recent call last):
  File "/home/janus/Skrivebord/lightning-rfc/tools/electrum/electrum/util.py", line 916, in wrapper
    return await func(*args, **kwargs)
  File "/home/janus/Skrivebord/lightning-rfc/tools/electrum/electrum/lnpeer.py", line 202, in wrapper_func
    return await func(self, *args, **kwargs)
  File "/home/janus/Skrivebord/lightning-rfc/tools/electrum/electrum/lnpeer.py", line 219, in main_loop
    await self._main_loop()
  File "/home/janus/Skrivebord/lightning-rfc/tools/electrum/electrum/lnpeer.py", line 230, in _main_loop

ysangkok

I am wondering if the first two roundtrips of pre-committing and then revealing R/r in MuSig signing can be moved to the keygen phase and made deterministic. That reduces the amount of messages that need to be exchanged, since keygen is done only once and we want to expand that phase. This would be especially useful for HD wallets so that at the expense of making wallet creation more complicated, signing needs fewer interactions.

The [musig paper](https://eprint.iacr.org/2018/068.pdf) on page 11, "Signing" specifies that signer 1:

1. sends t<sub>1</sub>=H<sub>com</sub>(R<sub>1</sub>)
2. receives t<sub>i</sub> 
3. sends R<sub>1</sub>
4. receives R<sub>i</sub>
5. checks that H<sub>com</sub>(R<sub>i</sub>)==t<sub>i</sub>

ysangkok

import threading
import asyncio
import time
import json
import subprocess
import colorama
import os

from utils import BitcoinRpc
from electrumutils import ElectrumX, ElectrumNode