The dcrlnd from decred

restorechanbackup requires peer to be connected

[ERR] RPCS: [/lnrpc.Lightning/RestoreChannelBackups]: unable to unpack chan backup: unable to connect to peer for SCB restore

Let `dcrwallet.grpchost` be used without port

Ideally it should detect the network and use the default grpc port of the wallet for that network.

Implement CreateSimpleTx

See disabled test here: https://github.com/decred/dcrlnd/blob/v0.2.0-rc2/lnwallet/interface_test.go#L2601-L2602

Currently createSimpleTx is only used by the estimateFee rpcserver call which ordinarily isn't used by users.

Hitting unused Address gap limit

Background

Through just normal usage, I have hit dcrlnwallet's gap limit, but not sure how to remove that limitation to open new channels or close existing channels.

Your environment

Version of dcrlnd.
0.3.7
Which operating system (uname -a on *Nix).
Fedora 34
Version of dcrd or other backend.
1.7.5
Any other relevant environment details.

Steps to reproduce

Not sure exactly how to reproduce, but basically just normal usage. Created some deposit addresses, opened and closed some channels. But now whenever I attempt to do any of that I get the gap limit error.

Create v0.3.0 release

README links to installation instructions and those link to releases page, and that has the latest proper release for v0.2.1 while the latest is v0.3.0.

I don't know how people commonly install dcrlnd but if there's a chance they use the Releases page, it might help them to navigate faster if they see a proper GH release.

As discussed in #dev around Jan 25 during the release days, maintaining GH releases involves extra not fun work of manually preparing the markdown release notes (because Release pages use a different Markdown renderer, for whatever reason). If that is too much effort, at least linking to v0.3 release notes would still be an improvement in navigation.

Verify chainntfs in case of disapproved blocks

The upstream chainntf package doesn't care about transactions that were reversed due to being in disapproved blocks, due to this mechanic not existing in bitcoin.

Generally we need to verify that the chainnfs package is behaving correctly when disapproved blocks are encountered. And more specifically:

Ensure no < 2-conf spend/confirm notifications are requested in ordinary usage;
Ensure that txs that trigger the start of a spend/confirm notification callback and are later found to be disapproved stop/reset the notification callback timer appropriately.

Remove all non Decred code from config.go

Originally at

davecgh#1

Lightning Network-based SaaS platform apps for enterprise?

Issue? We need to keep up with Bitcoin's steps into adoption.
Centralized money is pushing it onto enterprise. Now it's Lightning will be getting SaaS support it seems.
https://twitter.com/saylor/status/1575922586307133441

I don't know about others but I just wanted to say, I would vote Yes for a heavily funded proposal that got our Lightning to also have a suite of apps for enterprise like Microstrategy is getting on SaaS.

Just saying.

Update Docker-related files

Ideally used the original decred backed ones.

Original items from davecgh#1

Rename docker/lnd to docker/dcrlnd and update
Either rename docker/btcd to docker/dcrd or use existing dcrd docker repository
Update docker/docker-compose.yml for dcrd, dcrctl, dcrlnd, dcrlncli, etc
Update docker/README.md for Decred

Remove `--mainnet`: it should be the default network

This is to keep dcrlnd in line with other decred tools where by default mainnet is used unless --testnet or --simnet is specified.

Dependency cycle causing shutdown deadlock

Sub-systems are shutdown concurrently:

dcrlnd/server.go

Line 1411 in 2975978

s.chanStatusMgr.Stop()

However there's interdependency between them. Specifically, chanRouter depends on the current cc.chainViewinstance but calls to GetBlock might block indefinitely until the chainView is called to stop.

One situation where this is manifested is on the garbage_collect_link_nodes itest where a channel is opened between Alice and Dave and immediately after that Bob and Carol are restarted. It might be the case that Bob (or Carol) is in the middle of a GetBlock() call and on the remotewallet implementation that cashes out to a loop that is only returned from once the wallet is told to shutdown. But that only happens later in the server shutdown routine, so the wallet shutdown deadlocks.

Currently this is solved in the itest with a dummy Sleep call but ideally this should be solved either by performing subsystem shutdown in parallel (so that the wallet shutting down bubbles up an error to chanRouter) or by requiring the chainView methods to accept a context parameter, so that the caller itself can cancel them.

dcrlncli - code review

With this PR on dcrdocs to include dcrlncli commands, we found various typo error and lack of explain. Then I decided to create a to-do list for code review each command to fix it and enjoy the time to analyze the code and make some improvements.

data race: seen in CI output

=== RUN   TestLightningWallet/dcrwallet/dcrd:signed_with_tweaked_pubkeys
=== RUN   TestLightningWallet/dcrwallet/dcrd:test_cancel_non-existent_reservation
=== RUN   TestLightningWallet/dcrwallet/dcrd:last_unused_addr
==================
WARNING: DATA RACE
Write at 0x0000021c24d0 by goroutine 79:
  github.com/decred/dcrlnd/lnwallet_test.TestLightningWallet()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/dcrwallet/log.go:32 +0x471
  testing.tRunner()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:909 +0x199

Previous read at 0x0000021c24d0 by goroutine 115:
  github.com/decred/dcrlnd/lnwallet/dcrwallet.(*RPCSyncer).start.func1()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/dcrwallet/rpcsync.go:59 +0x1d2

Goroutine 79 (running) created at:
  testing.(*T).Run()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:960 +0x651
  testing.runTests.func1()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:1202 +0xa6
  testing.tRunner()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:909 +0x199
  testing.runTests()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:1200 +0x521
  testing.(*M).Run()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:1117 +0x2ff
  main.main()
      _testmain.go:168 +0x223

Previous read at 0x0000021c24d0 by goroutine 115:
  github.com/decred/dcrlnd/lnwallet/dcrwallet.(*RPCSyncer).start.func1()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/dcrwallet/rpcsync.go:59 +0x1d2
Goroutine 115 (finished) created at:
  github.com/decred/dcrlnd/lnwallet/dcrwallet.(*RPCSyncer).start()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/dcrwallet/rpcsync.go:52 +0x526
  github.com/decred/dcrlnd/lnwallet/dcrwallet.(*DcrWallet).Start()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/dcrwallet/wallet.go:151 +0x13f
  github.com/decred/dcrlnd/lnwallet.(*LightningWallet).Startup()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/wallet.go:314 +0x86
  github.com/decred/dcrlnd/lnwallet_test.createTestWallet()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/interface_test.go:367 +0x4ba
  github.com/decred/dcrlnd/lnwallet_test.runTests()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/interface_test.go:3046 +0x13b5
  github.com/decred/dcrlnd/lnwallet_test.TestLightningWallet()
      /home/runner/work/dcrlnd/dcrlnd/lnwallet/interface_test.go:2823 +0x1345
  testing.tRunner()
      /opt/hostedtoolcache/go/1.13.4/x64/src/testing/testing.go:909 +0x199
==================

Don't rely on the wallet for off-chain keys

Currently, the keychain package (responsible for generating public and private keys used throughout the ln processes) is implemented by generating accounts and addresses directly in the underlying wallet.

This has the following drawbacks:

Forces the creation of several accounts that might become visible for other wallet software
If using alongside a regular wallet, accounts might get a lot of generated addresses built for them without ever seeing a transaction
The vast majority of these addresses (pretty much all of them) are never published on chain
Most of the keys/addresses are further tweaked before being used in the ln processes (meaning the current wallet software cannot even in principle know about them)
Most of the keys/addresses are used in scripts the wallet doesn't understand and therefore is unable to use for anything
The wallet ends up tracking this enormous amount of addresses that are essentially useless (for its regular onchain operation) with associated memory and processing consequences

In the upstream lnd, this was solved by using a separate HD branch with a different purpose value and implementing a mechanism in the underlying btcwallet (KeyScope) to allow usage of branches with a purpose other than the default 44'.

While some feature to allow different purpose branches isn't available in dcrwallet, an alternative approach is to use a single account masterpub to derive all dcrlnd-specific keys. Done correctly, this can ease switching to a different root purpose key in the future.

This means dcrlnd will have to track the indexes of used keys itself instead of relying on the underlying wallet, but this seems reasonable given that pretty much all the functionality associated with addresses and accounts is useless for the off-chain side anyway.

checkCanSendPayments needs to ignore negative chans

when one of the channels in checkCanSendPayments has no local capacity because it's an inbound channel, the reserve makes the max outbound amount negative

this is wrong and needs to be fixed

RPC doesn't start if blocks are not being generated

Testnet had not seen a block for 5+ hours, and it caused some odd behaviour.

After unlocking the wallet, dcrlnd stopped listening on port 10009 and performed it's startup activities. It then logged the following:

2019-04-26 11:49:13.040 [INF] DCRW: Blockchain sync completed, wallet ready for general usage.

It seems like everything is ready, and at this point I would expect the RPC to be available on port 10009. However there is nothing listening on the port, and any usage of dcrlncli results in connection errors.

After speaking with @matheusd it seems that this is because dcrlnd only starts the RPC server after the wallet considers itself synced, and it won't consider itself synced if it hasn't seen a block for 2 hours. We should alter the logging so that instead of incorrectly saying the wallet is ready for usage, we inform the user that the wallet is not synced and thus the RPC is not available.

(Running commit 22a6961)

Pass correct ValueIn of funding tx input in commitment tx

The local (initiator) node is not passing the correct value in here:

dcrlnd/lnwallet/wallet.go

Line 929 in 2975978

PreviousOutPoint: *chanPoint,

This will change in the upcoming #99 PR so hold off fixing until that is merged.

dcrlncli - code review

With this PR on dcrdocs to include dcrlncli commands, we found various typo error and lack of explain. Then I decided to create a to-do list for code review each command to fix it and enjoy the time to analize the code and make some improvements.

asdasd
[ ]
[ ]
[ ]
[ ]

kw unit used in log line

2019-04-26 12:32:16.161 [INF] FNDG: Target commit tx atom/kw for pendingID(ad7f8b7f75ccd187f40428f309ddc513d7ea64ad909785c40e999670f8014b71): 10000

Should be updated to use b or kb

Fix scriptversion TODOs

https://github.com/decred/dcrlnd/blob/v0.2.0-rc2/lnwallet/interface.go#L72
and
https://github.com/decred/dcrlnd/blob/v0.2.0-rc2/rpcserver.go#L870

The wallet doesn't currently return the script version and versions other than 0 aren't defined yet, so this doesn't have a lot of priority.

edge not found

[ERR] NANN: Unable to retrieve chan status for Channel(txid:X): edge not found
We need to figure out a way to detect this specific case (remote end disconnected and never completed the ann after channel funding) vs other potential causes though (e.g. db corruption or some
other race condition)

Check account vs db id during unlock

When using the remotedcrwallet driver, during the driver initialization it ensures the account being used is the same one as the previously used ones (specifically, here).

This check could (also) be done during the wallet unlock call of the WalletUnlocker service so that an error is synchronously returned to callers instead of waiting for the driver to start the init phanse and casuse the dcrlnd process to exit.

This would improve the UX in decrediton where we could capture this error more easily and present a better message than just time out connecting to dcrlnd

Update all CLI flags to remove the namespacing

Originally at davecgh#1

Report progress during rescan on wallet startup

Starting up an old wallet causes a rescan of the chain to verify whether channels were closed. On slow nodes this ends up causing a delay to startup the services without any progress indication on standard logging levels or on decrediton.

Ideally this should be exposed in logs and/or via some rpc to improve feedback in such situations.

SPV Support

Issue to track the changes needed for SPV support

cfilterV2/blockcf2 support in dcrwallet (decred/dcrwallet#1648)
Create a dcrwalletnotify driver for chainntnfs such that it can use cfiltersV2 to perform the chain watching capabilities (fulfill the chainntnfs.ChainNotifier interface)
- Create chainscan that uses cfiltersv2 to scan for confirmation/spends (#83)
- Possibly work in solution for #69
- Create appropriate APIs in the wallet to allow fetching cfiltersV2 and blocks in embedded and remote wallet modes (decred/dcrwallet#1705)
Use dcrwalletnotify even in RPC mode (blockheader committed filters allow that without loss of security - assumes dcp0005 passes); this allows unifying into a single code path independent of the node's mode of operation (rpc/spv) (#92, #93)
Create an WalletChainIO to fulfill lnwallet.BlockChainIO interface
- (only GetUtxo() is potentially faster in rpc mode vs spv so for the most part deprecate RPChainIO and use WalletChainIO even in rpc mode (#94)
Test SPV mode when running in remote wallet mode (#95)
Add SPV mode for embedded wallet mode (#140)

doc: create an method to automatically create/update the docs

update static docs
create an method to automatically generate the docs

Add piperx/pipetx

Similar to dcrwallet.

piperx is used to shutdown the daemon when the wallet is closed and pipetx allows binding the rpc server in a random port and informing the caller of this port, which in turn allows multiple dcrlnd instances running in the same machine.

Choose unique default Ports for dcrlnd

Background

DCRLND and BTC LND currently assign the same ports in the default configuration. This leads to conflicts when both DCR and BTC Lightning are running on the same machine and requires manual configuration to run both daemons in parallel.

Steps to reproduce

Run LND and DRCLND in the default configuration on the same machine. Tested with IPv4, i expect the same problem with IPv6 setups.

Expected behaviour

We should choose unique ports for the DCRLND instead of: 8080,9735,10009 for IPv4 and their respective IPv6 ports

Generate gRPC bindings via internal tool

Do this similarly to how dcrwallet currently does, so that different users can generate consistent bindings.

Breach arbiter should watch for spends that invalidate justice tx

When publishing the justice transaction (

dcrlnd/breacharbiter.go

Lines 572 to 573 in 2975978

    
           err = b.cfg.PublishTransaction(finalTx) 
        
           if err != nil {

) if the transaction is successfully published the breach arbiter assumes the transaction will be mined.

However it might be the case that one of the inputs gets double spent making the justice tx invalid. One way this can happen is in SPV mode where the transaction fails to be relayed in time and a different second-level htlc transaction is published.

The breach arbiter should watch for spends of the inputs of the justice transaction and craft a different justice tx even if the original publishing was correct.

Fixing this will allow enabling the "testRevokedCloseRetributionRemoteHodlSecondLevel" test for the SPV backend.

Mention lnd vulns fixed in 0.3.0 release notes

I discovered this tweet and followed to the full disclosure of the two vulnerabilities on Oct 20.

Perhaps they deserve to be mentioned in the list of upstream changes in v0.3.0 release notes.

Pass in ephemeral macaroon via pipetx

This would work somewhat similar to how dcrwallet generates an ephemeral client cert for decrediton use and passes it through the IPC pipe subsystem.

Basically, dcrlnd would always generate an ephemeral admin.macaroon file and instead of writing it to disk, it would pass it via the IPC. This should prevent any other applications in users' computers from performing calls to the running dcrlnd instance.

--txindex

As per previous DM with matheusd:

Pls include documentation on how to get decrediton working with the --txindex in the dcrlnd install.md

Watchtower Improvements

Meta-issue for watchtower improvements

Show sync status against the watchtowers (ideally for each channel)
Add option to prevent advancing channels unless at least n watchtowers have been contacted and received the justice kit
Allow removing watchtowers even when no sessions are running

dcrlncli: remove `-n/--network` switches

Given dcrlncli is only expected to connect to the decred network and to make it use the same convention as other decred tools, it should default to mainnet and only require a --testnet/--simnet switch to connect to a different network.

Config build tags to build subsytems by default

Most subsystems are meant to be built in the final production build but aren't currently due to use of build tags.

Upstream this is solved by producing release builds via make but we don't want to rely on that given our preferred build tool.

So we should switch build tags from positive (e.g. routerrpc) to negative (!routerrpc) so that by default the desired subsystems are included in a release build and you don't need anything other than `go build' to get a full fledged dcrlnd node.

Update `docker/README.md` - currently it leads to an error

Background

I tried to go through docker/README.md today and came across this issue

Your environment

Version of dcrlnd
master
Which operating system (uname -a on *Nix).
linux
Version of dcrd or other backend.
Dockerfile pinned 1.5.1

Steps to reproduce

docker-compose run -d --name alice dcrlnd :

2021-03-07 18:19:19.683 [DBG] DCRW: Starting rpc syncer
2021-03-07 18:19:19.732 [INF] DCRW: Headers synced through block 6bef82c645999585f7255cb02672921ac2f5492820090cd635fe3a59d16b4f87 height 0
2021-03-07 18:19:19.732 [INF] DCRW: Transactions synced through block 6bef82c645999585f7255cb02672921ac2f5492820090cd635fe3a59d16b4f87 height 0
2021-03-07 18:19:19.733 [ERR] DCRW: RPCSyncer error: rpcsyncer.Run:
        dcrd.GetMempoolTSpends: Invalid transaction type: tspend -- supported types: [regular tickets votes revocations all]

Expected behaviour

Maybe the dcrlnd version should be pinned to a tag without TSPEND or the dcrd/dcrwallet Dockerfiles should be updated to 1..6.1. I'm unsure if this should wait until the TSPEND fork happens

Missing protocol in dcrlnd/docs/INSTALL.md instructions: https://

Background

Missing https:// at https://github.com/decred/dcrlnd/blame/master/docs/INSTALL.md#L79

switch to golanci for linting in makefile

Now that we've updated to golangci-lint (#7) for travis usage, the makefile needs to be updated to use it as well, with the same rules so that checking locally is consistent with the travis check.

decred / dcrlnd Goto Github PK

dcrlnd's Introduction

dcrlnd

Lightning Network Daemon

LND Porting Status

Lightning Network Specification Compliance

Developer Resources

Installation

Quick Simnet Network

Docker

Safety

Security

Further reading

dcrlnd's People

Contributors

Stargazers

Watchers

Forkers

dcrlnd's Issues

Background

Your environment

Steps to reproduce

Background

Steps to reproduce

Expected behaviour

Background

Your environment

Steps to reproduce

Expected behaviour

Background

Recommend Projects

Recommend Topics

Recommend Org