profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/TheBlueMatt/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Matt Corallo TheBlueMatt https://git.bitcoin.ninja Many repos moved, see https://git.bitcoin.ninja.

lightningnetwork/lightning-rfc 1265

Lightning Network Specifications

rust-bitcoin/rust-bitcoin 770

Rust Bitcoin library

rust-bitcoin/rust-lightning 405

A highly modular Bitcoin Lightning library written in Rust. Its Rust-Lightning, not Rusty's Lightning!

rust-bitcoin/bitcoin_hashes 46

Simple library which implements a few hashes and does nothing else

TheBlueMatt/bips 42

Bitcoin Improvement Proposals

TheBlueMatt/bitcoin 18

Bitcoin (dont fork from here, fork from bitcoin/bitcoin)

sipa/bitcoin-net-simul 17

Bitcoin network simulator

rust-bitcoin/rust-bitcoinconsensus 16

Bitcoin's libbitcoinconsenus.a with Rust binding. Built from Bitcoin sources with cargo.

sipa/asmap 6

Compact encoding of approximate prefix->AS table

lightningdevkit/ldk-garbagecollected 5

LDK Bindings for Garbage-Collected Languages

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::CreateTransactionInternal(                     return false;                 } -                nFeeNeeded = coin_selection_params.m_effective_feerate.GetFee(nBytes);-                if (nFeeRet >= nFeeNeeded) {-                    // Reduce fee to only the needed amount if possible. This-                    // prevents potential overpayment in fees if the coins-                    // selected to meet nFeeNeeded result in a transaction that-                    // requires less fee than the prior iteration.--                    // If we have no change and a big enough excess fee, then-                    // try to construct transaction again only without picking-                    // new inputs. We now know we only need the smaller fee-                    // (because of reduced tx size) and so we should add a-                    // change output. Only try this once.-                    if (nChangePosInOut == -1 && nSubtractFeeFromAmount == 0 && pick_new_inputs) {-                        unsigned int tx_size_with_change = nBytes + coin_selection_params.change_output_size + 2; // Add 2 as a buffer in case increasing # of outputs changes compact size-                        CAmount fee_needed_with_change = coin_selection_params.m_effective_feerate.GetFee(tx_size_with_change);-                        CAmount minimum_value_for_change = GetDustThreshold(change_prototype_txout, coin_selection_params.m_discard_feerate);-                        if (nFeeRet >= fee_needed_with_change + minimum_value_for_change) {-                            pick_new_inputs = false;-                            nFeeRet = fee_needed_with_change;-                            continue;-                        }-                    }

Oh, wow. I guess I was looking at the new code first where nChange means input exceeding originally requested output, or change+fees. But in the current code as long as nValueToSelect still contains fees, then nChange will just be pure change:

https://github.com/bitcoin/bitcoin/blob/0f402b9263b0579b29aa0f841fc64ad58d3efba6/src/wallet/wallet.cpp#L2620 https://github.com/bitcoin/bitcoin/blob/0f402b9263b0579b29aa0f841fc64ad58d3efba6/src/wallet/wallet.cpp#L2664

So nChange could be 0 even if the final fee turned out to be a significantly less than the originally estimated fee, and the change output would not be added on the first pass.

I guess now the thing I don't understand is why commit "Move output reductions for fee to after coin selection" (234f85c44042d6566b7cf7e1bf1b969b2e38f903) is safe before commit "Remove CreateTransaction while loop and some related variables" (1f2cf3cf180a5928171729ce92324952cb172d9f) because it seems like the change output could still be missing until after the nValueToSelect += nFeeRet; line is dropped or no longer doing anything, resulting either in excessive fees paid again or just a failure (forgot details of the part below already....)

achow101

comment created time in 2 minutes

pull request commentbitcoin/bitcoin

guix: Add codesignature attachment support for osx+win

Added commit to use SHA256 as digest for osslsigncode

dongcarl

comment created time in 9 minutes

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::SelectCoinsMinConf(const CAmount& nTargetValue, const CoinEligibil     if (coin_selection_params.use_bnb) {         std::vector<OutputGroup> positive_groups = GroupOutputs(coins, !coin_selection_params.m_avoid_partial_spends, effective_feerate, coin_selection_params.m_long_term_feerate, eligibility_filter, true /* positive_only */);         bnb_used = true;-        return SelectCoinsBnB(positive_groups, nTargetValue, coin_selection_params.m_cost_of_change, setCoinsRet, nValueRet, not_input_fees);+        return SelectCoinsBnB(positive_groups, nTargetValue, coin_selection_params.m_cost_of_change, setCoinsRet, nValueRet);     } else {         // The knapsack solver has some legacy behavior where it will spend dust outputs. We retain this behavior, so don't filter for positive only here.         // The knapsack solver currently does not use effective values, so we give GroupOutputs feerates of 0 so it sets the effective values to be the same as the real value.         std::vector<OutputGroup> groups = GroupOutputs(coins, !coin_selection_params.m_avoid_partial_spends, CFeeRate(0), CFeeRate(0), eligibility_filter, false /* positive_only */);          bnb_used = false;-        return KnapsackSolver(nTargetValue, groups, setCoinsRet, nValueRet);+        return KnapsackSolver(nTargetValue + coin_selection_params.m_change_fee, groups, setCoinsRet, nValueRet);

Our assumption is that KnapsackSolver will always find a result that has change as BnB will find any that do not have change. I've updated the commit message.

achow101

comment created time in 19 minutes

pull request commentbitcoin/bips

New BIP: PoST Datastore for Advanced Cryptography and Higher Efficiency Mining

Hi @MarcoFalke I do apologize if I do sound a bit salty. I will provide a comments summary in this BIP in regards to the concerns on support levels and insight and clarity on that area. I was hoping however, that you would provide comments in regards to which areas you were looking for more expansions on or comments in regards to the tech. Henceforth, my disparaging remarks in the morning. Best regards, Andrew

Mentors4EDU

comment created time in 19 minutes

pull request commentbitcoin/bips

Add Kalle Alm as BIP editor

ACK f5575fb

jnewbery

comment created time in 20 minutes

Pull request review commentrust-bitcoin/rust-lightning

Background processing of ChannelManager and ChannelMonitor events

 impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> MessageSend 	} } -impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> EventsProvider for ChannelManager<Signer, M, T, K, F, L>-	where M::Target: chain::Watch<Signer>,-        T::Target: BroadcasterInterface,-        K::Target: KeysInterface<Signer = Signer>,-        F::Target: FeeEstimator,-				L::Target: Logger,+impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref, E> EventsProvider<E> for ChannelManager<Signer, M, T, K, F, L>+where+	M::Target: chain::Watch<Signer>,+	T::Target: BroadcasterInterface,+	K::Target: KeysInterface<Signer = Signer>,+	F::Target: FeeEstimator,+	L::Target: Logger, {-	fn get_and_clear_pending_events(&self) -> Vec<Event> {+	fn process_pending_events<H: Deref>(&self, handler: H) -> Result<(), E>+	where H::Target: EventHandler<E> {+		let _persistence_guard = PersistenceNotifierGuard::new(&self.total_consistency_lock, &self.persistence_notifier); 		//TODO: This behavior should be documented. It's non-intuitive that we query 		// ChannelMonitors when clearing other events. 		self.process_pending_monitor_events(); -		let mut ret = Vec::new(); 		let mut pending_events = self.pending_events.lock().unwrap();-		mem::swap(&mut ret, &mut *pending_events);-		ret+		for event in pending_events.drain(..) {+			handler.handle_event(event)?;

Right, I guess the only case where errors make sense is some kind of transitory issue that we know will resolve very soon, allowing us to handle the error momentarily while holding off persisting the ChannelManager. That said, I think you could just block in the handler in that case, as long as we only hold an event-specific lock?

Will update this to remove the return type from handle_event.

Maybe we can have a separate lock allowing us to block any other event handlers from entering while still allowing adding new events from other things going on?

pending_events is already behind a Mutex. But I guess if we want to allow other event producers to add more events, we could immediately drop the lock after either draining fully into a Vec or swapping as before.

jkczyz

comment created time in 24 minutes

issue commentsignalapp/Signal-Desktop

Add support for formatting text with Markdown

Sorry if I ask this question: when is this feature planned? If I see it correctly then it is not even planned for any release?

lokesh-krishna

comment created time in 32 minutes

pull request commentlightningdevkit/ldk-sample

Don't panic if broadcast_transaction fails due to duplicate broadcasts

Sg, I'll add another commit updating the upstream commit at that point too.

Shouldn't be needed as of #8.

valentinewallace

comment created time in 40 minutes

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::SelectCoinsMinConf(const CAmount& nTargetValue, const CoinEligibil     if (coin_selection_params.use_bnb) {         std::vector<OutputGroup> positive_groups = GroupOutputs(coins, !coin_selection_params.m_avoid_partial_spends, effective_feerate, coin_selection_params.m_long_term_feerate, eligibility_filter, true /* positive_only */);         bnb_used = true;-        return SelectCoinsBnB(positive_groups, nTargetValue, coin_selection_params.m_cost_of_change, setCoinsRet, nValueRet, not_input_fees);+        return SelectCoinsBnB(positive_groups, nTargetValue, coin_selection_params.m_cost_of_change, setCoinsRet, nValueRet);     } else {         // The knapsack solver has some legacy behavior where it will spend dust outputs. We retain this behavior, so don't filter for positive only here.         // The knapsack solver currently does not use effective values, so we give GroupOutputs feerates of 0 so it sets the effective values to be the same as the real value.         std::vector<OutputGroup> groups = GroupOutputs(coins, !coin_selection_params.m_avoid_partial_spends, CFeeRate(0), CFeeRate(0), eligibility_filter, false /* positive_only */);          bnb_used = false;-        return KnapsackSolver(nTargetValue, groups, setCoinsRet, nValueRet);+        return KnapsackSolver(nTargetValue + coin_selection_params.m_change_fee, groups, setCoinsRet, nValueRet);

In commit "Roll not_input_fees into nValueToSelect instead of having it be separate" (534917d11c12a713b39708290f51f495f370a66d)

Thanks for new code comments, very helpful. IIUC. I'm still a little surprised to see this change here in this commit, instead of in it's own commit or in the "Have KnapsackSolver actually use effective values" commit. Everything else in this commit is not a change in behavior, but this one change passing a higher target to KnapsackSolver is a change in behavior? If this is the case, it would be nice to split this up into two commits, or alternately say how the two different parts of this change are dependent in the commit message.

I'm also curious about tradeoffs with the new behavior. This is probably just my ignorance, but I don't know if it is strictly better to target the change cost, or if there are there expected cases where targeting no-change cost would be better. Would be nice to be able to understand more of this background thinking from the code comment or commit message.

achow101

comment created time in an hour

Pull request review commentbitcoin/bitcoin

Add prune blockers to BlockManager

 int BlockManager::GetSpendHeight(const CCoinsViewCache& inputs)     return pindexPrev->nHeight + 1; } +const CBlockIndex* BlockManager::GetLastPruneBlock(const CBlockIndex* start_block) {+    const CBlockIndex* block = start_block;+    CHECK_NONFATAL(block);

Thanks! I made the changes as suggested.

fjahr

comment created time in 43 minutes

pull request commentlightningdevkit/ldk-sample

Don't panic if broadcast_transaction fails due to duplicate broadcasts

Will merge once rust-bitcoin/rust-lightning#919 is merged upstream.

Sg, I'll add another commit updating the upstream commit at that point too.

valentinewallace

comment created time in 44 minutes

pull request commentlightningdevkit/ldk-sample

Don't panic if broadcast_transaction fails due to duplicate broadcasts

Will merge once https://github.com/rust-bitcoin/rust-lightning/pull/919 is merged upstream.

cc: @TheBlueMatt

valentinewallace

comment created time in an hour

Pull request review commentbitcoin/bitcoin

wallet: Fix issues when `walletdir` is root directory(Windows)

 std::vector<fs::path> ListDatabases(const fs::path& wallet_dir)         try {             // Get wallet path relative to walletdir by removing walletdir from the wallet path.             // This can be replaced by boost::filesystem::lexically_relative once boost is bumped to 1.60.-            const fs::path path = it->path().string().substr(offset);+            fs::path path = wallet_dir.string();

You could still keep path const as before, by utilizing immediately-invoked lambda, as suggested in ES.28: Use lambdas for complex initialization, especially of const variables guideline, with something like this (also avoiding re-initializing path variable):

            const fs::path path = [&wallet_dir, &it, offset]() {

                if (wallet_dir == wallet_dir.root_path()) {
                   return it->path().string().substr(offset - 1);
                }

                return it->path().string().substr(offset);
            }();

Not sure if this is the best way to do that overall, as I don't have basically any experience with boost/stl filesystem...

prayank23

comment created time in an hour

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

That's indeed the main reason I wrote this, though I can see how it's useful for redownloading pruned blocks too.

I'm using this for ForkMonitor to fetch stale blocks and compare the transactions, to see if there was a double-spend: https://forkmonitor.info/stale/btc/679823

Sjors

comment created time in an hour

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

Oh, I see. I missed that fetching non-main-chain blocks was a goal here.

Why would you want that?

Sjors

comment created time in an hour

issue commentbitcoin/bitcoin

ci: ccache does not work for macOS cross-compiling builds

Urgh... That kinda sucks... I think the easiest solution is perhaps to wait until ccache 4.1 is available on all distros and set compiler_type/CCACHE_COMPILERTYPE?

hebasto

comment created time in an hour

PR opened ElementsProject/secp256k1-zkp

Replace MuSig(1) module with MuSig2

The main commit comprises 905 insertions(+), 1253 deletions(-). The diff isn't as small as I had hoped, but that's mostly because it was possible to simplify the API quite substantially which required rewriting large parts. Sorry, almost all of the changes are in one big commit which makes the diff very hard to read. Perhaps best to re-review most parts from scratch.

A few key changes:

  • Obviously no commitment round. No big session struct and no verifier sessions. No signer struct.
  • There's a new secnonce struct that is the output of musig_session_init and derived from a uniformly random session_id32. The derivation can be strengthened by adding whatever session parameters (combined_pk, msg) are available. The nonce function is my ad-hoc construction that allows for these optional inputs. Please have a look at that.
  • The secnonce is made invalid after being used in partial_sign.
  • Adaptor signatures basically work as before, according to https://github.com/ElementsProject/scriptless-scripts/pull/24
  • To avoid making this PR overly complex I did not consider how this implementation interacts with nested-MuSig, sign-to-contract, and antiklepto.
  • Testing should be close to complete. There's no reachable line or branch that isn't exercised by the tests.
  • [ ] In the current implementation when a signer sends an invalid nonce (i.e. some garbage that can't be mapped to a group element), it is ignored when combining nonces. Only after receiving the signers partial nonce and running partial_nonce_verify will we notice that the signer misbehaved. The reason for this is that 1) this makes the API simpler and 2) malicious peers don't gain any additional powers because they can always interrupt the protocol by refusing to sign. However, this is up for discussion.
  • [ ] For every partial signature we verify we have to parse the pubnonce (two compressed points), despite having parsed it in process_nonces already. This is not great. process_nonces could optionally output the array of parsed pubnonces.
  • [ ] I left src/modules/musig/musig.md unchanged for now. Perhaps we should merge it with the musig-spec
  • [ ] partial verification should use multiexp to compute R1 + b*R2 + c*P, but this can be done in a separate PR
  • [ ] renaming wishlist
    • pre_session -> keyagg_cache (because there is no session anymore)
    • pubkey_combine, nonce_combine, partial_sig_combine -> pubkey_agg, nonce_agg, partial_sig_agg (shorter, matches terminology in musig2)
    • musig_session_init -> musig_start (shorter, simpler)
    • musig_partial_signature to musig_partial_sig (shorter)

Based on #120.

+1883 -1298

0 comment

16 changed files

pr created time in an hour

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::CreateTransactionInternal(                     return false;                 } -                nFeeNeeded = coin_selection_params.m_effective_feerate.GetFee(nBytes);-                if (nFeeRet >= nFeeNeeded) {-                    // Reduce fee to only the needed amount if possible. This-                    // prevents potential overpayment in fees if the coins-                    // selected to meet nFeeNeeded result in a transaction that-                    // requires less fee than the prior iteration.--                    // If we have no change and a big enough excess fee, then-                    // try to construct transaction again only without picking-                    // new inputs. We now know we only need the smaller fee-                    // (because of reduced tx size) and so we should add a-                    // change output. Only try this once.-                    if (nChangePosInOut == -1 && nSubtractFeeFromAmount == 0 && pick_new_inputs) {-                        unsigned int tx_size_with_change = nBytes + coin_selection_params.change_output_size + 2; // Add 2 as a buffer in case increasing # of outputs changes compact size-                        CAmount fee_needed_with_change = coin_selection_params.m_effective_feerate.GetFee(tx_size_with_change);-                        CAmount minimum_value_for_change = GetDustThreshold(change_prototype_txout, coin_selection_params.m_discard_feerate);-                        if (nFeeRet >= fee_needed_with_change + minimum_value_for_change) {-                            pick_new_inputs = false;-                            nFeeRet = fee_needed_with_change;-                            continue;-                        }-                    }

I think the key thing in understanding this code is that nChange (now named change_and_fee) was actually supposed to just be the change. nValueToSelect includes the nFeeRet from the previous iteration. So we could have nChange == 0 if we select exactly enough to cover the recipient amount + previous nFeeRet. That would cause this code to trigger.

achow101

comment created time in an hour

pull request commentbitcoin/bitcoin

wallet: Fix issues when `walletdir` is root directory(Windows)

Welp, I did crazy thing and launched bitcoind as root, with:

sudo src/bitcoind -regtest -walletdir=/ -datadir=/tmp/datadir -server

Created wallet, and then listed:

{
  "wallets": [
    {
      "name": "est"
    },
    {
      "name": "ome/vincas/.bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-8198c6f7-2f0b-4394-a92a-d4d738994f33/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-9063e6a5-c013-4127-a7dd-a10a3874ed18/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-e9783f5b-51ab-458f-ab57-31976e38bff8/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-f1c34eba-d63e-4379-a315-75056bbcc162/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-d4096df3-5adb-40dd-9425-6f80fb6fd07b/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/eclair/eclair_recovery_tool.git/eclair-core/target/integration-e6a27da9-a78e-48a5-a272-38a950ddfd41/datadir-bitcoin/regtest/wallets"
    },
    {
      "name": "ome/vincas/code/bitcoin/123-bitcoin-core-gui.git/test/functional/data/wallets/high_minversion"
    },
    {
      "name": "ome/vincas/code/bitcoin/149-bitcoin-core-gui.git/test/functional/data/wallets/high_minversion"
    }
  ]
}

Interesting to see bitcoind scan whole system for wallets :D (log even printed ListDatabases: Error scanning /sys/fs/bpf: boost::filesystem::status: Operation not permitted: "/sys/fs/bpf/wallet.dat").

Anyhow, issue is the same on Linux, and this PR did fix that too:

{
  "wallets": [
    {
      "name": "test"
    },
...same...
prayank23

comment created time in an hour

issue commentsignalapp/Signal-Desktop

Add support for formatting text with Markdown

I'd also love to see the support of ``` code quotes in Signal. Telegram supports it and it make shared code a lot more pleasant to read.

This is the most important one. If I want to share something, like an email, I want the entire thing to be quoted and any links to be inactive, etc.

lokesh-krishna

comment created time in an hour

Pull request review commentbitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

 def test_rpc(self):         assert_equal(json0["vin"][0]["sequence"], 4294967293)         assert_equal(json1["vin"][0]["sequence"], 4294967294) +    def test_no_inherited_signaling(self):+        # Send tx from which to conflict outputs later+        base_txid = self.nodes[0].sendtoaddress(self.nodes[0].getnewaddress(), Decimal("10"))+        self.nodes[0].generate(1)+        self.sync_blocks()++        # Create a explicitly opting parent transaction+        optin_parent_tx = self.nodes[0].createrawtransaction([{+            'txid': base_txid,+            'vout': 0,+            "sequence": 0xfffffffd,+        }], {self.nodes[0].getnewaddress(): Decimal("9.99998")})++        optin_parent_tx = self.nodes[0].signrawtransactionwithwallet(optin_parent_tx)++        # Broadcast parent tx+        optin_parent_txid = self.nodes[0].sendrawtransaction(hexstring=optin_parent_tx["hex"], maxfeerate=0)+        assert optin_parent_txid in self.nodes[0].getrawmempool()++        replacement_parent_tx = self.nodes[0].createrawtransaction([{+            'txid': base_txid,+            'vout': 0,+            "sequence": 0xfffffffd,+        }], {self.nodes[0].getnewaddress(): Decimal("9.90000")})++        replacement_parent_tx = self.nodes[0].signrawtransactionwithwallet(replacement_parent_tx)++        # Test if parent tx can be replaced.+        res = self.nodes[0].testmempoolaccept(rawtxs=[replacement_parent_tx['hex']], maxfeerate=0)[0]++        # Parent can be replaced.+        assert_equal(res['allowed'], True)++        # Create a optout child tx spending opting parent+        optout_child_tx = self.nodes[0].createrawtransaction([{+            'txid': optin_parent_txid,+            'vout': 0,+            "sequence": 0xffffffff,+        }], {self.nodes[0].getnewaddress(): Decimal("9.99990")})++        optout_child_tx = self.nodes[0].signrawtransactionwithwallet(optout_child_tx)++        # Broadcast child tx+        optout_child_txid = self.nodes[0].sendrawtransaction(hexstring=optout_child_tx["hex"], maxfeerate=0)+        assert optout_child_txid in self.nodes[0].getrawmempool()++        replacement_child_tx = self.nodes[0].createrawtransaction([{+            'txid': optin_parent_txid,+            'vout': 0,+            "sequence": 0xffffffff,+        }], {self.nodes[0].getnewaddress(): Decimal("9.00000")})++        replacement_child_tx = self.nodes[0].signrawtransactionwithwallet(replacement_child_tx)++        # Broadcast replacement child tx+        # BIP 125 :+        # 1. The original transactions signal replaceability explicitly or through inheritance as described in the above+        # Summary section.

This is a good place to refer to the CVE so it's clear the behaviour here is not following BIP125.

ariard

comment created time in an hour

issue commentsignalapp/Signal-Desktop

"Error processing image" when adding image to Sticker pack creator

@gabrc52 Thanks for pointing this out. I can confirm that this works with the flatpak release :)

righy

comment created time in an hour

pull request commentbitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

utACK fb2047b

ariard

comment created time in an hour

pull request commentbitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

Also, I had a look on the rest of RBF functional test coverage (i.e feature_rbf.py, mempool_accept.py, p2p_invalid_tx.py). AFAICT, the latest check on incremental relay fee increase doesn't seem to have coverage ?

ariard

comment created time in an hour

PR opened bitcoin/bitcoin

Document and test lack of inherited signaling in RBF policy

Contrary to BIP125 or other full-node implementation (e.g btcd), Bitcoin Core's mempool policy doesn't implement inherited signaling.

This PR documents our mempool behavior on it and add a test demonstrating the case.

+73 -4

0 comment

2 changed files

pr created time in an hour

pull request commentbitcoin/bitcoin

rpc: getblockfrompeer

@sipa we don't fetch a block if we already have one for that height. So if you're trying retrieve the losing block from a race, most likely your peers also saw it later and didn't fetch it.

Sjors

comment created time in an hour

issue commentsignalapp/Signal-Desktop

"Error processing image" when adding image to Sticker pack creator

@kommulu I am on Fedora 34 (Flatpak) and it works fine; it's probably a missing library on your system. The Signal team might need to add that dependency to the list, but it should be filed as a separate issue.

righy

comment created time in 2 hours

Pull request review commentbitcoin/bitcoin

Use effective values throughout coin selection

 bool CWallet::CreateTransactionInternal(                     return false;                 } -                nFeeNeeded = coin_selection_params.m_effective_feerate.GetFee(nBytes);-                if (nFeeRet >= nFeeNeeded) {-                    // Reduce fee to only the needed amount if possible. This-                    // prevents potential overpayment in fees if the coins-                    // selected to meet nFeeNeeded result in a transaction that-                    // requires less fee than the prior iteration.--                    // If we have no change and a big enough excess fee, then-                    // try to construct transaction again only without picking-                    // new inputs. We now know we only need the smaller fee-                    // (because of reduced tx size) and so we should add a-                    // change output. Only try this once.-                    if (nChangePosInOut == -1 && nSubtractFeeFromAmount == 0 && pick_new_inputs) {-                        unsigned int tx_size_with_change = nBytes + coin_selection_params.change_output_size + 2; // Add 2 as a buffer in case increasing # of outputs changes compact size-                        CAmount fee_needed_with_change = coin_selection_params.m_effective_feerate.GetFee(tx_size_with_change);-                        CAmount minimum_value_for_change = GetDustThreshold(change_prototype_txout, coin_selection_params.m_discard_feerate);-                        if (nFeeRet >= fee_needed_with_change + minimum_value_for_change) {-                            pick_new_inputs = false;-                            nFeeRet = fee_needed_with_change;-                            continue;-                        }-                    }

It's change boosting but in the case where we don't have change.

It's the same scenario as change boosting, but instead of having selected more than enough to cover the fees from the previous iteration, we have selected exactly enough to cover those fees. But in this second iteration, there are fewer inputs, so fewer fees, so we need to add a change output because there is no existing change to boost.

I keep linking to line 2683: https://github.com/bitcoin/bitcoin/blob/0f402b9263b0579b29aa0f841fc64ad58d3efba6/src/wallet/wallet.cpp#L2683

Because in every case where the code below it (line 2766) would seemingly need to add a change output, it seems like this line would already have added it. This line happens after selecting coins in the same iteration of the while loop. My only understanding (which makes no sense) is that the code is selecting coins, seeing if a change output needs to be added, then adding it on line 2683. Then seeing if a change output needs to be added again on line 2766, but this code can never trigger because the change output should be already added.

If the code added in 0f402b9263b0579b29aa0f841fc64ad58d3efba6 is just nonsense that doesn't do anything, then it should be safe to drop. And it could be safe to drop anyway. Everything else in this PR looks good, just these CreateTransactionInternal changes are still pretty opaque to me.

achow101

comment created time in 2 hours

PR opened bitcoin/bitcoin

test: add P2PK support to MiniWallet

This PR adds support for creating and spending transactions with raw pubkey (P2PK) outputs to MiniWallet, as suggested by MarcoFalke. Using that mode in the test feature_csv_activation.py, all txs submitted to the mempool follow the standard policy, i.e. -acceptnonstdtxn=1 can be removed.

Possible follow-ups:

  • Improve MiniWallet constructor Interface; an enum-like parameter instead of two booleans would probably be better
  • Look at other tests that could benefit from P2PK (e.g. feature_cltv.py?)
  • Check vsize also for P2PK txs (vsize varies due to signature, i.e. a range has to be asserted)
+44 -8

0 comment

2 changed files

pr created time in 2 hours

issue commentsignalapp/Signal-Desktop

"Error processing image" when adding image to Sticker pack creator

Just updated to 5.1.0 on Fedora 34 and the issue is still present, but changed. The window for creating a stickerpack now opens and just stays blue. Debuglog shows this:

ERROR 2021-05-13T17:39:07.986Z Preload error in [REDACTED]/app.asar/sticker-creator/preload.js:  
Something went wrong installing the "sharp" module

libvips-cpp.so.42: cannot open shared object file: No such file or directory

- Remove the "node_modules/sharp" directory then run
  "npm install --ignore-scripts=false --verbose sharp" and look for errors
- Consult the installation documentation at https://sharp.pixelplumbing.com/install
- Search for this error at https://github.com/lovell/sharp/issues
righy

comment created time in 2 hours