Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Support broadcasting multiple transactions at once #2272
Changes from all commits
29b392a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that's why I said
these transactions should be considered to be a package
. so they assume it is one but doesn't sound like it always is one.wording is hard here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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 comment
The reason will be displayed to describe this comment to others. Learn more.
Note there is a) Core’s RPC definition of a package (
submitpackage
), a mining code definition of a packageCreateNewBlock
and c) the WIP BIP331 defining package at the p2p-level, so which definition the user is expected to respect here ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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 comment
The 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 comment
The 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 comment
The 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 comment
The 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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
Borrow
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for transactions we can just do straight
&[Transaction]
if its practical, making it generic is a lot of compiler overhead, and we don't need the&[&X]
indirection for bindings for transaction specifically.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I don't think we ever return a
Vec
of transaction references anyway that would force us to clone.There was a problem hiding this comment.
Choose a reason for hiding this comment
The 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