< bitcoin-git>
bitcoin/master 9bd3ff4 Wladimir J. van der Laan: Merge #14383: qt: Clean system tray icon menu for '-disablewallet' mode...
< bitcoin-git>
[bitcoin] kallewoof opened pull request #14492: autoconf: add 'test' alias for 'tests' to configure (master...ac-test-arg-alias) https://github.com/bitcoin/bitcoin/pull/14492
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #14491: Allow descriptor imports with importmulti (master...201810_importmulti_desc_2) https://github.com/bitcoin/bitcoin/pull/14491
< kallewoof>
How does bitcoin core track bip9 activation states? I have odd cases where a copied chain state will result in all bip9 soft forks turning up as "failed" rather than "activated". If I disable the timeout, they show up as 'started', but with 'possible: false'.
2018-10-15
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14489: refactor: Drop boost::thread and boost::chrono (master...interruptible-thread) https://github.com/bitcoin/bitcoin/pull/14489
< bitcoin-git>
[bitcoin] achow101 closed pull request #14019: Import pubkeys when importing p2sh with importmulti (master...import-multi-pubkeys) https://github.com/bitcoin/bitcoin/pull/14019
< bitcoin-git>
[bitcoin] DesWurstes opened pull request #14486: Add explicit cast to base58 and bech32 string constants in order to silence GCC warning (master...patch-4) https://github.com/bitcoin/bitcoin/pull/14486
< bitcoin-git>
bitcoin/master 2a2cac7 Jonas Schnelli: Merge #14424: Stop requiring imported pubkey to sign non-PKH schemes...
< bitcoin-git>
[bitcoin] HatboyWonder opened pull request #14484: changed request payment button text and tab description (master...master) https://github.com/bitcoin/bitcoin/pull/14484
< karelb>
Also - how much does bitcoin (at least new code) use all the const correctness stuff? I never know how to write it correctly and where to add `const`
< karelb>
"Class member variables have a m_ prefix" - I don't see that in many class variables in bitcoin codebase?
< karelb>
Is there some linter on bitcoin core that looks for line length?
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #14481: Add P2SH-P2WSH support to listunspent RPC (master...201810_listunspent_wsh) https://github.com/bitcoin/bitcoin/pull/14481
< bitcoin-git>
[bitcoin] MeshCollider closed pull request #11708: Add P2SH-P2WSH support to signrawtransaction and listunspent RPC (master...201711_signrawtransaction_wsh) https://github.com/bitcoin/bitcoin/pull/11708
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14480: refactor: Drop boost::this_thread::interruption_point and boost::thread_interrupted in main thread (master...drop-boost-thread-import) https://github.com/bitcoin/bitcoin/pull/14480
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #14478: Show error to user when corrupt wallet unlock fails (master...201810_wallet_corruption_error) https://github.com/bitcoin/bitcoin/pull/14478
2018-10-13
< bitcoin-git>
[bitcoin] sipa opened pull request #14477: Add ability to convert solvability info to descriptor (master...201810_inferdescript) https://github.com/bitcoin/bitcoin/pull/14477
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14475: serialize: Document integer width assumptions we are making when calculating compact sizes (master...integer-width-assumptions) https://github.com/bitcoin/bitcoin/pull/14475
< bitcoin-git>
[bitcoin] alecalve opened pull request #14474: bitcoin-tx: Use constant for n pubkeys check (master...bitcoin_tx_use_constant) https://github.com/bitcoin/bitcoin/pull/14474
< bitcoin-git>
[bitcoin] Sjors opened pull request #14472: [doc] getblocktemplate: use SegWit in example (master...2018/10/doc-getblocktemplate-segwit) https://github.com/bitcoin/bitcoin/pull/14472
< jnewbery>
promag: yes, the version the RPC will be removed in should be in the warning text and the release notes when the RPC is deprecated. See https://github.com/bitcoin/bitcoin/pull/14468/files for example
< echeveria>
#bitcoin is not +r, it does not require registration.
< echeveria>
grey-jacket: #bitcoin is not restricted in any way, ask there.
< grey-jacket>
I see this is the wrong channel, but messages to #bitcoin don't go out
< gwillen>
provoostenator: uhm, hm. It does it when I build it myself at the tag v0.17.0, but not when I run the release binary downloaded from bitcoin.org.
2018-10-11
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14465: tests: Stop node before removing the notification file (master...test-notification-fix) https://github.com/bitcoin/bitcoin/pull/14465
< sipa>
try bitcoin.stackexchange.com too, and have some patience
< sipa>
so yes, your questions about usage or development with bitcoin core are off topic
< tradermyx>
So I ask in ##bitcoin and nobody responds for hours. Ghost town. What do you want me to do? Sit and twiddle my thumbs or ask where there are experts on this particular software?
< sipa>
this channel is about develop*ing* bitcoin core
< tradermyx>
Well, I "develop", but not Bitcoin Core... rather trying to use it.
< tradermyx>
I give up. I've now wasted countless hours of my life trying to figure out the basic information about how Bitcoin Core's .conf file wants strings escaped.
< tradermyx>
And yeah, I should probably ask this in ##bitcoin...
< tradermyx>
Once I have Bitcoin Core running and the console window open, can I make it output whatever value it chose for blocknotify?
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14464: rafactor: Remove use of boost::condition_variable and boost::mutex in checkqueue (master...drop-boost-cond) https://github.com/bitcoin/bitcoin/pull/14464
< rafalcpp>
tradermyx: this channel is rather for develpoing Bitcoin. As for using it, #bitcoin
< tradermyx>
#bitcoin :Cannot send to nick/channel
< tradermyx>
Interesting find: Bitcoin Core fails to start if bitcoin.conf contains: wallet = "wallet.dat"
< tradermyx>
I just noticed that a program I temporarily used (Armory?) modified bitcoin.conf to set a rpcuser and rpcpassword (but not anything else). I thought the rpcbind and rpcport options were what actually "enabled" the RPC API? But it's enough to just specify the username/password?
< bralyclow>
hi everyone, not a development question, but no one can/will answer in #bitcoin, was the New button on the Receiving Addresses screen removed in macOS version of 0.17.0 bitcoin core node gui, it is not there any longer, still on the Send Addresses screen to create a new one there, but not on Receiving Address screen?
< tradermyx>
Why does it feel as if now that I'm finally getting Bitcoin "up and running" and being able to charge people and send them money in an automated fashion, the "party is over", so to speak?
< Jmabsd>
(repeat of #bitcoin question:) What is the Bitcoin Core policy for the *minimum value that a tx output must have* for the tx to still be gossiped? (as an absolute value number of satoshis)
< gmaxwell>
Basically gleb's simulator simulates a plausable bitcoin network topology, and then measures how transactions relay around in it with different relaying schemes, so we can try different ideas and measure their impacts.
< sipa>
but bitcoin-cli is a way for humans to talk to bitcoind
< gmaxwell>
It's the recommended way to use bitcoin from the commandline.
< tradermyx>
sipa: I mean, why use cURL requests if I can just shell_exec() the bitcoin-cli binary?
< sipa>
bitcoin-cli is really just a slightly-specialized version of curl
< tradermyx>
I didn't think Bitcoin Core itself had the ability to connect/do anything with the RPC API on a different machine.
< tradermyx>
Come to think of it, I don't really understand what bitcoin-cli is either. I use standard cURL requests to talk to http://127.0.0.01/ with the port specified (it works).
< tradermyx>
I have rpcconnect, rpcport, rpcuser, rpcpassword set in my bitcoin.conf. Don't really understand why Bitcoin Core needs to be told where to connect... itself?
< sipa>
rpcconnect only affects bitcoin-cli
< sipa>
rpcbind only affects bitcoind and bitcoin-qt (when running with -daemon)
2018-10-03
< wumpus>
you could dig in the bitcoin talk forums and find layer after layer of the same kinds of discussions, going back to the beginning, repeated every time. Where did those 8 years go, suddenly...
< wumpus>
on the old bitcoin.org server there was a script that automatically generated the .torrent when all the files are in place; but I don't think that helps much, compared to uploading the torrent along with the rest of the files
< gwillen>
I followed the intstructions in the OS X build docs for opening the project in QT Creator, but by default it was unable to see a bunch of headers and I had to add some lines to bitcoin-qt.include to make it avoid drowning everything in red squiggly underlines
< queip>
abcore for android, wrapping bitcoin core, works fine
< queip>
what is the outlook for Bitcoin Core for iOs? Grim? I'm looking forkward to building on top of it, glad to help in testing (though no iOs coding skill myself)
2018-09-30
< gribble>
https://github.com/bitcoin/bitcoin/issues/13515 | travis: Avoid timeout without saving caches, also enable qt builds for all jobs if available by ken2812221 · Pull Request #13515 · bitcoin/bitcoin · GitHub
< bralyclow>
hi everyone, what exactly are all these /bitcore:1.1.2/ nodes connecting to my Bitcoin Core Full Node, I have more of them than Satoshi nodes?
< gribble>
https://github.com/bitcoin/bitcoin/issues/14348 | depends: fix bitcoin-qt back-compat with older freetype versions at runtime by theuni · Pull Request #14348 · bitcoin/bitcoin · GitHub
< jamesob>
anecdotally, if someone just wants to transact in bitcoin they often just go to electrum/trezor/bread/etc.
< gmaxwell>
if it were, I think bitcoin would be nearly dead... there would be very little reason for people to bother even trying to start a node.
< jamesob>
would it be an acceptable user experience for us to completely strip bdb out in some major release, provide an upgrade tool, and throw an error if users try to start bitcoin with bdb-format wallets?
< wumpus>
that way, bitcoin won't magically install its own qt; so it will build against system qt if available, and not build against qt at all if not available
< hebasto>
wumpus: what is the way to build bitcoin-qt against system qt?
< wumpus>
jonasschnelli: I don't think so; the bitcoin-qt background should be the same as other gtk applications, say "charmap"
< jonasschnelli>
wumpus: using the dark arc theme in Ubuntu Bionic, the background of Bitcoin Qt is still light gray/whiteish? Is that expected?
< jonasschnelli>
Bitcoin Qt looks a bit strange in OSX 10.14 (Mojaves) dark mode. :)
< gmaxwell>
And the reason it would matter is if under that case, you handle errors differently, e.g. the actual bug may be elsewhere in bitcoin or in the test but were hidden by the old behavior. The fact that you can't reproduce it locally is kind of annoying. you could try to figure out which test case is failing, by adding commits to change the test.
< andytoshi>
in any case I think for the purposes of rust-bitcoin we're not too concerned about that
< sipa>
yeah, i think the correct thing to do is to treat a bitcoin-pubkey as a pair of (ec-pubkey, compressedness), as from bitcoin's perspective they're really different things
< andytoshi>
we haven't had trouble thus far having the compressed/uncompressed distinction only exist as part of bitcoin Privkeys that correspond to bitcoin addresses
< andytoshi>
ok. the issue is that in rust-bitcoin, we don't store whether a pubkey is compressed or uncompressed, it's just a libsecp secp256k1_pubkey. (our Address and Privkey have this extra info ofc, but the raw ecdsa pubkey type does not)
< karelb>
just today I was trying to google "what is a sighash again?" (since when I do not work on bitcoin for a while I keep forgetting its terminology) and I keep ending up at bitcoin.org developer docs
< harding>
karelb: an alternative approach is to maintain your own diff between the `bitcoin-cli help` in its current inconsistent format and the idealized consistent format you suggest, which shouldn't be too much work as the current help is pretty stable, then develop your tooling around that, proving its worth. Then you'll not only have stronger evidence that it's externally useful, but you'll also have the parsing tools to help create
< earlz>
David Jaenson independently discovered the vulnerability and it was reported to the Bitcoin Core security contact email
< luke-jr>
maybe - 19:50 David Jaenson independently discovered the vulnerability, and his colleague earlz reported it to the Bitcoin Core security contact email.
< jarthur>
gmaxwell: https://github.com/bitcoin/bitcoin/pull/14305 for better or worse, the only other mis-named attribute I could find was in the same functional test module. Included that in the fix, but avoided the one already covered in #14300.
< harding>
kanzure: is the bitcoin-dev mailing list being migrrated to another host? If so, do you think it'd also be able to support an -announce list that only supported sending from the mailman moderator interface?
< gmaxwell>
though it sucks more when its the guy controlling bitcoin.org doing it.
< gmaxwell>
I dunno I get called incompetent because of things random people I've never heard of before on twitter says too. People can't grok decenteralization, so apparently every participant is the bitcoin project is jointly and severally responsible for everything every supporter says. or something. :P
2018-09-23
< gmaxwell>
maybe we need to get forrestv back into bitcoin, guy was a wizard with overly complex python things. :P
< provoostenator>
Getting fairly consistent behavior now, even with disablewallet=1. bitcoin-cli stop seems to stop the RPC server, but not the invalidation process. Curious if anyone can reproduce. I'll let it sync to the tip before trying again.
< provoostenator>
Also, it's still going even though bitcoin-cli stop said it would stop. I'll look at the dirty page counts...
< echeveria>
is there some tool or setup guide that is telling people to open this port? I thought it was pretty difficult (not a single switch) to get Bitcoin Core to bind the RPC interface to 0.0.0.0.
< echeveria>
I was looking at one of the public internet mapping tools for bitcoin core versions. there's a pretty disturbing number of hosts that have 8332 open.
< echeveria>
there used to be bitcoin-security, but that was handled sort of poorly.
< gmaxwell>
nanotube: :( I feel really uncomfortable with people going to bitcoin.org for that kind of information.
< harding>
nanotube: any page on Bitcoin.org, top menu, Participate, Development, "to report an issue, please see the Bug Reporting page", Responsible Disclosure.
< nanotube>
would it make sense to propose a 'contact' page on bitcoin.org similar to the one on bitcoincore.org? it appears it is non-trivial to find where to privately report security issues unless one knows to go to bitcoincore.org, since earlz had to come asking on #bitcoin-dev and -core-dev for a way to report.
< jnewbery>
promag: I think you could just oen a PR for a test for bitcoin-wallet-tool, including the commit from 13926. I expect any test would be merged as part of the original PR, but discussion of the tests can be in your new PR.
< wumpus>
MarcoFalke: rcs for old releases used to be deleted because of disk space constraints on bitcoin.org, don't know if bitcoincore.org has the same problem
< wumpus>
when bitcoincore.org started hosting executables I think I copied everything from bitcoin.org
< MarcoFalke>
bitcoincore.org is mostly concerned about distributing working, tested and non-vulnerable software versions of Bitcoin Core. The site should not serve as an archive of binary blobs. Note that releases before 0.10.0 are already not offered as download on https://bitcoincore.org/bin/.
< earlz>
What's the best way to privately report a security problem in bitcoin core?
< wumpus>
I'm more concerned with adding more utilities to bitcoin core than the test framework expanding to test them