This commit adds glide integration in order to make lnd builds fully
reproducible. Rather than using “go get” users should now manually pull down
the repo, use glide to fetch+install the dependancies, then manually install
all related binaries.
With this change we no longer have to chase dependancies making breaking API
changes under us. We can manually update the managed dependancies once a new
stable release of a defendant package is released.
Additionally, reproducible builds are a strong requirement in order to securely
distribute future major releases of lnd.
This commit finishes the initial draft of the commitment state machine.
A full re-write of the prior protocol which combines aspects of the
former ‘lnstate’ package has replaced the prior un-finished
stop-and-wait protocol.
This new protocol is designed to operate in an asynchronous environment
and to facilitate non-blocking batched and pipelined updates to the
committed channel states. The protocol is also de-synchronized meaning
that either side can propose new commitment states independent of the
actions of the other party.
The state machine implemented is very similar to that of c-lightning,
however we allow multiple unrevoked commentates in order to minimize
blocking, and also to reduce latency across several hops in a
bi-directional setting.
The current implementation consists of 3 main data structures: a
commitment chain which consist of unrevoked commitment transactions
(one for each side), and a (mostly) append-only log of HTLC updates
shared between both sides. New commitments proposed index into the log
denoting which updates they include, this allows both parties to
progress chains independent of one another. Revoked commitments, reduce
the length of the chain by one, and free up space within the revocation
window.
At this point only basic tests are in place for the state machine,
however more extensive testing infrastructure along with formal proofs
using PlusCall are planned.
This update the wallet to implement the new single funder workflow
which uses revocation keys rather than revocation hashes for the
commitment transactions.
This unifies some inconstancies across the code-base with hashes being
32 vs 20 bytes. All hashes, whether payment or revocation are now
uniformly 32 bytes everywhere. As a result, only OP_SHA256 will be used
within commitment and HTLC scripts. The rationale for using sha256
instead of hash160 for the HTLC payment pre-image is that alternative
chains are more likely to have sha256 implemented, rather than
ripemd160.
A forthcoming commit will update the current commitment, and HTLC
scripts.
This commit adds additional test cases to test both cases (initiator vs
responder) for a single funder channel workflow. Additionally, the
previous dual funder tests have been extended in order to detect proper
funding channel broadcast, and the ChainNotifier’s role in notifying
upstream callers that a funding transaction has been embedded in the
chain at a sufficient depth.
At this point the tests certainly need to be cleaned up. bobNode should
be replaced with a second instance of the wallet modeling a remote
peer.
Only nested p2sh or pure witness outputs are used when selecting coins
for inputs to a funding transaction.
The funding transaction output now uses p2wsh rather than regular p2sh.
All tests have been updated accordingly.
* Previously, if the call to SetUp(..) returned an error, then the test
harness would fail to stop the running bcd process, and clean up the
test directories. This would cause any subsequent tests to fail. This
commit remedies this scenario.
Instead of creating “fake” utxos for bob, and alice. We now employ a
dedicated mining node to hand out utxos, and generate blocks with hand
picked transactions.
* As a result in order to not over-shadow the Start/Stop methods of
btcwallet.Wallet, the Start/Stop methods on LightningWallet have been
renamed to Startup/Shutdown.
* Initial draft of brain dump of chandler. Nothing yet set in stone.
* Will most likely move the storage of all structs to a more “column”
oriented approach. Such that, small updates like incrementing the total
satoshi sent don’t result in the entire struct being serialized and
written.
* Some skeleton structs for other possible data we might want to store
are also included.
* Seem valuable to record as much data as possible for record keeping,
visualization, debugging, etc. Will need to set up a time+space+dirty
cache to ensure performance isn’t impacted too much.
