profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/luke-jr/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.

luke-jr/bfgminer 1530

Modular ASIC/FPGA miner written in C, featuring overclocking, monitoring, fan speed control and remote interface capabilities.

luke-jr/eloipool 107

Fast Python3 Bitcoin pool server

bitcoinknots/bitcoin 106

Bitcoin Knots enhanced Bitcoin node/wallet software

luke-jr/BitForce_SC 43

BitForce SC MCU firmware

luke-jr/bips 21

Bitcoin Improvement Proposals

luke-jr/bitcoin 16

Bitcoin integration/staging tree

luke-jr/freeabode 10

Home automation software

luke-jr/cgminer 5

CPU/GPU miner in c for bitcoin

luke-jr/ddrescue-fuse 4

FUSE filesystem to prioritise ddrescue domain on demand

PR closed bitcoin-core/secp256k1

ci: Set -Werror for all CI builds

Let's see if that passes...

+94 -63

3 comments

5 changed files

real-or-random

pr closed time in 2 minutes

PR merged bitcoin-core/secp256k1

Add ARM32/ARM64 CI
+49 -0

6 comments

2 changed files

sipa

pr closed time in 4 minutes

push eventbitcoin-core/secp256k1

Pieter Wuille

commit sha 7d65ed5214273275841f5aa272ad561df7ea7f21

Add ARM32/ARM64 CI

view details

Pieter Wuille

commit sha 8bbad7a18e5dc5054b27ae44ea0c8dffe050f6bf

Add asm build to ARM32 CI

view details

Jonas Nick

commit sha bf0ac460661849828e7afcbf9870acb3cbb696f5

Merge #930: Add ARM32/ARM64 CI 8bbad7a18e5dc5054b27ae44ea0c8dffe050f6bf Add asm build to ARM32 CI (Pieter Wuille) 7d65ed5214273275841f5aa272ad561df7ea7f21 Add ARM32/ARM64 CI (Pieter Wuille) Pull request description: ACKs for top commit: real-or-random: ACK 8bbad7a18e5dc5054b27ae44ea0c8dffe050f6bf CI output looks fine jonasnick: ACK 8bbad7a18e5dc5054b27ae44ea0c8dffe050f6bf Tree-SHA512: 090a52af6914cf9fb659f9626a8224d82c8da81f6e628b7300e34851e198d8299dfd25789c0f1d6f2c79f58b5413be498f9fba43bc50238480fe6524b640538a

view details

push time in 4 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 6 minutes

pull request commentbitcoin-core/secp256k1

VERIFY_CHECK precondition for secp256k1_fe_set_int.

Cherry-picked.

Now that I look at it again, do you think the VERIFY_CHECK's I add are really needed? Any overflow will be caught by the subsequent secp256k1_fe_verify. So maybe I should just stick with your one commit.

roconnor-blockstream

comment created time in 15 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 16 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 16 minutes

pull request commentbitcoin-core/gui

rpc: Do not accept command while executing another one

Not sure if I understand your question in part "producing GitHub review"...

In Github web interface, we can go to "Files changed" tab, check "Viewed" checkboxes on the files, and click "Review changes" -> "Submit review", which produces sort of "special" kind of "comment". Maybe it's "better" for maintainers to check for these kind of "reviews", instead of "just" a comment?

In this project we strive to rely on GitHub as little as possible :) Ofc, a reviewer could use any GitHub feature he like. Features you mentioned make no difference for maintainers.

hebasto

comment created time in 16 minutes

pull request commentbitcoin/bips

Add Kalle Alm as BIP editor

ACK f5575fb

jnewbery

comment created time in 17 minutes

push eventbitcoin-core/secp256k1

Andrew Poelstra

commit sha 0d9561ae879848191a14bcc67db87cbfd44fb69a

add `secp256k1_ec_pubkey_cmp` method

view details

Andrew Poelstra

commit sha 6eceec6d566898a5c157630e47f95b260767026b

add `secp256k1_xonly_pubkey_cmp` method

view details

Jonas Nick

commit sha 202a030f7d1cb299dcb1c6d1e64c4af72aa7924f

Merge #850: add `secp256k1_ec_pubkey_cmp` method 6eceec6d566898a5c157630e47f95b260767026b add `secp256k1_xonly_pubkey_cmp` method (Andrew Poelstra) 0d9561ae879848191a14bcc67db87cbfd44fb69a add `secp256k1_ec_pubkey_cmp` method (Andrew Poelstra) Pull request description: ACKs for top commit: elichai: Code review ACK 6eceec6d566898a5c157630e47f95b260767026b jonasnick: ACK 6eceec6d566898a5c157630e47f95b260767026b real-or-random: ACK 6eceec6d566898a5c157630e47f95b260767026b Tree-SHA512: f95cbf65f16c88a4adfa1ea7cc6ddabab14baa3b68fa069e78e6faad4852cdbfaea42ee72590d2e0b8f3159cf9b37969511550eb6b2d256b101e2147711cc817

view details

push time in 18 minutes

pull request commentbitcoin-core/gui

rpc: Do not accept command while executing another one

Not sure if I understand your question in part "producing GitHub review"...

In Github web interface, we can go to "Files changed" tab, check "Viewed" checkboxes on the files, and click "Review changes" -> "Submit review", which produces sort of "special" kind of "comment". Maybe it's "better" for maintainers to check for these kind of "reviews", instead of "just" a comment?

hebasto

comment created time in 22 minutes

issue commentbitcoin-core/gui

bitcoinbuilds.org macOS CI is broken

It should adopt https://github.com/bitcoin/bitcoin/pull/19817 changes.

Sjors

comment created time in 30 minutes

pull request commentbitcoin-core/gui

WIP qt: mempool stats chart

I would prefer MB over count too if it's not too difficult. I might take a look a later to see how...

Can you split this PR a bit? E.g. one commit for the src/interfaces changes, one for mempoolstats.cpp (which probably should mostly be moved out of the GUI code), one for the UI change, etc.

RandyMcMillan

comment created time in 34 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 40 minutes

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 openedbitcoin-core/gui

bitcoinbuilds.org macOS CI is broken

See e.g. https://github.com/bitcoin-core/gui/pull/325 build log: https://bitcoinbuilds.org/index.php?ansilog=be6bfe20-7e28-4344-9664-6ae1ff46dbb9.log

4643   In file included from ./boost/config.hpp:44:
L4644   ./boost/config/detail/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
L4645   #  include <cstddef>
L4646              ^~~~~~~~~
L4647   1 error generated.

cc @jonasschnelli

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

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

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-core/secp256k1

VERIFY_CHECK precondition for secp256k1_fe_set_int.

@roconnor-blockstream Maybe cherry-pick https://github.com/bitcoin-core/secp256k1/pull/636/commits/b17a7df8145a6a86d49c354c7e7b59a432ea5346 (or just steal my improved comment for here.) and then add the VERIFY_CHECK here.

roconnor-blockstream

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