< bitcoin-git>
bitcoin/0.18 c89611e Wladimir J. van der Laan: net: Log to net category for exceptions in ProcessMessages
< bitcoin-git>
bitcoin/0.18 8b67698 fanquake: Merge #17974: [0.18] net: Log to net category for exceptions in ProcessMes...
< bitcoin-git>
[bitcoin] fanquake merged pull request #17974: [0.18] net: Log to net category for exceptions in ProcessMessages (0.18...bp18_network_exceptions) https://github.com/bitcoin/bitcoin/pull/17974
< xabbix>
Hi everyone. While syncing a new node, the message received in the rawtx subscription in ZMQ does not contain any identification for the block that the tx is included in. Why is that? Is it possible to include it in some way? (running with txindex=1)
< wumpus>
I think it's because rawtx is *generally* meant for network transactions, not block transactions
< wumpus>
IIRC transaction notification is even disabled during initial sync because there otherwise would be too many of them
< xabbix>
wumpus Thanks. Looking for the most efficient way of syncing an external source with JSON data regarding transactions from block 0 to last. Any recommendations?
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17989: tests: Add fuzzing harness for ProcessMessage(...). Enables high-level fuzzing of the P2P layer. (master...fuzzers-net-process_message) https://github.com/bitcoin/bitcoin/pull/17989
< wumpus>
xabbix: probably the most efficient way is to request the blocks through the REST interface, in binary format is most efficient (IIRC they will be loaded from disk and sent out in raw without intermediate server-side decoding), but if you prefer it in JSON format that's a possibility too
< wumpus>
another way to get all the block data is the approach used in contrib/linearize/*.py, it requests only the block headers from the server then, using direct access to the block files, finds the blocks; I'm not sure if I can really recommend that, because there isn't really a guarantee that the format won't change at some point, but it can be really efficient
< xabbix>
wumpus Thanks for all the help, I'll look into both approaches
< gribble>
https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs . Pull Request #16702 . bitcoin/bitcoin . GitHub
< wumpus>
though jamesob had some new review comments, I think most of those can be done in follow-up PRs
< wumpus>
jonatack: thanks, yes there's been some more questions about the unit tests, there's some functions (like the interpreter function) that are not tested directly and probably should
< wumpus>
then again, this could all be added later, I have the idea it would be good to get the basic functionality in soon so iteration can be quicker
< jamesob>
wumpus (and anyone else): thanks for the review
< gribble>
https://github.com/bitcoin/bitcoin/issues/16974 | Walk pindexBestHeader back to ChainActive().Tip() if it is invalid by TheBlueMatt . Pull Request #16974 . bitcoin/bitcoin . GitHub
< jamesob>
re: 16442: I think gleb and ariard have some concept concerns that should be articulated somewhere at some point
< wumpus>
ah, works not, that one has a lot of open comments still and no ACKs
< jamesob>
the gist of which is, as far as I can tell, that neutrino is sort of useless for lightning because for sybil-resistance, lightning users need to verify all channel openings on-chain, which would result in downloading every incoming block anyway. but this is probably out of scope for this meeting
< wumpus>
okay, yes, would be good to discuss concept concerns first before spending a lot of time reviewing code details
< sipa>
jamesob: that sounds like a discussion for the ML
< jamesob>
agreed
< wumpus>
good point
< wumpus>
ok then there is fanquake's MacOS toolchain update (#16392) which should be straightforward, but I think it's held up on a non-MacoSX way to extract the SDK, not so much review
< gribble>
https://github.com/bitcoin/bitcoin/issues/17261 | Make ScriptPubKeyMan an actual interface and the wallet to have multiple by achow101 . Pull Request #17261 . bitcoin/bitcoin . GitHub
< instagibbs>
that one is getting close hopefully
< wumpus>
seems it has ACKs, if my comment isn't really an issue then it can be merged soon
< wumpus>
I'm really not sure about non-primitive constants in header files in C++
< wumpus>
MarcoFalke: yes, I'm going to--thanks, will keep that in mind
< MarcoFalke>
thx
< emilengler>
hebasto: Which should I ACK?
< emilengler>
I would prefer to ACK a final squashed commit
< emilengler>
Thats the reason why I asked for the sqash btw
< emilengler>
But otherwise I will ACK HEAD~1
< wumpus>
you should always ACK HEAD
< wumpus>
at least, the topmost commit, this implies you ACK everything below it too
< jonatack>
emilengler: review locally (not on GitHub, use it only for reading/writing comments) which makes it easy to simply use the topmost (HEAD) commit hash in the PR branch you pulled locally, for the ack commit