Split out EcdsaChannelSigner method from BaseSign, and rename it to ChannelSigner
#1967
Conversation
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
4 times, most recently
from
897f881
to
48aca53
Compare
Codecov ReportBase: 90.71% // Head: 90.97% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1967 +/- ##
==========================================
+ Coverage 90.71% 90.97% +0.26%
==========================================
Files 97 98 +1
Lines 50677 52857 +2180
Branches 50677 52857 +2180
==========================================
+ Hits 45971 48086 +2115
- Misses 4706 4771 +65
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
from
48aca53
to
2539e40
Compare
| @@ -90,7 +90,7 @@ impl EnforcingSigner { | |||
| } | |||
| } | |||
|
|
|||
| impl BaseSign for EnforcingSigner { | |||
| impl EcdsaChannelSigner for EnforcingSigner { | |||
There was a problem hiding this comment.
Also rename EnforcingSigner to EnforcingEcdsaChannelSigner?
There was a problem hiding this comment.
good point. My bigger question is actually what to do with Sign. Should it perhaps be gone entirely and the writeable trait should be required explicitly where Sign is required?
There was a problem hiding this comment.
That sounds good to me. ECDSA signers still require Writeable for compatibility reasons, but the taproot signer shouldn't require it since it'll never be stored and we'll always re-derive.
There was a problem hiding this comment.
Maybe we can just make EcdsaChannelSigner inherit Writeable instead?
There was a problem hiding this comment.
yeah if they all require it, that would probably be nicer. I'll see how many compilation errors that's gonna produce.
There was a problem hiding this comment.
I actually wonder whether we might wanna parametrize EnforcingSigner with an ECDSA and a Taproot signer subvariant. If it's ok, I'll punt on this to a PR where we introduce actual Taproot types.
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
from
2539e40
to
6d2d526
Compare
|
Please wrap commit titles and messages at around 80 chars long |
| /// Returns the holder's channel public keys and basepoints. | ||
| fn pubkeys(&self) -> &ChannelPublicKeys; | ||
|
|
There was a problem hiding this comment.
Wont pubkeys potentially be different with taproot? Presumably it may have a different set of keys?
There was a problem hiding this comment.
Why? As far as I can tell, only the signatures will be different.
There was a problem hiding this comment.
I guess I'm surprised it doesn't need some kind of additional data for key construction, but ok.
There was a problem hiding this comment.
Nope, nothing has changed here. We'll need to handle the nonces separately as part of the taproot signer trait.
| @@ -249,12 +246,35 @@ pub trait BaseSign { | |||
| /// irrelevant or duplicate preimages. | |||
| fn validate_holder_commitment(&self, holder_tx: &HolderCommitmentTransaction, | |||
| preimages: Vec<PaymentPreimage>) -> Result<(), ()>; | |||
|
|
|||
There was a problem hiding this comment.
Won't validate_holder_commitment potentially be different on taproot channels? The preimage set will need to include some PTLC secrets, which would require a different signer?
There was a problem hiding this comment.
I think you might be right. I wasn't really considering PTLCs yet, but perhaps it should indeed be moved. However, I think the more important question is whether the method signature would actually change. I know @wpaulino is planning a bunch of commitment-builder-related refactors, any thoughts?
There was a problem hiding this comment.
I see this PR as a starting point for the base ChannelSigner trait. We should hold off on moving any items we are not 100% sure will also apply to the taproot signer. Once we start getting through the bulk of the changes, we'll have a better idea of what should go where.
There was a problem hiding this comment.
I guess so, I'm just really not a fan of moving-removing-unmoving-and-then-moving-again over and over. It causes a bunch of churn for downstream code, which isn't so nice. If we're confident this PR is where we'll want stuff for taproot-v1, though, I'm okay with that.
There was a problem hiding this comment.
To be fair, the introduction of PTLCs (unclear if it'll even happen this year) will require a few changes from users anyway, so moving this back to the ECDSA signer will be just a small part of that.
arik-so
force-pushed
the
2023-01-rename-signer-traits
branch
from
642d4dc
to
712c60e
Compare
0.0.114 - Mar 3, 2023 - "Faster Async BOLT12 Retries" API Updates =========== * `InvoicePayer` has been removed and its features moved directly into `ChannelManager`. As such it now requires a simplified `Router` and supports `send_payment_with_retry` (and friends). `ChannelManager::retry_payment` was removed in favor of the automated retries. Invoice payment utilities in `lightning-invoice` now call the new code (lightningdevkit#1812, lightningdevkit#1916, lightningdevkit#1929, lightningdevkit#2007, etc). * `Sign`/`BaseSign` has been renamed `ChannelSigner`, with `EcdsaChannelSigner` split out in anticipation of future schnorr/taproot support (lightningdevkit#1967). * The catch-all `KeysInterface` was split into `EntropySource`, `NodeSigner`, and `SignerProvider`. `KeysManager` implements all three (lightningdevkit#1910, lightningdevkit#1930). * `KeysInterface::get_node_secret` is now `KeysManager::get_node_secret_key` and is no longer required for external signers (lightningdevkit#1951, lightningdevkit#2070). * A `lightning-transaction-sync` crate has been added which implements keeping LDK in sync with the chain via an esplora server (lightningdevkit#1870). Note that it can only be used on nodes that *never* ran a previous version of LDK. * `Score` is updated in `BackgroundProcessor` instead of via `Router` (lightningdevkit#1996). * `ChainAccess::get_utxo` (now `UtxoAccess`) can now be resolved async (lightningdevkit#1980). * BOLT12 `Offer`, `InvoiceRequest`, `Invoice` and `Refund` structs as well as associated builders have been added. Such invoices cannot yet be paid due to missing support for blinded path payments (lightningdevkit#1927, lightningdevkit#1908, lightningdevkit#1926). * A `lightning-custom-message` crate has been added to make combining multiple custom messages into one enum/handler easier (lightningdevkit#1832). * `Event::PaymentPathFailure` is now generated for failure to send an HTLC over the first hop on our local channel (lightningdevkit#2014, lightningdevkit#2043). * `lightning-net-tokio` no longer requires an `Arc` on `PeerManager` (lightningdevkit#1968). * `ChannelManager::list_recent_payments` was added (lightningdevkit#1873). * `lightning-background-processor` `std` is now optional in async mode (lightningdevkit#1962). * `create_phantom_invoice` can now be used in `no-std` (lightningdevkit#1985). * The required final CLTV delta on inbound payments is now configurable (lightningdevkit#1878) * bitcoind RPC error code and message are now surfaced in `block-sync` (lightningdevkit#2057). * Get `historical_estimated_channel_liquidity_probabilities` was added (lightningdevkit#1961). * `ChannelManager::fail_htlc_backwards_with_reason` was added (lightningdevkit#1948). * Macros which implement serialization using TLVs or straight writing of struct fields are now public (lightningdevkit#1823, lightningdevkit#1976, lightningdevkit#1977). Backwards Compatibility ======================= * Any inbound payments with a custom final CLTV delta will be rejected by LDK if you downgrade prior to receipt (lightningdevkit#1878). * `Event::PaymentPathFailed::network_update` will always be `None` if an 0.0.114-generated event is read by a prior version of LDK (lightningdevkit#2043). * `Event::PaymentPathFailed::all_paths_removed` will always be false if an 0.0.114-generated event is read by a prior version of LDK. Users who rely on it to determine payment retries should migrate to `Event::PaymentFailed`, in a separate release prior to upgrading to LDK 0.0.114 if downgrading is supported (lightningdevkit#2043). Performance Improvements ======================== * Channel data is now stored per-peer and channel updates across multiple peers can be operated on simultaneously (lightningdevkit#1507). * Routefinding is roughly 1.5x faster (lightningdevkit#1799). * Deserializing a `NetworkGraph` is roughly 6x faster (lightningdevkit#2016). * Memory usage for a `NetworkGraph` has been reduced substantially (lightningdevkit#2040). * `KeysInterface::get_secure_random_bytes` is roughly 200x faster (lightningdevkit#1974). Bug Fixes ========= * Fixed a bug where a delay in processing a `PaymentSent` event longer than the time taken to persist a `ChannelMonitor` update, when occurring immediately prior to a crash, may result in the `PaymentSent` event being lost (lightningdevkit#2048). * Fixed spurious rejections of rapid gossip sync data when the graph has been updated by other means between gossip syncs (lightningdevkit#2046). * Fixed a panic in `KeysManager` when the high bit of `starting_time_nanos` is set (lightningdevkit#1935). * Resolved an issue where the `ChannelManager::get_persistable_update_future` future would fail to wake until a second notification occurs (lightningdevkit#2064). * Resolved a memory leak when using `ChannelManager::send_probe` (lightningdevkit#2037). * Fixed a deadlock on some platforms at least when using async `ChannelMonitor` updating (lightningdevkit#2006). * Removed debug-only assertions which were reachable in threaded code (lightningdevkit#1964). * In some cases when payment sending fails on our local channel retries no longer take the same path and thus never succeed (lightningdevkit#2014). * Retries for spontaneous payments have been fixed (lightningdevkit#2002). * Return an `Err` if `lightning-persister` fails to read the directory listing rather than panicing (lightningdevkit#1943). * `peer_disconnected` will now never be called without `peer_connected` (lightningdevkit#2035) Security ======== 0.0.114 fixes several denial-of-service vulnerabilities which are reachable from untrusted input from channel counterparties or in deployments accepting inbound connections or channels. It also fixes a denial-of-service vulnerability in rare cases in the route finding logic. * The number of pending un-funded channels as well as peers without funded channels is now limited to avoid denial of service (lightningdevkit#1988). * A second `channel_ready` message received immediately after the first could lead to a spurious panic (lightningdevkit#2071). This issue was introduced with 0conf support in LDK 0.0.107. * A division-by-zero issue was fixed in the `ProbabilisticScorer` if the amount being sent (including previous-hop fees) is equal to a channel's capacity while walking the graph (lightningdevkit#2072). The division-by-zero was introduced with historical data tracking in LDK 0.0.112. In total, this release features 130 files changed, 21457 insertions, 10113 deletions in 343 commits from 18 authors, in alphabetical order: * Alec Chen * Allan Douglas R. de Oliveira * Andrei * Arik Sosman * Daniel Granhão * Duncan Dean * Elias Rohrer * Jeffrey Czyz * John Cantrell * Kurtsley * Matt Corallo * Max Fang * Omer Yacine * Valentine Wallace * Viktor Tigerström * Wilmer Paulino * benthecarman * jurvis
No description provided.