<bitcoin-git>
[bitcoin] theuni opened pull request #23226: c++20: Opt-in to modeling view and borrowed_range for Span (master...borrowed-span) https://github.com/bitcoin/bitcoin/pull/23226
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<bitcoin-git>
bitcoin/master 90ad8ad John Newbery: [fuzz] Make RandAddr() a free function in fuzz/addrman.cpp
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake merged pull request #23053: [fuzz] Use public methods in addrman fuzz tests (master...2021-09-addrman-fuzzer-public-methods2) https://github.com/bitcoin/bitcoin/pull/23053
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 260 seconds]
c_arc has joined #bitcoin-core-dev
jarthur_ has quit [Ping timeout: 245 seconds]
solocshaw has joined #bitcoin-core-dev
solocshaw has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<fanquake>
Seems to be a lot of misinformation/confusing about the difference between someone being blocked from the repository and issues being locked. The two have nothing todo with each other. Obviously there is a distinction between "lock vs block".
<fanquake>
The only users who get blocked from bitcoin/bitcoin are the ones posting outright nonsense / spam.
<fanquake>
As mentioned, Marco recently went through and did a bulk lock of a number of old, already closed issues. This is something I've also done in the past to proactively prevent spam, although never in bulk.
<fanquake>
There are many cases where an issue can be locked immediately, as there is not going to be any further useful discussion, for example, #23056, so just leaving it open for spam comments seems pointless.
<fanquake>
In any case, any user is always free to open a new issue, or if they'd like to comment on something that has been locked, they can post in IRC, email a maintainer, or just open a new issue anyway, and say they wanted to comment on the older one. However, I'm not aware of this actually having been an issue yet.
<fanquake>
Similar to comments about instances of issue locking, PR closing etc, they never seem to be bought up at the time they may happen, it's only during a discussion like in the meeting, and then no-one seems to have examples. If you've got a problem with an action taken on the repository, please just make someone aware, even if by posting into this channel.
<fanquake>
In regard to certain users, who aren't spammers (and won't be blocked), but have a long history of opening low quality / spammy PRs (i.e see the ratio of opened PRs to merged), and a tendency to perform code review on PRs that may be 5+ years old, after being asked many times not to do so, yes, sometimes those threads get locked, in order to prevent what might as well be spam comments.
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
vnogueira has quit [Ping timeout: 276 seconds]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
smartin has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
vnogueira has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Kiminuo has joined #bitcoin-core-dev
saranshsharma has quit [Remote host closed the connection]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Guest8477 has joined #bitcoin-core-dev
<Guest8477>
привет , мне нужна помощь.
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
smartin has quit [Ping timeout: 260 seconds]
vysn has quit [Quit: WeeChat 3.2]
smartin has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<vasild>
MarcoFalke: fanquake: any idea how those spammers operate - is it a human manually posting stuff or robots? I wonder if their logic is "find any open issue and post there"? If yes and we have 90 closed and 10 opened issues, then the opened issues would get 10% of the spam where it is more harmful compared to on closed issue because on open issues some discussions are going on.
<vasild>
and, so, if the 90 closed issues are locked, then the open issues would get 100% of the spam?
<vasild>
but having more locked ones would not reduce the amount of spam, just redirect it to the open ones?
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
hebasto_ has quit []
hebasto_ has joined #bitcoin-core-dev
hebasto_ has quit [Client Quit]
hebasto has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
tla2k21 has quit [Ping timeout: 276 seconds]
tla2k21 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
earnestly has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
jgarzik has joined #bitcoin-core-dev
jgarzik has quit [Client Quit]
sturles2 has joined #bitcoin-core-dev
sturles2 has quit [Client Quit]
Guest60asd has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 245 seconds]
kexkey has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<Guest8477>
hello i need help
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<meshcollider>
Guest8477: for most help, #bitcoin would be a better channel to ask in
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Guest8477 has quit [Quit: Client closed]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dougEfresh closed pull request #23224: [RFC] util: Add suffix byte unit parser for ArgsManager (master...add-args-byte-units) https://github.com/bitcoin/bitcoin/pull/23224
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
<MarcoFalke>
vasild: I think the spammers are bored people on a phone (GitHub is an app on the play store). They probably think it is some kind of game.
<vasild>
:)
c_arc has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
Kiminuo has quit [Ping timeout: 256 seconds]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
roconnor has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
Enki[m] has quit [Remote host closed the connection]
stick[m] has quit [Read error: Connection reset by peer]
xor9[m] has quit [Remote host closed the connection]
devrandom has quit [Read error: Connection reset by peer]
siv2r[m] has quit [Read error: Connection reset by peer]
Murch[m] has quit [Read error: Connection reset by peer]
vasanth2[m] has quit [Write error: Connection reset by peer]
cdecker[m] has quit [Remote host closed the connection]
kibizc[m] has quit [Read error: Connection reset by peer]
merkle_noob[m] has quit [Remote host closed the connection]
kakolainen[m]1 has quit [Remote host closed the connection]
kvaciral[m] has quit [Remote host closed the connection]
tutwidi[m] has quit [Remote host closed the connection]
vincenzopalazzo has quit [Read error: Connection reset by peer]
RCasatta[m] has quit [Read error: Connection reset by peer]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<laanwj>
oh no, github as phone app for bored people, that's the worst idea
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 252 seconds]
jaybny has quit [Ping timeout: 256 seconds]
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
saranshsharma has quit [Remote host closed the connection]
saranshsharma has joined #bitcoin-core-dev
<prayank>
luke-jr: Agree he isn't spam. Not sure if rebroad is in the channel, if you are reading this your pull requests arent low quality or spams. Just that few people in this repository don't agree with you. Also sometimes I have found interesting and helpful things in few closed PRs. So your contribution is appreciated.
<prayank>
There are few very low quality and spammy merged PRs btw but will leave that discussion for some other day
prayank has quit [Quit: irc thread exit]
saranshsharma has quit [Ping timeout: 265 seconds]
<yanmaani>
With #23201, would it be welcomed to send in a PR that would, if you provided a signed transaction, use that as the weights?
<gribble>
https://github.com/bitcoin/bitcoin/issues/23201 | wallet: Allow users to specify input weights when funding a transaction by achow101 · Pull Request #23201 · bitcoin/bitcoin · GitHub
<yanmaani>
e.g. I send a transaction with signatue from input A. FRT would automatically detect the signature, and set its size as the size of the signature from A.
<yanmaani>
it would still discard it
<yanmaani>
also, I guess this is sort of a stupid idea, but would it make sense to have a notion of "soft" and "hard" sizes? Where soft means "go with this if you have no other estimate", and hard means "go with this always"
c_arc has joined #bitcoin-core-dev
<jamesob>
cjdns testers: are running cjdnsroute with sudo? anyone figure out a clever way of avoiding that, or just yolo?
<achow101>
yanmaani: it would probably be better to implement that on top of #23202. I realized that your idea can work as long as we figure out where the signatures are and use their max weights instead of actual weights given 23202 does that with txs to be rbf'd, and I think that can be extended to fundrawtransaction fairly easily
<jonatack>
jamesob: good point, i confess to launching it with sudo ./cjdroute < cjdroute.conf > cjdroute.log but plan to look into avoiding that, or in the worst case reach out to caleb james delisle on mastodon where we're in touch
<yanmaani>
achow101: implement what?
<achow101>
yanmaani: getting weight information out of existing scriptSigs/witnesses in fundrawtransaction
<vasild>
jamesob: it only starts as root but then drops to nobody and chroot()s (if configured)
<yanmaani>
why would you not want to use their actual weights?
<sipa>
jonatack, jamesob: given that it needs to create a network device, i don't see how you could avoid elevated privileges entirely
<yanmaani>
isn't there some way to give an account special privs to make network devices?
<achow101>
yanmaani: because the signature size can change depending on the signature
<yanmaani>
achow101: but if it's already signed?
<achow101>
it will be thrown away after funding, and the signature will change after funding
<achow101>
There is 1 pre-proposed topic. any last minute topics to add?
<S3RK>
hi
<S3RK>
I'd like to ask a question about descriptors that produce same scriptpubkeys
<sipa>
hi
<achow101>
#topic expand fundrawtx external input support to allow arbitrary scripts (achow101)
<kanzure>
hi
<achow101>
Originally I wanted to ask whether we should do this, but I think it's a bit moot now since people have been reviewing #23201
<gribble>
https://github.com/bitcoin/bitcoin/issues/23201 | wallet: Allow users to specify input weights when funding a transaction by achow101 · Pull Request #23201 · bitcoin/bitcoin · GitHub
<achow101>
the current proposal is to just let users specify the weights. yanmaani has suggested allowing users to provide signed inputs (in the tx for fundrawtx) and use that for weight estimation
<achow101>
the only issue I saw with the latter idea is that signature sizes can change, but that can be solved by figuring out how many signatures there are and using their max sizes rather than real sizes
<achow101>
thoughts?
<sipa>
no opinion, really
* S3RK
shrugs
<achow101>
I suspected that would be the case
<achow101>
#topic descriptors that produce same scriptpubkeys (S3RK)
<S3RK>
I believe it's technically possible right now to import multiples descriptors that would produce same scripts
<S3RK>
can you think of any valid use cases for this?
<achow101>
upgrading a raw(addr) to full descriptor?
<sipa>
or upgrading in general; e.g. adding origin info?
<achow101>
but perhaps upgrading should be an actual upgrade and not duplicating
<sipa>
right
<S3RK>
yes, for upgrading we can replace the existing descriptor
<S3RK>
if this is the only case, should we try to prevent users from importing such descriptors?
<achow101>
yes, but that may be difficult
<S3RK>
I think it could be hard to detect in some casees
saranshsharma has joined #bitcoin-core-dev
<achow101>
e.g. something with derived keys at a high index
<S3RK>
yes, exactly what I thought
<sipa>
remind me, is it possible to import non-ranged descriptors?
<achow101>
yes
<S3RK>
yes
<achow101>
I'm not sure that duplicating is necessarily detrimental though
<achow101>
other than wasting space
<S3RK>
It makes it a bit harder to reason about code
<S3RK>
I made this mistake in my last PR
<S3RK>
should we try to prevent at least in cases when we can detect it?
<achow101>
iirc signing and fillpsbt go through all of the spkmans so it doesn't matter if one has less info than another, although conflicting info may be a problem
<S3RK>
another one is `getaddressinfo`
<achow101>
hmm yes
<achow101>
I think it's reasonable to prevent it in obvious cases
saranshsharma has quit [Ping timeout: 252 seconds]
<achow101>
I would say that having multiple descriptors for the same scripts is not a supported use case, so we shouldn't worry too much about it
<achow101>
*about writing code that can deal with it
<S3RK>
khm... I agree with the sentiment, but than we should make it clear that it's not supported
<S3RK>
s/than/then/
<achow101>
yes
<S3RK>
we can prevent at import time most cases
<S3RK>
and if we detect later we can deactivate maybe?
<S3RK>
I don't know how far we should go to avoid it
<achow101>
if we were to detect it later, there isn't much that can be done to resolve it
<achow101>
it would mean that the user would need to be able to delete the descriptor, but I'm really hesitant to add anything that would let people delete data from their wallet
<achow101>
especially private keys
<S3RK>
and there are probably already wallets like this :)
<S3RK>
ok. good to know your thoughts, thanks
<achow101>
any other topics?
<achow101>
#endmeeting
<Kaizen_Kintsugi>
Are these meetings scheduled somewhere? I just happened to be here and stumble across this.
<laanwj>
looks like the precompiled freebsd package for cjdns doesn't work on my server, it crashes with "illegal instruction" because it uses vxorps %xmm0,%xmm0,%xmm0 which is... avx
<sipa>
ha
<sipa>
what cpu do you have?
Kaizen_Kintsugi has quit [Remote host closed the connection]
Kaizen_Kintsugi has joined #bitcoin-core-dev
<laanwj>
Intel Atom C2350
Kaizen_Kintsugi has quit [Ping timeout: 245 seconds]
<laanwj>
i'm sure it can be resolved with compiling from source, but it surprised me as i haven't seen their precompiled packages make assumptions about instruction set support before
<jonatack>
fwiw i have the impression of seeing more peer connection churn than usual on master ~this past week, haven't pinned it down yet, but if anyone else is seeing it LMK