--- Log opened Mon Jun 21 00:00:44 2021
08:08 < dergoegge> calvinalvin: why did we choose to go with an extra "getublocks" message? i dont remember if there is a specific reason but i think we dont need that. A csn has the NODE_UTREEXO service flag right? So if you are a bridge node you can just serve  csn's with blocks and txs + proof.
08:09 < dergoegge> https://github.com/mit-dci/utcd/blob/c4401e7270ba0253e6c5be6840822437ae89fd52/peer/peer.go#L1206
08:09 < dergoegge> ^ getublock and getblock get the same response
08:10 < dergoegge> i will try to add proof serving ability to the c++ bridge node next, thats why am asking
08:11 < dergoegge> are there any other changes you made to the p2p layer besides "getublocks" and the service flag?
08:39 < dergoegge> https://github.com/mit-dci/utcd/blob/79580a7e86cd6505f5c386ac755009cd90f3dd70/wire/protocol.go#L90
08:39 < dergoegge> do we really need two service flags?
08:41 < dergoegge> also according to this: https://github.com/bitcoin/bitcoin/blob/74013641e035a2f1b12383e63938a5e848506df3/src/protocol.h#L293
08:41 < dergoegge> we should not be using anything smaller than 1 << 24
21:41 < calvinalvin> the extra message because the bridge node will serve normal bitcoin nodes as well
21:41 < calvinalvin> NODE_UTREEXO service flag to find utreexo specific nodes in the wild
21:43 < calvinalvin> > https://github.com/mit-dci/utcd/blob/c4401e7270ba0253e6c5be6840822437ae89fd52/peer/peer.go#L1206
21:43 < calvinalvin> Ah I didn't really focus that much on separating out the internal processes. The pendingResponses field is just so that btcd internally knows that it asked for a block
21:43 < calvinalvin> Didn't make a separate map since a csn node will never ask for a normal bitcoin block
21:44 < calvinalvin> So in package peer and in package blockchain, you'll see a lot of overlap stuff that really should be separated out in the future but
21:45 < calvinalvin> Didn't focus on that bit
21:45 < calvinalvin> > we should not be using anything smaller than 1 << 24
21:45 < calvinalvin> Ok urm what should we use
21:47 < calvinalvin> I guess it's about time we standardize some p2p stuff :)
--- Log closed Tue Jun 22 00:00:45 2021