Expose `Mnemonic` as interface to bindings users by tnull · Pull Request #1059 · lightningdevkit/ldk-node

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull · 2026-08-19T07:49:29Z

Invalid mnemonic strings currently fail during implicit custom-type
lifting, which leaves generated bindings without a catchable validation
error.
Parse mnemonic phrases through a fallible object constructor while
keeping bip39::Mnemonic in the native Rust API.

And, since we now expose Mnemonic::generate to bindings users directly, we can get rid of our global generate_entropy_mnemonic helper.

ldk-reviews-bot · 2026-08-19T07:49:32Z

👋 Thanks for assigning @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

benthecarman

nits otherwise lgtm

benthecarman · 2026-08-19T07:53:39Z

+	#[uniffi::constructor]
+	pub fn generate(word_count: Option<WordCount>) -> Self {
+ let word_count = word_count.unwrap_or(WordCount::Words24).word_count();
+ let inner = Bip39Mnemonic::generate(word_count)


Can we do the same as #1013 here

Hmm, no, I'd prefer to just call through to bip39 here, though that should do it soon, see rust-bitcoin/rust-bip39#105 (we just need to get a release out)

benthecarman · 2026-08-19T07:54:51Z

+
+	/// Returns the number of words in the mnemonic.
+	pub fn word_count(&self) -> u8 {
+ self.inner.word_count() as u8


changing the type here is kinda weird

Yeah, unfortunately no usize in uniffi. Would you prefer we just no expose the method?

Could also wait until after rust-bitcoin/rust-bip39#98 lands and ships, when we'll re-introduce WordCount (just seemed weird to keep it for bindings only for now)

This is fine for now, we can move to that in the future. No reason we'd ever break the u8 here for any practical reason

Invalid mnemonic strings currently fail during implicit custom-type lifting, which leaves generated bindings without a catchable validation error. Parse mnemonic phrases through a fallible object constructor while keeping bip39::Mnemonic in the native Rust API. Co-Authored-By: HAL 9000

Mnemonic generation no longer needs a separate global entry point now that bindings expose a real mnemonic object. Use numeric word counts for both native and binding constructors so the APIs stay aligned without a binding-specific enum. Co-Authored-By: HAL 9000

tnull · 2026-08-19T12:31:43Z

Amended with some fixes to make CI pass.

kaloudis · 2026-08-20T16:28:54Z

Thanks for fixing!

tnull requested a review from benthecarman August 19, 2026 07:49

tnull mentioned this pull request Aug 19, 2026
Return an error from NodeEntropy::from_bip39_mnemonic in bindings #1058
Closed

benthecarman reviewed Aug 19, 2026
View reviewed changes

benthecarman previously approved these changes Aug 19, 2026
View reviewed changes

tnull added 2 commits August 19, 2026 14:29

tnull dismissed benthecarman’s stale review via ec9567fAugust 19, 2026 12:29

tnull force-pushed the 2026-08-uniffi-mnemonic branch from 9e8f8ed to ec9567fCompare August 19, 2026 12:29

tnull requested a review from benthecarman August 19, 2026 12:31

benthecarman approved these changes Aug 19, 2026
View reviewed changes

tnull merged commit 925b26e into lightningdevkit:mainAug 20, 2026
25 of 26 checks passed