-
Notifications
You must be signed in to change notification settings - Fork 410
Support broadcasting multiple transactions at once #2272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,8 +19,20 @@ use bitcoin::blockdata::transaction::Transaction; | |
|
||
/// An interface to send a transaction to the Bitcoin network. | ||
pub trait BroadcasterInterface { | ||
/// Sends a transaction out to (hopefully) be mined. | ||
fn broadcast_transaction(&self, tx: &Transaction); | ||
/// Sends a list of transactions out to (hopefully) be mined. | ||
/// This only needs to handle the actual broadcasting of transactions, LDK will automatically | ||
/// rebroadcast transactions that haven't made it into a block. | ||
/// | ||
/// In some cases LDK may attempt to broadcast a transaction which double-spends another | ||
/// and this isn't a bug and can be safely ignored. | ||
TheBlueMatt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
/// | ||
/// If more than one transaction is given, these transactions should be considered to be a | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we want to say its a package if they're not a package? Maybe transactions may be a package? Dunno what the right phrasing is to make clear it (a) may be a package, and (b) if it is a package (but we're not telling you if it is or not) you need to make sure its handled as a package. Dont think we need to update the API for that given Core handles it the same either way, but I wonder if there's any P2P-based clients that would benefit from a flag? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah that's why I said wording is hard here There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wording is always hard :( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But, yea, I think this LGTM. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Note there is a) Core’s RPC definition of a package ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good to use the P2P definition, can we reference to BIP331 directly in the code/documentation (nothing it's not final as of LDK upcoming v0.0.116 release) ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could also/instead link to https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could link to that, but that feels more like "the things LDK needs to do to create its packages" than "what the user needs to be aware of to implement this" - rather, we can just be explicit and say "via BIP331 over the P2P protocol or via the XXX Bitcoin Core RPC"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, just thought it'd be nice to provide some more literature if they're not too familiar with the concept and that breaks it down a bit better than diving straight into the BIP. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes with the warning than packages.md might be more loose than p2p packages as defined in BIP331. |
||
/// package and broadcast together. Some of the transactions may or may not depend on each other, | ||
/// be sure to manage both cases correctly. | ||
/// | ||
/// Bitcoin transaction packages are defined in BIP 331 and here: | ||
/// https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md | ||
fn broadcast_transactions(&self, txs: &[&Transaction]); | ||
TheBlueMatt marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not a blocker, but we could make this a bit more flexible with the use of
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think for transactions we can just do straight There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough, I don't think we ever return a |
||
} | ||
|
||
/// An enum that represents the speed at which we want a transaction to confirm used for feerate | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2327,10 +2327,13 @@ impl<Signer: WriteableEcdsaChannelSigner> ChannelMonitorImpl<Signer> { | |
where B::Target: BroadcasterInterface, | ||
L::Target: Logger, | ||
{ | ||
for tx in self.get_latest_holder_commitment_txn(logger).iter() { | ||
let commit_txs = self.get_latest_holder_commitment_txn(logger); | ||
let mut txs = vec![]; | ||
for tx in commit_txs.iter() { | ||
log_info!(logger, "Broadcasting local {}", log_tx!(tx)); | ||
broadcaster.broadcast_transaction(tx); | ||
txs.push(tx); | ||
} | ||
broadcaster.broadcast_transactions(&txs); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this was the only place I found where we could make use of the change |
||
self.pending_monitor_events.push(MonitorEvent::CommitmentTxConfirmed(self.funding_info.0)); | ||
} | ||
|
||
|
Uh oh!
There was an error while loading. Please reload this page.