< gmaxwell>
sorry, don't know anything about it. You might want to try reaching out to the document author, or contacting slushpool?
< ahmed_>
all good. i've looked at the spec that's been creating and i've followed it to the T
< ahmed_>
so unless something is different im not quite sure myself either
< jb55>
should walletnotify pass the wallet name? just noticed my emailer was failing: it was calling gettransaction with the wrong -rpcwallet when fetching the tx inside the walletnotify script
< sipa>
jb55: i think walletnotify doesn't pass the wallet name at all
< gmaxwell>
MarcoFalke: Would you care to offer a version of #15983 up to upstream libsecp256k1? (mindful of CFLAGS vs CXXFLAGS). If you don't have time, thats okay.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #16084: scripted-diff: Complete the move from CCriticalSection to identical RecursiveMutex (both are AnnotatedMixin<std::recursive_mutex>) (master...recursive-mutex) https://github.com/bitcoin/bitcoin/pull/16084
< jnewbery>
wallet meeting?
< sipa>
hi
< jnewbery>
hi
< kanzure>
hi
< sipa>
no quorum, i think?
< jnewbery>
i think you're right
< bitcoin-git>
[bitcoin] fanquake opened pull request #16086: contrib: use newer config.guess & config.sub in install_db4.sh (master...db4_install_new_config_guess_sub) https://github.com/bitcoin/bitcoin/pull/16086
< instagibbs>
long holiday weekend in US at least :)
< Chris_Stewart_5>
Is there a reason sendheaders would not be working on bitcoin 0.16.3 or 0.17.1? I'm generating a block in regtest mode and it appears that the header is not being relayed. I have sent the 'sendheaders' message to the regtest bitcoind node
< Chris_Stewart_5>
There is this section in BIP130, which is a little unclear to me "Upon receipt of a "sendheaders" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect)."
< Chris_Stewart_5>
sdaftuar: ^
< sipa>
Chris_Stewart_5: do you announce segwit support?
< Chris_Stewart_5>
Hmm.. no i don't believe I do. Is that in a protocol version?
< sipa>
we don't care about blocks announced by non-segwit peers, as they'd be missing witnesses
< sipa>
NODE_WITNESS service flag
< Chris_Stewart_5>
i'm trying to get a lite client to receive headers messages, so i'm a bit confused as to why that would be necessary?
< sipa>
ah
< sipa>
oops, i got things backwards then
< Chris_Stewart_5>
it's stock bitcoind announcing the block, i've tried 0.16.3 and 0.17.1 to just to make sure there isn't some weirdness in versions
< sipa>
what protocol version do you announce?
< Chris_Stewart_5>
'ProtocolVersion70013'
< Chris_Stewart_5>
I do receive the header via an inv
< Chris_Stewart_5>
which is painful to try and fetch, AFAICT I need to use a 'getdata' and retrieve the full block (seems like i might be missing something here, though.)
< sipa>
IIRC announcing via headers is also only done when the node believes it's up to date
< Chris_Stewart_5>
so if there isn't some history of IBD it just announces via inv?
< sipa>
i don
< sipa>
i don't remember the details
< sipa>
but as sendheaders is only useful for block relay at the tip (not during IBD), it's not used when the node believes it's in IBD
< Chris_Stewart_5>
ok, well i'll investigate. I'll follow up when i get to the bottom of it
< Chris_Stewart_5>
Yeah, this is in a test case situation where i want to do basic sanity tests for a lite client where i am generating blocks off of the genesis block, so it is a bit contrived
< sdaftuar>
Chris_Stewart_5: we only announce via headers if we think our peer has the previous block header (or rather, is missing fewer than I think headers from the tip)
< sdaftuar>
er, missing fewer than 8 headers
< sdaftuar>
if you announce the current tip to the node, then the node will figure out you have the latest tip, and subsequent blocks should be announced via header
< Chris_Stewart_5>
Is there any downside in just announcing your best hash when fire up your node? I'm guessing this information is pretty easy to discern any way when you send your first get headers message
< sdaftuar>
if i remember correctly, the way this normally works in regular operation is that peers either (a) respond to our getheaders message that we send to every peer at least once, (b) send us a getheaders message, or (c) announce a block to us
< sdaftuar>
Chris_Stewart_5: well i think in theory you shouldn't announce a block hash if you're not going to provide the block upon request
< gmaxwell>
You shouldn't ^
< sdaftuar>
so what i should have said is, send a getheaders message with a locator constructed from the chain you have
< sdaftuar>
or respond to the one that the node sends you
< sdaftuar>
now that i think about it, responding to the one the node sends you is actually not what light clients should do, as then we'll think we can download what they have? hmm
< sdaftuar>
might be some suboptimal stuff happening there
< Chris_Stewart_5>
So AFAICT flow from a lite client perspective is 1. Receive inv 2. Call 'getblock' 3. Discard everything in getblock besides header
< Chris_Stewart_5>
if you haven't communicated with your peer yet and announced your best hash with inv which seems to be discouraged
< sdaftuar>
Chris_Stewart_5: just send a getheaders instead of a getblock
< sdaftuar>
that will result in you getting the header and in being in sync with the node so that future block announcements will be via header
< Chris_Stewart_5>
yes... let me look over my code again to make sure i'm not footgunning myself some where. That is what i am attempting to do now though.
< Chris_Stewart_5>
yep that worked. I was missing that getheaders call. Thanks!
< jb55>
sipa achow101: should importmulti work without the output descriptor checksum? it seems like it gets a non descriptive error message if it's missing atm.
< jb55>
took me awhile to figure out what was wrong
< achow101>
jb55: no, checksum is required for imports
< jb55>
achow101: I ended up just doing getdescriptorinfo so it seems like it could be done for you...
< jb55>
not sure if that's a good idea though...
< achow101>
jb55: it's for integrity checks
< sipa>
jb55: the point is that you'll generally import things you receive from other people; hopefully they will add the checksum, not you
< jb55>
yeah I'll just get my clightning key export tool to add those then