< sipa>
this channel is about discussing development on the Bitcoin Core software; you're welcome to idle or discuss relevant topics, but those don't include other Bitcoin clients, and certainly not trojan horse software
< oshithemoto>
no one is writting here, just like idling here? gg I am an old developer, i did some decentraliced stuff bevor bitcoin, cordinated ddos attacs and i hope to find some old crew member, it was not sub7 crew but some of the ppl from this crew can help me find my old crew members I think one of them is satoshi nakamoto. his "old" nickname was "oso", he was a hacker and our crew name was #ratpack and he told my about a decen
< jarthur>
Specifically Bitcoin Core development. #bitcoin-dev or #bitcoin may be better suited.
< oshithemoto>
Anyone here who coded a bitcoin wallet in VB.NET?
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14585: Don't rely on locale dependent functions in base_blob<BITS>::SetHex(...) (uint256), DecodeBase58(...), ParseMoney(...) and ParseHex(...) (master...no-locale-surprises-please) https://github.com/bitcoin/bitcoin/pull/14585
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14534: Enable flake8 rule E225 which checks for missing whitespace around op… (master...flake8-fix-E225) https://github.com/bitcoin/bitcoin/pull/14534
< bitcoin-git>
[bitcoin] ken2812221 closed pull request #13827: [WIP] depends: Add native_nsis to support unicode (master...depends-nsis) https://github.com/bitcoin/bitcoin/pull/13827
< andytoshi>
rust-jsonrpc is better but it's still not where i want it to be. afaik there is no HTTP client library for rust that doesn't have a bad dependency story. we would need to write our own to do bitcoin-cli in rust.
< harding>
wumpus: that's what I remember being done for all the other 0.*.*.1 releases, and it's easiest for the website if there are release notes because, as you say, it's the same release process. It is possible (and pretty easy) to have binaries split across two directories on both BitcoinCore.org and Bitcoin.org as we both use the same mechanism to allow for easy changes in the filenames across releases, so let me know if you ever do
< harding>
For 0.17.0.1, a few questions related to what changes I might need to make to BitcoinCore.org for it: (1) is only the MacOS binary going to be added to /bin/bitcoin-core-0.17.0.1/ or will there be .0.1 versions for all platforms? (2) Are there going to be release notes for it? (3) Do we want a blog post about it on the home page?
< bitcoin-git>
[bitcoin] kallewoof opened pull request #14582: wallet: try -avoidpartialspends mode and use its result if fees do not change (master...181026-try-avoidpartialspends) https://github.com/bitcoin/bitcoin/pull/14582
< bitcoin-git>
[bitcoin] fanquake closed pull request #12656: Add scripts for doing gitian builds on any platform using VirtualBox + Vagrant + Packer (master...vagrant) https://github.com/bitcoin/bitcoin/pull/12656
< gmaxwell>
echeveria: I personally liked the one company going around telling everyone that bitcoin core constantly crashed, and then got shut up by a developer offering them a sizable bet that they couldn't report any crash...
< echeveria>
some of this comes from parties like blockchain.info who have frequently gone around conferences repeating stories of how they tried so hard to contribute to bitcoin core and were rejected for their efforts.
< gmaxwell>
(I very much want their input for sure, but if they don't provide it.. they don't provide it. Unfortunately, my expirence with many bitcoin companies is that they have executives that have never actually used software in a commercial context before, much less open source... and they treat it like the android play store... an app doesn't do what you want, you swap out for another one).
< echeveria>
from my experience people making a lot of these sort of claims don’t actually use the software at all, so keep that in mind too. I’ve had people sit and insist to me that the bitcoin wallet has all sorts of stupid behaviour I full well know it doesn’t.
< kallewoof>
gmaxwell: sdaftuar spoke against the feature in the original PR here: https://github.com/bitcoin/bitcoin/pull/12257#discussion_r204168100 ("I'm not sure that -avoidpartialspends works very well on wallets that have substantial address reuse, in particular I think you can devolve into cases where you'd produce giant transactions that take forever to sign and would never pass policy (or consensus) limits, in extreme cases.")
< esotericnonsense>
wumpus: no just write the bits of qemu you need to emulate bitcoin-cli on riscv.
< esotericnonsense>
just write bitcoin-cli in bash.
< gmaxwell>
Maybe the rust-bitcoin people have already done it.
< wumpus>
let's write bitcoin-cli in rust
< gmaxwell>
I don't think it was bad to raise, we might end up back on it if later bitcoin-cli is blocking disabling tcp rpc by default, and libevent still can't handle using domain sockets for the -cli case.
< esotericnonsense>
someone using bitcoin-cli in scripts ... argh\
< sipa>
my preference is just replacing the libevent http code in bitcoin-cli with hand-written HTTP though :)
< sipa>
gmaxwell: generally i agree with that... but i also think bitcoin-cli is very simple :)
< gmaxwell>
yea, if we wanted to rewrite anything bitcoin-cli would be it! :)
< wumpus>
it woult make zero difference for bitcoin-cli wrt performance
< gmaxwell>
I don't think thats absurd on its face, but: it would probably be a massive slowdown for those users who do processing using bitcoin-cli in scripts, and would suffer the standard "throwaway and rewrite software issues" -- the complexity of existing code is effectively all the accrewed knoweldge built from years and years of use... and that it probably gets right lots of behaviors none of us
< wumpus>
rewriting bitcoin-cli in python, certainly using the code already in the test framework, would be trivial, but why?
< esotericnonsense>
gmaxwell: i'm not suggesting it but rather responding to wumpus'/sipa message above about bitcoin-cli not needing to be a full http client and inventing some thing
< sipa>
afaik the origin bitcoin-cli code was just some printf statements into a socket
< esotericnonsense>
what bitcoin-cli?
< esotericnonsense>
all of bitcoin? :D:D
< gmaxwell>
I think esotericnonsense is suggesting bitcoin-cli get replaced with a python tool?
< esotericnonsense>
WRT bitcoin-cli and http/domain sockets/etc
< esotericnonsense>
obviously it's so that you can stick your bitcoin rpc behind nginx and put it on https://myexchange.com/api
< bitcoin-git>
[bitcoin] hebasto opened pull request #14577: qt: Cleanup `textInteractionFlags` for `QLabel` (master...20181025-textInteractionFlags) https://github.com/bitcoin/bitcoin/pull/14577
< wumpus>
(why does bitcoin use http? I do not know, I guess JSON-RPC is marginally better than rolling yet another custom protocol, though the line-based JSON RPC of c-lightning is *pretty neat*)
< sipa>
wumpus: you may hate this... but given that bitcoin-cli is specific to bitcoind, it probably doesn't need to actually implement full HTTP; just whatever subset is needed for bitcoind
< gmaxwell>
sipa: e.g. will it crash under concurrent request load, etc. thats something we'd probably find out really fast with bitcoin-cli switched to it.
< sipa>
gmaxwell: any type of issue you're worried about in particular w.r.t. unix socket support but excluding bitcoin-cli initially?
< gmaxwell>
jonasschnelli: it's hard to test extensively without bitcoin-cli support, I'd worry about it bitrotting.
< jarthur>
bitcoin-cli support is what was held up by proposed upstream libevent work
< jarthur>
While some folks are still here, I'm curious if any of you would be against an incremental introduction of unix domain sockets for the RPC API. e.g. release with just server support first, no bitcoin-cli support and no official work around abstract sockets. Server support may be exhumable from wumpus PR #9919.
< jnewbery>
sorry I missed the meeting. On the topic of testing RCs, the optech newsletter has action items each week, which included 'allocate time to test Bitcoin Core RC' for the weeks that we had RCs (eg https://bitcoinops.org/en/newsletters/2018/09/11/). If there are more specific instructions, let us know and we can help spread them.
< gribble>
https://github.com/bitcoin/bitcoin/issues/14451 | Add BIP70 deprecation warning and allow building GUI without BIP70 support by jameshilliard · Pull Request #14451 · bitcoin/bitcoin · GitHub
< luke-jr>
how about I make a Twitter account for posting experimental releases of Core, Knots, and other reputable Bitcoin projects? (Electrum, etc?)
< esotericnonsense>
anyway, this is not bitcoin core dev, sorry :P
< wumpus>
yes, I guess the threat model for bitcoin is somewhat different than say, ssh
< esotericnonsense>
so yeah if you have the list it would probably take a few seconds to hit them all and see if they're not bitcoin. :P
< luke-jr>
harding: well, I mean perhaps some other software is listening in 8332 while Bitcoin isn't
< wumpus>
or maybe they found an exploit in bitcoin-cli and are waiting for you to use it on them :-)
< harding>
luke-jr: the list of IPs I scan cam from bitnodes, which I think currently filters out Bitcoin Cash nodes. Obviously so were probably spy nodes and the like.
< luke-jr>
I wonder if these 8332s aren't even bitcoin itself?
< esotericnonsense>
luke-jr: is it possible to get a bitcoin-like response back with invalid auth
< esotericnonsense>
e.g. if you had bitcoind, bitcoin-qt and bitcoin-qt had perms on the socket but other than bitcoin-qt only root did
< gribble>
https://github.com/bitcoin/bitcoin/issues/14532 | Never bind INADDR_ANY by default, and warn when doing so explicitly by luke-jr · Pull Request #14532 · bitcoin/bitcoin · GitHub
< wumpus>
I have various scripts that interface to bitcoin and I use them with the GUI too.
< esotericnonsense>
personally i'd probably ask why bitcoin-qt even has the ability to enable RPC
< wumpus>
what, if you want to enable RPC in bitcoin-qt you should be able to
< esotericnonsense>
i've just jumped in here and stuck some chat in #bitcoin
< gmaxwell>
harding: probably making bitcoin make its own template config file when one doesn't exist would help.
< harding>
I guess when .bitcoin is created, a default bitcoin.conf could be created with some normal-to-change options and basic comment documentation. I think you'd want to keep it short, rather than providing every possible option, so that people aren't tempted to delete the whole thing and replace it with a random config from the Wiki.
< wumpus>
in any case I checked: bitcoin-qt still doesn't enable RPC server by default
< gmaxwell>
echeveria crawled the internet and found something like 3000 bitcoin rpc ports listening, which would be a substantial percentage of all p2p listening nodes.
< harding>
Looked up the conversation on #bitcoin, the user didn't explicitly say that he was using the default config, so he could've had -server=1.
< harding>
I did test on Linux, and bitcoin-qt doesn't do RPC there by default.
< wumpus>
harding: setting server=1 in bitcoin.conf should be the only way to enable it with bitcoin-qt
< harding>
wumpus: someone in #bitcoin the other day said that RPC was enabled by default on Windows in bitcoin-qt. That surprised me, as I didn't even know bitcoin-qt could expose RPC (I thought you needed to use bitcoind for that). I didn't think to mention it here because I didn't realize that not running RPC with bitcoin-qt was supposed to be a security feature.
< wumpus>
I think what discourages people from even trying browser-based attacks is that bitcoin-qt by default has the RPC server disabled, so most unknowning users won't be affected, the people that enable RPC will generally be more technical and hopefully be careful what they allow
< Sentineo>
but someoone might try to give you a browser which does not check CORS and connect to your bitcoin through rpc?
< bitcoin-git>
bitcoin/master 754a00d Wladimir J. van der Laan: Merge #14416: Fix OSX dmg issue (10.12 to 10.14)...
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14571: [tests] Test that nodes respond to getdata with notfound (master...Mf1810-qaNotfound) https://github.com/bitcoin/bitcoin/pull/14571
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14569: travis: Print characters per 9 min to avoid timeout (master...travis-avoid-timeout) https://github.com/bitcoin/bitcoin/pull/14569
< bitcoin-git>
[bitcoin] kallewoof closed pull request #14507: net: avoid being disconnected from pruned nodes when syncing up (master...net-pruned-limit-requests) https://github.com/bitcoin/bitcoin/pull/14507
< bitcoin-git>
[bitcoin] jameshilliard opened pull request #14564: Adjust configure so that only bip70 is disabled when protobuf is missing instead of the GUI (master...bip70-disable-check) https://github.com/bitcoin/bitcoin/pull/14564
2018-10-24
< bitcoin-git>
[bitcoin] instagibbs closed pull request #14563: Pin flake8 version to earlier version to avoid pyflakes update (master...fix_flake) https://github.com/bitcoin/bitcoin/pull/14563
< bitcoin-git>
[bitcoin] instagibbs opened pull request #14563: Pin flake8 version to earlier version to avoid pyflakes update (master...fix_flake) https://github.com/bitcoin/bitcoin/pull/14563
< luke-jr>
not building bitcoin-qt seems a bit extreme though; might make sense to refactor configure to just change the bip70 option
< fanquake>
wumpus are we meant to be able to build bitcoin-qt without protobuf after #14451?
< gribble>
https://github.com/bitcoin/bitcoin/issues/14451 | Add BIP70 deprecation warning and allow building GUI without BIP70 support by jameshilliard · Pull Request #14451 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] laanwj closed pull request #14451: Add BIP70 deprecation warning and allow building GUI without BIP70 support (master...deprecate-bip70) https://github.com/bitcoin/bitcoin/pull/14451
< bitcoin-git>
[bitcoin] achow101 opened pull request #14558: rpc: Require solvability in importmulti if importing more than the scriptPubKey (master...importmulti-solvability) https://github.com/bitcoin/bitcoin/pull/14558
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #14444: Add compile time checking for cs_main locks which we assert at run time (master...move-runtime-checking-to-compile-time-checking) https://github.com/bitcoin/bitcoin/pull/14444
< bitcoin-git>
[bitcoin] merland opened pull request #14553: Fix wrong unit on hourly progress increase (master...progress-increase-per-h) https://github.com/bitcoin/bitcoin/pull/14553
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14552: wallet: throw an error if user load the wallet file by different ways (master...default-wallet-fix) https://github.com/bitcoin/bitcoin/pull/14552
< bitcoin-git>
bitcoin/master 2c6281f Pieter Wuille: Add key origin support to descriptors
< bitcoin-git>
bitcoin/master ff37459 Pieter Wuille: Add tests for key origin support
< bitcoin-git>
bitcoin/master 8afb166 Pieter Wuille: Update documentation to incude origin information
< bitcoin-git>
[bitcoin] instagibbs opened pull request #14543: [QA] minor p2p_sendheaders fix of height in coinbase (master...p2p_sendheaders_height) https://github.com/bitcoin/bitcoin/pull/14543
< bitcoin-git>
[bitcoin] practicalswift closed pull request #13766: Prefer initialization to assignment in constructors. Prefer in-class initializers to member initializers in constructors for constant initializers. (master...initialize-members-in-initialization-list) https://github.com/bitcoin/bitcoin/pull/13766
< bitcoin-git>
[bitcoin] practicalswift closed pull request #12984: logs: Make the columns in subsequent UpdateTip log entries horizontally aligned (master...attention-to-detail) https://github.com/bitcoin/bitcoin/pull/12984
< sanket1729>
Hello, can anyone comment on the following claim. "If there is a clock drifts more than 2 hours and and there are 2 chains similar PoW, then we can have a fork where both chains think they are longest in their own view. So, bitcoin network operates on some synchronous assumptions."
< wumpus>
if you're looking for a specific block, you could check block explorers if they have it, or ask here or in #bitcoin
< sanket1729>
Hello, I have one small quick question. Does bitcoin core ever prune orphan blocks? I mean do all full nodes have a very old orphan block, say from 2014?
< bitcoin-git>
[bitcoin] jbampton opened pull request #14534: Enable flake8 rule E225 which checks for missing whitespace around op… (master...flake8-fix-E225) https://github.com/bitcoin/bitcoin/pull/14534
< bitcoin-git>
[bitcoin] mrwhythat opened pull request #14533: wallet: ensure wallet files are not reused across chains (master...wallet-file-reuse-prevention) https://github.com/bitcoin/bitcoin/pull/14533
< bitcoin-git>
[bitcoin] luke-jr opened pull request #14532: Never bind INADDR_ANY by default, and warn when doing so explicitly (master...rpcbind_explicit) https://github.com/bitcoin/bitcoin/pull/14532
< bitcoin-git>
[bitcoin] promag opened pull request #14531: Replace fs::relative call with custom GetRelativePath (master...2018-10-getrelativepath) https://github.com/bitcoin/bitcoin/pull/14531
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14530: scripted-diff: Use RPCHelpMan on RPCs with no args (master...Mf1810-rpcHelpMan) https://github.com/bitcoin/bitcoin/pull/14530
< bitcoin-git>
[bitcoin] laanwj closed pull request #14527: qa: Revert "Make qt wallet test compatible with qt4" (master...Mf1810-qtRemoveQT4file) https://github.com/bitcoin/bitcoin/pull/14527
< bitcoin-git>
bitcoin/master fadffae MarcoFalke: Revert "Make qt wallet test compatible with qt4"...
< bitcoin-git>
bitcoin/master 96c409c Wladimir J. van der Laan: Merge #14527: qa: Revert "Make qt wallet test compatible with qt4"...
< fanquake>
Chris_Stewart_5 See the channel history, we've forked rapidcheck to bitcoin-core, could be a chance to use the new make install method etc. You should have gotten invite to /bitcoin and /bitcoin-core as well.
< midnightmagic>
still burns me atmel dropped avr for arm. wumpus: well if it does anything interesting with the bitcoin node, I know I at least would love to hear about it.
< wumpus>
yes, bitcoin runs ok, syncing doesn't go super fast but it was a bit faster than most ARM boards from a few years ago I've tried on