integration with bitcoin-spv #4

tamasblummer · 2018-03-05T16:43:15Z

bitcoin-spv now offers an implementation of ChainWatchInterface. Although it is work in progess, it works with a single local peer. Downloads (and stores) headers than serves the above interface.

I added it as a feature as it comes with a lot of dependencies. I want to cut down on those later, but want to get it work before optimizing. Do we really want to rewrite futures, async IO or logging code ?

Unfortunately bitcoin-spv needs a patched version of rust-bitcoin as my trivial PR's are still pending.

Please let me know if useful and what further functions you need on lightning side.
See bitcoin_spv::SPV:new (...) for simple use

… updating master

TheBlueMatt · 2018-03-05T18:11:45Z

I'd rather put things that implement the APIs in a new crate, no? A simple crate which uses tokio for net, bitcoin-spv for Bitcoin implementation, etc should suffice as a "full Bitcoin-lightning usage" without polluting the library itself with deps. Adding stubs which are easily usable by a futures/logging library is easy enough (see current net stuff already), and then letting users call their libraries of choice with one or two-line bindings should be trivial.

tamasblummer · 2018-03-09T15:08:02Z

Closing for now in favor of a later integration project

PaymentFailed events contain an optional NetworkUpdate describing changes to the NetworkGraph as conveyed by a node along a failed payment path according to BOLT lightningdevkit#4. An EventHandler should apply the update to the graph so that future routing decisions can account for it. Provide an EventHandler decorator that updates the NetworkGraph and then delegates Event handling to the decorated EventHandler. Previously, NetGraphMsgHandler::handle_htlc_fail_channel_update implemented this behavior.

# This is the 1st commit message: test utils: refactor fail_payment_along_route for mpp # This is the commit message #2: Add MppId field to HTLCSource as a way to correlate mpp payment paths # This is the commit message #3: Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage # This is the commit message #4: Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits # This is the commit message #5: Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received # This is the commit message #6: Add all_paths_failed field to PaymentFailed see field docs for details # This is the commit message #7: Drop writer size hinting/message vec preallocation In order to avoid significant malloc traffic, messages previously explicitly stated their serialized length allowing for Vec preallocation during the message serialization pipeline. This added some amount of complexity in the serialization code, but did avoid some realloc() calls. Instead, here, we drop all the complexity in favor of a fixed 2KiB buffer for all message serialization. This should not only be simpler with a similar reduction in realloc() traffic, but also may reduce heap fragmentation by allocating identically-sized buffers more often. # This is the commit message #8: [fuzz] Swap mode on most messages to account for TLV suffix # This is the commit message #9: Add forward-compat due serialization variants of HTLCFailureMsg Going forward, all lightning messages have a TLV stream suffix, allowing new fields to be added as needed. In the P2P protocol, messages have an explicit length, so there is no implied length in the TLV stream itself. HTLCFailureMsg enum variants have messages in them, but without a size prefix or any explicit end. Thus, if a HTLCFailureMsg is read as a part of a ChannelManager, with a TLV stream at the end, there is no way to differentiate between the end of the message and the next field(s) in the ChannelManager. Here we add two new variant values for HTLCFailureMsg variants in the read path, allowing us to switch to the new values if/when we add new TLV fields in UpdateFailHTLC or UpdateFailMalformedHTLC so that older versions can still read the new TLV fields. # This is the commit message #10: Convert most P2P msg serialization to a new macro with TLV suffixes The network serialization format for all messages was changed some time ago to include a TLV suffix for all messages, however we never bothered to implement it as there isn't a lot of use validating a TLV stream with nothing to do with it. However, messages are increasingly utilizing the TLV suffix feature, and there are some compatibility concerns with messages written as a part of other structs having their format changed (see previous commit). Thus, here we go ahead and convert most message serialization to a new macro which includes a TLV suffix after a series of fields, simplifying several serialization implementations in the process. # This is the commit message #11: Update docs to specify where process events is called

# This is the 1st commit message: Update fuzz README with latest instructions # This is the commit message #2: Allow multiple monitor_update_failed calls without requiring calls to channel_monitor_updated in between. Found by the fuzzer # This is the commit message #3: Move CounterpartyForwardingInfo from channel to channelmanager CounterpartyForwardingInfo is public (previously exposed with a `pub use`), and used inside of ChannelCounterparty in channelmanager.rs. However, it is defined in channel.rs, away from where it is used. This would be fine, except that the bindings generator is somewhat confused by this - it doesn't currently support interpreting `pub use` as a struct to expose, instead ignoring it. Fixes lightningdevkit/ldk-garbagecollected#44 # This is the commit message #4: test utils: refactor fail_payment_along_route for mpp # This is the commit message #5: Add MppId field to HTLCSource as a way to correlate mpp payment paths # This is the commit message #6: Implement Readable/Writeable for HashSet To be used in upcoming commits for MPP ID storage # This is the commit message #7: Add MPP ID to pending_outbound_htlcs We'll use this to correlate MPP shards in upcoming commits # This is the commit message #8: Prevent duplicate PaymentSent events by removing all pending outbound payments associated with the same MPP payment after the preimage is received # This is the commit message #9: Add all_paths_failed field to PaymentFailed see field docs for details # This is the commit message #10: Drop writer size hinting/message vec preallocation In order to avoid significant malloc traffic, messages previously explicitly stated their serialized length allowing for Vec preallocation during the message serialization pipeline. This added some amount of complexity in the serialization code, but did avoid some realloc() calls. Instead, here, we drop all the complexity in favor of a fixed 2KiB buffer for all message serialization. This should not only be simpler with a similar reduction in realloc() traffic, but also may reduce heap fragmentation by allocating identically-sized buffers more often. # This is the commit message #11: [fuzz] Swap mode on most messages to account for TLV suffix # This is the commit message #12: Add forward-compat due serialization variants of HTLCFailureMsg Going forward, all lightning messages have a TLV stream suffix, allowing new fields to be added as needed. In the P2P protocol, messages have an explicit length, so there is no implied length in the TLV stream itself. HTLCFailureMsg enum variants have messages in them, but without a size prefix or any explicit end. Thus, if a HTLCFailureMsg is read as a part of a ChannelManager, with a TLV stream at the end, there is no way to differentiate between the end of the message and the next field(s) in the ChannelManager. Here we add two new variant values for HTLCFailureMsg variants in the read path, allowing us to switch to the new values if/when we add new TLV fields in UpdateFailHTLC or UpdateFailMalformedHTLC so that older versions can still read the new TLV fields. # This is the commit message #13: Convert most P2P msg serialization to a new macro with TLV suffixes The network serialization format for all messages was changed some time ago to include a TLV suffix for all messages, however we never bothered to implement it as there isn't a lot of use validating a TLV stream with nothing to do with it. However, messages are increasingly utilizing the TLV suffix feature, and there are some compatibility concerns with messages written as a part of other structs having their format changed (see previous commit). Thus, here we go ahead and convert most message serialization to a new macro which includes a TLV suffix after a series of fields, simplifying several serialization implementations in the process. # This is the commit message #14: Update docs to specify where process events is called

Fix implementation of `chain::Confirm` for `ChannelManager`

Sample v0

…-payment-forwarded fix: rgb amount in channel not updated after payment forwarded

tamasblummer added 2 commits March 5, 2018 17:37

integration with bitcoin-spv

7afbb72

better use a dedicated integration branch, so I do not break it while…

d03e877

… updating master

tamasblummer closed this Mar 9, 2018

ariard pushed a commit to ariard/rust-lightning that referenced this pull request Jun 20, 2018

test prune_payment_preimages uncomplete lightningdevkit#4

3e8ef24

luckysori pushed a commit to get10101/rust-lightning that referenced this pull request Apr 20, 2023

Merge pull request lightningdevkit#4 from get10101/split-tx-experiment

9143493

Fix implementation of `chain::Confirm` for `ChannelManager`

carlaKC referenced this pull request in carlaKC/rust-lightning Aug 9, 2023

Merge pull request #4 from valentinewallace/sample-v0

6199433

Sample v0

k0k0ne pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024

Merge pull request lightningdevkit#4 from whfuyn/fix-rgb-amount-after…

153f521

…-payment-forwarded fix: rgb amount in channel not updated after payment forwarded

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

integration with bitcoin-spv #4

integration with bitcoin-spv #4

tamasblummer commented Mar 5, 2018 •

edited

Loading

TheBlueMatt commented Mar 5, 2018 •

edited

Loading

tamasblummer commented Mar 9, 2018

integration with bitcoin-spv #4

integration with bitcoin-spv #4

Conversation

tamasblummer commented Mar 5, 2018 • edited Loading

TheBlueMatt commented Mar 5, 2018 • edited Loading

tamasblummer commented Mar 9, 2018

tamasblummer commented Mar 5, 2018 •

edited

Loading

TheBlueMatt commented Mar 5, 2018 •

edited

Loading