Prepare initial deployement options for users

[dpc]

• [x] build OCI images in CI
• [ ] upload to docker hub
• [ ] prepare docker-compose setup based on docker hub
• [ ] fix port config
• [ ] more ...

[dpc]

@dpc Could you help me figure out how to deploy our nix-bitcoin fork (https://github.com/fedimint/nix-bitcoin) using something like nixops?

Why do we need a whole fork? Could I setup vanilla nix-bitcoin + binaries build from fedimint repo? (I'm not very familiar with nix-bitcoin - I used nixpkgs bitcoind before and they worked for me). @justinmoon

[dpc]

Which binaries exactly are necessary? ligthinind + bitcoind + minimint?

Should minimit server binary be called minimintd?

[justinmoon]

Should minimit server binary be called minimintd?

I vote for fedimintd (we're renaming all occurrences of minimint to fedimint https://github.com/fedimint/fedimint/issues/286)

Which binaries exactly are necessary? ligthinind + bitcoind + minimint?

bitcoind, lightningd, ln_gateway running as core lightning plugin, and fedimintd (or whatever we call it). You can read about core-lighting plugins here. You can start plugins in 3 ways: passing argument to lightningd on startup, RPC call, or just sticking the binary in core lighting plugin folder.

Why do we need a whole fork?

Once we get it working we would upstream packages for fedimintd and ln_gateway (could use a better name for this one, too). But it doesn't quite work yet, so we have a fork.

[elsirion]

I think we should separate the two components:

• Federation server: requires fedimintd from our side and bitcoind (should probably be supplied optionally, some users might already have one running). The interesting thing about the bitcoind instance for fedimintd is that afaik it can run in pruned mode since we only ever care about the the current height and past block hashes from the past and only begins caring about full blocks once we generate change to ourselves on withdraws (correct me if I'm wrong @jkitman).
• Lightning Gateway: requires the gateway core-lightning plugin from our side. We should probably have some container that can run a cln instance with the GW plugin, but should also just supply the binary somewhere/have build instructions (we should test if flakes make the build reproducible, that would be cool!).

The gateway will most likely be run by far fewer people than the federation server since it's a more specialized task (managing liquidity etc.).

[jkitman]

afaik it can run in pruned mode

Yes, although in the future it might be problem for generating TxOutProofs for users if the tx is old.

[justinmoon]

Yes, although in the future it might be problem for generating TxOutProofs for users if the tx is old.

Doesn't the client always generate the TxOutProof? i.e. not fedimintd ...

[elsirion]

Yes, although in the future it might be problem for generating TxOutProofs for users if the tx is old.

Doesn't the client always generate the TxOutProof? i.e. not fedimintd ...

I think our code shouldn't try to generate txoutproofs. The federation may very well run an electrum server though to help clients do so. EDIT: Eventually :tm: