< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16438: travis: Print memory and number of cpus (master...1907-travisFreeProc) https://github.com/bitcoin/bitcoin/pull/16438
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #16438: travis: Print memory and number of cpus (master...1907-travisFreeProc) https://github.com/bitcoin/bitcoin/pull/16438
< elichai2> sipa: FYI https://github.com/rust-bitcoin/rust-secp256k1/pull/132 from my very non serious benchmarks it seem to be 10-15 precent faster in verification
< sipa> yeah, seems expected
< sipa> libsecp256 benchmarks show something similar
< fanquake> So is Travis always meant to give us 2 cores per build, or does it just flip a coin to pick between 1 or 2 cores.
< fanquake> Maybe I'm misunderstanding how it's setup: https://github.com/bitcoin/bitcoin/pull/16438#issuecomment-514010659
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/51a6e2c41929...67737cf22aee
< bitcoin-git> bitcoin/master fa4010e MarcoFalke: travis: Print memory and number of cpus
< bitcoin-git> bitcoin/master 67737cf MarcoFalke: Merge #16438: travis: Print memory and number of cpus
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16438: travis: Print memory and number of cpus (master...1907-travisFreeProc) https://github.com/bitcoin/bitcoin/pull/16438
< fanquake> Raystonn: I'm working on porting one of our C based tools to Rust. The library (libdmg-hfsplus) is unmaintained, and broken such that we need to use genisoimage to first create an ISO, then convert that to a DMG.
< fanquake> Ideally we can replace both with a single tool. It'd also mean we can drop some of our "hacks" and generate DMGs closer to what you'd expect to see out of hdiutil.
< fanquake> ariard: would you like anything put into high-priority? One of the base PRs for some of your locking changes?
< ariard> fanquake: hey, #15713 has already been reviewed a lot by jnewbery, I think it's ready for another round, that's the first step for the locking changes
< gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub
< luke-jr> fanquake: so now we'd need to build a Rust compiler instead? I'm not sure that's an improvement
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/67737cf22aee...ad4391ca384b
< bitcoin-git> bitcoin/master fa56b21 MarcoFalke: doc: Update bips 35, 37 and 111 status
< bitcoin-git> bitcoin/master ad4391c fanquake: Merge #16430: doc: Update bips 35, 37 and 111 status
< bitcoin-git> [bitcoin] fanquake merged pull request #16430: doc: Update bips 35, 37 and 111 status (master...1907-docBips) https://github.com/bitcoin/bitcoin/pull/16430
< bitcoin-git> [bitcoin] ajtowns opened pull request #16439: RPC: support "@height" in place of blockhash for getblock etc (master...201907-getblock-at-height) https://github.com/bitcoin/bitcoin/pull/16439
< kallewoof> If I wanna turn a CKey into a CTxDestination, is ExtractDestination(GetScriptForRawPubKey(key.GetPubKey()), dest) the right approach? It looks weird, e.g. GetScriptForRawPubKey() gives a P2PK script...
< aj> kallewoof: GetAllDestinationsForKey() ?
< kallewoof> aj: Ahh, nice. Thank you
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ad4391ca384b...848f245d04b6
< bitcoin-git> bitcoin/master 4f050b9 James O'Beirne: move-onlyish: move CCoinsViewErrorCatcher out of init.cpp
< bitcoin-git> bitcoin/master 848f245 fanquake: Merge #16355: refactor: move CCoinsViewErrorCatcher out of init.cpp
< bitcoin-git> [bitcoin] fanquake merged pull request #16355: refactor: move CCoinsViewErrorCatcher out of init.cpp (master...2019-07-au-coinscatcher) https://github.com/bitcoin/bitcoin/pull/16355
< fanquake> aj: done
< aj> fanquake: thanks!
< bitcoin-git> [bitcoin] kallewoof opened pull request #16440: BIP-322: Generic signed message format (master...feature-generic-signed-message-format) https://github.com/bitcoin/bitcoin/pull/16440
< bitcoin-git> [bitcoin] fanquake pushed 9 commits to master: https://github.com/bitcoin/bitcoin/compare/848f245d04b6...e6e99d4f757f
< bitcoin-git> bitcoin/master 1ec30b8 Carl Dong: depends: xproto is only directly needed by libXau
< bitcoin-git> bitcoin/master 9a01ab0 Carl Dong: depends: qt: Explicitly stop using Xlib/libX11
< bitcoin-git> bitcoin/master aa53cb7 Carl Dong: depends: libX11: Make package headers-only
< bitcoin-git> [bitcoin] fanquake merged pull request #16408: depends: Prune X packages (master...2019-07-depends-X-pruning) https://github.com/bitcoin/bitcoin/pull/16408
< aj> fanquake: can you restart https://travis-ci.org/bitcoin/bitcoin/builds/553802498 again? :( :)
< fanquake> aj: done again
< bitcoin-git> [bitcoin] fanquake opened pull request #16441: Remove qt libjpeg check from bitcoin_qt.m4 (master...remove-qt-libjpeg-check) https://github.com/bitcoin/bitcoin/pull/16441
< promag> test only pull: #16404
< gribble> https://github.com/bitcoin/bitcoin/issues/16404 | qa: Test ZMQ notification after chain reorg by promag · Pull Request #16404 · bitcoin/bitcoin · GitHub
< Raystonn> fanquake: Just saw the message regarding the port of libdmg-hfsplus to rust. That's great. Are there any other tools or other unmaintained modules that you think could use the same treatment? I'm tempted to port everything to rust just to see what flaws it can help us find in Core. But so much work in a complex moving target.
< ryanofsky> dongcarl, wumpus: question about bip-0155. I don't see a size field. So if we add a new network type, and serialize a list of addresses, can old software deserialize the full list and only ignore new addresses?
< dongcarl> ryanofsky: From my understanding we're not going to send addrv2 messages to old peers
< ryanofsky> by "old software" i mean software that understands addrv2, but doesn't understand new address types that we could add later
< ryanofsky> if there's a size field, that software could skip unknown address types in a list and ignore them. question is if that's possible in the proposal without a size field
< sipa> oh, i assumed there was some form of size field
< sipa> ryanofsky: addr is serialized as a byte vector
< sipa> which has an implicit length byte
< ryanofsky> ah, missed that part, thanks
< ryanofsky> and i see dongcarl basically asked the opposite question yesterday. just catching up now
< dongcarl> I think the "size" can be specified either at the addr-field level (as in the spec) or at the "address"-level... I'll try both out when implementing and see which one is simpler. If people have a preference with a rationale that would also be nice
< dongcarl> s/"address"/"address-entry"/
< sipa> dongcarl: i suspect it's easiest as specified in the bip
< sipa> just treat the addr field as a std::vector<uint8_t> and convert it from/to internal format
< dongcarl> sipa: makes sense!
< bitcoin-git> [bitcoin] jimpo opened pull request #16442: Serve BIP 157 compact filters (master...bip157-net) https://github.com/bitcoin/bitcoin/pull/16442
< ryanofsky> yeah, field level as specified is probably easier to implement. entry level probably doesn't have an advantage because there are already other fields that could be used to extend entry format in the future
< ryanofsky> one thing i might change is "Network port. If not relevant for the network this MUST be 0."
< ryanofsky> if port is not relevant for the networkID, could just not serialize the port field
< ryanofsky> but this would argue for entry-level rather than field-level size i guess...
< sipa> yup, exactly
< sipa> could also merge the port field into the address
< sipa> with network type specific semantics on how to split them
< jnewbery> Is there any reason for CMerkleTx to exist (separate from CWalletTx)? It's been there since it was in main.cpp in the first git commit, but it's now in wallet.h and is _only_ used as the base class for CWalletTx, so it seems redundant.
< sipa> it used to be the case that for every CWalletTx , a CMerkleTx was stoeea for each unconfirmed dependency or so
< sipa> *stored
< jnewbery> That doesn't seem to be the case any more
< sipa> indeed; i believe they're redundant now
< jnewbery> yeah, looks like it was called vtxPrev, removed in 93a18a3650292afbb441a47d1fa1b94aeb0164e3
< jnewbery> I guess we'd still need the deserialization logic, to be able to read old wallet files
< sipa> oh, good point
< jnewbery> but we could have a very small class with just serialize/deserialize functions and move all the other functions into CWalletTx
< MarcoFalke> If you do that, it might be good to move it to ./primitives/ (see https://github.com/bitcoin/bitcoin/pull/5306#issuecomment-63618817)
< MarcoFalke> Oh, maybe not, because it is only used by the wallet
< * MarcoFalke> off
< jnewbery> yeah, I imagine adding some class DummyMerkleTx or similar in wallet.h that just deals with [de]serialization, and moving all the actual CMerkleTx code into CWalletTx
< jnewbery> (this is in the context of https://github.com/bitcoin/bitcoin/pull/15931/commits/827f65ba7a98bc1124a3483f42157df9db0975a7, in which some of those CMerkleTx functions require access to the CWallet class)
< jnewbery> thanks for the pointers all
< amiti> hi! I have been thinking about improvements to rebroadcast logic. Instead of nodes only rebroadcasting wallet txns, nodes will rebroadcast all txns it believes should have been in the last block. The goal is to improve privacy by making it harder to discern the transaction source.
< amiti> You can also see https://github.com/bitcoin/bitcoin/issues/15734 for more context.
< amiti> Looking for critical feedback and concept ACKs. Thanks in advance !
< MarcoFalke> Concept ACK ;)
< jonasschnelli> amiti: probably send that to the mailing list
< jonasschnelli> although very Bitcoin Core specific... but probably ok
< sipa> it may make sense to write a comprehensive "how bitcoin core does transaction broadcasting" for publishing once we've figured everything out
< fanquake> Might be worth bringing up at the meeting?
< sipa> i'm not sure it matters that much at this point
< sipa> yeah
< amiti> sipa: not sure what matters much?
< sipa> amiti: getting mailinglist input at this point
< amiti> gotcha
< amiti> as per ryanofsky's comment on the issue, I'm thinking of posting a version of the gist to the dev wiki (https://github.com/bitcoin-core/bitcoin-devwiki/wiki) once its more figured out
< gleb> 50 minutes ago I was not aware of bitcoin-devwiki :)
< amiti> I'm happy to bring up at the meeting
< amiti> gleb: yeah, looks like a thriving place =P
< sipa> haha
< fanquake> amiti: you can suggest a topic in here using #proposedmeetingtopic
< amiti> #proposedmeetingtopic: Transaction Rebroadcasting https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba
< bitcoin-git> [bitcoin] jamesob opened pull request #16443: refactor: have CCoins* data managed under CChainState (master...2019-07-au-coins-under-chainstate) https://github.com/bitcoin/bitcoin/pull/16443
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16437: Always connect NotifyEntryRemoved with MempoolEntryRemoved (master...1907-AlwaysNotifyMempoolEntryRemoved) https://github.com/bitcoin/bitcoin/pull/16437
< promag> those on macos, how do you run guix? vm or docker container?
< dongcarl> promag: I believe fanquake has been doing so on docker
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16400: [refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts (master...2019-07-refactor-atmp) https://github.com/bitcoin/bitcoin/pull/16400
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #16400: [refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts (master...2019-07-refactor-atmp) https://github.com/bitcoin/bitcoin/pull/16400
< dongcarl> promag: Ping me if you run into any trouble
< promag> dongcarl: thanks, for sure
< bitcoin-git> [bitcoin] fjahr opened pull request #16445: test: Skip flaky p2p_invalid_messages test on macOS (master...mac_test) https://github.com/bitcoin/bitcoin/pull/16445
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #16328: rpc: Tidy up reporting of buried and ongoing softforks (master...1907-rpcSoftforks) https://github.com/bitcoin/bitcoin/pull/16328
< achow101> meshcollider: do you think #16301 is ready to merge yet?
< gribble> https://github.com/bitcoin/bitcoin/issues/16301 | Use CWallet::Import* functions in all import* RPCs by achow101 · Pull Request #16301 · bitcoin/bitcoin · GitHub
< instagibbs> achow101, imo one more in depth ACK should do it?
< meshcollider> Yeah ^ it's very close but I'd like at least one more or a tested ack
< meshcollider> I'll try and build and test later today
< fanquake> promag: yea all my test builds in the Guix PR were done using that Docker setup.
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e6e99d4f757f...67923d6b3c1e
< bitcoin-git> bitcoin/master fad2502 MarcoFalke: init: Use InitError for all errors in bitcoind/qt
< bitcoin-git> bitcoin/master fa6f402 Russell Yanofsky: Call node->initError instead of InitError from GUI code
< bitcoin-git> bitcoin/master 67923d6 MarcoFalke: Merge #16366: init: Use InitError for all errors in bitcoind/qt
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16366: init: Use InitError for all errors in bitcoind/qt (master...1907-initErrorGui) https://github.com/bitcoin/bitcoin/pull/16366