2018-08-30

< bitcoin-git> [bitcoin] laanwj closed pull request #14103: docs: Fix broken Doxygen comments (master...doxygen-cleanups) https://github.com/bitcoin/bitcoin/pull/14103
< bitcoin-git> bitcoin/master be301a5 Wladimir J. van der Laan: Merge #14103: docs: Fix broken Doxygen comments...
< bitcoin-git> bitcoin/master 0e534d4 practicalswift: Fix incorrect Doxygen comments
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4e9a6f87b7d2...be301a577776
< bitcoin-git> [bitcoin] practicalswift opened pull request #14103: Fix broken Doxygen comments (master...doxygen-cleanups) https://github.com/bitcoin/bitcoin/pull/14103
< gribble> https://github.com/bitcoin/bitcoin/issues/13825 | [wallet] Kill accounts by jnewbery · Pull Request #13825 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fingera opened pull request #14102: export der always compressed (master...3-export-der) https://github.com/bitcoin/bitcoin/pull/14102

2018-08-29

< promag> I mean, specific to development of bitcoin-core
< promag> reza: this channel is bitcoin-core specific
< reza> I had an idea for a Bitcoin wallet, i’d like to hear your thoughts about it.
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14083: bench: Fix thread sanitizer issue in AssembleBlock benchmark (master...Mf1808-benchAssembleBlockThread) https://github.com/bitcoin/bitcoin/pull/14083
< gribble> https://github.com/bitcoin/bitcoin/issues/14096 | Add reference documentation for descriptors language by sipa · Pull Request #14096 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< jonasschnelli> there is currently an extra round for the 4bytes length: https://github.com/bitcoin/bitcoin/pull/14050/files#diff-58a94ae53d4f04a57e9dc33014a679eaR70
< sipa> that would defeat the purpose of not being recognizable as bitcoin traffic
< jonasschnelli> Also, the v2 handshake doesn't reveal "bitcoin traffic" (not very DPI resistant though)
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14101: qa: Use named args in validation acceptance tests (master...Mf1808-qaNamedArgsAcceptance) https://github.com/bitcoin/bitcoin/pull/14101
< leishman> I added an update to the wiki with a note about the txindex db migration: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes#how-to-upgrade
< bitcoin-git> [bitcoin] ryanofsky closed pull request #9381: Remove CWalletTx merging logic from AddToWallet (master...pr/atw-nomerge) https://github.com/bitcoin/bitcoin/pull/9381
< bitcoin-git> [bitcoin] laanwj closed pull request #14097: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip (master...Mf1808-validationLogError) https://github.com/bitcoin/bitcoin/pull/14097
< bitcoin-git> bitcoin/master 4e9a6f8 Wladimir J. van der Laan: Merge #14097: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip...
< bitcoin-git> bitcoin/master fa309dc MarcoFalke: validation: Log FormatStateMessage on ConnectBlock error in ConnectTip
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/888acefa5ee1...4e9a6f87b7d2
< bitcoin-git> [bitcoin] laanwj closed pull request #13792: tx pool: Avoid passing redundant hash into addUnchecked (scripted-diff) (master...Mf1808-constTxPoolEntries) https://github.com/bitcoin/bitcoin/pull/13792
< bitcoin-git> bitcoin/master fa58777 MarcoFalke: scripted-diff: Remove unused first argument to addUnchecked...
< bitcoin-git> bitcoin/master fe5c497 MarcoFalke: tx pool: Use the entry's hash instead of the one passed to addUnchecked
< bitcoin-git> bitcoin/master ddd395f MarcoFalke: Mark CTxMemPoolEntry members that should not be modified const
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/1361f8babcc1...888acefa5ee1
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14020: Add tests for RPC help (master...2018-08-test-help) https://github.com/bitcoin/bitcoin/pull/14020
< bitcoin-git> bitcoin/master 6af6d9b João Barbosa: test: Add tests for RPC help
< bitcoin-git> bitcoin/master 1361f8b MarcoFalke: Merge #14020: Add tests for RPC help...
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b0eb8f7ed43e...1361f8babcc1
< gribble> https://github.com/bitcoin/bitcoin/issues/13845 | Include tinyformat as a subtree by Empact · Pull Request #13845 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13846 | Move src/tinyformat.h to src/tinyformat/tinyformat.h by Empact · Pull Request #13846 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj closed pull request #14028: Explicitly initialize prevector _union (master...prevector-explicit-initialization) https://github.com/bitcoin/bitcoin/pull/14028
< bitcoin-git> bitcoin/master b0eb8f7 Wladimir J. van der Laan: Merge #14028: Explicitly initialize prevector _union...
< bitcoin-git> bitcoin/master 1d9aa00 Ben Woosley: Explicitly initialize prevector _union
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5924dadc2f2d...b0eb8f7ed43e
< bitcoin-git> [bitcoin] laanwj closed pull request #13671: Remove the boost/algorithm/string/case_conv.hpp dependency (master...patch/remove_boost_case_conv.hpp) https://github.com/bitcoin/bitcoin/pull/13671
< bitcoin-git> bitcoin/master b193d5a 251: Removes the Boost case_conv.hpp dependency....
< bitcoin-git> bitcoin/master 7a208d9 251: Implements custom tolower and toupper functions....
< bitcoin-git> bitcoin/master e2ba043 251: Implements ParseNetwork unit test....
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ddce35abcb8...5924dadc2f2d
< bitcoin-git> [bitcoin] laanwj closed pull request #13862: utils: drop boost::interprocess::file_lock (master...custom-filelock) https://github.com/bitcoin/bitcoin/pull/13862
< bitcoin-git> bitcoin/master 2ddce35 Wladimir J. van der Laan: Merge #13862: utils: drop boost::interprocess::file_lock...
< bitcoin-git> bitcoin/master 1661a47 Chun Kuan Lee: add unicode compatible file_lock for Windows...
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/13887f41f229...2ddce35abcb8
< bitcoin-git> [bitcoin] laanwj opened pull request #14100: doc: Change documentation for =0 for non-boolean options (master...2018_08_nodoc) https://github.com/bitcoin/bitcoin/pull/14100
< bitcoin-git> [bitcoin] osbc closed pull request #14099: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14099
< bitcoin-git> [bitcoin] osbc opened pull request #14099: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14099
< wumpus> yessss @ bitcoin-git
< bitcoin-git> [bitcoin] osbc closed pull request #14098: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14098
< bitcoin-git> [bitcoin] osbc opened pull request #14098: Dev (master...dev) https://github.com/bitcoin/bitcoin/pull/14098
< leishman_> I see in jimpos PR here (https://github.com/bitcoin/bitcoin/pull/13033) that it was tested. What kind of migration times did others see?

2018-08-28

< gribble> https://github.com/bitcoin/bitcoin/issues/13825 | [wallet] Kill accounts by jnewbery · Pull Request #13825 · bitcoin/bitcoin · GitHub
< gmaxwell> But say, for example, we decide we want to have a HEADERS2 message coded as value 27 in bitcoin core. We're going to negoiate its activation with something like SENDHEADERS. Say another implementation BitcoinConnectUnlimitedClassic (BCUX) wants to use 27 for XHEADERS. An implementation could support talking to both kinds of peers just by assigning the meaning of 27 based on the negoation.
< waxwing> sipa, what's going on here? why would someone be adding both witness and non-witness utxo fields in the same input (bip174)? https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L256-L259
< gribble> https://github.com/bitcoin/bitcoin/issues/14087 | Remove unnecessary G_TRANSLATION_FUN nullptr assignment by promag · Pull Request #14087 · bitcoin/bitcoin · GitHub
< wumpus> (re: bitcoin P2P specifically: do we ever get *unexpected* big messages?)

2018-08-27

< jonasschnelli> gmaxwell: I can't follow your comment here: https://github.com/bitcoin/bitcoin/pull/14049#discussion_r213027446
< gribble> https://github.com/bitcoin/bitcoin/issues/13825 | [wallet] Kill accounts by jnewbery · Pull Request #13825 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/14023 | Remove accounts rpcs by jnewbery · Pull Request #14023 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/5 | Make the version number the protocol version and not the client version · Issue #5 · bitcoin/bitcoin · GitHub
< Jmabsd> *actually*, the hex string printer does NOT reverse the hex positions (https://github.com/bitcoin/bitcoin/blob/eb7daf4d600eeb631427c018a984a77a34aca66e/src/utilstrencodings.h#L121 - see here there's no reversing of the order of the bits in the byte) - and the reversing logic applied on the whole per-structure level is reversing byte order only, never bit order (ref. https://github.com/bitcoin/bitcoin/blob/eb7daf4d600eeb631427c018a984a77a34aca66e/sr
< Jmabsd> wait, in the Bitcoin PoW 32bit floating point structure "deserializer" at https://github.com/bitcoin/bitcoin/blob/eb7daf4d600eeb631427c018a984a77a34aca66e/src/arith_uint256.cpp#L209
< ossifrage> looking at: pmap -x $(pidof bitcoin-qt) | grep .ldb | awk '{if($3 == 0){print}}' shows that many of the ldb files aren't using any RSS memory (after being up for almost a month)

2018-08-26

< gmaxwell> in bitcoin we're seeing an increase of hundreds of meg.
< Chris_Stewart_5> jimpo: These test vectors seem to be a dead link https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki#appendix-c-test-vectors
< instagibbs> Chris_Stewart_5, merged two hours ago, didnt see that https://github.com/bitcoin/bitcoin/pull/12254
< instagibbs> Chris_Stewart_5, https://github.com/bitcoin/bitcoin/pull/13144
< gribble> https://github.com/bitcoin/bitcoin/issues/13023 | Fix some concurrency issues in ActivateBestChain() by skeees · Pull Request #13023 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13937 | Track best-possible-headers (TheBlueMatt) by Sjors · Pull Request #13937 · bitcoin/bitcoin · GitHub
< provoostenator> Any volunteer for making a PR based on this commit? https://github.com/bitcoin/bitcoin/commit/a9db3dada0119c183d16627805e90c4dbca05c6a
< luke-jr> hopefully I won't "damage" my mainnet .bitcoin trying this.. :x
< gribble> https://github.com/bitcoin/bitcoin/issues/12495 | Increase LevelDB max_open_files by eklitzke · Pull Request #12495 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12495 | Increase LevelDB max_open_files by eklitzke · Pull Request #12495 · bitcoin/bitcoin · GitHub
< wumpus> luke-jr: the only reason that the change to num files was acceptable is because leveldb, at least the version in our tree, doesn't actually keep more files open (on platforms with mmap) see also https://github.com/bitcoin/bitcoin/pull/12495#issuecomment-377228329
< luke-jr> was there a point to https://github.com/bitcoin-core/leveldb/pull/19 considering we limit leveldb to 1000 open files anyway?

2018-08-25

< jamesob> (for those following along at home: https://github.com/bitcoin/bitcoin/pull/13925/files)
< Jmabsd> > sipa, right and when getting a disassembly printout in Bitcoin Core and related tools, those 20B:s are printed in normal order
< Jmabsd> What about pubkey hashes (20B), pubkeys (32B) and signatures (64B) - are those printed in normal or reverse byte order? so, I have a P2SH pubkey script, say. in there is a 20B hash of my redeemscript, right. when I use Bitcoin Core's script disassembly function, will it print that hash in byte or normal order? i mean there is an outer extent to what Core prints in reverse order - for instance, binary transaction dumps (in hex) are in
< Jmabsd> wait, so Bitcoin has the tendency to print (256 & 160bit) hashes in *reverse* order, right - block hashes, transaction hashes and merkle root hashes.

2018-08-24

< gribble> https://github.com/bitcoin/bitcoin/issues/2802 | Add an address-based transaction index by sipa · Pull Request #2802 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13243 | Make reusable base class for auxiliary indices by jimpo · Pull Request #13243 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13033 | Build txindex in parallel with validation by jimpo · Pull Request #13033 · bitcoin/bitcoin · GitHub
< BlueMatt> of which there are many, any I generally dont trust most bitcoin libraries...for obvious reasons
< BlueMatt> sipa: well its either that or we have to pass a flag into signrawtransaction (and any equivalent APIs in any bitcoin library anywhere)
< BlueMatt> at least rust-bitcoin currently doesnt
< BlueMatt> and doesnt-need-to-be-backwards-compatible APIs (eg rust-bitcoin's deserializer) can *only* handle it that way
< gribble> https://github.com/bitcoin/bitcoin/issues/13033 | Build txindex in parallel with validation by jimpo · Pull Request #13033 · bitcoin/bitcoin · GitHub
< as1nc> jonasschnelli, yes but i really want to incite people to txindex their chain so they can benefit the full spectrum of bitcoin capabilities. lightning for exemple require a txindexed chain right ?
< MaxHastings_> jonasschnelli: Ah I see I did not know bloom filters were ineffective for keeping user privacy. Are there any other missing vulnerabilities on that page other than privacy concerns? I was told on Bitcoin slack that the SPV client could be tricked to change its consensus rules by malicious nodes.
< jonasschnelli> But its OT in this channel... so use #bitcoin
< as1nc> Hello guys, just published a 2018 simple guide to set up a bitcoin core node on, feedback really appreciated. https://gist.github.com/larafale/b4df34a97c7134cf1579539caf2db2c2
< MaxHastings_> Hey. I just have a quick question. Are all the known vulnerabilities for SPV wallets listed here? https://bitcoin.org/en/developer-guide#simplified-payment-verification-spv I've been told on the Bitcoin slack that there are more.
< luke-jr> I have cache/bitcoin-linux-0.17/bitcoin-linux-0.17/, possibly from manual copy-from-target on failures

2018-08-23

< jonasschnelli> Does anyone knows why appveyor has build issues when travis and gitian is fine with it? https://ci.appveyor.com/project/DrahtBot/bitcoin/build/master.148
< gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< gmaxwell> AFAIK, it just works. It's kinda limited though because none of them resist traffic analysis and it's SUPER easy to identify bitcoin traffic with traffic analysis. :)
< gmaxwell> wumpus: I think jonasschnelli suggests that we have support for these obfscuated transports without putting tor in the middle. I think we already do (in fact, I used one of the ones made for tor to bridge bitcoin nodes last year when we were worried about china blocking bitcoin... before later changing to an icecast stream so that it wouldn't be identifyable by traffic analysis)
< jonasschnelli> The idea is to make Bitcoin work in DPI env in case it would get blocked,.. like China or Iran
< wumpus> integrating tor's code into bitcoin core is not a good idea
< sipa> how is it bitcoin specific, or what do you specifically propose?
< wumpus> looks like a layer violation to worry about this? or do you want to make tor tunnel over bitcoin instead of the other way around?
< wumpus> bitcoin core can use tor
< gribble> https://github.com/bitcoin/bitcoin/issues/13961 | util: Replace boost::signals2 with std::function by MarcoFalke · Pull Request #13961 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 two were merged, one was added, this leaves five open
< gribble> https://github.com/bitcoin/bitcoin/issues/14032 | Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli · Pull Request #14032 · bitcoin/bitcoin · GitHub
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
< gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
< wumpus> I don't see it https://ci.appveyor.com/project/DrahtBot/bitcoin/build/master.127, but maybe I'm looking over it
< _flow_> wumpus: jonasschnelli: thanks. I'll consider adding a test for the issue the user in https://github.com/bitcoin/bitcoin/pull/12255#issuecomment-403666092 is experiencing
< _flow_> What can I do to get https://github.com/bitcoin/bitcoin/pull/13621 merged? It improves the, currently terriable, configuration mechanics of bitcoind a bit (while still not perfect) and re-enables a recently disabled test.
< ken2812221_> MarcoFalke: You can checkout https://ci.appveyor.com/gitHubTeams and https://ci.appveyor.com/project/Drahtbot/bitcoin/settings/permissions to help you setting up appveyor permissions.
< gnappuraz> thx for the answer. But let's assume that I have to add a new file that if meant to be use by both bitcoind and bitcoin-qt, the rationale behind putting it in COMMON vs UTIL should be: if used by bitcoin-cli then UTIL, otherwise COMMON (since bitcoin-cli links UTIL but not COMMON)?
< jonasschnelli> gnappuraz: these are semi-independent modules. Those modules get linked for the different binaries we have (bitcoin-tx, bitcoin-cli, bitcoind, bitcoin-qt).
< gmaxwell> achow101: https://bitcoin.stackexchange.com/questions/78292/insanely-high-fee lol I wonder if we should make it _harder_ to bypass that...
< Jmabsd> derp derp, ok Bitcoin Core gonna kick in more reverse order hex conventions in the ecosystem over time, he he. however users won't care really about those.
< achow101> (in a modification of Bitcoin Core)
< Jmabsd> gmaxwell: exactly, Bitcoin Core's HDwallet seeds are 160bit and presented in reverse order, yes
< Jmabsd> some other hash, even if it relates to the bitcoin protocol, then normal order is fine
< Jmabsd> achow101: exactly. so all over the whole Bitcoin ecosystem, those three values (block HASH, transaction HASH and merkle root HASH aka ID whatever), when you're dealing with hex representation, it must ALWAYS be in reverse order bc otherwise you'll screw up
< achow101> Jmabsd: fun fact, bitcoin core does exactly that
< Jmabsd> so we can only understand that transaction id:s and merkle root id:s (and in Bitcoin Core's case also hd wallet seeds) got this reverse byte order,
< achow101> Jmabsd: Bitcoin Core checks that if the block hash is bigger than the target, it should fail, hence the return false that follows
< Jmabsd> so, Bitcoin Core does "if (UintToArith256(hash) > bnTarget)" - so you're checking that the block hash is "more work" than the target value, and meanwhile LibBitcoin does "to_uint256(hash()) <= target;", https://github.com/libbitcoin/libbitcoin/blob/master/src/chain/header.cpp#L464
< Jmabsd> achow101: the "nBits" value, which is copied from the block header and is applied in PoW here https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L80 : "arith_uint256 bnTarget;bnTarget.SetCompact(nBits, &fNegative, &fOverflow);" , it's in the Bitcoin-internal 32bit floating point format right??
< Jmabsd> achow101: right so Bitcoin Core defines both 256bit and 160bit hashes as subclasses of "base_blob", is this what you mean by byte array?
< achow101> Jmabsd: Bitcoin Core prints everything that is a byte array in reverse byte order
< dcousens> Bitcoin core reverse orders any 256-bit hex string, basically
< Jmabsd> wait, hashes are such are binary/byte concepts so the whole idea of relating to them as comparable numbers, is a concept that Bitcoin adds on top of them, right? the inventor of SHA256 never related to hashing as SHA256(byte string) => 256bit integer which may be little or big endian, right?
< Jmabsd> dcousens: aha. Bitcoin Core would print the merkle root in reverse order. anyhow right.
< Jmabsd> luke-jr: https://github.com/bitcoin/bitcoin/blob/master/src/uint256.h#L49 is this the < operator used, or is the logics somewhere else?
< Jmabsd> (which is some Bitcoin transaction for some purpose)
< Jmabsd> for instance, for symmetry with Bitcoin, if you make a Dcousens Bitcoin Transaction format, then obviously its hash should be printed in reverse order.
< Jmabsd> dcousens: yeap i see. i'm trying to make just a bit of sense here, so that, if you make a Dcousens Protocol to do some Bitcoin-related stuff, and you have some structure in your protocol that you hash and then give to people, in what order should it be.
< Jmabsd> that makes sense yes. what code in Bitcoin Core compares two uint256:es, which would be used for sorting?
< gmaxwell> 21:30:21 < gmaxwell> block hash is interpreted as a 256-bit little endian number for target comparison as luke says, so then bitcoin needed to print it that way too, otherwise the 0s would have been on the right which would have been confusing... and the same code was then used to print other hashes.
< gmaxwell> 21:29:12 < gmaxwell> Jmabsd: the point is that bitcoin's UI uses the same stuff to print all these 256 bit hashes.
< Jmabsd> oh, the HD wallet stuff uses reverse byte order too: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L3059

2018-08-22

< MarcoFalke> They are known to be broken and only meant to run on bitcoin/bitcoin pull requests
< jonasschnelli> MarcoFalke: travis on my repository fails even on the lint level: https://travis-ci.org/jonasschnelli/bitcoin/jobs/419285727
< jonasschnelli> 3e953061e6baa7dc4d759d8447041071bff6222bc70188a66eddbcee8136c55e bitcoin-0.17.0-win-unsigned.tar.gz
< jonasschnelli> cef09c6e3d13bc082a5cdb878324b350a17c492fa77af805e0745ba52ee031aa bitcoin-0.17.0-osx-unsigned.dmg
< MarcoFalke> jonasschnelli: Huh, I can't find any recent travis builds on you repo https://github.com/jonasschnelli/bitcoin/commits/master
< jonasschnelli> Maybe they don't fall on bitcoin/bitcoin travis due to the exta CPU cycles we bought
< sipa> airplanemod: bitcoin core is primarily developed on unix systems (and the windows binaries are produced through cross compiling on linux)
< sipa> setting up a development environment isn't very bitcoin core specific, so i wouldn't say is on topic here
< airplanemod> Hey guys, I would like to know if it is possible to set up a development environment for bitcoin-qt and/or bitcoind that will allow me to set breakpoints and step through live code as it is running? I cannot seem to find a tutorial or any good starting point for how to do this. I have been testing my own edits in a simple text editor and using gitian builder to compile and test using
< Jmabsd> (yes I totally see that Bitcoin Core or the Bitcoin protocol never represent data in reverse order internally - it's only a human representation thing)
< gmaxwell> block hash is interpreted as a 256-bit little endian number for target comparison as luke says, so then bitcoin needed to print it that way too, otherwise the 0s would have been on the right which would have been confusing... and the same code was then used to print other hashes.
< gmaxwell> Jmabsd: the point is that bitcoin's UI uses the same stuff to print all these 256 bit hashes.
< Jmabsd> gmaxwell, yes interesting, i see clearly in Bitcoin Core and other implementations that indeed there is no reversing whatsoever, no "endianness" or the like here. you are right that the code in the wild must have been mitigating some kind of user-facing hex representation quirk.
< gmaxwell> Bitcoin "UI" hashes are backwards for path dependant but otherwise explicable reasons...
< gmaxwell> Jmabsd: Sipa already answered this question previously. The bitcoin protocol uses sha256 exactly as it is.
< Jmabsd> luke-jr: is any particular byte ordering or "endianness" to the SHA256 used here, i've seen some Bitcoin merkle node calculation use byte-reverse logics
< Jmabsd> it's used in merkle calculation (https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L57) and the code in itself presently leaves a little bit of guesswork to the reader about what's going on
< Jmabsd> it would be great if crypto/sha256.cpp's SHA256D64() would be clarified in a comment, what it does exactly (https://github.com/bitcoin/bitcoin/blob/master/src/crypto/sha256.cpp#L698)
< Jmabsd> sipa, two quick off-topic but conceptually related questions, as general guidance for design of any new signing protocols, would you suggest using a single hash instead of double, or could it make sense to recycle Bitcoin's double-hash for symmetry with Bitcoin? also for guidance for other protocols, if you're going to do a salted hash of some message e.g. SHA256HMAC(protocolmessage,"SIPAPROTOCOL"), then for extension
< sipa> bitcoin basically everywhere either uses ripemd160(sha256(x)) or sha256(sha256(x))
< Jmabsd> the hash used in signing is a single-pass (small-endian? err) SHA256 hash of the signtext (here, https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1298 ) right?
< Jmabsd> and so Bitcoin is really only dealing with the "contract endorsement" structures, and hence in the real world those are 72B+1B sighhash=73B max.
< Jmabsd> sipa: ah right, so, the zoomed-out situation in Bitcoin is that DER situations are in sigscript, redeem script (part of sigscript right) and P2WSH witness script (input's last witness element), only.
< sipa> every signature in bitcoin script has a sighash byte
< Jmabsd> Wait, in what situations are sighash bytes not added vs. added, to ecdsa signatures in Bitcoin? With a sighhash byte the DER signature max size is 73B (if low-s, 72B) whereas without sighash byte the max size is 72B (if low-s, 71B).

2018-08-21

< wumpus> but you can be certain it's not about a "string parser", nothing in bitcoin script uses strings
< gribble> https://github.com/bitcoin/bitcoin/issues/13501 | Correctly terminate HTTP server by promag · Pull Request #13501 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
< Jmabsd> (ah he responded on #bitcoin, great.)
< sipa> and bitcoin adds a 1 byte sighash to the end
< Jmabsd> (this may be more of a #bitcoin question), what is an authoritative reference on that the DER signature's max size is 72 bytes? i see some discussion like this https://bitcoin.stackexchange.com/questions/12554/why-the-signature-is-always-65-13232-bytes-long but it's not super clea.r
< Jmabsd> wait, where are Bitcoin Core's logics to actually enforce little-endian serialization - say I run Bitcoin Core on an ARM.. is this the line that will cause the big endian (native to my computer) to little endian (serialization form) conversoin: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L89 ?
< Jmabsd> sipa, the SHA256 specific about Bitcoin is why you need to byte-reverse most(all?) SHA256 libraries' results within Bitcoin merkle tree merkle node calculations, right?
< sipa> (SHA256 internally uses big endian, but that's black box - it's a function that takes as input a byte array and produces another byte array from bitcoin's pov)
< sipa> everything in bitcoin uses little endian
< Jmabsd> Where is Bitcoin Core's serialization and deserialization code for values in various structures such as transactions, block headers, and protocol data? This code shows the endianness used
< gribble> https://github.com/bitcoin/bitcoin/issues/13968 | [wallet] couple of walletcreatefundedpsbt fixes by instagibbs · Pull Request #13968 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/14005 | [0.17] depends: fix qt determinism by MarcoFalke · Pull Request #14005 · bitcoin/bitcoin · GitHub

2018-08-20

< wumpus> Zenton: better ask in #bitcoin, this is a developer channel, you'd probably want to mention your perceived threat model for 'secure enough' as well
< gribble> https://github.com/bitcoin/bitcoin/issues/13248 | [gui] Make proxy icon from statusbar clickable by mess110 · Pull Request #13248 · bitcoin/bitcoin · GitHub
< mess110> hi, can I get a few reviews for https://github.com/bitcoin/bitcoin/pull/13248 please?

2018-08-18

< sipa> bitcoin-qt -reindex
< sipa> this discussion should probably move to #bitcoin
< unixb0y> sipa: I run bitcoin-qt tbh :P
< gmaxwell> Unfortunately, Bitcoin actually makes quite full use of the computer and so if its flaky at all it'll croak out. deleting blk and rev files is never going to help anything.
< unixb0y> HI guys, I have a little issue with the initial Bitcoin Core setup.

2018-08-17

< gribble> https://github.com/bitcoin/bitcoin/issues/14000 | depends: fix qt determinism by theuni · Pull Request #14000 · bitcoin/bitcoin · GitHub
< MarcoFalke> gitian-builder/cache/bitcoin-linux-0.17/x86_64-linux-gnu/* I meant
< gmaxwell> I think it's fine to just wait for the next message for bitcoin core, since we ping with a perfectly fine interval.
< gmaxwell> it think it would be really neat for someone to implement a UDP protocol for bitcoin that just runs as a proxy in another process.
< achow101> cfields_: here are my binaries https://github.com/achow101/bitcoin/releases/tag/v0.17.0rc1
< achow101> oh, nvm, i see what you meant by bitcoin-qt being the non-deterministic one
< wumpus> bitcoin-qt only suggests to me it's another non-determinism thing with the qt tooling, maybe file ordering or date/time in metadata in the qrc archives
< ken2812221> The difference is on bitcoin-qt, I've compared it before but I deleted the docker one.
< promag> in 13501, I was puzzled to know why bitcoin-cli worked differently than AuthProxy
< gribble> https://github.com/bitcoin/bitcoin/issues/13501 | Correctly terminate HTTP server by promag · Pull Request #13501 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< gribble> https://github.com/bitcoin/bitcoin/issues/13501 | Correctly terminate HTTP server by promag · Pull Request #13501 · bitcoin/bitcoin · GitHub

2018-08-16

< kevink> I'm using Bitcoin Core's API and am wondering whats the difference between `duplicate-inconclusive` and `duplicate` when calling `submitblock`. I'm just trying to verify that a block exists in the blockchain and `submitblock` seems like the simplest way to do that.
< wumpus> probably the first RISC-V bitcoin node in the world
< gribble> https://github.com/bitcoin/bitcoin/issues/12493 | [wallet] Reopen CDBEnv after encryption instead of shutting down by achow101 · Pull Request #12493 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHub
< jtimon> if high priority is still for blockers, https://github.com/bitcoin/bitcoin/pull/13311 is kind of a blocker for https://github.com/bitcoin/bitcoin/pull/8994 which is itself a blocker for toher things I wanted to do
< gribble> https://github.com/bitcoin/bitcoin/issues/13866 | utils: Use _wfopen and _wfreopen on Windows by ken2812221 · Pull Request #13866 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13968 | [wallet] couple of walletcreatefundedpsbt fixes by instagibbs · Pull Request #13968 · bitcoin/bitcoin · GitHub
< instagibbs> https://github.com/bitcoin/bitcoin/pull/13968 bugfixes for psbt stuff too(0.17 backport)
< gribble> https://github.com/bitcoin/bitcoin/issues/13723 | PSBT key path cleanups by sipa · Pull Request #13723 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 there's only one PR in there at the moment, #13100
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
< gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
< jonasschnelli> wumpus: still building: https://bitcoin.jonasschnelli.ch/build/743

2018-08-15

< gmaxwell> https://github.com/bitcoin/bitcoin/pull/13657 I don't understand this change. Coinbase transactions can be conflicted, by being orphaned block. I guess GetDepthInMainChain doesn't return negative in the case, but I think it probably should.
< fanquake> Unsure how a readme got added with a bunch of references to open PRs? https://github.com/bitcoin/bitcoin/pull/13981#issuecomment-413190203 Not sure if they should be removed or not
< Jmabsd> i would think that Bitcoin accomodated burn already, that's why i was so surprised to see that comment in that bitcoin.org article.
< Jmabsd> sipa: exactly, i'm rading the relay code and can't find it too. so i was thinking maybe that bitcoin.org article is bss*ahem*incorrect*ahem*obsolete.
< sipa> this discussion is more appropriate for #bitcoin or https://bitcoin.stackexchange.com
< Jmabsd> "Bitcoin Core 0.12.0 defaults to relaying and mining null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data output and it must still pay exactly 0 satoshis."
< Jmabsd> luke-jr: wrong url sorry, here! https://bitcoin.org/en/developer-guide#standard-transactions
< Jmabsd> there's a weird claim at https://en.bitcoin.it/wiki/Script#Constants that null outputs must have amount == 0 to be relayed. is it so?

2018-08-14

< jonasschnelli> The tor argument "collect now, decrypt later" may not be applicable 1:1 to bitcoin
< sipa> but you don't want existing addnode=IP lines in bitcoin.conf files suddenly fail
< bitcoin-git> [bitcoin] laanwj closed pull request #13960: Fix PSBT deserialization of 0-input transactions (master...fix-decodepsbt-no-in) https://github.com/bitcoin/bitcoin/pull/13960
< bitcoin-git> bitcoin/master 3e5424f Wladimir J. van der Laan: Merge #13960: Fix PSBT deserialization of 0-input transactions...
< bitcoin-git> bitcoin/master 43811e6 Andrew Chow: Fix PSBT deserialization of 0-input transactions...
< bitcoin-git> bitcoin/master bd19cc7 Andrew Chow: Serialize non-witness utxo as a non-witness tx but always deserialize as witness...
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/dabfcb03071e...3e5424faf6ff
< gribble> https://github.com/bitcoin/bitcoin/issues/13901 | adduser: The user `bitcoin already exists. Exiting. · Issue #13901 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< gribble> https://github.com/bitcoin/bitcoin/issues/13826 | packaging: Auto-change datadir in ubuntu ppa · Issue #13826 · bitcoin/bitcoin · GitHub
< Gnappuraz> Hi, I was going through the bitcoin documentation but I can't find the rationale behind the fact of using the prevTx.scriptPubKey in the place of curTx.scriptSig when creating the signature
< wumpus> ken2812221_: problems with bitcoincore.org you can file at https://github.com/bitcoin-core/bitcoincore.org
< waiting2compile> hi, could someone walk me a bit through running Bitcoin's tests? I tried following the instructions in the README.md, though I suspect there's some extra setup that needs to be done that's missing, since running the command just gives make errors and the like (pardon me, I'm new to this and am trying to fix one of the good first bugs :))

2018-08-13

< nmnkgl> MarcoFalke: Could you point me to anything would prevent bitcoin core nodes from having crazy everlasting loops in case when there is a ring of whitelisted peers? In regular mode the loop will break at least because of using INVs. That may be very unlikely case though.
< MarcoFalke> This is bitcoin-core-dev
< gribble> https://github.com/bitcoin/bitcoin/issues/13951 | Hardcoded seeds update pre-0.17 branch by laanwj · Pull Request #13951 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13905 | docs: fixed bitcoin-cli -help output for help2man by hebasto · Pull Request #13905 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< MarcoFalke> wumpus: I think https://github.com/bitcoin/bitcoin/pull/13905 can go in to 0.17 as doc bug fix (tiny one)
< gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13938 | refactoring: Cleanup StartRest() by DesWurstes · Pull Request #13938 · bitcoin/bitcoin · GitHub
< kallewoof> I tried [ createpsbt "[]" "[{\"$(./bitcoin-cli getnewaddress)\":0.01}]" ], which worked fine. But decodepsbt errors for the result.
< gribble> https://github.com/bitcoin/bitcoin/issues/12391 | TODO for release notes 0.17.0 · Issue #12391 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub

2018-08-12

< gmaxwell> I totally agree that wallets shoudl be batching and whatnot, but consider: we don't even have a friendly way to do that... There is no dohicky in bitcoin core where you can queue a payment, have it draft it, but not send it, waiting for either more payments it can be bached with, timeout, or shutdown trigger.
< MarcoFalke> I was hoping we could do a primitive cache for now and later replace that with https://github.com/bitcoin/bitcoin/pull/13804 (tx pool layer)
< sipa> he left. also, https://bitcoin.stackexchange.com is your friend
< itaseski> i wasn't able to find anything bitcoin specific ...
< devmob> hi, I'd really like to know how bitcoin does gossip, like how the gossip protocol is implemented
< reald0ff1> well thanks for the answer. I think I will try to contact bitcoincore.org via email and bitcoin.org also via email to the website maintainer. Maybe some of them could provide me stats
< harding> reald0ff1: I don't know if anyone has that information for BitcoinCore.org, sorry. In addition, the binaries can also be downloaded from Bitcoin.org (maintained by a different team) or via a torrent (with optional magnet URI) that contains the binaries for all platforms.
< reald0ff1> Can someone please provide me download stats (or at least share in %) of bitcoin core, regarding the different platform versions (Win, Linux, OSX, etc) ?

2018-08-10

< gribble> https://github.com/bitcoin/bitcoin/issues/13930 | Better explain GetAncestor check for m_failed_blocks in AcceptBlockHeader by Sjors · Pull Request #13930 · bitcoin/bitcoin · GitHub
< ken2812221> I wonder why the linter failed? https://travis-ci.org/bitcoin/bitcoin/jobs/414449333
< sipa> this channel is mostly about developmemt of the bitcoin core software
< sipa> Jmabsd: i think your questions are probably better suited for bitcoin.stackexchange.com
< Jmabsd> are we in a place today where you can assume that every relevant participant in the Bitcoin ecosystem will be fine with Bitcoin transactions with version = 2?

2018-08-09

< sipa> 2018-08-09T18:55:00.301077Z receive version message: /bitcoinj:0.14.7/Bitcoin Wallet:6.28/: version 70001, blocks=535894, us=127.0.0.1:8333, peer=414
< sipa> and your ISP's cost, and the bitcoin exchange rate?
< gribble> https://github.com/bitcoin/bitcoin/issues/13808 | wallet: shuffle coins before grouping, where warranted by kallewoof · Pull Request #13808 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13922 | Lower default relay fees by ajtowns · Pull Request #13922 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/13666 | Always create signatures with Low R values by achow101 · Pull Request #13666 · bitcoin/bitcoin · GitHubAsset 1Asset 1