< sipa>
and it's unrelated to the development of the bitcoin core software
< Bilnon>
what gets to me the most with acronyms like "uPoW" is how much these people take for granted the proof-of-work scheme used in bitcoin, like that useful proofs of work could be integrated at all without converting the entire system to a PoS system,
< Bilnon>
I dont know how these idiot get their papers published, this is a terrible idea written by morons who clearly cant grasp even the basic concepts of bitcoin
< bitcoin-git>
[bitcoin] jonatack opened pull request #22447: test: whitelist rpc_rawtransaction peers to speed up tests (master...speed-up-rpc_rawtransaction-test) https://github.com/bitcoin/bitcoin/pull/22447
< bitcoin-git>
[bitcoin] hebasto opened pull request #22446: test: Fix wallet_listdescriptors.py if bdb is not compiled (master...210714-desc) https://github.com/bitcoin/bitcoin/pull/22446
< bitcoin-git>
[bitcoin] sriramdvt opened pull request #22445: fuzz: Move implementations of non-template fuzz helpers from util.h to util.cpp (master...fuzz_move) https://github.com/bitcoin/bitcoin/pull/22445
< roconnor>
[Monday, June 28, 2021] [10:07:08 AM EDT] <real_or_random> https://github.com/bitcoin-core/secp256k1/pull/959 :O this had a red cirrus run (due to failed randomness tests), which scared me of for a second...
< bitcoin-git>
[bitcoin] fanquake opened pull request #22436: build: use aarch64 Clang if cross-compiling for darwin on aarch64 (master...arm64_macos_cross_clang) https://github.com/bitcoin/bitcoin/pull/22436
< laanwj>
if you want to fork bitcoin core, go ahead, i don't think it would be bad to have more projects at all, you'll also discover soon enough that maintaining a project like this is difficult
<@gribble>
https://github.com/bitcoin/bitcoin/issues/21851 | [WIP] build: support cross-compiling for arm64-apple-darwin20 (Apple M1) in depends by fanquake · Pull Request #21851 · bitcoin/bitcoin · GitHub
2021-07-12
< prayank>
And I didn't use bitcoin because of number go up FYI
< sipa>
prayank: i would encourage you to find other things in life to do too; making everything about bitcoin (or any single thing) is going to drive you nuts
< prayank>
married lots of other things. I just want to focus on learning and doing better. I have issues idk. Lets see. If not Core. Fork. But Bitcoin.
< prayank>
sipa I dont know much about you to be honest but I started using bitcoin in 2015 because of some reasons and have some background. I am not as goood as you in programming. But maybe I was never good in anything thats why chatting here today, or I care too much about Bitcoin. I think I have decided that I can do anything for Bitcoin. Younger bro
< sipa>
okay - as long as you don't have an expectation that these tests will be integrated into the bitcoin core repository or test infrastructure
< prayank>
Goal: 1. Internship project 2. Nice GUI for script kiddies to play and think Bitcoin is not Digital Gold mem they can play with it and pentest. 3. Reference in Infosec Conf: I dont need followers. Bitcoin needs software devs. 4. Experiment and lets see see if we if find something new
< prayank>
Idk. I am true to myself and others. I tried everything. Its not helping. I will look for funding or do something to start a better fork (better than Luke Dash Jr). I don't care about anyone to be honest but Bitcoin. Only person I liked during conversations was Pieter Wuille, Greg Maxwell and Sometimes Drunk conversations with others. But I always
< sipa>
and wrote the tor hidden service support in bitcoin core
< prayank>
achow101: please do not take anything for you. Because its not. Maintainers suck, And its for them. Or maybe compromised by now. However, I couldnt find a vulnerability that they introduced so they can enjoy. You need examples: Ex1: https://github.com/bitcoin/bitcoin/pull/22432 (how to merge quickly) with less ACKs. No merge after few ACKs:
< bitcoin-git>
[bitcoin] prayank23 closed pull request #21755: Add more info about prefix in error message for invalid address (master...error-address) https://github.com/bitcoin/bitcoin/pull/21755
< bitcoin-git>
[bitcoin] prayank23 closed pull request #22430: Fix syntax for `getindexinfo` params in help examples (master...getindexinfo) https://github.com/bitcoin/bitcoin/pull/22430
< bitcoin-git>
[bitcoin] prayank23 closed pull request #22317: doc: Highlight DNS requests part in tor.md (master...highlight-dns-request) https://github.com/bitcoin/bitcoin/pull/22317
< prayank>
How many ACKs are required for a PR to get merged if the author is not from chaincode labs or blockstream or OG dev for a simple change that doesn't affect functionality in Bitcoin Core?
< vasild>
sipa: in https://github.com/bitcoin/bitcoin/pull/22387#issuecomment-878417152, do you mean that if a node is connected to e.g. only 3 others and I am one of those 3, then every time that node chooses 2 random peers to relay to, then I am very likely to be the chosen one?
< sipa>
is your question about whether there is a benefit to *using* an old bitcoin core version to spy with (no, spy nodes aren't bitcoin core at all, or heavily modified ones at least), or whether there is a benefit to *claiming* you're an old bitcoin core version when spying (not really, you can claim whatever you want, the data isn't used for anything except statistics etc)
< ZEFRON>
2. When I tried to fork Bitcoin-core I hit a roadblock with my implementation at the inability to gracefully access node.chainman within CheckProofOfWork()
< bitcoin-git>
[bitcoin] prayank23 opened pull request #22430: Fix syntax for `getindexinfo` params in help examples (master...getindexinfo) https://github.com/bitcoin/bitcoin/pull/22430
< brcolow>
I am confused by something. If you look at this line of code: https://github.com/bitcoin/bitcoin/blob/master/src/crypto/sha256_avx2.cpp#L63 it is writing a 32-bit (4byte) integer. In the case of -1996298034 that is, in big endian, 8902 e8ce - then it's converted to little endian which is CEE8 0289 - however what's strange is that WriteLE32 function writes CEE8289 - it skips the
< bitcoin-git>
[bitcoin] sipa opened pull request #22421: Make IsSegWitOutput return true for taproot outputs (master...202107_taproot_is_segwit) https://github.com/bitcoin/bitcoin/pull/22421
< bitcoin-git>
[bitcoin] laanwj merged pull request #22253: validation: distinguish between same tx and same-nonwitness-data tx in mempool (master...2021-06-same-txid-diff-wtxid) https://github.com/bitcoin/bitcoin/pull/22253
< bitcoin-git>
bitcoin/master fdb4816 glozow: [validation] distinguish same txid different wtxid in mempool
< bitcoin-git>
bitcoin/master b7a8cd9 glozow: [test] submit same txid different wtxid as mempool tx
< bitcoin-git>
bitcoin/master 8ab0c77 W. J. van der Laan: Merge bitcoin/bitcoin#22253: validation: distinguish between same tx and s...
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22253 | validation: distinguish between same tx and same-nonwitness-data tx in mempool by glozow · Pull Request #22253 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/master 285a65c Sebastian Falbesoner: test: use script_util helpers for creating P2SH scripts
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22363: test: refactor: use `script_util` helpers for creating P2{PKH,SH,WPKH,WSH} scripts (master...202106-test-refactor-use_scriptpubkey_helpers) https://github.com/bitcoin/bitcoin/pull/22363
< bitcoin-git>
bitcoin/master b57b633 Sebastian Falbesoner: test: use script_util helpers for creating P2PKH scripts
< bitcoin-git>
[gui] ryanofsky opened pull request #379: Prompt to reset settings when settings.json cannot be read (master...pr/badset) https://github.com/bitcoin-core/gui/pull/379
< prayank>
Overall goal: Get feedback for my project which is related to testing bitcoin core in a different way from people who are involved in testing core regularly
< prayank>
Hi everyone 👋 I wanted to get some feedback on few things related to testing in Bitcoin Core. So, created this form with 5 simple questions. Will be helpful if you could answer them:
< bitcoin-git>
[bitcoin] luke-jr closed pull request #18479: RPC: Show fee in results for signrawtransaction* for segwit inputs (master...rpc_sign_show_fees) https://github.com/bitcoin/bitcoin/pull/18479
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #22402: doc: Install Rosetta on M1-macOS for qt in depends (master...210705-rosetta) https://github.com/bitcoin/bitcoin/pull/22402
< bitcoin-git>
[bitcoin] sipa closed pull request #22402: doc: Install Rosetta on M1-macOS for qt in depends (master...210705-rosetta) https://github.com/bitcoin/bitcoin/pull/22402
< fanquake>
I wonder if we can further restrict permissions to prevent that from happening. There's really no need for anyone to ever push their development branches to bitcoin/bitcoin.
< fanquake>
wumpus / sipa : can you delete the "please-delete-accidental-push" and "checktemplateverify-rebase-4-15-21" branches that have been pushed to bitcoin/bitcoin
2021-07-05
< bitcoin-git>
[bitcoin] theStack opened pull request #22408: test: add tests for `bad-txns-prevout-null` reject reason (master...202107-test-add_test_for_bad-txns-prevout-null) https://github.com/bitcoin/bitcoin/pull/22408
< bitcoin-git>
bitcoin/master 16b0a93 Carl Dong: guix: Rebase toolchain on glibc 2.24 (2.27 for riscv64)
< bitcoin-git>
[bitcoin] hebasto opened pull request #22402: doc: Install Rosetta on M1-macOS for qt in depends (master...210705-rosetta) https://github.com/bitcoin/bitcoin/pull/22402
< bitcoin-git>
[bitcoin] amitiuttarwar reopened pull request #22387: Rate limit the processing of rumoured addresses (master...202106_rate_limit_addr) https://github.com/bitcoin/bitcoin/pull/22387
< bitcoin-git>
[bitcoin] amitiuttarwar closed pull request #22387: Rate limit the processing of rumoured addresses (master...202106_rate_limit_addr) https://github.com/bitcoin/bitcoin/pull/22387
< bitcoin-git>
[bitcoin] hebasto opened pull request #22397: build: Fix macOS Apple Silicon build with miniupnpc and libnatpmp (master...210703-brew-arm) https://github.com/bitcoin/bitcoin/pull/22397
< bitcoin-git>
bitcoin/master 7fc1e14 fanquake: ci: use Ubuntu 20.04 as the default Docker container
< bitcoin-git>
bitcoin/master 7a49fdc MarcoFalke: Merge bitcoin/bitcoin#22388: ci: use Ubuntu 20.04 as the default Docker co...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22388: ci: use Ubuntu 20.04 as the default Docker container (master...ci_ubuntu_20_04) https://github.com/bitcoin/bitcoin/pull/22388
< bitcoin-git>
[bitcoin] fanquake opened pull request #22390: system: skip trying to set the locale on NetBSD (master...netbsd_dont_set_locale) https://github.com/bitcoin/bitcoin/pull/22390
< bitcoin-git>
[bitcoin] fanquake opened pull request #22390: system: skip trying to set the locale on NetBSD (master...netbsd_dont_set_locale) https://github.com/bitcoin/bitcoin/pull/22390
< bitcoin-git>
[bitcoin] fanquake opened pull request #22388: ci: use Ubuntu 20.04 as the default Docker container (master...ci_ubuntu_20_04) https://github.com/bitcoin/bitcoin/pull/22388
< bitcoin-git>
[bitcoin] fanquake opened pull request #22388: ci: use Ubuntu 20.04 as the default Docker container (master...ci_ubuntu_20_04) https://github.com/bitcoin/bitcoin/pull/22388
< bitcoin-git>
[bitcoin] sipa opened pull request #22387: Rate limit the processing of rumoured addresses (master...202106_rate_limit_addr) https://github.com/bitcoin/bitcoin/pull/22387
< bitcoin-git>
[bitcoin] sipa opened pull request #22387: Rate limit the processing of rumoured addresses (master...202106_rate_limit_addr) https://github.com/bitcoin/bitcoin/pull/22387
< harding>
We've had to update the expiration on laanwj's key before, which created some confusion but not much. On Bitcoin.org years ago, we saw that 99% of people who downloaded binaries didn't download the SHASUMs file, so most people aren't verifying in any case.
< harding>
We've had to update the expiration on laanwj's key before, which created some confusion but not much. On Bitcoin.org years ago, we saw that 99% of people who downloaded binaries didn't download the SHASUMs file, so most people aren't verifying in any case.
< laanwj>
harding: this is not a major version update (0.21.0 to 0.21.1) ... but i agree all of this is manouvring around auto-updates just being a bad idea for bitcoin in the first place, and people who use it through a package manager sign up for that
< laanwj>
harding: this is not a major version update (0.21.0 to 0.21.1) ... but i agree all of this is manouvring around auto-updates just being a bad idea for bitcoin in the first place, and people who use it through a package manager sign up for that
< sipa>
i think the message really isn't so much "warning, this has taproot, do you like that?", but it is "warning: the package maintainer you trust has power to make your system update to new consensus rules, you should be aware of that risk, and evaluate whether that's an acceptable way to use bitcoin"
< sipa>
it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included"
< sipa>
it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included"
< sipa>
i think the message really isn't so much "warning, this has taproot, do you like that?", but it is "warning: the package maintainer you trust has power to make your system update to new consensus rules, you should be aware of that risk, and evaluate whether that's an acceptable way to use bitcoin"
< earnestly>
sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them?
< earnestly>
sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them?
< harding>
Some packages in debian come shipped in a not-completely-functional state; you have to flip some flag in /etc/defaults/package-name. You can have Bitcoin Core 0.21.1+ require you put "taproot = yes" in that file before it'll run.
< harding>
Some packages in debian come shipped in a not-completely-functional state; you have to flip some flag in /etc/defaults/package-name. You can have Bitcoin Core 0.21.1+ require you put "taproot = yes" in that file before it'll run.
< laanwj>
right, it's for good reason we resisted bitcoin being part of package repositories for a long time
< laanwj>
right, it's for good reason we resisted bitcoin being part of package repositories for a long time
< sipa>
this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism
< sipa>
this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub