mit-dci/lit

Lightning Network node software

lit's Issues

Prioritize the Roadmap

Would be useful to prioritize features, and determine which are required for real-money usage and which can be implemented later.

NewWallit crash Error

Hello,
I am trying to run the lit node using this command : llit.exe -tn3 fullnode.net -v
and I get this output

2017/07/30 11:06:45 lit v0.1
2017/07/30 11:06:45 -h for list of options.
WARNING!! Key file not encrypted!!
Anyone who can read the key file can take everything!
You should start over and use a good passphrase!
2017/07/30 11:06:45.185152 db says 1 keys
2017/07/30 11:06:45.217740 DB height 0
2017/07/30 11:06:45.218016 DB height 1032192
2017/07/30 11:06:45.228048 opened header file .lit\testnet3\header.bin
2017/07/30 11:06:48.176676 NewWallit crash dial tcp 122.194.229.38:18333: connectex: No connection could be made because the target machine actively refused it.
2017/07/30 11:11:56.743467 -- started BlockHandler type 1, block channel cap 8

Where is the problem and why the Newwalit is crashd ?

Unused Locks

While looking at #7, I came across this neat piece of TODO:

	nd.RemoteMtx.Lock()
	nd.RemoteMtx.Unlock() //TODO: This unlock is in the wrong place...?

I think we can remove this since there is nothing going on?

Add address book

lit should remember the IP addresses of LN nodes it has connected to. Also should be able to assign names to them. Also should log chat history with LN peers.

Reorg and difficulty adjustment error

There is some kind of interaction between reorgs and difficulty adjustment which causes uspv to think a difficutly change is invalid. This was on testnet, which I still don't 100% understand the difficulty nerfing algo for, so may be related to that, or may be something simpler.

errors here:

2017/11/30 13:18:54.471755 got inv.  Contains:
2017/11/30 13:18:54.471789 	0)MSG_BLOCK : 0000000000000bfccbcc411f787296eb13fddbe4f32858ad3c37885088636711
2017/11/30 13:18:54.471805 asking for headers due to inv block
2017/11/30 13:18:54.471845 got header tip height 1251344
2017/11/30 13:18:54.472130 get headers message has 19 header hashes, first one is 00000000000007eb00fc245c0808b2c04c4d17c3cffaff515944fba61d27fd67
2017/11/30 13:18:54.473163 got 2 headers. Range:
0000000000000da79fd9445b794a6d9f52d834e6eb7c28c559b9fc8985380f3c - 0000000000000bfccbcc411f787296eb13fddbe4f32858ad3c37885088636711
2017/11/30 13:18:54.473212 header file position: 17532160
2017/11/30 13:18:54.473230 made 2017 header slice
2017/11/30 13:18:54.485187 Header 0000000000000da79fd9445b794a6d9f52d834e6eb7c28c559b9fc8985380f3c attaches at height 1251343
2017/11/30 13:18:54.485201 reorg from height 1251344 to 1251345
2017/11/30 13:18:54.485219 Header error: Block 1251345 0000000000000da79fd9445b794a6d9f52d834e6eb7c28c559b9fc8985380f3c incorrect difficuly.  Read 1a3fffc0, expect 1b00ffff

Close transaction not detected

May have been recently introduced.
When the counterparty broadcasts a unilateral close, it wasn't detected.

In regtest

Channel 1 (peer 1) type 257 685d3a67a5275de5e67bc18cd7a0d35197053fdee28a1270c30e12493ff5b606;0
	 cap: 300000000 bal: 146764641 h: 2941 state: 8

but was closed by dfd6ef34f204c528dc236738a20e751ab8195a7d4b1e55a390d1841946b86288

node didn't seem to care:

2017/05/08 14:50:08 got inv.  Contains:
2017/05/08 14:50:08 	0)MSG_TX : dfd6ef34f204c528dc236738a20e751ab8195a7d4b1e55a390d1841946b86288
2017/05/08 14:50:08 added dfd6ef34f204c528dc236738a20e751ab8195a7d4b1e55a390d1841946b86288 to OKTxids at height 0
2017/05/08 14:50:08 asking for tx dfd6ef34f204c528dc236738a20e751ab8195a7d4b1e55a390d1841946b86288
2017/05/08 14:50:08 received msgtx dfd6ef34f204c528dc236738a20e751ab8195a7d4b1e55a390d1841946b86288

will look for that & try to re-create

lndc_test.go fails

running lndc_test.go fails:

→ go test .
# github.com/mit-dci/lit/lndc
lndc/lndc_test.go:43: cannot use localPriv.PubKey().SerializeCompressed() (type []byte) as type string in argument to conn.Dial

I've tried changing the []byte to a string in call to conn.Dial():

@@ -40,7 +40,7 @@ func TestConnectionCorrectness(t *testing.T) {
        wg.Add(1)
        go func() {
                dialErr = conn.Dial(remotePriv, listener.Addr().String(),
-                       localPriv.PubKey().SerializeCompressed())
+                       string(localPriv.PubKey().SerializeCompressed()))
                wg.Done()
        }()

but lndc_test now times out after 10 minutes and fails:

→ go test -v .
=== RUN   TestConnectionCorrectness
SIGQUIT: quit
PC=0x45af01 m=0 sigcode=0

goroutine 0 [idle]:
runtime.futex(0x95ded0, 0x0, 0x0, 0x0, 0x7f5000000000, 0xa42cd940, 0x0, 0x0, 0x7ffea42cd970, 0x40f32b, ...)
	/usr/local/go/src/runtime/sys_linux_amd64.s:422 +0x21
runtime.futexsleep(0x95ded0, 0x0, 0xffffffffffffffff)
	/usr/local/go/src/runtime/os_linux.go:45 +0x62
runtime.notesleep(0x95ded0)
	/usr/local/go/src/runtime/lock_futex.go:145 +0x6b
runtime.stopm()
	/usr/local/go/src/runtime/proc.go:1650 +0xad
runtime.findrunnable(0xc420022600, 0x0)
	/usr/local/go/src/runtime/proc.go:2102 +0x2e4
runtime.schedule()
	/usr/local/go/src/runtime/proc.go:2222 +0x14c
runtime.park_m(0xc4204309c0)
	/usr/local/go/src/runtime/proc.go:2285 +0xab
runtime.mcall(0x7ffea42cdb00)
	/usr/local/go/src/runtime/asm_amd64.s:269 +0x5b

goroutine 1 [chan receive, 9 minutes]:
testing.(*T).Run(0xc42047e270, 0x6f1db0, 0x19, 0x81f880, 0xc42043fd20)
	/usr/local/go/src/testing/testing.go:698 +0x2f4
testing.runTests.func1(0xc42047e270)
	/usr/local/go/src/testing/testing.go:882 +0x67
testing.tRunner(0xc42047e270, 0xc42043fde0)
	/usr/local/go/src/testing/testing.go:657 +0x96
testing.runTests(0xc420474220, 0x951900, 0x1, 0x1, 0xc42043fed0)
	/usr/local/go/src/testing/testing.go:888 +0x2c1
testing.(*M).Run(0xc420497f20, 0xc42043ff20)
	/usr/local/go/src/testing/testing.go:822 +0xfc
main.main()
	github.com/mit-dci/lit/lndc/_test/_testmain.go:42 +0xf7

goroutine 17 [syscall, 9 minutes, locked to thread]:
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:2197 +0x1

goroutine 5 [semacquire, 9 minutes]:
sync.runtime_notifyListWait(0xc420432a50, 0xc400000000)
	/usr/local/go/src/runtime/sema.go:298 +0x10b
sync.(*Cond).Wait(0xc420432a40)
	/usr/local/go/src/sync/cond.go:57 +0x89
github.com/btcsuite/seelog.(*asyncLoopLogger).processItem(0xc420072e40, 0x0)
	/home/john/Code/go/src/github.com/btcsuite/seelog/behavior_asynclooplogger.go:50 +0x97
github.com/btcsuite/seelog.(*asyncLoopLogger).processQueue(0xc420072e40)
	/home/john/Code/go/src/github.com/btcsuite/seelog/behavior_asynclooplogger.go:63 +0x33
created by github.com/btcsuite/seelog.newAsyncLoopLogger
	/home/john/Code/go/src/github.com/btcsuite/seelog/behavior_asynclooplogger.go:40 +0x96

goroutine 6 [semacquire, 9 minutes]:
sync.runtime_notifyListWait(0xc420432bd0, 0xc400000000)
	/usr/local/go/src/runtime/sema.go:298 +0x10b
sync.(*Cond).Wait(0xc420432bc0)
	/usr/local/go/src/sync/cond.go:57 +0x89
github.com/btcsuite/seelog.(*asyncLoopLogger).processItem(0xc420072f60, 0x0)
	/home/john/Code/go/src/github.com/btcsuite/seelog/behavior_asynclooplogger.go:50 +0x97
github.com/btcsuite/seelog.(*asyncLoopLogger).processQueue(0xc420072f60)
	/home/john/Code/go/src/github.com/btcsuite/seelog/behavior_asynclooplogger.go:63 +0x33
created by github.com/btcsuite/seelog.newAsyncLoopLogger
	/home/john/Code/go/src/github.com/btcsuite/seelog/behavior_asynclooplogger.go:40 +0x96

goroutine 10 [IO wait, 9 minutes]:
net.runtime_pollWait(0x7f50bd225a78, 0x72, 0x6)
	/usr/local/go/src/runtime/netpoll.go:164 +0x59
net.(*pollDesc).wait(0xc4200aa068, 0x72, 0x93a080, 0x937440)
	/usr/local/go/src/net/fd_poll_runtime.go:75 +0x38
net.(*pollDesc).waitRead(0xc4200aa068, 0xc4200120d8, 0x2)
	/usr/local/go/src/net/fd_poll_runtime.go:80 +0x34
net.(*netFD).Read(0xc4200aa000, 0xc4200120d8, 0x2, 0x8, 0x0, 0x93a080, 0x937440)
	/usr/local/go/src/net/fd_unix.go:250 +0x1b7
net.(*conn).Read(0xc4200a0000, 0xc4200120d8, 0x2, 0x8, 0x0, 0x0, 0x0)
	/usr/local/go/src/net/net.go:181 +0x70
io.ReadAtLeast(0x7f50bc1a0000, 0xc4200a0000, 0xc4200120d8, 0x2, 0x8, 0x2, 0x6901c0, 0x7f50bc1a0001, 0xc4200120d8)
	/usr/local/go/src/io/io.go:307 +0xa9
io.ReadFull(0x7f50bc1a0000, 0xc4200a0000, 0xc4200120d8, 0x2, 0x8, 0x50, 0x16, 0x1)
	/usr/local/go/src/io/io.go:325 +0x58
encoding/binary.Read(0x7f50bc1a0000, 0xc4200a0000, 0x93e680, 0x978f60, 0x67fa60, 0xc4200120d0, 0x81fa38, 0x27)
	/usr/local/go/src/encoding/binary/binary.go:170 +0xea
github.com/mit-dci/lit/lndc.readClear(0x93e8c0, 0xc4200a0000, 0x454020, 0x7f50bfa4ce10, 0xe, 0xc420041c90, 0x4106e2)
	/home/john/Code/go/src/github.com/mit-dci/lit/lndc/netio.go:60 +0xdc
github.com/mit-dci/lit/lndc.(*Listener).createCipherConn(0xc420452240, 0xc420076000, 0xc4200a0000, 0x0, 0x0, 0xc420041d08, 0x657548)
	/home/john/Code/go/src/github.com/mit-dci/lit/lndc/listener.go:75 +0x53
github.com/mit-dci/lit/lndc.(*Listener).Accept(0xc420452240, 0x81f878, 0xc420452260, 0xc42047e410, 0xc4204762a0)
	/home/john/Code/go/src/github.com/mit-dci/lit/lndc/listener.go:53 +0xb4
github.com/mit-dci/lit/lndc.TestConnectionCorrectness(0xc42047e340)
	/home/john/Code/go/src/github.com/mit-dci/lit/lndc/lndc_test.go:47 +0x369
testing.tRunner(0xc42047e340, 0x81f880)
	/usr/local/go/src/testing/testing.go:657 +0x96
created by testing.(*T).Run
	/usr/local/go/src/testing/testing.go:697 +0x2ca

rax    0xca
rbx    0x0
rcx    0x45af03
rdx    0x0
rdi    0x95ded0
rsi    0x0
rbp    0x7ffea42cd940
rsp    0x7ffea42cd8f8
r8     0x0
r9     0x0
r10    0x0
r11    0x286
r12    0x0
r13    0xc4200689c0
r14    0x440340
r15    0x8792e0
rip    0x45af01
rflags 0x286
cs     0x33
fs     0x0
gs     0x0
*** Test killed with quit: ran too long (10m0s).
FAIL	github.com/mit-dci/lit/lndc	600.004s

Watch interface for lit-af

The watchtower package doesn't have a lit-af interface right now. As predicted by adiabat, watchtower doesn't seem to work all that great now, so would be nice to do along with that PR (in-progress).

EDIT: PR #149

what is meant by my.testnet.node.tld in last step of installation instructions?

Does this require a testnet node to be running on my computer, and it wants the ip address to it?

Thanks for clarification.

Syncing Testnet after Regtest

So I had a weird chain with a couple of inv blocks and forks in between and I try to re sync it. Syncing without the re-sync flag explicitly specified results in an Out of Order block as expected. Syncing with re-sync enabled still stops at the first invalid block.

I specify the --dir flag along with the resync flag and this is what happens- The chain syncs fine on regtest till the current tip and then after that, proceeds to contact a peer from our DNS Seeds for testnet and syncs on testnet. Investigating.

ERC20 support

Ethereum support

How can I check micropayments are successful after closing a channel?

I connected and made a channel with other lit node and I sent 500,000satoshis.

How can I check the payments on the blockchain for testnet3? Some explorers such as blocks.io do not support segwit address yet.

The lit closed the channel after sending command "close 1" like below so I want to check the payment on blockchain explorer such as blockr.io.

lit-af# ls
entered command: ls

1 xxx.xxx.xxx.xxx:46664
	Channels:
Closed  1 (peer 1) f8bd9f192d34e4b3d2a4021661f7c5f7083a7270ae066d290f718159f50b32ea:0
	 cap: 1000000 bal: 500000 h: 1083882 state: 1
	Txos:
0 41cfba314ec08240c9e93cc48a1059db4331fdd59516cecaf605f6b51829a54b:0 h:1083882 amt:495000 /44'/0'/30'/1'/1'
	Addresses:
0 H5qcfNinP29CEeXWV9H54dszzPKzqEhs9nZ2c (mtiV1YhdA8As7V11SupiTunU7h14u1Ezmc)
	Utxo: 495000 Conf:495000 Channel: 500000
Sync Height 1083883

Usage of -tip not provided but used to explain reSync

Cryptokernel support

Cross-chain swaps

Attempt to reconnect to the backend coind if it disconnects

Push command error: peer 1 does not have channel 1

Any suggestions to why this error is occuring? If I enter "push 1 50000" in lit-af, the following is returned, "Push error: peer 1 doesn't have channel 1"

Here is 'ls' info from node A.

ls
entered command: ls
Peers:
1 127.0.0.1:50148
Channels:
Channel 1 (peer 1) type 1 00ad8f71a47dabbe6c9e6893aece37c4539a31e95a06933fed894f3ea3f81ed8;0
cap: 1000000 bal: 1000000 h: -1 state: 0
Txos:
0 b3a09eb80ee7bf286b579d18dd3c2ee6a3ccfc9395788ecf71d3f1e9df4a1a33;0 h:1255786 amt:229983999 /44'/1'/0'/0'/0' testnet3
Listening Ports:
Listening for connections on port(s) [:2448] with key ln1dle4yvnuxwyz4tlesvmlrueu6ttfuzsq6k0mra
Addresses:
0 tb1qjtnrurhn5pgt8hgsqw82jlsgl0htjmpmag733l (mtugmasNhzGAwpuaRZYA8KVgqtHQaYQAyS)
1 tb1qzks0fl434c2a42365cga0j388tlhdm6rvfmfj2 (mhVKJa7LcdvTVoNYLaPsNRiGCTtQ9fF7tD)
2 tb1ql0022d7w9mw99q85jcv0ct9t53p7jf550pnt8c (n4Uicskd68tQSCCZp5MEi5Sa2cmo5YnpfZ)
Type: 1 Sync Height: 1255844 FeeRate: 80 Utxo: 229983999 WitConf: 229983999 Channel: 1000000

Testnet seed connects to Bitcoin cash node

Something very weird happened when connecting to Peter Todd's testnet seed at testnet-seed.bitcoin.petertodd.org:

2018/01/04 17:14:33.014980 DB height 1257406
2018/01/04 17:14:33.015010 DB height 1257406
2018/01/04 17:14:33.015041 opened header file /root/.lit/testnet3/header.bin
2018/01/04 17:14:33.015050 Attempting connection based on DNS seed
2018/01/04 17:14:33.046706 Got 38 IPs from DNS seed testnet-seed.bitcoin.petertodd.org
2018/01/04 17:14:33.046826 Attempting connection to node at 64.52.84.86:18333
2018/01/04 17:14:33.255641 wrote 134 byte version message to 64.52.84.86:18333
2018/01/04 17:14:33.462726 got 137 byte response 7f1101002500000000000000a1134e5a00000000000000000000000000000000000000000000ffff31ce73462e812500000000000000000000000000000000000000000000000000af289037bf2824771b2f426974636f696e204142433a302e31362e31284542382e30292f5f51120001
 command: version
2018/01/04 17:14:33.462798 connected to /Bitcoin ABC:0.16.1(EB8.0)/
2018/01/04 17:14:33.462837 remote reports version 1117f (dec 70015)
2018/01/04 17:14:33.462985 got header tip height 1257406
2018/01/04 17:14:33.463209 Got verack.  Whatever.
2018/01/04 17:14:33.463304 Got unknown message type alert
2018/01/04 17:14:33.463569 get headers message has 19 header hashes, first one is 0000000000000168ae0daf3966778af563af35440f0f4de39cfe53d0caa94868
2018/01/04 17:14:33.726934 Got unknown message type sendheaders
2018/01/04 17:14:33.727227 got 1 addresses.
2018/01/04 17:14:34.377146 got 2000 headers. Range:
00000000000a3abd905d7ff94fdf9eb754f1b8587b4892937f9b88a3089621ab - 000000000003cfc8793011c3c96af8962c5a7bfba9c1e36d64ba6ce5ebcac151
2018/01/04 17:14:34.393777 header file position: 18017120
2018/01/04 17:14:34.393840 made 2017 header slice
2018/01/04 17:14:34.412326 Header 00000000000a3abd905d7ff94fdf9eb754f1b8587b4892937f9b88a3089621ab attaches at height 1032192
2018/01/04 17:14:34.412396 Header error: reorg message up to height 1034192, but have up to 1257406
2018/01/04 17:14:34.412416 blockTip to 1257406 headerTip 1257406
2018/01/04 17:14:34.412424 no blocks to request, entering wait state

This issue might be a good chance to add a couple more testnet seeds from Core (even Peter's seed has changed URLs)

When using powless, the counterparty cannot push

Since the channel open tx never confirms for the counterparty (h stays at -1), the counterparty is unable to push using the channel, receiving the message:

push 2 5000
entered command: push 2 5000
push error: height -1; must wait min 1 conf for non-test coin

Often channel fund and push commands will fail non-recoverably

This happens irrespective of the cointype or sync method. Issuing a fund or a push command hangs with the only way to recover to quit lit-af. Upon reopening lit-af, a failed push renders the channel unusable due to the channel being marked as busy. Upon restarting lit, if connected to the peer a close command will hang and a break command will fail with the message nil elkrem receiver.

If both lit nodes are restarted the channel can be recovered, but the first push results in:

push error: Didn't send.  Recovered though, so try again!

On the counterparty side, the following log entry occurs:

decrypted message is 304f6e00295d2833cd9027a6a1aa44014322306559c5585aac8c1399d3cb74a95c00000000000186a0093ae18c7762332ea96a0d9fcd8a22ac62734ce150d3b44f0a28cd840162f65b7aba3beb243c7ceb76f016ad2359a5d57f4502bb3a971358b998d80094dbc91a
peerIdx is 4
routed bytes 304f6e00295d2833cd9027a6a1aa44014322306559c5585aac8c1399d3cb74a95c00000000000186a0093ae18c7762332ea96a0d9fcd8a22ac62734ce150d3b44f0a28cd840162f65b7aba3beb243c7ceb76f016ad2359a5d57f4502bb3a971358b998d80094dbc91a
message type 30
chanIdx is 4
Got DELTASIG from 4
COLLISION is (%!s(bool=true))
delta sig COLLISION (100000)
> made SH script, state 3
         revPub 03f0099b998d017d5c3c4c0a7632c8b517473789c2d781169dba812296aa797e5f timeout pub 02b89450fc31ab5b3932e33e1eceb6e23d3c83c20404cbd833a8a16ec6a5b82012
         script 632103f0099b998d017d5c3c4c0a7632c8b517473789c2d781169dba812296aa797e5f6755b2752102b89450fc31ab5b3932e33e1eceb6e23d3c83c20404cbd833a8a16ec6a5b8201268ac         scripthash 00204a39eae564369cbc834a0738de4aed581f3529eac7bce15b87b10bb58c48b395
        combined refund 038cd2b6f8941e4fe4e816618977a42256fa58395536f614bd818cfb57ef9abf86, pkh 0014a0b23c103dfa25893642de5c4fa125aaab3aaa72
____ sig verification for channel (4,4):
        input 5ca974cbd399138cac5a58c559653022430144aaa1a62790cd33285d29006e4f;0
        output 0: 0014a0b23c103dfa25893642de5c4fa125aaab3aaa72 14100000
        output 1: 00204a39eae564369cbc834a0738de4aed581f3529eac7bce15b87b10bb58c48b395 14300000
        state 3 myamt: 15100000 theiramt: 14900000
        sig: 093ae18c7762332ea96a0d9fcd8a22ac62734ce150d3b44f0a28cd840162f65b7aba3beb243c7ceb76f016ad2359a5d57f4502bb3a971358b998d80094dbc91a
PeerHandler error with 4: DeltaSigHandler err Invalid signature on chan 4 state 3

I will fill in the issue as I gather more information.

node_id format and iterop with other LN implementations

It seems that the node_id format used by lit is not compatible with the format used by other LN implementations (lnd and c-lightning for instance).
The pubkey is bech32 encoded in lit but hex encoded in other implementations.
Is a PR to change the node_id format is relevant ?

Lit as a full node (utreexo?)

Tracker needs to provide IPv4 and IPv6 addresses so IPv4 only doesn't try to connect to the IPv6 address

Add multiple peers for LN node

Currently in the LnNode struct, there is one connection to a remote node, RemoteCon *lndc.LNDConn. The comment on that line is // make a bunch of em later, which is needed.

It's not too complex in that incoming messages are already somewhat routed, and currently a listening node can have multiple incoming connections. (There's probably bugs related to this as it hasn't been tested). Multiple outgoing connections aren't supported yet.

Once multiple outgoing connections are supported, some commands will need an additional argument of which peer to interact with. "Fund" and "say" currently have an implicit counterparty (the only one you can connect to right now). Other channel commands such as "push" and "break" have the counterparty explicitly specified.

Add multiple peers for SPV

Currently SPVCon has con, a single net.Conn to a bitcoin full node.

It'd be better to have connections to multiple nodes in case some go down or omit data. Making it into a slice of net.Conns with some logic to send messages to different nodes should be doable.

Also maintaining an IP address listing of full nodes, populated by getaddrs messages from other nodes. And / or DNS seeds.

Test framework improvements

Once #60 is merged, we'll have a decent integration test framework that we can work on in parallel. Most of the test framework infrastructure has been separated from the test logic, so there's quite a large surface that we can work on without stepping on each others' toes. If anyone is interested in working on the tests, here's a grab bag of things that we could do:

• #63 Refactor the LitNode class into its own module. Individual test cases can then subclass LitNode and override the run_test() method with their own test logic
• #72 Actually test litecoin. I've added the framework for testing litecoin in bcnode.py, but haven't yet added test logic to do that
• #64 Copy combine_logs.py from the bitcoin repo. This combines logs from bitcoind and the test framework to give a total overview of what's happening in the test case. It'd be really useful to enhance this so it can ingest lit and litecoin logs as well, so we can see everything that's happening in the test case.
• #68 Use python logging instead of print() - see bitcoin/bitcoin#9768 for an example of how to do this
• Add lots of individual test cases:
  • #65 opening/closing channels (cooperatively and uncooperatively)
  • #65 sending payments between nodes
  • #77 breaking a channel
  • transmitting an old channel state (justice!)
  • reorgs (not yet implemented)
  • multi-hop (not yet implemented)
  • multi-chain wallit with channels on each chain
  • atomic crosschain swaps (not yet implemented)
• Add interface to uspv from test_framework, so we can send P2P messages directly into lit instead of via a bitcoind node. That would allow us to test more edge cases.

We should also:

• Integrate with coveralls so we can see code coverage
• write more unit tests

@vinchang2015 you mentioned you wanted to help with this. Let me know if you want to grab any of these tasks. I'm happy to give pointers/review code.

Forwarding between channels using HTLCs

Change API provider for powless

Not that big of a concern, but looks like blockexplorer.com will refer to bitcoin as "Bitcoin Legacy" (ref: https://blockexplorer.com/news/blockexplorer-support-bitcoin-cash-bitcoin-legacy/) and Bitcoin Cash as "Bitcoin" in the near future. There isn't a testnet yet for Bitcoin Cash afaik, but in the case it does come out, we should expect something similar.

SPV re-counting already spent outputs

This seems reproducible and I have an idea where to look for the bug.

Have 1 utxo in your wallet (utxo A), confirmed. Call "send" and send some portion to some other address.

Now you have utxo B, h:0. Call send again.

You now have a smaller uxto C, h:0.

Wait for a block to come in.

The wallet will display utxo B again, as confirmed. It keeps utxo C as h:0, unconfirmed, and it'll appear as confirmed.

Forwarding between channels using HTLCs

Given a list of channel outpoints, or other reasonable network known route, forward a payment between them.

Exchanging DLC signatures might take long, causing RPC timeout

When issuing the dlc contract accept command, for contracts with many possible outcomes (i tried with a contract ranging 10000-20000 with increments of 1), the exchanging of signatures works, provided you have the bigmsg merge in place, but it takes quite a while. So the RPC call times out.

I think we could fix this by moving the signing to a go routine, and returning the RPC call once we initiated that.

libp2p project from the hackathon

Hi all,

On the spreadsheet listing projects for the L2 hackathon, I saw a suggestion of trying out libp2p for the p2p communication for lit. Also, on the road map (#30), I saw a mention of NAT traversal and hole punching.

I wonder if there is any interest in this as importing libp2p goes against the "not invented here" syndrome pointed to in the contributions guidelines.

• libp2p support a wide range of transports, so that might, or might not be handy.

• libp2p does NAT traversal as best it could, I guess

• For p2p encrypted connections, we could use the secio module from libp2p:
  https://github.com/libp2p/go-libp2p-secio

• Finally, we tap into the wider community supporting the p2p layer for lit

Thoughts on trying libp2p, as an experiment?

Pruned node

Hello,

does lit work with pruned node?

All the other three lightning implementations require non-pruned node.

channels don't show as closed

using the close command doesn't register the channel as closed in the UI until a block comes in confirming the close tx

Mutex Lock Correctness

There is a mutex lock in the function: func (nd *LitNode) FundChannel(peerIdx uint32, ccap, initSend int64) (uint32, error) in .../qln/fund.go. That lock doesn't seem to get cleared if any portion of code below it errors.

That seems bad and could easily peek up in other places throughout the code.

Sync blocks from tip height

--reSync is a remnant of the old -tip flag that used to exist before 7e1463a. We should bring back tip in case someone finds a use for it.

uspv and watchtower on startup

watchtower doesn't need to do anything if there are no addresses to watch on fresh startup -->

uspv model shouldn't hand anything to the watchtower if the watchtower hasn't registered with it.

Funding a channel: what are the coinType arguments?

I have two nodes running, and connected on one PC. I cannot, however, get a channel open using the fund command. It seems that I am missing the coinType parameter for opening a channel.

Multi-hop routing

Reconnect to other lit node automatically on startup and if we lose connection to them

Funding tx fails

Even though both parties have funds, while trying to fund a transaction (say with capacity 1million and initial fund of 180000), the broadcasting part keeps trying to send messages ( e.g. type 70 95 bytes to peer 1) but the other party can't seem to receive any other message other than the initial decrypted message is xyz . On closing the channel doesn't appear on the channel history, unlike the other issue. Will investigate further and update this thread.

pubhash?

Trying to open a channel to my lit node from the Eclair Android App. I need a pubhash for that. "lit-af ls" shows a key like this: ln1m9yyruaprzllm8k2j450597nq4paf6vzx9qrx7

However, Eclair requires a key in this format: 021a2522abf01d932c11b2ed745319a7900ff513dbdff50272ab517eebe3554a7d

Is there a way to convert from one to the other? Or am I doing it wrong?

Roadmap

Stuff to work on, and who, if anyone, is working on it.

Some of these are "nice to haves", some are more like requirements.

Note that the checkbox doesn't indicate "complete" but instead "assigned"; if checked, some people are working on it on a branch.

Once people are working on the task, we can make a github issue specific to that task and detail implementation there.

• Message concurrency

The channel message handling currently does deal with message collisions and invalid messages, but often gives up and leaves channels in an unusable state. This can be improved and recover from more invalid messages in both the funding and the push/pull sequence.

• WebUI
  https://github.com/Firescar96/lit/tree/lit-bamf
  Have lit listen on port 8080 or so, and when you go to http://127.0.0.1:8080, a web UI opens up which lets you control lit. Like lit-af, but maybe with less info, and you can use a mouse to click.

• Hole punching

The internet is kindof broken and most home users are behind NAT, and so can't connect to each other directly. One way to try to get computers to talk to each other is called "hole punching". That would be nice to have for lit data connections.

• Integration Tests

Right now, a lot of testing is manual, which results in human employement and idle CPU cores. A comprehensive integration test setup would reverse that, as well as offer better assurance as to the functionality of the software.

Probably could be done in python or go.

Steps:

• Compile lit

• Activate a bitcoind regtest node with no previous state

• Mine a few hundred blocks to activate everything

• Start 2 instances of the compiled lit binary, with different home folders

• Get addresses from both lits over RPC, and send some money to both
  (note that currently wallit does not support coinbase tx outputs: doesn't know about maturity requirement, and won't see P2PK)

• Fan, sweep, send, some money around between nodes

• Have lit1 connect to lit2

• Have lit1 make a channel with lit2, and vice versa

• Send a bunch of payments

• Close channels, cooperatively, uncooperatively, and incorrectly; make sure justice txs work

• Txids of this process are non-deterministic, but final balaces and number of utxos should be.

• Chat

The "say" command was there just to test network connectivity, but chat is popular. Adding better chat features like rooms, saving chat logs, (maybe file transfer?) would make this more fun and usable.

• MultiParam HTLC

the litNode:wallit:uspv structure allows for a single litNode to control multiple wallits with different parameters (eg testnet3, regtest). It'd be cool to be able to trade between testnet coins.

(As long as you only trade between valueless testnet coins, this trading is probably in keeping with the testnet prime directive. If test networks have persistent exchange rates against each other, but maintain zero values with respect to main networks, then it's kindof like extending the real number line into the complex plane, and maybe we can make a testnet/mainnet mandelbrot plot or something.)

This would require HTLC handling, but routing is greatly simplified as there are 2 hops, and the source of the HTLC is also the destination. Complexity shouldn't be much worse than currently implemented 1:1 payments.

• Stronger USPV

• Deal with reorgs. This will probably require changing upstread wallit code and interfaces

• Add in DNS seed lookups for initial connect? Or have a list of hardcoded nodes

• One USPV hook should be able to connect to multiple full nodes

• Ask remote nodes about other remote nodes (getaddrs) and store that list

• Ban nodes if they are doing something annoying, including being slower than other nodes

• Full graph routing and onion HTLC handling

Kindof complex and long term

• Broadcast / propagate / store channel construction messages

• Given utxo set and construction messages, build full LN graph

• Onion routing, blaming, fees, HTLC recovery

• Logging

https://github.com/jsphkn/lit/tree/logs

Add more fine grained logging to files instead of printing everything to stdout.

• RPC authentication

Currently the RPC listener doesn't authenticate at all and allows any commands to run. Also by default it listens on 0.0.0.0. This is dangerous as anyone could connect in and control your lit node. We could just set it to only listen on 127.0.0.1, and tell people to ssh port forward. Better would be some type of authentication via RPC.

New Coin Selection Algorithm

Well, I went deep into a rabbit hole while looking at Core's algorithm, so here's what I found:

There are four major algorithms used by various implementations:

1. Highest Priority first (bitcoinj)
2. Oldest first (Electrum)
3. Pruned Oldest First (Mycelium)
4. Target sized Change (Electrum)

Core, is however a bit more complex system which either tries for an exact match, falls back to a knapsack problem and then worst case, there's the const change one with 0.01 btc as const change.

Core is looking at migrating to a better algorithm detailed over at bitcoin/bitcoin#10637 (overkill at the moment).

I'm guessing that any one of the first four would be sufficient for our use case right now. I'll look more into this and put in a PR for the most appropriate one.

Windows running lit with -tn3 throws unknown flag errors

After building the project, running lit.ext -tn3 myfullnode.net throws the following error

Error while creating a directory
unknown flag `n'
unknown flag `n'
2017/10/24 12:11:19 unknown flag `n'

Is this the right way to run it or am I missing something in the documentation? Digging a little into the code I realize that -n is not available as a possible flag, am I looking in the wrong place? https://github.com/mit-dci/lit/blob/master/lit.go#L23-L42

Fixing Travis Builds

From my analysis of what Travis is doing, it seems that it randomly prints out different sets of output for the same commit. The initial error was with travis.yml itself (pip3 install needs sudo apparently) and then onwards, the build gets stuck at this piece of code:

assert litnode0_channel['MyBalance'] == 950000000
assert litnode1_channel['MyBalance'] == 50000000

Secondly, changing the wait time over at

wait_until(lambda: abs(self.litnodes[1].get_balance(self.coins[0]['code'])['TxoTotal'] - 50000000) < self.coins[0]["feerate"] * 2000)

affects the aforementioned assert statements and reverting to the previous commits in which the assert statement wasn't changed doesn't seem to work. The builds are over at https://travis-ci.org/Varunram/lit (there might be a few silly builds, apologies in advance). I'll update this thread if I find something new, although I believe that it isn't a problem on our side.

Fee Estimates stuck in a loop

So I was trying out a couple transactions and i noticed that for some weird amount (in my case 33333 sat among others) it seemed to get stuck between two estimated fees until I stopped the node. Log attached below.

2017/11/23 17:53:55.415097 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.415192 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.415281 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.415428 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.415507 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.415575 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.415656 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.415737 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.415957 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416036 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416102 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416165 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416232 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416294 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416357 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416419 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416482 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416542 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416605 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416668 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416731 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416788 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416852 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.416913 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.416976 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.417039 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.417101 80 spB, est vsize 202, fee 16160
2017/11/23 17:53:55.417164 80 spB, est vsize 268, fee 21440
2017/11/23 17:53:55.417226 80 spB, est vsize 202, fee 16160

(continues for like 1500 lines after which I had to shut the node down)
We could have a counter attached that can be used to exit the loop after trying to find a set of utxos (1000 maybe?) so that we aren't left waiting. I'll make a PR for this after I'm done with the RBF stuff :)

Clean up GetCloseTxos()

The GetCloseTxos() method for a Qchan is a bit long and redundant. It actually doesn't bother me too much but it could be split up into functions. It does the same thing 3 times. Not quite the same but close enough that you could probably turn it into a function and reduce LoC.

utxos not showing up at address 0

With a new wallet, wallet doesn't recognize utxos sent to adr 0
May only happen with segwit txs