vls-protocol-signer-0.11.0 compilation error

[darioAnongba]

I initially opened this issue on the Breez SDK but after digging a bit I think it belongs here. Breez SDK is importing gl-client as such.:

gl-client = { git = "https://github.com/Blockstream/greenlight.git", features = [
    "permissive",
], rev = "97e2f418c331653330f9fa928ed10ed1538c27d0" }

While updating the dependencies of our project with cargo update, I ran into the following compiling error linked to VLS. This is on MacOS M2 using the Breez SDK v0.4.0 (tried with 0.4.0-rc1 as well). I'm not sure what the issue could be here:

error[E0507]: cannot move out of dereference of `Octets`
   --> /.../.cargo/registry/src/index.crates.io-6f17d22bba15001f/vls-protocol-signer-0.11.0/src/handler.rs:690:36
    |
690 |                   let data: Vec<_> = m
    |  ____________________________________^
691 | |                     .u5bytes
692 | |                     .clone()
    | |____________________________^ move occurs because value has type `std::vec::Vec<u8>`, which does not implement the `Copy` trait
693 |                       .into_iter()
    |                        ----------- value moved due to this method call
    |
note: `into_iter` takes ownership of the receiver `self`, which moves value
   --> ....rustup/toolchains/1.76-aarch64-apple-darwin/lib/rustlib/src/rust/library/core/src/iter/traits/collect.rs:268:18
    |
268 |     fn into_iter(self) -> Self::IntoIter;
    |                  ^^^^
help: you can `clone` the value and consume it, but this might not be your desired behavior
    |
690 ~                 let data: Vec<_> = <std::vec::Vec<u8> as Clone>::clone(&m
691 |                     .u5bytes
692 ~                     .clone())    |

Using rustc 1.76.0. Pretty surprised no-one is running into this issue so I'm wondering if I messed up something. Sadly for me, I didn't commit the Cargo.lock to revert so now I'm stuck :/.

I tried cargo clean without success.

Externally tracked at https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/495

[cdecker]

Sounds like there is some instability in either rustc on MacOS or upstream in the VLS repository.

[darioAnongba]

any idea how to bypass this even temporarily ? Should I open an issue on the VLS repo? Are you all developing on Linux so that's why you don't see the bug?

[darioAnongba]

After some research I'm pretty sure the problem is unrelated to MacOS as I tried on my Linux machine (Ubuntu) and it fails with same error. To be absolutely sure I created a new sample project that you can find here: https://github.com/bitcoin-numeraire/breez-sdk-sample-project. It does absolutely nothing and simply has 1 dependency, the Breez SDK (latest version but will fail with all versions that use greenlight rev=97e2f418c331653330f9fa928ed10ed1538c27d0). I didn't manage to compile it using rust 1.73, 1.76 and 1.78 so I'm pretty convinced it's not rustc either. Maybe someone can try to compile it?

Given that I'm not a Rust guru I can't say for sure what's the issue here but I really don't understand how Greenlight with VLS 0.11.0 is not currently failing to compile everywhere it's used.

[cdecker]

It should be reported to the VLS team indeed. As for why it doesn't compile in certain scenarios, they'll likely be able to help much better, and likely identify the underlying issue. We have a bunch of cross-compile targets including windows and MacOS m1, which so far have worked fine, so this is a rather strange issue.

[darioAnongba]

ok I'll try opening a ticker there directly. I tried on a fresh machine that didn't have Rust installed at all. I installed Rust and tried compiling the sample project and failed with same error so we now have 3 different scenarios where gl-client does not compile:

• MacOS M2
• Ubuntu 20
• Debian Docker container from @JssDWt

This is starting to become mysticism lol. Maybe it's only working for people that didn't update their cache? I completely wiped ~/.cargo/registry/src/ and still fails.

Here is the ticket for reference: https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/495

[cdecker]

Quick update on this: when trying to do a cargo publish --dry-run we run into the same compilation issue. We'll follow up on the VLS issue and keep this thread up-to-date :+1:

Thanks for the report :hugs:

[darioAnongba]

Hi @cdecker, this fixes it:

[dependencies]
breez-sdk-core = { git = "https://github.com/breez/breez-sdk", tag = "0.4.1-rc2" }
serde_bolt = "=0.3.4"

Don't ask me why. Is serde_bolt a mandatory dependency on vls-protocol-signer that is somehow missing?

[ok300]

I summarized why this is happening here: https://github.com/breez/breez-sdk/issues/969#issuecomment-2104700522

IMO the simplest solution to avoid this is, where possible, to specify dependencies with

# This way (which pins it to a specific version)
dependency = "=x.y.z"

# Instead of this way (which is a range)
dependency = "x.y.z"

This is why the workaround above worked

serde_bolt = "=0.3.4"

because it set serde_bolt to v0.3.4. Cargo initially tried to use v0.3.5 because it interpreted the serde_bolt = "0.3.4" from VLS as the >=0.3.4, <0.4.0 range, so it got the latest available version in that range. VLS 0.11 was however tested and released with 0.3.4.

[devrandom]

this was a subtle API break in serde_bolt, and the latest VLS main actually was already compatible with it, but not 0.11.0.

I've updated the VLS issue linked above, and also created an MR if we decide we need a VLS point release.

pinning serde_bolt is a reasonable temporary workaround.