<theStack>
PaperSword: txs with output scripts containing not-on-curve pubkeys are standard-valid, if that's what you're asking
<PaperSword>
Yeah they are just tested and found out.
<PaperSword>
Is there a reason why?
andrew_mo_ has quit [Ping timeout: 245 seconds]
<PaperSword>
Wait so if the pubkeys are invalid are they prunable?
Talkless has quit [Remote host closed the connection]
Talkless has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
brunoerg has quit [Ping timeout: 240 seconds]
PaperSword has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
bomb-on_ has quit [Read error: Connection reset by peer]
bomb-on has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
andrew_mo_ has quit [Ping timeout: 244 seconds]
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 245 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 250 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 245 seconds]
jon_atack has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 258 seconds]
brunoerg has joined #bitcoin-core-dev
dplusplus has quit [Ping timeout: 245 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
andrew_mo_ has quit [Ping timeout: 246 seconds]
jon_atack has quit [Read error: Connection reset by peer]
jon_atack has joined #bitcoin-core-dev
dplusplus has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
StayWoke has joined #bitcoin-core-dev
StayWoke has quit [Changing host]
StayWoke has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
cm has quit [Ping timeout: 246 seconds]
cm has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 245 seconds]
ExEric3 has quit [Ping timeout: 260 seconds]
ExEric3 has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
dplusplus has quit [Remote host closed the connection]
dplusplus has joined #bitcoin-core-dev
benwestgate has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 245 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
preimage has joined #bitcoin-core-dev
<achow101>
PaperSword: you can unsubscribe from the discussion if it's getting too noisy
<achow101>
we do moderate, but only stuff that's obviously bad. if it gets really heated we'll lock it temporarily
andrew_mo_ has joined #bitcoin-core-dev
provoostenator has joined #bitcoin-core-dev
<provoostenator>
At some point I'll just have to accept the Matrix bridge is not coming back...
<PaperSword>
@achow101 Thank you! None of the content is bad per say, just IMO more 'heated' than what I am used to. None the less I am very glad that discussion is happening and have learned so much from it!
<sipa>
achow101: possibly - i'm happy to continue with bip324 stuff without 28100 so it's not a blocker
<fanquake>
28100 is about done anyays after the current comments are addressed
<sipa>
but i think it's nice, as throughout this effort lots of parts of the crypto/ codebase have been converted to use Span<std::byte> based interfaces, which work really nicely
<provoostenator>
jamesob: the shutdown stalled so I had to force quit, but it worked fine at restart.
<PaperSword>
@jamesob I will compile and test.
<jamesob>
provoostenator: do you think the coinscache might have been flushing? how long did you wait?
<jamesob>
PaperSword: thanks
<PaperSword>
you can log coinscache flushing with the USDT tacepoint script right?
<jamesob>
yeah, though there should be a lower-tech way to do that... maybe we should log to the standard facilities if the flush duration is over some length of time
Guyver2 has left #bitcoin-core-dev [Closing Window]
<PaperSword>
contrib/tracing/log_utxocache_flush.py it works incredibly well IMO
<PaperSword>
was using it with sjors DB_CACHE issue
<provoostenator>
james: this was a pruned node, so it would have flushed a bunch of times. I also think it was more than 24 hours after IBD finished, but not 100% sure.
<jamesob>
provoostenator: so you triggerd a shutdown, but then the shutdown process hung? or it hung during normal operation?
<cfields>
If we're done with ad-hoc review items, I have a quick item.
<achow101>
#topic PR#27260 (PaperSword)
<gribble>
https://github.com/bitcoin/bitcoin/issues/27260 | Enhanced error messages for invalid network prefix during address parsing. by russeree · Pull Request #27260 · bitcoin/bitcoin · GitHub
<achow101>
cfields: there's a preproposed topic first
<cfields>
👍
<PaperSword>
I was wondering mostly about relevance of this?
<achow101>
can you be more specific?
andrew_mo_ has joined #bitcoin-core-dev
<PaperSword>
Was wondering if this is something that should be continued to be worked on mostly?
<PaperSword>
Luke has reviewed some items in this PR, and those issues were addressed.
<sipa>
PaperSword: that's up to whomever contributes individually
<PaperSword>
Okay!
<PaperSword>
That concludes my request
<achow101>
#topic #28217 (PaperSword)
<sipa>
the project does have a few projects that we choose to focus on, but aside from that, everyone decides for themselves where they spend time
<PaperSword>
Yes, uses base blockdata only and each outpoint has to hit dust when relaying.
<sipa>
a bit, yes
<sipa>
but the big problem, i think, is about changing the policy is the first place
<PaperSword>
absolutely
<sipa>
so really the answer to why is the Y component not checked, i think, is because the Y component was not checked in the past
<PaperSword>
It could be of interest, because by checking it during relay would not allow others to use the Y component for extra byes of arb storage.
<achow101>
if you do want it checked, use a hybrid key? lol
<sipa>
PaperSword: that's exactly what the controversy is about, it wouldn't change anything
andrew_mo_ has joined #bitcoin-core-dev
<provoostenator>
I don't think it makes sense to use relay policy to "fight" market forces. You'll just end up with private relay networks, which in turn
<luke-jr>
of course it would
<provoostenator>
means worse fee estimation, and maybe even pinning issues.
<sipa>
indeed
<luke-jr>
provoostenator: if miners maliciously try to bypass the network, it's at least clear they are acting maliciously, rather than a passive indifference
<luke-jr>
and that alone may be sufficient
<PaperSword>
Okay. current implementations of stamps and these protocols seem to only use 33 bytes per outpoint
<sipa>
i very much doubt that
<sipa>
given that they're already convincing miners to do whatever
<provoostenator>
Full RBF is indicator of those dynamics.
<luke-jr>
they're not
<luke-jr>
there's a few bad actor pools, but many are not actively going around things
<PaperSword>
What about the fact that items in the UTXO set that have an invalid Y coordinate could never be signed for?
<provoostenator>
Also, it's not malicious if users are settings allow bare multisig to true.
<luke-jr>
provoostenator: full RBF is not the same thing
<PaperSword>
Would they then be prunable?
<sipa>
PaperSword: P2PK and k-of-n P2MS with n-k+1 invalid, i think could be pruned yes
andrew_mo_ has quit [Read error: Connection reset by peer]
<PaperSword>
Thank you @darosior
<luke-jr>
provoostenator: it's malicious to setup private relay networks to mine attacks on Bitcoin that the community is actively trying to mitigate
andrew_mo_ has joined #bitcoin-core-dev
<provoostenator>
But it's not miners setting those up.
<sipa>
luke-jr: you holding that opinion is irrelevant to people's behavior :)
<luke-jr>
provoostenator: isn't that the argument being made? [10:31] <provoostenator> I don't think it makes sense to use relay policy to "fight" market forces. You'll just end up with private relay networks, which in turn
<sipa>
(even though i largely agree, for some definition of attacks)
<provoostenator>
All miners need to do is to not upgrade and/or manually set this setting. And then other users will get those transaction to them. Why would they not mine them
<luke-jr>
sipa: yes, but it's not irrelevant to the big picture and sensible default policies
<PaperSword>
Why would a P2MS or P2PK outpoint that could never be signed for be relayed IMO.
<vasild>
hi
<_aj_>
provoostenator: "why would they not mine them" -- because they have a long term investment in bitcoin, and they believe mining those txs is bad for that investment, same as the reason why people would want to remove the spam in the first place
<provoostenator>
If we removed the setting entirely, maybe that changes the morality a bit.
<luke-jr>
_aj_: +1
<sipa>
PaperSword: why are OP_RETURNs relayed? they also can't be spent
<luke-jr>
though in those cases, those miners can already not-mine them
<PaperSword>
They are prunable, and pruned
<sipa>
your question is about relayed, not about pruning :)
<provoostenator>
_aj_ they can already choose not to mine them and leave the money on the table.
<PaperSword>
tuche :D
<luke-jr>
unfortunately, I have to leave early :< but hopefully my points have been made, and others can continue
<PaperSword>
Okay then why can one do 196 bytes using p2ms using invlid pubkeys but only 80 bytes with OP_RETURN
<dergoegge>
can we move on?
<PaperSword>
sure
<sipa>
PaperSword: i think this is becoming more a question for the ML
<PaperSword>
ML sorry?
<sipa>
mailing list
<sipa>
bitcoin-dev
<PaperSword>
I will submit.
<PaperSword>
Thank you.
<sipa>
i would encourage you to first read the ongoing discussion already :)
<sipa>
and yes, we could prune some more unspendable outputs, but that's an implementation detail inside bitcoin core, which imho shouldn't really interact with questions about relay policy
<achow101>
#topic cfields thing
<cfields>
heh
andrew_mo_ has quit [Ping timeout: 246 seconds]
<cfields>
Just wanted to make a quick announcement to the wider group that we now have a clang-tidy plugin merged and hooked up to c-i. This means that we can now add our own (simple) compiler rules and have them enforced. It's most immediately useful for linting, but it could also enforce constraints that aren't possible with code alone. For now we only have one simple check.
<cfields>
I'll open a PR to expand the README so it's clear what it can and can't do (sorry, I meant to have that done by now). If anyone has any use for additional checks (besides the ones Marco has proposed), please ping me after the meeting or mention it in that PR once opened.
<dergoegge>
🎉
<cfields>
That's all :)
<TheCharlatan>
wootwoot
<sipa>
cfields: can you give a quick cool example of what's possible with this?
<PaperSword>
nice
<achow101>
neat
<cfields>
sipa: the initial one, for example, enforces that there's a "\n" at the end of every logprintf...
<dergoegge>
vasild: yea that can probably be closed now
<vasild>
\o/
<achow101>
any other topics to discuss today?
guest-127 has quit [Ping timeout: 246 seconds]
<jamesob>
good old /* Continued */
<achow101>
#endmeeting
<vasild>
sipa: people will keep adding "\n" by habit so then a rule will be needed that there is no trailing \n and that really would have to be enforced to avoid double \n in new code, or annoying review comments to remove \n
<sipa>
vasild: i was assuming LogPrintf would just add a \n if there weren't one already
<sipa>
;)
<vasild>
;-)
<lightlike>
would be awful if we had to change each existing LogPrintf...
<cfields>
jamesob: fyi, those /* Continued */ are gone because clang-tidy is smarter than our python scripts. We now opt-out with // NOLINT(bitcoin-unterminated-logprintf)
guest-127 has joined #bitcoin-core-dev
<vasild>
wow!
<cfields>
lightlike: actually that's something else clang-tidy could do very easily. If you can describe the change, via AST it's trivial to use it to transform the entire codebase programatically.
<fanquake>
enhanced scripted-diff
<lightlike>
cfields: sure, but the PR to do that would conflict with almost every other PR...
<cfields>
fanquake: Yep, I plan on PR'ing that as well if anyone is interested. You could assert that the transform generated the expected changes. Mostly useful for huge changes like the log example above.
<cfields>
lightlike: right, that's why realistically checking the "\n" was the simpler thing to do.
<earnestly>
clang-query(1) is a relatively new tool which lets you play with matchers and such
<vasild>
cfields: Thank you!
andrew_mo_ has joined #bitcoin-core-dev
<cfields>
Earnestly: yes, clang-query is essential for testing queries without recompiling every time.
<cfields>
(You can copy/paste our query from the cpp into clang-query and it should just work. It's quite convenient)
<cfields>
vasild: thanks for testing!
<vasild>
I didn't test it (yet)
<cfields>
vasild: whoops, I thought I remembered you chiming in. nm :)
<cfields>
we could essentially use it to enforce policy in our codebase, rather than just documenting it.
<cfields>
(in this case, the example policy is obviously to always use make_shared rather than new)
provoostenator has quit [Quit: Client closed]
provoostenator has joined #bitcoin-core-dev
<cfields>
I don't mean that example is interesting, just that it very simply shows how new code policy could be introduced/enforced.
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
provoostenator has quit [Quit: Client closed]
bugs_ has joined #bitcoin-core-dev
tecnecio has quit [Quit: Leaving]
<jon_atack>
Hi! I think I've noticed a related subtle logging rule the new plugin could enforce or that the macro could be smarter about.
<jon_atack>
If the string argument following the Log* call is on a separate line rather than the same line, logsourcelocations=1 doesn't work.
<MacroFake>
cfields: I think modernize-make-shared disabled Wnarrowing, so I am not sure if there are any benefits to using it
<jon_atack>
example separate line:
<jon_atack>
2023-08-17T03:35:25.306155Z [scheduler] [net_processing.cpp:5170] [operator()] [net] Protecting from eviction last remaining cjdns outbound peer=36 that relays transactions: [fc70:704d:b268:cdbf:d622:ea9f:db12:859e]:8333 (outbound-full-relay)
<jon_atack>
and same line:
<jon_atack>
2023-08-17T11:56:10.285371Z [msghand] [net_processing.cpp:2801] [UpdatePeerStateForReceivedHeaders] [net] Protecting from eviction for bad or slow chain outbound peer=1154 net=i2p, peeraddr=wxtdi7pvtcd5vnnhcuwy7uffdjjeky7jjqn7mgnksnz4micqkvoa.b32.i2p:0 (outbound-full-relay)
<cfields>
MacroFake: yeah, I didn't mean _that_ example at all. Sorry. I was just showing the _kind_ of thing we could enforce.
<MacroFake>
ah ok
<jon_atack>
sorry, bad paste
<jon_atack>
but "operator()" is printed rather than the source method
<MacroFake>
jon_atack: That shouldn't be related to a newline in the C++ source code
<jon_atack>
MacroFake: Sorry, I may have misdiagnosed, just saw it in a change I made locally. Will look.
<MacroFake>
I presume operator() means you are inside a lambda
<cfields>
blah, I really shouldn't have used the log example in the meeting. It's much more than a linter heh.
<jon_atack>
yes, inside a m_connman.ForEachNode in EvictExtraOutboundPeers
<MacroFake>
cfields: There may be a chance we can use native C++20 instead of the bitcoin-unterminated-logprintf tidy rule
<MacroFake>
I'll look into that once and if we have C++20
<sipa>
wen c++20?
<MacroFake>
Generally it seems preferable to enforce all rules at compile time in the compiler, as opposed to a separate linter executable
<MacroFake>
sipa: I'll open a pull in two weeks, and see what everyone thinks for 27.0
vasild has quit [Remote host closed the connection]
<cfields>
sipa: anything you wish you could enforce with Span? Either in the impl or with what callers do with them?
<MacroFake>
cfields: We'll switch to std::span, soon :)
<sipa>
cfields: lifetimebound being actually enforced would be nice :p
<andytoshi>
test/script_tests.cpp: In member function ‘void script_tests::script_json_test::test_method()’:
<andytoshi>
test/script_tests.cpp:933:44: error: invalid initialization of reference of type ‘const std::string&’ {aka ‘const std::__cxx11::basic_string<char>&’} from expression of type ‘const unsigned char [215625]’ 933 | UniValue tests = read_json(json_tests::script_tests);
<achow101>
andytoshi: make clean first
andrew_mo_ has quit [Ping timeout: 246 seconds]
<andytoshi>
achow101: oh, thanks!
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
vysn has joined #bitcoin-core-dev
mekster669493 has quit [Ping timeout: 244 seconds]
dougefish__ has joined #bitcoin-core-dev
dougefish_ has quit [Ping timeout: 250 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
andrew_mo_ has joined #bitcoin-core-dev
Guest50 has joined #bitcoin-core-dev
Guest50 has quit [Client Quit]
andrew_mo_ has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
flooded has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
test_ has quit [Ping timeout: 244 seconds]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
andrew_mo_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 245 seconds]
mekster669493 has joined #bitcoin-core-dev
szkl has joined #bitcoin-core-dev
achow101 has quit [Quit: Bye]
vysn has quit [Remote host closed the connection]
preimage has quit [Quit: WeeChat 4.0.3]
nick_ has joined #bitcoin-core-dev
nick_ has quit [Client Quit]
ne0h has joined #bitcoin-core-dev
ne0h has quit [Client Quit]
neoh has joined #bitcoin-core-dev
neoh has quit [Quit: Leaving]
brunoerg has joined #bitcoin-core-dev
ne0h has joined #bitcoin-core-dev
<ne0h>
i am trying to make a program that connects to the bitcoin network to collect new transactions in the mempool and new blocks in real time, but I am having trouble getting it going. My version message doesn't get a response... I suspect it's something to do with the formatting or something, but i have tried a few things and nothing has worked so far, if anybody could help me get this running it would be quite appreciated
brunoerg has quit [Ping timeout: 256 seconds]
<fjahr>
This channel is particularly for development of bitcoin core, an alternative implementation of the protocol is out of scope. I would recommend you post your question on bitcoin stack exchange. And fwiw, you should also check if you can achieve your goal by just using bitcoin core's zmq interface, then you won't need to think about version messages etc.
jespada has quit [Ping timeout: 246 seconds]
jespada has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 245 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_m_ has quit [Remote host closed the connection]