<bitcoin-git>
bitcoin/master 1bbe289 W. J. van der Laan: Merge bitcoin/bitcoin#22565: [script] signet's getcoins.py improvements
<bitcoin-git>
[bitcoin] Saibato opened pull request #22781: wallet: fix the behavior of IsHDEnabled, return false in case of a blank hd wallet. (master...fix_ishdenabled) https://github.com/bitcoin/bitcoin/pull/22781
<laanwj>
sipa: yeah, true, it's just that we now have squashed most of the usability issues in bitcoin-cli (after the libevent switch), that would basically start over
<sipa>
iirc, my suggestion at the time was just dropping libevent for bitcoin-cli, as bitcoind-compatible-httpd should be very simple to implement by hand :)
<bitcoin-git>
[bitcoin] darosior opened pull request #22779: policy: correct (lower) the dust threshold for Taproot outputs (master...taproot_dust_limit) https://github.com/bitcoin/bitcoin/pull/22779
<laanwj>
if you don't care about bitcoin-cli (e.g. use it from python) server-side might be enough thogh
<laanwj>
so we basically cannot do it, at least in bitcoin-cli, without some really ugly hacks around libevent
<Randolf>
videre_e: This is the development channel. For mining questions, please ask in the #bitcoin-mining channel instead: /join #bitcoin-mining
<bitcoin-git>
bitcoin/master 6bb5470 nthumann: util: Check if specified config file cannot be opened
<bitcoin-git>
[bitcoin] glozow closed pull request #22252: policy: Trim Packages when transaction with same txid exists in mempool (master...2021-06-mempool-matches) https://github.com/bitcoin/bitcoin/pull/22252
<bitcoin-git>
[bitcoin] jnewbery opened pull request #22777: net processing: don't request tx relay on feeler connections (master...2021-08-feeler-no-frelay) https://github.com/bitcoin/bitcoin/pull/22777
<bitcoin-git>
[bitcoin] fanquake merged pull request #22275: A few follow-ups for taproot signing (master...202106_taproot_sign_followup) https://github.com/bitcoin/bitcoin/pull/22275
<bitcoin-git>
[bitcoin] ben-kaufman opened pull request #22775: rpc: Add option to list transactions from oldest to newest in `listtransactions` RPC command (master...listtransactions-set-order) https://github.com/bitcoin/bitcoin/pull/22775
2021-08-22
<laanwj>
but lets move GUI discussion to #bitcoin-core-gui
<laanwj>
i think what projects like umbrel do right is to treat core as a component, not as something that should absorb or include all the other functionality, they make it more user friendly by offering things like web guis and a way to install and manage everything bitcoin related as a suite
<bitcoin-git>
[bitcoin] mzumsande opened pull request #22772: refactor: hasher cleanup (follow-up to 19935) (master...202108_hasher_cleanup) https://github.com/bitcoin/bitcoin/pull/22772
<prayank>
laanwj: Are these ever discussed before? 1. Bitcoin Core web console like i2p has a webpage at 127.0.0.1:7070. We could add lot of thing in it that are normally rejected for qt. Example: Mempool charts and other charts (basics) 2. Plugins for qt like Electrum
<bitroach>
I can add Github integration to the Bitcoin Forum pretty easily, lets see how you guys will like the forum first ;)
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22769: fuzz: Use LIMITED_WHILE instead of limit_max_ops (master...2108-fuzzRefactor) https://github.com/bitcoin/bitcoin/pull/22769
<bitroach>
I open the forum soon as I published the Bitcoin paper in markdown (I did just had some issue with the database what I fixed) also by default all users has end-to-end encrypted PMs enabled which based on BIP-39, PMs can't be scanned by the AI as you imagine because of the strong encryption
<bitroach>
the current Bitcoin environment like r/Bitcoin the IRC channels like this one as well the GitHub repo and the theymos and cobrabitcoin run Bitcoin sites are brutally censored and extremely centralized in the hands of a few, I'm the person who going to change that and nobody can do absolutely nothing to stop what is coming
<bitroach>
Artifical Intelligence also deployed on the Bitcoin Forum so trolls has no chance, they post will be hidden by the AI soon as they click the submit button
<bitroach>
both Bitcoin Core discussions and Bitcoin Cash discussions are welcome to the Bitcoin Forum, I'm only going to censor those who in any way advocate for Blockstream
<bitroach>
Bitcoin Cash is still Bitcoin, possibly even more than the current Bitcoin Core
<bitroach>
Just to make it clear, I allow Bitcoin Cash to be on the Bitcoin Forum, why would I censor Roger Ver and Kim DotCom?
<bitroach>
funny isn't? I offering thousands of dollars + working on a Bitcoin Forum and I get attacked, banned and censored on IRC
<bitroach>
I even offered over 20% donation to Bitcoin Core from all the forum related income, I talked with luke-jr and I would only pay to him nobody else, we didn't agree in the terms yet I just offered a cut
<bitroach>
I'm open for helping Bitcoin Core Developers by allowing them to join the Bitcoin Forum, Bitcoin Core Developers have exclusive right to post and moderate the Development category on the forum. At one point I considered to approve all signups with @bitcoincore.org emails and grant them developer badges, but after that my domain is censored on IRC I changed my mind pretty quickly. currently the only person I respect is luke-jr,
<bitcoin-git>
[bitcoin] n-thumann opened pull request #22768: script: Add commits signed with sipas expired key to allow-revsig-commits (master...add_sipa_expired_key_signed_commits) https://github.com/bitcoin/bitcoin/pull/22768
<bitroach>
I'm not theymos bud, I don't hide and certainly not scamming and stealing 11,000 Bitcoin
<bitroach>
I'm definitely going to call Bitcoiners to abandon all Bitcoin related IRC channels because run by fucktards who censor it
<bitroach>
well, turned out that Zoltan controls the Bitcoin Forum, keep bullshitting and each of you will be doxed in a nice topic
<bitroach>
you can clearly see that by linking my Bitcoin Forum
<bitroach>
American anti-chinese anti-russian motherfuckers pushing for propaganda even on Bitcoin related IRC channels
<bitroach>
if any ops trolling the forum I will publish a topic and will call Bitcoin Core developers terrorists
<bitroach>
let me absolutely clear, none of you welcome on the Bitcoin Forum and I find any of you (talking about the ops on these channels) will be immediately kicked banned from the Bitcoin Forum
<bitroach>
you can't link a bitcoin forum without approval from the motherfuckers who think they own Bitcoin
<bitroach>
I getting kicked from these channels because I own the bitcoin.forum domain if you link https://bitcoin.forum you will be immediately kicked from these channels
<michaelfolkson>
bitroach: If you get kicked from #bitcoin you can move to another channel or set up your own channel. But this definitely isn't the right channel for general ranting.
<bitroach>
I just compiled Bitcoin Core on another server I own with --disable-wallet and --without-gui yet when I go to the .bitcoin folder there is a folder called wallets
<bitroach>
Gavin Andresen's access to the GitHub repository revoked and all kinds of shit merged to Bitcoin Core without any vote whatsoever
<bitroach>
they not forked the repository, they paid out millions of dollars to merge they crap to Bitcoin core
<bitroach>
why segwit or taproot can't be a fork outside of Bitcoin Core?
<bitroach>
little bit of money here and there and all developers agree to merge crap and destroy Bitcoin
<bitroach>
they trolled Bitcoin Core
<bitroach>
basically with segwit and now with taproot blockstream totally taken over the Bitcoin core repository on GitHub
<bitroach>
I have all right to be outraged about this blockstream crap and the propaganda on the Bitcoin repository on GitHub
<bitroach>
#bitcoin is censored, in fact all bitcoin related channel, forums even github is censored
<bitroach>
segwit and taproot is merged to Bitcoin core because devs working for blockstream inc
<meshcollider>
bitroach: you should move to #bitcoin, but most of the devs aren't employed by blockstream, no. There's a big variety in developer funding (volunteers, grants, sponsorship, patreon, employment, etc.)
<bitroach>
I believe that Bitcoin is in danger, number 1, it is controlled by a very few people when there are way better engineers in the world, number 2, these so called "developers" working for various corporations not only to Blockstream Inc, example Amazon and Google
<bitroach>
isn't Bitcoin supposed to be independent from corporations and governments?
<bitroach>
Blockstream Inc's payees merged segwit and now they merging taproot too into the Bitcoin core software
<bitroach>
does Bitcoin core developers get paid by Blockstream inc?
<bitroach>
I have some questions regarding Bitcoin development
<bitcoin-git>
[bitcoin] ryanofsky opened pull request #22766: refactor: Clarify and disable unused ArgsManager flags (master...pr/argscripts) https://github.com/bitcoin/bitcoin/pull/22766
<bitcoin-git>
[bitcoin] hebasto opened pull request #22764: build: Include qt sources for parsing with extract_strings.py (master...210821-translation) https://github.com/bitcoin/bitcoin/pull/22764
<bitcoin-git>
[bitcoin] prakash1512 opened pull request #22763: fuzz: execute each file in dir without fuzz engine (master...issue-21461-execute-file-without-fuzz-engine) https://github.com/bitcoin/bitcoin/pull/22763
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22762: Raise InitError when peers.dat is invalid or corrupted (master...2108-InitErrorAddrmanCorrupt) https://github.com/bitcoin/bitcoin/pull/22762
<robertspigler>
prayank: If you're trying to build a private tx broadcasting scheme into bitcoin, we need to come up with something more complete. Like Dandelion with DoS issues figured out
<prayank>
No. Because I am trying to improve privacy of Bitcoin Core (ipv4) nodes and not create another privacy project for broadcasting transactions.
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22757: test: Use boost::unit_test::enable_if<RUN_RAII_EVENT_TESTS> (master...2108-testEnableIf) https://github.com/bitcoin/bitcoin/pull/22757
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22707: test: refactor use of getrawmempool in functional tests for efficiency (master...test_improve_mempool_updatefromblock_efficiency) https://github.com/bitcoin/bitcoin/pull/22707
<bitcoin-git>
bitcoin/master 86dbd54 Michael Dietz: test: improve mempool_updatefrom efficiency by using getmempoolentry for s...
<bitcoin-git>
bitcoin/master 5a9e255 Hennadii Stepanov: ci: Run fuzzer task for the master branch only
<bitcoin-git>
[bitcoin] fanquake closed pull request #22731: [DO NOT MERGE, DEMO] [22.0] ci: Run fuzz tests for the master branch only (22.x...210817-22.0-ci-fuzz) https://github.com/bitcoin/bitcoin/pull/22731
<jonatack>
Chris_Stewart_5: would the section in doc/tor.md "Manually create a Bitcoin Core onion service" do what you want? e.g.
<Chris_Stewart_5>
1. It allows inbound connections, 2. Doesn't gossip the peer address across the bitcoin network
<laanwj>
information leakage is kept to a minimum, too, with an extra P2P connection in bitcoin core there's always the risk of some fingerprinting vector we don't yet know of, for example
<prayank>
If you are using a node it will broadcast transactions. If it is not using Tor/i2p which most of the nodes do, your peers can keep an eye on your transactions. Let's assume every time I launch Bitcoin Core it connects with 3 spy nodes. This functionality can improve privacy by making it difficult for spy nodes to follow specific pattern. But I agree few things are best when added as plugins. Unfortunately we don't have plugins in Core.
<bitcoin-git>
[bitcoin] MarcoFalke closed pull request #20362: test: Implicitly sync after generate* to preempt races and intermittent test failures (master...2011-noSync) https://github.com/bitcoin/bitcoin/pull/20362
<sipa>
so it's restrictive to build it into bitcoin core; it's more usable if it's something external
<sipa>
but even if that doesn't suffice, there isn't much need for this functionality to be in bitcoin core - it doesn't need an actual node
<bitcoin-git>
bitcoin/master 607a633 fanquake: Merge bitcoin/bitcoin#22331: crypto: Fix K1/K2 use in ChaCha20-Poly1305 AE...
<bitcoin-git>
bitcoin/master cd37356 Dhruv Mehta: [crypto] Fix K1/K2 use in ChaCha20-Poly1305 AEAD
<bitcoin-git>
[bitcoin] fanquake opened pull request #22739: doc: link to managing-wallets from docs README (master...link_managing_wallets) https://github.com/bitcoin/bitcoin/pull/22739
2021-08-18
<bitcoin-git>
[bitcoin] fanquake merged pull request #22724: windres: use PACKAGE_VERSION rather than building more version numbers (master...windres_version_somplify) https://github.com/bitcoin/bitcoin/pull/22724
<bitcoin-git>
[bitcoin] fanquake closed pull request #21496: fuzz: execute each file in dir without fuzz engine (master...21461-fuzz-directory-without-engine) https://github.com/bitcoin/bitcoin/pull/21496
<bitcoin-git>
[bitcoin] fanquake closed pull request #14049: Enable libsecp256k1 ecdh module, add ECDH function to CKey (master...2018/08/bip151_ecdh) https://github.com/bitcoin/bitcoin/pull/14049
<bitcoin-git>
[bitcoin] fanquake closed pull request #18242: Add BIP324 encrypted p2p transport de-/serializer (only used in tests) (master...2020/03/net_v2) https://github.com/bitcoin/bitcoin/pull/18242
<bitcoin-git>
[bitcoin] fanquake merged pull request #22732: net: use m_client_interface rather than uiInterface (master...use_uiinterface_in_net) https://github.com/bitcoin/bitcoin/pull/22732
<bitcoin-git>
bitcoin/master e35c4a3 fanquake: Merge bitcoin/bitcoin#22732: net: use m_client_interface rather than uiInt...
<bitcoin-git>
[bitcoin] MarcoFalke closed pull request #22498: Check that CAddrMan::nKey is not null after deserialize (master...2107-addrmanKeyZero) https://github.com/bitcoin/bitcoin/pull/22498
<bitcoin-git>
[bitcoin] fanquake opened pull request #22732: net: use m_client_interface rather than uiInterface (master...use_uiinterface_in_net) https://github.com/bitcoin/bitcoin/pull/22732
<bitcoin-git>
bitcoin/master 5c5d0b6 Russell Yanofsky: Add FoundBlock.found member
<bitcoin-git>
bitcoin/master 62cb400 fanquake: Merge bitcoin/bitcoin#22215: refactor: Add FoundBlock.found member
<larryruane>
Found a couple of typos in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/22.0-Release-Candidate-Testing-Guide (I don't have permissions to change): line 173, "lets" should be "let's", and (more importantly) line 198, "wait" probably meant to be "watch" (the wait command makes no sense here)... If someone could fix those, I'd appreciate it!
2021-08-17
<bitcoin-git>
[bitcoin] hebasto opened pull request #22731: [DO NOT MERGE, DEMO] [22.0] ci: Run fuzz tests for the master branch only (22.x...210817-22.0-ci-fuzz) https://github.com/bitcoin/bitcoin/pull/22731
<bitcoin-git>
[bitcoin] vasild opened pull request #22729: Make it possible to disable and check for error in -bind=...=onion (master...torbind) https://github.com/bitcoin/bitcoin/pull/22729
<bitcoin-git>
[bitcoin] laanwj merged pull request #22721: doc: add inital PR and author list to 0.21.2 release notes (0.21...0_21_2rc1_prelim_relnotes) https://github.com/bitcoin/bitcoin/pull/22721
<bitcoin-git>
[bitcoin] jnewbery opened pull request #22725: MOVEONLY: tests: Move addrman ser/deser tests to addrman_tests.cpp (master...2021-08-move-addrman-tests) https://github.com/bitcoin/bitcoin/pull/22725
<bitcoin-git>
[bitcoin] fanquake opened pull request #22724: windres: use PACKAGE_VERSION rather than building more version numbers (master...windres_version_somplify) https://github.com/bitcoin/bitcoin/pull/22724
<bitcoin-git>
[bitcoin] fanquake closed pull request #22688: contrib: use `keys.openpgp.org` to retrieve builder keys (master...use_ubuntu_keyserver) https://github.com/bitcoin/bitcoin/pull/22688
<bitcoin-git>
[bitcoin] fanquake opened pull request #22721: doc: add inital PR and author list to 0.21.2 release notes (0.21...0_21_2rc1_prelim_relnotes) https://github.com/bitcoin/bitcoin/pull/22721
<BlueMatt>
that's what I'd generally expect, but i dunno many/any lightning devs who follow bitcoin core closely enough to ensure that, which is part of the reason for me flagging now that non-v0 segwit output dust limit *also* falls under the "plz notify lightning devs and give us time to adapt before you change this" category
<harding>
Sure, but I think Bitcoin Core's open development process has a pretty strong commitment to listening to LN devs and other ecosystem devs, so I think that's implicitly covered
<BlueMatt>
sure, but that kind of thing requires at least a loose commitment from bitcoin core to do dust limit changes in a way that is compatible with that :p
<BlueMatt>
"charity" of reducing total bitcoin supply :)
<harding>
Sure, but if feerates increase significantly (and that certainly seems like a plausible scenario), those problems are going to need to be dealt with anyway. I don't think we should be forcing anyone to deal with those problems now, but I also kinda feel like some of the attention on the dust limit problem should be focused on improving LN rather than changing Bitcoin Core.
<harding>
LN doesn't need to use the same dust limit Bitcoin Core does. Y'all can choose to treat as dust outputs that would cost more to spend than they're worth at 20 s/b, and so be insulated against any reasonable change in Bitcoin Core (especially since changes in Bitcoin Core should take a long time to become predominant across relay and mining).