profile
viewpoint
Martin Habovštiak Kixunil Funcoil Bratislava https://ln-ask.me Beside programming, I'm interested in security, cryptography, Bitcoin and freedom.

Kixunil/cryptoanarchy-deb-repo-builder 36

Tooling for building a Debian repository containing interconnected, well-working applications.

Kixunil/configure_me 30

A Rust library for processing application configuration easily

Kixunil/btc-rpc-proxy 12

Finer-grained permission management for bitcoind.

Kixunil/bitcoin_parser_tutorial 6

Totorial about how to parse Bitcoin blockchain.

Kixunil/dangerous_option 4

Implicitly unwrapped Option for Rust

Kixunil/btcsteg 2

Script that hides message into set of Bitcoin addresses. (proof-of-concept)

Kixunil/dhcpsniff 2

Detects DHCP request on the network and runs chosen command with client MAC address as last argument.

Kixunil/bitcoin-fortunes 1

Fortune files related to Bitcoin (quotes, jokes...)

Kixunil/Books 1

Automatic book information retriever

issue commentLNP-BP/rgb-node

Dependency Vesrion Conflict in lnpbp/master

Removing Bug because this is not a functional failure.

rajarshimaitra

comment created time in 43 minutes

issue commentLNP-BP/rgb-node

Dependency Vesrion Conflict in lnpbp/master

Notes after further investigation:

  • This particular version issue goes away with cargo update and rm -rf target.

  • But it's not ideal to try to build lnpbp-master here because this will create a conflicting compilation of both versions, master and v0.2-beta.2. Because lnpbp-derive and lnpbp-service depends on v0.2-beta.2.

To put it in context I require lnpbp-master to use https://github.com/LNP-BP/rust-lnpbp/pull/153 while implementing hammerbald.

What would be the right way to this? Or in general in such a situation where some added logic is required which is not available in the latest release tag?

rajarshimaitra

comment created time in 44 minutes

PublicEvent

pull request commentrust-bitcoin/rust-lightning

Don't include below-dust inbound HTLCs in commit tx fee calculation

Codecov Report

Merging #762 (ab16970) into main (773c2d1) will decrease coverage by 0.06%. The diff coverage is 90.90%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #762      +/-   ##
==========================================
- Coverage   91.40%   91.33%   -0.07%     
==========================================
  Files          37       37              
  Lines       22423    22431       +8     
==========================================
- Hits        20495    20487       -8     
- Misses       1928     1944      +16     
Impacted Files Coverage Δ
lightning/src/ln/channel.rs 87.45% <90.00%> (+<0.01%) :arrow_up:
lightning/src/ln/functional_tests.rs 96.92% <100.00%> (-0.23%) :arrow_down:
lightning/src/ln/channelmanager.rs 84.92% <0.00%> (-0.10%) :arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 773c2d1...ab16970. Read the comment docs.

valentinewallace

comment created time in 9 hours

PR opened rust-bitcoin/rust-lightning

Don't include below-dust inbound HTLCs in commit tx fee calculation

Closes #757

Does this fix look right? Seems like an oops from the original channel reserve PR. Let me know and I'll write tests.

+20 -6

0 comment

2 changed files

pr created time in 9 hours

issue closedromanz/electrs

Query server.version via jsonrpc returns error

After upgrading electrs to 0.8.6, querying the server.version with echo '{"jsonrpc": "2.0", "method": "server.version", "id": 0}' | netcat 127.0.0.1 50001 fails with {"error":"invalid params: []","id":0,"jsonrpc":"2.0"}

closed time in 9 hours

dematerializer

issue commentromanz/electrs

Query server.version via jsonrpc returns error

Yes indeed, thanks for pointing the right places out to me, I missed that something changed in 0.8.6 because the docs weren't updated. The call echo '{"jsonrpc": "2.0", "method": "server.version", "params": ["", "1.4"], "id": 0}' | netcat 127.0.0.1 50001 works! I updated the documentation, see merge request #340.

dematerializer

comment created time in 9 hours

PR opened romanz/electrs

Update rpc example following protocol changes

See #339 for reference.

+2 -2

0 comment

1 changed file

pr created time in 9 hours

startedGekkio/gb-ctr

started time in 10 hours

startedrustwasm/gloo

started time in 10 hours

Pull request review commentrust-bitcoin/rust-lightning

Introduce CommitmentTransactionInfo

 impl ChannelKeys for InMemoryChannelKeys { 	fn pubkeys(&self) -> &ChannelPublicKeys { &self.holder_channel_pubkeys } 	fn key_derivation_params(&self) -> (u64, u64) { self.key_derivation_params } -	fn sign_counterparty_commitment<T: secp256k1::Signing + secp256k1::Verification>(&self, feerate_per_kw: u32, commitment_tx: &Transaction, pre_keys: &PreCalculatedTxCreationKeys, htlcs: &[&HTLCOutputInCommitment], secp_ctx: &Secp256k1<T>) -> Result<(Signature, Vec<Signature>), ()> {-		if commitment_tx.input.len() != 1 { return Err(()); }-		let keys = pre_keys.trust_key_derivation();+	fn sign_counterparty_commitment<T: secp256k1::Signing + secp256k1::Verification>(&self, commitment_tx: &CommitmentTransaction, secp_ctx: &Secp256k1<T>) -> Result<(Signature, Vec<Signature>), ()> {+		let keys = commitment_tx.trust_key_derivation();  		let funding_pubkey = PublicKey::from_secret_key(secp_ctx, &self.funding_key);-		let accepted_data = self.accepted_channel_data.as_ref().expect("must accept before signing");-		let channel_funding_redeemscript = make_funding_redeemscript(&funding_pubkey, &accepted_data.counterparty_channel_pubkeys.funding_pubkey);--		let commitment_sighash = hash_to_message!(&bip143::SigHashCache::new(commitment_tx).signature_hash(0, &channel_funding_redeemscript, self.channel_value_satoshis, SigHashType::All)[..]);-		let commitment_sig = secp_ctx.sign(&commitment_sighash, &self.funding_key);--		let commitment_txid = commitment_tx.txid();--		let mut htlc_sigs = Vec::with_capacity(htlcs.len());-		for ref htlc in htlcs {-			if let Some(_) = htlc.transaction_output_index {-				let htlc_tx = chan_utils::build_htlc_transaction(&commitment_txid, feerate_per_kw, accepted_data.holder_selected_contest_delay, htlc, &keys.broadcaster_delayed_payment_key, &keys.revocation_key);-				let htlc_redeemscript = chan_utils::get_htlc_redeemscript(&htlc, &keys);-				let htlc_sighash = hash_to_message!(&bip143::SigHashCache::new(&htlc_tx).signature_hash(0, &htlc_redeemscript, htlc.amount_msat / 1000, SigHashType::All)[..]);-				let our_htlc_key = match chan_utils::derive_private_key(&secp_ctx, &keys.per_commitment_point, &self.htlc_base_key) {-					Ok(s) => s,-					Err(_) => return Err(()),-				};-				htlc_sigs.push(secp_ctx.sign(&htlc_sighash, &our_htlc_key));-			}+		let channel_funding_redeemscript = make_funding_redeemscript(&funding_pubkey, &self.counterparty_pubkeys().funding_pubkey);++		let channel_parameters = self.make_channel_parameters();+		let directed_channel_parameters = channel_parameters.to_directed(false);+		let commitment_sig = commitment_tx.get_signature(&directed_channel_parameters, &self.funding_key, &channel_funding_redeemscript, self.channel_value_satoshis, secp_ctx);

This ends up creating the Tx, hashing it, and then dropping it, and then we create it again on the next line just to hash it, all in a call from channel.rs that is a few lines below calculate_txid in send_commitment_no_state_update. Given this is an incredibly common operation, I don't think that much malloc/free traffic (ie memory fragmentation potential) and SHA256 is acceptable. I'm still a bit dubious of the API here, its just too hard to accidentally blow up complexity for no reason - especially gnarly when it happens on the signer, potentially on embedded hardware.

If we want to change it, there are a few options - we could make the fields private and expose getters (eh? but we do already do this for the TxCreationKeys), or we could add a new struct that you can get from the CommitmentTransaction that holds a cached/calculated tx and then expose all the various signature/Txid methods on it instead. I think I would prefer the second, except its pretty hard to use that across the Channel/signer boundary, though there may be something we can do that's somewhere in between more akin to what we do for TxCreationKeys.

devrandom

comment created time in 11 hours

Pull request review commentrust-bitcoin/rust-lightning

Introduce CommitmentTransactionInfo

 impl<ChanSigner: ChannelKeys> ChannelMonitor<ChanSigner> { 			self.counterparty_hash_commitment_number.insert(htlc.payment_hash, commitment_number); 		} -		let new_txid = unsigned_commitment_tx.txid();-		log_trace!(logger, "Tracking new counterparty commitment transaction with txid {} at commitment number {} with {} HTLC outputs", new_txid, commitment_number, htlc_outputs.len());-		log_trace!(logger, "New potential counterparty commitment transaction: {}", encode::serialize_hex(unsigned_commitment_tx));+		log_trace!(logger, "Tracking new counterparty commitment transaction with txid {} at commitment number {} with {} HTLC outputs", txid, commitment_number, htlc_outputs.len());+		// TODO do we really want to log the transaction hex?

Two points: a) I think we don't log_trace nearly enough today - log_trace should be more than enough to figure out exactly what paths were taken through the code at every point so that we can debug in-production failures after the fact. We should probably also be considering more carefully how to separate the different log levels. b) there are a number of log_trace entries today which exist in large part to make updating the full_stack_target test cases easier to fix when they break, I'm not sure if this is one of them, most of them are in channel.rs, but it may be.

devrandom

comment created time in 2 days

Pull request review commentrust-bitcoin/rust-lightning

Introduce CommitmentTransactionInfo

 impl<ChanSigner: ChannelKeys + Writeable> ChannelMonitor<ChanSigner> {  impl<ChanSigner: ChannelKeys> ChannelMonitor<ChanSigner> { 	pub(crate) fn new(keys: ChanSigner, shutdown_pubkey: &PublicKey,-			on_counterparty_tx_csv: u16, destination_script: &Script, funding_info: (OutPoint, Script),-			counterparty_htlc_base_key: &PublicKey, counterparty_delayed_payment_base_key: &PublicKey,-			on_holder_tx_csv: u16, funding_redeemscript: Script, channel_value_satoshis: u64,-			commitment_transaction_number_obscure_factor: u64,-			initial_holder_commitment_tx: HolderCommitmentTransaction) -> ChannelMonitor<ChanSigner> {+	                  on_counterparty_tx_csv: u16, destination_script: &Script, funding_info: (OutPoint, Script),+	                  channel_parameters: &ChannelTransactionParameters,+	                  funding_redeemscript: Script, channel_value_satoshis: u64,+	                  commitment_transaction_number_obscure_factor: u64,+	                  initial_holder_commitment_tx: HolderCommitmentTransaction) -> ChannelMonitor<ChanSigner> {  		assert!(commitment_transaction_number_obscure_factor <= (1 << 48)); 		let our_channel_close_key_hash = WPubkeyHash::hash(&shutdown_pubkey.serialize()); 		let shutdown_script = Builder::new().push_opcode(opcodes::all::OP_PUSHBYTES_0).push_slice(&our_channel_close_key_hash[..]).into_script(); 		let payment_key_hash = WPubkeyHash::hash(&keys.pubkeys().payment_point.serialize()); 		let counterparty_payment_script = Builder::new().push_opcode(opcodes::all::OP_PUSHBYTES_0).push_slice(&payment_key_hash[..]).into_script(); -		let counterparty_tx_cache = CounterpartyCommitmentTransaction { counterparty_delayed_payment_base_key: *counterparty_delayed_payment_base_key, counterparty_htlc_base_key: *counterparty_htlc_base_key, on_counterparty_tx_csv, per_htlc: HashMap::new() };--		let mut onchain_tx_handler = OnchainTxHandler::new(destination_script.clone(), keys.clone(), on_holder_tx_csv);--		let holder_tx_sequence = initial_holder_commitment_tx.unsigned_tx.input[0].sequence as u64;-		let holder_tx_locktime = initial_holder_commitment_tx.unsigned_tx.lock_time as u64;-		let holder_commitment_tx = HolderSignedTx {-			txid: initial_holder_commitment_tx.txid(),-			revocation_key: initial_holder_commitment_tx.keys.revocation_key,-			a_htlc_key: initial_holder_commitment_tx.keys.broadcaster_htlc_key,-			b_htlc_key: initial_holder_commitment_tx.keys.countersignatory_htlc_key,-			delayed_payment_key: initial_holder_commitment_tx.keys.broadcaster_delayed_payment_key,-			per_commitment_point: initial_holder_commitment_tx.keys.per_commitment_point,-			feerate_per_kw: initial_holder_commitment_tx.feerate_per_kw,-			htlc_outputs: Vec::new(), // There are never any HTLCs in the initial commitment transactions+		let counterparty_channel_parameters = channel_parameters.counterparty_parameters.as_ref().unwrap();+		let counterparty_delayed_payment_base_key = counterparty_channel_parameters.pubkeys.delayed_payment_basepoint;+		let counterparty_htlc_base_key = counterparty_channel_parameters.pubkeys.htlc_basepoint;+		let counterparty_tx_cache = CounterpartyCommitmentTransaction { counterparty_delayed_payment_base_key, counterparty_htlc_base_key, on_counterparty_tx_csv, per_htlc: HashMap::new() };++		let mut onchain_tx_handler = OnchainTxHandler::new(destination_script.clone(), keys.clone(), channel_parameters.clone());++		let secp_ctx = Secp256k1::new();++		let directed_channel_parameters = channel_parameters.to_directed(true);+		let txid = initial_holder_commitment_tx.calculate_txid(&directed_channel_parameters, &secp_ctx);++		// block for Rust 1.34 compat+		let (holder_commitment_tx, current_holder_commitment_number) = {+			let commitment_tx = &initial_holder_commitment_tx.inner;+			let tx_keys = &commitment_tx.keys;+			let current_holder_commitment_number = commitment_tx.commitment_number;+			let holder_commitment_tx = HolderSignedTx {

Obviously doesn't make sense in this PR, but may be worth adding a TODO to suggest swapping HolderSignerTx with a HolderCommitmentTransaction + a Vec of HTLCSource objects.

devrandom

comment created time in 11 hours

Pull request review commentrust-bitcoin/rust-lightning

Introduce CommitmentTransactionInfo

 impl<ChanSigner: ChannelKeys + Writeable> ChannelMonitor<ChanSigner> {  impl<ChanSigner: ChannelKeys> ChannelMonitor<ChanSigner> { 	pub(crate) fn new(keys: ChanSigner, shutdown_pubkey: &PublicKey,-			on_counterparty_tx_csv: u16, destination_script: &Script, funding_info: (OutPoint, Script),-			counterparty_htlc_base_key: &PublicKey, counterparty_delayed_payment_base_key: &PublicKey,-			on_holder_tx_csv: u16, funding_redeemscript: Script, channel_value_satoshis: u64,-			commitment_transaction_number_obscure_factor: u64,-			initial_holder_commitment_tx: HolderCommitmentTransaction) -> ChannelMonitor<ChanSigner> {+	                  on_counterparty_tx_csv: u16, destination_script: &Script, funding_info: (OutPoint, Script),+	                  channel_parameters: &ChannelTransactionParameters,+	                  funding_redeemscript: Script, channel_value_satoshis: u64,+	                  commitment_transaction_number_obscure_factor: u64,+	                  initial_holder_commitment_tx: HolderCommitmentTransaction) -> ChannelMonitor<ChanSigner> {  		assert!(commitment_transaction_number_obscure_factor <= (1 << 48)); 		let our_channel_close_key_hash = WPubkeyHash::hash(&shutdown_pubkey.serialize()); 		let shutdown_script = Builder::new().push_opcode(opcodes::all::OP_PUSHBYTES_0).push_slice(&our_channel_close_key_hash[..]).into_script(); 		let payment_key_hash = WPubkeyHash::hash(&keys.pubkeys().payment_point.serialize()); 		let counterparty_payment_script = Builder::new().push_opcode(opcodes::all::OP_PUSHBYTES_0).push_slice(&payment_key_hash[..]).into_script(); -		let counterparty_tx_cache = CounterpartyCommitmentTransaction { counterparty_delayed_payment_base_key: *counterparty_delayed_payment_base_key, counterparty_htlc_base_key: *counterparty_htlc_base_key, on_counterparty_tx_csv, per_htlc: HashMap::new() };--		let mut onchain_tx_handler = OnchainTxHandler::new(destination_script.clone(), keys.clone(), on_holder_tx_csv);--		let holder_tx_sequence = initial_holder_commitment_tx.unsigned_tx.input[0].sequence as u64;-		let holder_tx_locktime = initial_holder_commitment_tx.unsigned_tx.lock_time as u64;-		let holder_commitment_tx = HolderSignedTx {-			txid: initial_holder_commitment_tx.txid(),-			revocation_key: initial_holder_commitment_tx.keys.revocation_key,-			a_htlc_key: initial_holder_commitment_tx.keys.broadcaster_htlc_key,-			b_htlc_key: initial_holder_commitment_tx.keys.countersignatory_htlc_key,-			delayed_payment_key: initial_holder_commitment_tx.keys.broadcaster_delayed_payment_key,-			per_commitment_point: initial_holder_commitment_tx.keys.per_commitment_point,-			feerate_per_kw: initial_holder_commitment_tx.feerate_per_kw,-			htlc_outputs: Vec::new(), // There are never any HTLCs in the initial commitment transactions+		let counterparty_channel_parameters = channel_parameters.counterparty_parameters.as_ref().unwrap();+		let counterparty_delayed_payment_base_key = counterparty_channel_parameters.pubkeys.delayed_payment_basepoint;+		let counterparty_htlc_base_key = counterparty_channel_parameters.pubkeys.htlc_basepoint;+		let counterparty_tx_cache = CounterpartyCommitmentTransaction { counterparty_delayed_payment_base_key, counterparty_htlc_base_key, on_counterparty_tx_csv, per_htlc: HashMap::new() };++		let mut onchain_tx_handler = OnchainTxHandler::new(destination_script.clone(), keys.clone(), channel_parameters.clone());++		let secp_ctx = Secp256k1::new();++		let directed_channel_parameters = channel_parameters.to_directed(true);+		let txid = initial_holder_commitment_tx.calculate_txid(&directed_channel_parameters, &secp_ctx);

Note this is duplicative with the call to calculate_txid in provide_latest_holder_commitment_tx immediately after the let block. I don't think its a huge deal given its once per new channel, just noting.

devrandom

comment created time in 11 hours

pull request commentrust-bitcoin/rust-lightning

Clean up and more liberally free holding cell HTLCs

In terms of:

an alternate approach to #754

If it would be fair to summarize this approach as: "don't fail back holding cell add HTLCs on disconnect," then I'm conceptACK. Still have to review the other parts of the PR in detail but that lgtm approach-wise!

TheBlueMatt

comment created time in 12 hours

issue commentrust-bitcoin/rust-lightning

Spurious Forwarding Failures in Async Monitor Update Clients

Taking a look at #756 and wondering about

but this probably has implications for the channel state machine around placing such HTLCs in the holding cell in a new case.

Could you clarify what implications? (and is "a new case" = the case where we now only return !is_live() if updating has run some time without completion?)

TheBlueMatt

comment created time in 13 hours

startedmtharrison/wasm-raytracer

started time in 13 hours

Pull request review commentrust-bitcoin/rust-bitcoin

New PSBT global keys

 impl Map for Global {             },         }); +        for (xpub, (fingerprint, derivation)) in &self.xpub {+            rv.push(raw::Pair {+                key: raw::Key {+                    type_value: PSBT_GLOBAL_KEY_XPUB,+                    key: xpub.encode().to_vec(),+                },+                value: {+                    let mut ret = Vec::with_capacity(4 + derivation.len() * 4);+                    ret[0..4].copy_from_slice(fingerprint.as_bytes());

This will cause runtime error. ret is a vec with length 0, so you can't use vec[0..4]

dr-orlovsky

comment created time in 14 hours

pull request commentrust-bitcoin/rust-bitcoin

Rearrange all the modules

Let's bundle this with #494 in a "dramatically break the API but don't change functionality" release after the next release.

Maybe we can take the occasion for cargo fmt?

apoelstra

comment created time in 14 hours

pull request commentrust-bitcoin/rust-bitcoin

impl PartialOrd/Ord for PublicKey

FWIW sort_by_cached_key maybe could save some re-serialization

sanket1729

comment created time in 14 hours

pull request commentrust-bitcoin/rust-bitcoin

Errors enum improvements

rebased

RCasatta

comment created time in 14 hours

issue openedromanz/electrs

Query server.version via jsonrpc returns error

After upgrading electrs to 0.8.6, querying the server.version with echo '{"jsonrpc": "2.0", "method": "server.version", "id": 0}' | netcat 127.0.0.1 50001 fails with {"error":"invalid params: []","id":0,"jsonrpc":"2.0"}

created time in 15 hours

issue commentLNP-BP/rust-amplify

Remove Cargo.lock?

Well, we use conditional dependencies. In general I have to say that dependency version management becomes a nightmare for libraries and I do not know any good solution to that...

Kixunil

comment created time in 15 hours

pull request commentromanz/electrs

Support for Signet

What about merging to master? Or do you plan for next to be the next release?

I am planning to port the missing features from master to next - e.g. configuration, better error handling - and then merge it into master as part of 0.9.* release, since it's DB schema is not backwards-compatible. I plan to support the 0.8.* branch for the near future, but I prefer to continue the development using the new code base.

dr-orlovsky

comment created time in 15 hours

issue commentLNP-BP/rgb-node

bash: target/release/rgbd: No such file or directory

I agree @rajarshimaitra, we cannot leave default build broken. It's better to find a temporary solution (yours seems good to me) and open an issue to remember to improve that. So I'll wait for @dr-orlovsky to take a decision and, based on that, I'll do a PR that just adds the missing dep or one that also changes build command

Goosie

comment created time in 17 hours

issue commentLNP-BP/rgb-node

Dependency Vesrion Conflict in lnpbp/master

cc: @dr-orlovsky

@dieeasy Have you seen something similar or any input you can provide on this?

rajarshimaitra

comment created time in 17 hours

issue openedLNP-BP/rgb-node

Dependency Vesrion Conflict in lnpbp/master

While building rgb-node with lnpbp master branch, the following cargo error is occuring.

Cargo.toml:

lnpbp = { git = "https://github.com/LNP-BP/rust-lnpbp", branch = "master", features = ["lnp", "url", "websockets"] }

cargo error:

error: failed to select a version for `cmake`.
    ... required by package `zeromq-src v0.1.10+4.3.2`
    ... which is depended on by `zmq-sys v0.11.0`
    ... which is depended on by `zmq v0.9.2`
    ... which is depended on by `lnpbp v0.2.0-beta.2`
    ... which is depended on by `lnpbp_services v0.2.0-beta.2`
    ... which is depended on by `rgb_node v0.2.0-beta.3 (/home/raj/github-repo/rgb-node)`
versions that meet the requirements `=0.1.44` are: 0.1.44

all possible versions conflict with previously selected packages.

  previously selected package `cmake v0.1.43`
    ... which is depended on by `zeromq-src v0.1.10+4.3.2 (https://github.com/LNP-BP/zeromq-src-rs?branch=fix/cmake#e95a4e68)`
    ... which is depended on by `lnpbp v0.2.0-beta.3 (https://github.com/LNP-BP/rust-lnpbp?branch=master#4d064975)`
    ... which is depended on by `rgb_node v0.2.0-beta.3 (/home/raj/github-repo/rgb-node)`

failed to select a version for `cmake` which could resolve this conflict

Not sure what's happening here, seems like cmake requires different versions for different crates?

created time in 17 hours

issue commentLNP-BP/rgb-node

bash: target/release/rgbd: No such file or directory

I think this is the same serde Issue I referenced here https://github.com/LNP-BP/rgb-node/pull/108

It seems --all-feature doesn't build default and default have this dependency bug. RGB file cache needs serde to work.

The trick is to either build --all-feature or put serde inside the default feature like done in the above PR.

I think it would safe for now to merge that PR until we find better ways to handle this. @dr-orlovsky

Goosie

comment created time in 17 hours

issue commentLNP-BP/rgb-node

bash: target/release/rgbd: No such file or directory

Yesss. This was the trick. Thanks. Now a lot of beginners would appreciate the update in the readme: The following lines should be changed:

sudo apt install -y build-essential pkg-config libzmq3-dev libssl-dev libpq-dev cmake into sudo apt install -y build-essential pkg-config libzmq3-dev libssl-dev libpq-dev cmake libsqlite3-dev

cargo build --release into cargo build --all-features --release

And the line target/release/rgbd --data-dir ~/.rgb --bin-dir target/release -vvvv - contract fungible into target/release/rgbd --data-dir ~/.rgb --bin-dir target/release -vvvv --contract fungible

Will help a lot of the starters in rgb :-) Thanks!

Goosie

comment created time in 18 hours

pull request commentromanz/electrs

Support for Signet

They are in the master, but not in crates.io (pending release)

dr-orlovsky

comment created time in 18 hours

more