< bitcoin-git>
[bitcoin] promag opened pull request #19104: gui, test: Fix Cannot queue arguments of type size_t (master...2020-05-register-metatypes) https://github.com/bitcoin/bitcoin/pull/19104
< bitcoin-git>
[bitcoin] jonasschnelli merged pull request #18165: Consolidate service flag bit-to-name conversion to a shared serviceFlagToStr function (master...svcflags2str) https://github.com/bitcoin/bitcoin/pull/18165
< bitcoin-git>
bitcoin/master de369c7 Jonas Schnelli: Merge #18165: Consolidate service flag bit-to-name conversion to a shared ...
< bitcoin-git>
bitcoin/master c31bc5b Luke Dashjr: Consolidate service flag bit-to-name conversion to a shared serviceFlagToS...
< bitcoin-git>
bitcoin/master cea91a1 Luke Dashjr: Bugfix: GUI: Use unsigned long long type to avoid implicit conversion of M...
< gribble>
https://github.com/bitcoin/bitcoin/issues/18921 | build: add stack-clash and control-flow protection options to hardening flags by fanquake · Pull Request #18921 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] achow101 opened pull request #19102: wallet: Introduce and use DummyDatabase instead of dummy BerkeleyDatabase (master...true-dummydb) https://github.com/bitcoin/bitcoin/pull/19102
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #19101: refactor: remove ::vpwallets and related global variables (master...pr/novp) https://github.com/bitcoin/bitcoin/pull/19101
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #19099: refactor: Move wallet methods out of chain.h and node.h (master...pr/wclient) https://github.com/bitcoin/bitcoin/pull/19099
< wumpus>
in any case the only reason this is controversial at all is because bitcoin's P2P is semi-stateless so losing a packet is not necessarily fatal, in a stateful protocol the only sensible thing is to disconnect
< wumpus>
especially as bitcoin's P2P protocol is more or less stateless and can handle lost messages
< wumpus>
in the case of something like SSH that's annoying because yo ureally want to remain connected to that one host, for bitcoin P2P though ,they'll just connect to a different node
< jamesob>
what is the anticipated burden of rerouting people filing issues/PRs in bitcoin/bitcoin to bitcoin/bitcoin-gui when appropriate?
< harding>
I think it's important for Bitcoin Core to continue to ship releases with a default GUI, which this allows, and making it easier for people to follow just GUI issues sounds very nice to me, so +1
< jamesob>
wumpus: do you really think it actually turns away people, just that GUI is under bitcoin/bitcoin?
< bitcoin-git>
[bitcoin] jnewbery opened pull request #19095: [tools] Update clang-format config for multi-line function declarations and calls (master...2020-05-clang-tidy) https://github.com/bitcoin/bitcoin/pull/19095
< bitcoin-git>
[bitcoin] laanwj opened pull request #19094: build: Only allow ASCII identifiers (master...2020_05_no_extended_identifiers) https://github.com/bitcoin/bitcoin/pull/19094
< bitcoin-git>
[bitcoin] fanquake opened pull request #19088: validation: use std::chrono throughout some validation functions (master...validation_chrono) https://github.com/bitcoin/bitcoin/pull/19088
< bitcoin-git>
[bitcoin] gillichu opened pull request #19082: Moved the CScriptNum asserts into the unit test in script.py (master...issue24) https://github.com/bitcoin/bitcoin/pull/19082
< gribble>
https://github.com/bitcoin/bitcoin/issues/18275 | wallet: error if an explicit fee rate was given but the needed fee rate differed by kallewoof · Pull Request #18275 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] achow101 opened pull request #19077: wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets (master...sqlite-wallet) https://github.com/bitcoin/bitcoin/pull/19077
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19072: doc: Expand section on Getting Started (master...2005-docContribClarif) https://github.com/bitcoin/bitcoin/pull/19072
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19071: [WIP RFC DONOTMERGE] meta: Separate repository for the gui (master...2005-splitRepoGui) https://github.com/bitcoin/bitcoin/pull/19071
< bitcoin-git>
[bitcoin] jnewbery opened pull request #19070: p2p: Signal support for compact block filters with NODE_COMPACT_FILTERS (master...2020-05-node-compact-filters) https://github.com/bitcoin/bitcoin/pull/19070
< bitcoin-git>
[bitcoin] theStack opened pull request #19069: refactor: replace pointers by references within tx_verify.{h,cpp} (master...20200526-refactor-replace-pointers-by-refs-in-tx_verify) https://github.com/bitcoin/bitcoin/pull/19069
< bitcoin-git>
[bitcoin] fanquake opened pull request #19068: build: Use a zip instead of dmg for macOS releases (master...macdeploy_zip_instead_of_dmg) https://github.com/bitcoin/bitcoin/pull/19068
< bitcoin-git>
[bitcoin] fanquake merged pull request #19059: gui: update Qt base translations for macOS release (master...macdeploy_translations) https://github.com/bitcoin/bitcoin/pull/19059
< bitcoin-git>
bitcoin/master 14f8447 fanquake: Merge #19059: gui: update Qt base translations for macOS release
< bitcoin-git>
[bitcoin] maitrebitcoin opened pull request #19061: doc: new section on to how to build with visual studio (master...master) https://github.com/bitcoin/bitcoin/pull/19061
2020-05-23
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19060: test: Remove global wait_until from p2p_getdata (master...2005-testWaitUntilGetdata) https://github.com/bitcoin/bitcoin/pull/19060
< bitcoin-git>
[bitcoin] achow101 opened pull request #19054: wallet: Skip hdKeypath of 'm' when determining inactive hd seeds (master...inactive-seed-skip-m) https://github.com/bitcoin/bitcoin/pull/19054
< bitcoin-git>
[bitcoin] theStack opened pull request #19053: refactor: replace CNode pointers by references within net_processing.{h,cpp} (master...20200522-refactor-use-cnode-references-within-net_processing) https://github.com/bitcoin/bitcoin/pull/19053
< bitcoin-git>
[bitcoin] practicalswift opened pull request #19052: tests: Don't limit fuzzing inputs to 1 MB for afl-fuzz (now: ∞ ∀ fuzzers) (master...remove-afl-limit) https://github.com/bitcoin/bitcoin/pull/19052
< bitcoin-git>
[bitcoin] rajarshimaitra opened pull request #19048: test: changing signature of wait_until(). (master...fixing-waituntil) https://github.com/bitcoin/bitcoin/pull/19048
< bitcoin-git>
[bitcoin] achow101 opened pull request #19046: Replace CWallet::Set* functions that use memonly with Add/Load variants (master...rm-load-memonly) https://github.com/bitcoin/bitcoin/pull/19046
< bitcoin-git>
[bitcoin] meshcollider merged pull request #17681: wallet: Keep inactive seeds after sethdseed and derive keys from them as needed (master...keep-inactive-seeds) https://github.com/bitcoin/bitcoin/pull/17681
< bitcoin-git>
bitcoin/master c93082e Andrew Chow: Generate new keys for inactive seeds after marking used
< bitcoin-git>
bitcoin/master 45f2f6a Andrew Chow: Determine inactive HD seeds from key metadata and track them in LegacyScri...
< bitcoin-git>
bitcoin/master b59b450 Andrew Chow: have GenerateNewKey and DeriveNewChildKey take a CHDChain as an argument
< BlueMatt>
my thinking was the goal wasnt to try to just scramble the bitcoin data to make it look like noise on the wire, it was to actually have redundant codepaths (and network paths) to fetch block data
< BlueMatt>
ariard: maybe, but (1) provides you ability to get data from things that arent bidirectional high-bandwidth sockets. (2) is just a way to shove bitcoin p2p protocol over top of something else.
< BlueMatt>
right, fair. i guess just in my past thinking on this I've always considered mostly more nice bitcoin data providers, less p2p-encryption/modoulation-style providers. I agree that would be a cool goal as well, though i guess is fully separate from things I was thinking about
< BlueMatt>
sipa: as for "the goal", thats true, if we want to model after eg tor's pluggable transport, we want a byte stream, but I think bitcoin data is a little too unique for that - because its so small, we end up being able to shove it in all kinds of queries
< wumpus>
BlueMatt: yes, I know, it was great! unfortuantely the approach to integrate them into bitcoin core didn't work with regard to review and organizationaly
< jnewbery>
perhaps this more speculative discussion is better suited to bitcoin-wizards or similar?
< jnewbery>
ariard: what do you need help with? From my perspective, there's still a lot of work to be done internally in Bitcoin Core cleaning up the layer separation between net / net_processing / validation, but I haven't reviewed your branch yet
< BlueMatt>
but you magically make the censor think you're connecting to that but are in fact connecting to a bitcoin core reset endpoint
< wumpus>
bitcoin core is I/O bound but usually only on disk, not on P2P/network
< wumpus>
if it runs in an external process and communicates with bitcoin core that's the right way
< wumpus>
while I think alternative transports are great, I don't think we should integrate the code for all the transports into bitcoin core