saranshsharma has quit [Remote host closed the connection]
saranshsharma has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 240 seconds]
saranshsharma has joined #bitcoin-core-dev
zonemix has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 240 seconds]
saranshsharma has quit [Ping timeout: 240 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
vasild has quit [Ping timeout: 276 seconds]
vasild has joined #bitcoin-core-dev
zonemix has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 245 seconds]
jtrag_ has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
<vasild>
ACK achow101 wallet maintainer
saranshsharma has quit [Ping timeout: 240 seconds]
zonemix has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
earnestly has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 240 seconds]
gleb74 has quit [Ping timeout: 268 seconds]
jtrag has joined #bitcoin-core-dev
rex4539 has joined #bitcoin-core-dev
Guest7824 has joined #bitcoin-core-dev
jtrag_ has quit [Ping timeout: 240 seconds]
Guest7824 has quit [Client Quit]
saranshsharma has joined #bitcoin-core-dev
zonemix has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 260 seconds]
saranshsharma has quit [Ping timeout: 256 seconds]
saranshsharma has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 240 seconds]
<darosior>
ACK achow101 maintainer
jtrag_ has joined #bitcoin-core-dev
zonemix has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 268 seconds]
zonemix has quit [Ping timeout: 240 seconds]
gnaf has joined #bitcoin-core-dev
jtrag_ is now known as jtrag
kexkey has quit [Ping timeout: 252 seconds]
kexkey has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
zonemix has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 240 seconds]
saranshsharma has quit [Ping timeout: 256 seconds]
jtrag_ has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 268 seconds]
jtrag__ has joined #bitcoin-core-dev
jtrag__ is now known as jtrag
rex4539 has quit [Ping timeout: 276 seconds]
jtrag_ has quit [Ping timeout: 260 seconds]
jtrag has quit [Read error: Connection reset by peer]
zonemix has joined #bitcoin-core-dev
jtrag has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 256 seconds]
saranshsharma has joined #bitcoin-core-dev
jtrag_ has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 256 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
<glozow>
ACK giving fanquake permission to block accounts posting spam. Framing it as a "power" is a misrepresentation; it's always just cleaning up meaningless gibberish afaict. Requiring him to ask someone else does nothing but slow progress on the repo.
jtrag_ is now known as jtrag
jtrag has quit [Read error: Connection reset by peer]
<glozow>
ACK achow101 wallet maintainer, imo it's very appropriate for someone with extensive knowledge+authorship of the wallet codebase to maintain it
rex4539 has joined #bitcoin-core-dev
<earnestly>
glozow: ('accounts posting spam' don't exist as a category external to 'accounts posting not-spam' and so the power to block accounts encompasses both)
<glozow>
earnestly: it would be extremely obvious if an account posting not-spam was blocked, so I see no risk of anybody abusing the privilege.
<earnestly>
Yeah I don't disagree, but the framing isn't wrong
<earnestly>
(More a limitation of github really)
jtrag has joined #bitcoin-core-dev
jtrag_ has joined #bitcoin-core-dev
jtrag_ has quit [Read error: Connection reset by peer]
jtrag has quit [Read error: Connection reset by peer]
jtrag has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
zonemix has joined #bitcoin-core-dev
<glozow>
earnestly: yeah it'd be nice if github could automatically block when obvious spam is obvious
saranshsharma has quit [Ping timeout: 268 seconds]
<earnestly>
glozow: Hm, I was thinking more about multiple confirmations needed for an action
mikehu44 has joined #bitcoin-core-dev
jtrag_ has joined #bitcoin-core-dev
jtrag is now known as Guest9045
zonemix has quit [Ping timeout: 240 seconds]
<laanwj>
the goal was be to speed things up, not slow them down even further
saranshsharma has joined #bitcoin-core-dev
<glozow>
laanwj: +1
Guest9045 has quit [Ping timeout: 240 seconds]
rex4539 has joined #bitcoin-core-dev
<laanwj>
i'm not sure what the fear here is, it seems to me the community around bitcoin dev is sufficiently diffuse and loosely organized that there's ton of ways for someone who is banned in error to have recourse
sdfgsdfg has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 256 seconds]
<laanwj>
like just that fanquake has disagreed with you on an issue once or refused to merge it doesn't mean he'll just ban you now instead, that was definitely not the idea, there's quite some arguing in bad faith going on
<fanquake>
i guess people are concerned that after 8-9 years of reputation building and project contributions, for some reason I'm going to undermine it all by abusing the ability to block people on GitHub
<laanwj>
yessss
<laanwj>
block block block you're all blocked
<fanquake>
At this point I really don't care, this discussion has already wasted too much bandwidth.
<fanquake>
I'd much prefer it if people spent that time scrutinising the code I write, and merge. The build system & related code is an area that could always use more eyes over it.
rex4539 has quit [Ping timeout: 276 seconds]
<laanwj>
agree
<earnestly>
fanquake: If it matters, I already trust your pgp for signed commits
<laanwj>
it's really a distortion of what matters
<earnestly>
So the ability to block accounts is pretty minor compared to that
<laanwj>
and what the risks are
<michaelfolkson>
Sorry, unrelated question. Where's the dev wiki gone in the Core repo?
<michaelfolkson>
Thanks, the tab has disappeared :)
<laanwj>
i haven't noticed anything different in that regard
<michaelfolkson>
I thought it was this new Projects thing moving the tab
<laanwj>
the new projects thing did make me worry yesterday, it looked like all the projects were gone
rex4539 has joined #bitcoin-core-dev
<laanwj>
i don't understand why there's Projects [beta] and Projects now it confuses me but i'm sure it will seem normal soon enough
<michaelfolkson>
On the permissions thing, it is more than just blocking right? An owner could say remove you as a co-owner right laanwj?
<michaelfolkson>
I'm using "owner" as the GitHub definition
<laanwj>
michaelfolkson: yes. sometimes i wish they did
<michaelfolkson>
I don't think there's an argument against fanquake whatsoever but I think we generally all trust laanwj's stewardship after all these years and so adding someone new makes some people uncomfortable
<michaelfolkson>
But if someone is to be added fanquake ticks all the boxes imo
Guest52 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
Guest52 has quit [Client Quit]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] shaavan opened pull request #23801: Refactor: Change time variable type from int64_t to std::chrono::seconds in net_processing.cpp (master...time_in_seconds_refactor) https://github.com/bitcoin/bitcoin/pull/23801
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
michaelfolkson: agree
jtrag_ is now known as jtrag
<glozow>
laanwj: do you have any objections to it? you're the person who would grant permissions right?
<michaelfolkson>
But yeah it is a credit to yourself laanwj that we generally all trust your stewardship :)
<michaelfolkson>
(I guess I shouldn't project my views on others without confirming but I'm sure that's the case)
zonemix has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
<laanwj>
glozow: no objections myself, but i do think it's important that people developing bitcoin core widely agree on it (which seems to be the case)
saranshsharma has quit [Ping timeout: 256 seconds]
rex4539 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
<michaelfolkson>
In normal times I'm sure it will be an irrelevance. It is just those stressful, strained times when under pressure someone could do something they later regret
<michaelfolkson>
But thankfully/hopefully they seem to occur very rarely
<MarcoFalke>
I don't think fanquake has ever done something they regretted later. I also hope no one is stressed. Taking time off might fix stress.
yanmaani has quit [Ping timeout: 276 seconds]
jtrag_ has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
<glozow>
laanwj: indeed!
jtrag has quit [Ping timeout: 240 seconds]
bomb-on has joined #bitcoin-core-dev
jtrag_ is now known as jtrag
<michaelfolkson>
There's no rush, take some time off and hopefully come back refreshed in the new year laanwj :)
yanmaani has joined #bitcoin-core-dev
jtrag_ has joined #bitcoin-core-dev
jtrag__ has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 256 seconds]
jtrag_ has quit [Ping timeout: 240 seconds]
jtrag__ is now known as jtrag
bomb-on has quit [Read error: Connection reset by peer]
<provoostenator>
ack en congrats achow101 wallet maintainer
jtrag_ has joined #bitcoin-core-dev
<michaelfolkson>
+1
saranshsharma has quit [Ping timeout: 240 seconds]
jtrag_ has quit [Client Quit]
jtrag has quit [Read error: Connection reset by peer]
<provoostenator>
fanquake: carefully building a reputation over many years and then suddenly destroying it, is a common theme in this industry. But usually not by blocking spammers on Github :-)
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
zonemix has quit [Ping timeout: 245 seconds]
<meshcollider>
Why block spammers, they're some of our most active PR and issue reviewers :)
saranshsharma has joined #bitcoin-core-dev
<meshcollider>
Also I have no idea why Luke's lone objection is still holding things up re: fanquake. Just ignore him and do it, his opinion should not outweigh literally every other dev here...
<meshcollider>
Consensus does not mean absolute agreement
zonemix has joined #bitcoin-core-dev
<michaelfolkson>
I don't think it would just be Luke with concerns on granting co-owner privileges on the repo to an additional person(s) ignoring who that person is
<michaelfolkson>
GitHub causes all sorts of unnecessary aggro
rex4539 has joined #bitcoin-core-dev
masta`` has joined #bitcoin-core-dev
<meshcollider>
I thought those same people argue against putting any trust into GitHub and this specific repo anyway ...
<meshcollider>
michaelfolkson: it is very clear that everyone speaking out is in favour except Luke and prayank, both for unrelated personal reasons
<michaelfolkson>
You minimize trust in GitHub but it can't go to zero during high pressure scenarios
<meshcollider>
...
<michaelfolkson>
And similarly with the Core repo I guess
gleb74 has joined #bitcoin-core-dev
<laanwj>
i mean in the end the github structure is contingent, it's not a representation of any formal power structure within bitcoin, if someone would really mess up the onus of development would simply move somewhere else
saranshsharma has quit [Ping timeout: 240 seconds]
<meshcollider>
Exactly, and that's a negligible chance anyway when the only people in question are some of the longest-standing and trusted contributors...
<michaelfolkson>
Right but it would be messy
<meshcollider>
michaelfolkson: stop fearmongering
rex4539 has quit [Ping timeout: 276 seconds]
<michaelfolkson>
I guess the elephant in the room is that some people wanted to remove Luke as a BIP editor earlier in the year. And rightly in my view laanwj didn't succumb to that pressure as there should be separation between Core and BIPs
<michaelfolkson>
So I'm not deliberately fearmongering
<laanwj>
it would but the same has to happen if we can't function efficiently and all project-level decisions are delayed or postponed indefinitely of course
<meshcollider>
But along the same lines, kalle was added despite Luke's objections there. Luke is almost always the only one objecting to these things
<michaelfolkson>
Maybe an additional owner of the repo would have acted differently in that scenario
<michaelfolkson>
A BIP editor who had been performing that role on his own for what 5+ years?
<laanwj>
that the bips repository is in the same organization is somewhat questionable in any case
<meshcollider>
A single BIP editor is also not very decentralised so that's not a good thing.
<michaelfolkson>
Right, we've got an additional one now which is great. But still people wanted to remove Luke
<michaelfolkson>
[12:15:03] <michaelfolkson> In normal times I'm sure it will be an irrelevance. It is just those stressful, strained times when under pressure someone could do something they later regret
<meshcollider>
Also, admin perms on bitcoin/bitcoin doesn't require admin on bitcoin/BIPs
<MarcoFalke>
I don't think anyone wanted to *remove* luke? I understood it as *adding* kalle, but I am not interested in rehashing the discussion here, so I probably shouldn't comment.
<meshcollider>
michaelfolkson: anyway, please don't perpetuate this discussion when apparently you're not actually objecting, and please leave it to dev consensus
<laanwj>
i'm not aware of anying asking to remove Luke either-just to add kallewoof
<earnestly>
(In disagreements focus hard on creating a set of measurable steps to solve whatever problem is causing it, sideline much of the purposeless discussion)
<earnestly>
From my lurking here I've not really seen anyone lay out a clear rationale for disagrement, usually because the other side refuses to acknowledge any aspect of it (and is quickly derailed into useless details), or because they don't have one.
<michaelfolkson>
meshcollider: I'm not objecting to fanquake as an additional owner of the repo if we get an additional owner of the repo. Just thinking through long term implications and being told that is fearmongering
<michaelfolkson>
But I'm repeating myself so I'll leave
<meshcollider>
There is no problem. fanquake should be given permissions because the supermajority of devs agree and those against have no valid objections. That's it.
<jnewbery>
meshcollider: +1
<earnestly>
> there is no problem if we redefine the problem to exclude the problem
<earnestly>
redefine the solution*
<michaelfolkson>
Happy to provide links to attempts to remove Luke as a BIP editor if they are needed though
<earnestly>
(Tbh, I've never seen a clear rationale given as to why fanquake shouldn't have permission to block accounts, usually because those against it don't explain themselves and there is no dialog with those who disagree. But I could easily have missed it too)
<laanwj>
so about reviewing PRs...
<_aj_>
laanwj: awww, mum, do we have to?
<MarcoFalke>
(Ok, some people might have asked for luke to be removed, but I hope my memory doesn't fail me telling me I was not one of them)
<laanwj>
_aj_: hehehe yess u should all review a PR and then if you still have energy to argue u can get back to discussion here
littlesh has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 256 seconds]
jtrag has joined #bitcoin-core-dev
arythmetic has quit [Remote host closed the connection]
sirdigby727 has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
rex4539 has joined #bitcoin-core-dev
littlesh has quit [Quit: Going offline, see ya! (www.adiirc.com)]
sdfgsdfg has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 268 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
jtrag_ has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 240 seconds]
jtrag has joined #bitcoin-core-dev
jtrag__ has joined #bitcoin-core-dev
jtrag_ has quit [Ping timeout: 268 seconds]
jtrag has quit [Ping timeout: 256 seconds]
saranshsharma has joined #bitcoin-core-dev
roconnor has quit [Quit: Konversation terminated!]
saranshsharma has quit [Ping timeout: 256 seconds]
evbo has joined #bitcoin-core-dev
arythmetic has joined #bitcoin-core-dev
arythmetic has quit [Ping timeout: 240 seconds]
saranshsharma has joined #bitcoin-core-dev
zonemix has quit [Remote host closed the connection]
ghost43 has quit [Remote host closed the connection]
zonemix has joined #bitcoin-core-dev
ghost43 has joined #bitcoin-core-dev
jtrag__ is now known as jtrag
zonemix has quit [Ping timeout: 268 seconds]
zonemix has joined #bitcoin-core-dev
zonemix has quit [Ping timeout: 240 seconds]
saranshsharma has quit [Ping timeout: 268 seconds]
<bitcoin-git>
bitcoin/master 4ad5904 W. J. van der Laan: Merge bitcoin/bitcoin#22704: fuzz: Differential fuzzing to compare Bitcoin...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jtrag has quit [Ping timeout: 240 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] laanwj merged pull request #22704: fuzz: Differential fuzzing to compare Bitcoin Core's and D. J. Bernstein's implementation of ChaCha20 (master...diff-fuzz-chacha20) https://github.com/bitcoin/bitcoin/pull/22704
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jtrag_ has quit [Ping timeout: 245 seconds]
arythmetic has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] glozow opened pull request #23804: validation: followups for de-duplication of packages (master...2021-12-dedup-packages) https://github.com/bitcoin/bitcoin/pull/23804
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
arythmetic has quit [Remote host closed the connection]
<bitcoin-git>
[gui] hebasto opened pull request #509: Respect dialog modality and fix a regression in wallet unlock (master...211217-unlock) https://github.com/bitcoin-core/gui/pull/509
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<S3RK>
so the current upper limit for bnb is not optimal
ZeroMaster_ has joined #bitcoin-core-dev
<S3RK>
it's economically better to drop more than the current upper limit for fees rather than add an extra input and create change output
<S3RK>
we can either 1) increase the limit or 2) drop the limit
<Murch[m]>
Yeah, we ran some experiments removing the upper bound for the exact match window and that resulted in an overall lower cost
<michaelfolkson>
hi
ZeroMaster_ has quit [Client Quit]
prayank has joined #bitcoin-core-dev
ghost43 has quit [Quit: Leaving]
<Murch[m]>
S3RK: My current position would be that I'd be apprehensive about dropping the limit altogether.
ZeroMaster has quit [Quit: излезна от чата]
ghost43 has joined #bitcoin-core-dev
<achow101>
if our calculation for the upper bound is incorrect, I would prefer to fix it rather than drop the limit entirely
<Murch[m]>
If both Knapsack and SRD find very bad solutions, we may drop a ton of money to fees.
ZeroMaster has joined #bitcoin-core-dev
<S3RK>
it's a bit tricky to calculate exact upper limit
<achow101>
but IIRC part of the issue is that our drop to fees handling is independent of the selection algorithm
<Murch[m]>
Right, but without an upper bound, BnB may end up returning a result that has a larger remainder than what's dropped and our transaction building ends up building a tx with a minuscule change
<S3RK>
hm... I'd say that's a related but separate issue. Would love to discuss it as well, but let's talk about the bnb limit first
<Murch[m]>
So, we could just post-filter BnB solutions to not use such a solution
<S3RK>
Murch, why do you think knapsack wouldn't find the same solution but with change?
<achow101>
the min change target
<Murch[m]>
Because Knapsack minimizes the overshoot past minChange
<S3RK>
hm...
<Murch[m]>
It doesn't prefer input sets with lower waste
<S3RK>
what about SRD?
<S3RK>
ah.. also min change
<Murch[m]>
SRD only runs once and also aims to create at least minChange
<S3RK>
yes, that's a bit of problem
<Murch[m]>
So you could have solutions on Knapsack and SRD that each have 10+ inputs
<Murch[m]>
and BnB finds a solution with a single input that ends up dropping 20k sats
<Murch[m]>
Or let's say 1k sats
<Murch[m]>
and we end up creating a transaction with a 750 sat output
<S3RK>
doesn't mean that right now we would say "insufficient funds" for such a tx?
<S3RK>
sorry
<S3RK>
does it mean taht ...
<Murch[m]>
So, right now, BnB would not find that solution, and it wuold use one of the Knapsack or SRD
<achow101>
actually knapsack should find the solution but with change
<achow101>
even if min change is not met
<achow101>
srd wouldn't
<S3RK>
I have to confess I don't know the details how knapsack works right now
<Murch[m]>
Right, but the scenario wasn't that we didn't have enough funds, but just that the solutions that Knapsack and SRD propose have huge input sets
<Murch[m]>
achow101: Do I misremember that Knapsack prefers the solution that overshoots the minchange the least?
<achow101>
that sounds right
<achow101>
it also prefers the solution that meets min change, but will produce a solution that does not if min change cannot be met
<Murch[m]>
Right
<S3RK>
It seems we should codify this scenarious in tests
<Murch[m]>
I guess we could amend Knapsack to compare the 1,000 trials via the waste metric instead of minimizing the excess, and then I'd agree.
<achow101>
so if bnb without limit found a solution that throws away lots to fees, knapsack should find the same thing but with change
<achow101>
the excess should dominate the waste calculation
<Murch[m]>
Yes
<S3RK>
achow101 +1 that was my understanding as well
<Murch[m]>
Correct
<Murch[m]>
That's why I painted a scenario in which they find different solutions because they optimize for different metrics in their selection ;)
<Murch[m]>
But yeah, if we use the waste metric internally to compare input sets on Knapsack as well, it would be pretty safe to drop the limit on BnB
<achow101>
however knapsack may also find a different solution that spends more inputs as it tries to meet min change. this would still be less waste on the knapsack side since excess dominates the bnb solution's waste
<Murch[m]>
But it would also kinda be pointless, because then Knapsack is very similar to BnB just for a solution that targets a +minchange larger target
<Murch[m]>
Yes
<achow101>
even if the knapsack fees are higher
<Murch[m]>
Knapsack and BnB are very similar in approach, except that Knapsack quasirandomly explores the binary UTXO tree, while BnB does it deterministically.
<achow101>
I think we need to change how we drop things to fees, and then run simulations
<achow101>
and see if bnb without limit causes some scenarios where we drop ridiculous amounts to fees
<Murch[m]>
Well, in the experiment you ran for us, the numbers showed that we had more BnB solutions used than changeless transactions.
<Murch[m]>
So, essentially, you've shown that already.
<S3RK>
it doesn't mean we drop ridiculous amounts to fees
<S3RK>
just more than we currently drop
<S3RK>
which I argue could still be more economical
<Murch[m]>
Yes, agreed
<S3RK>
what if we introduce a safeguard?
<S3RK>
put a limit on what is "ridiculous" to drop to fees?
<Murch[m]>
But it also breaks a lot of assumptions about BnB, because previously we assumed that BnB never creates change, and when we find a really large excess, the transaction we build actually does result in a change output
<achow101>
time for "absurdly-high-fee" errors again :p
<Murch[m]>
Isn't that equivalent to just updating our upper bound for the exact match window? ;)
<S3RK>
my PR does exactly this. BnB never creates change
<achow101>
yes, we do need to look at 23367 and also run simulations on it
<S3RK>
hm... yes we can also extend upper bound by the "absurdly-high-fee"
<achow101>
(there used to be a mempool policy reject error named absurdly-high-fee)
<achow101>
I think the fee had to be 0.1 or thereabouts
<S3RK>
there is still some limit. 0.1 sounds about right
<S3RK>
if you can write in plain english scenarios that concerns you, I can codify them as tests
<prayank>
AI
<S3RK>
I take it as a compliment :)
<achow101>
one thing that concerns me is that it's probably going to hit the iteration limit very quickly
<achow101>
since we are removing one of the bounds that allow BnB to be called Branch and _Bound_
<S3RK>
it shouldn't because there will be no branching
MattCorallo[m] is now known as BlueMatt[m]
<S3RK>
so it's linear to the amount of coins higher than the target
<Murch[m]>
achow101: No, finding a valid solution backtracks just like overshooting the window does
<Murch[m]>
Once you find a solution, it next explores the omission branch of the last included UTXO, the same as when it overshoots and stops searching the subtree because it already has too much
<achow101>
oh right
<achow101>
overshoot == finding a solution without limit, and both backtrack
<achow101>
anything else to discuss?
<Murch[m]>
It would be great if we had a test that does produce selections for which BnB without an upper bound on the exact match window breaks down
<S3RK>
what do you mean by breaks down
<S3RK>
I have a crazy idea. What if we create a test that iterates sending value from 1sat to 10^8sat and verifies fees
<Murch[m]>
Well, something were SRD and BnB would be highly likely to produce an input set with a large count of inputs, while BnB finds one that overshoots the exact match window severely and the BnB input set scores best according to the waste metric
<Murch[m]>
S3RK: I think that would be interesting, but probably the source of the issue would probably be found in the UTXO pool rather than the target amount
<Murch[m]>
E.g. a wallet that has 1,000 UTXOs that have the same size, and one that is larger
<S3RK>
true
<Murch[m]>
And 100 UTXOs match the target plus minChange plus fees by the satoshi, but the one large input is just enough for the target without change but has a large excess
<S3RK>
if we agreed that the waste metric is a good metric, than there is no problem with dropping more to fees no?
<S3RK>
I'll try to create some interesting test scenarios. Including one where current coin selectio fails
<Murch[m]>
Mh, I guess the fees would still be lower overall on the BnB solution in what I describe, but you'd not get the benefit of consolidating 100 UTXOs, so it feels like you paid more for less
<S3RK>
the benefit of consolidating only works if the fees are lower than "long term fee"
<S3RK>
if that's the case that would lower the waste
<S3RK>
i.e. consolidating value is counted in waste
<S3RK>
achow101 Murch what would be a good place for such tests?
<achow101>
if fees are high, the 100 utxos might have a larger fee than the bnb excess
<S3RK>
coinselection_test or some new/existing functional test?
<Murch[m]>
yes, to both
<Murch[m]>
but it still feels a bit icky, if you know what I mean
<S3RK>
yes :)
<achow101>
S3RK: usually rpc_fundrawtransaction
<achow101>
and coinselection_tests
<S3RK>
so in conclusion 1) I work on the tests
<S3RK>
achow101 could run simulations
<S3RK>
and you can also take a look at the PR
<achow101>
yes
<Murch[m]>
Yes
<S3RK>
thanks
<achow101>
any other topics?
<S3RK>
congrats, it looks like you'll be wallet maintainer soon :)
<prayank>
RPC would respond with balance and getbalances already does that but we add a condition so parameter
<achow101>
#topic add optional transaction(s) to getbalances (prayank)
<core-meetingbot>
topic: add optional transaction(s) to getbalances (prayank)
<achow101>
prayank: because such an RPC can be expanded to be much more than just balance fetching
<prayank>
like?
<achow101>
the reason I asked for simulaterawtransaction is because we can do things like seeing if a transaction has conflicts with the wallet, and if it does, what gets replaced
<prayank>
hmm
jtrag_ has quit [Ping timeout: 240 seconds]
<prayank>
I liked the idea of having such params in few other RPC to simulate things
<prayank>
You don't like the idea to add similar parameter in getmempool and see how mempool looks if some txs get added?
<achow101>
IMO it's better to have simulating things in one spot, rather than spread in many different places
<prayank>
yes its one param
<achow101>
prayank: no, I think that should be its own RPC
<achow101>
I don't think it makes sense to have a fetching function do simulation things
<prayank>
ah okay then I guess we have different opinion. No problem. But the wallet conflicts thing makes sense.
<prayank>
ryanofsky: had asked to create an issue which was never created
<prayank>
I was thinking to create one
<sipa>
I don't understanding anything about node-tor, or why you'd want to use a separate tor network for just bitcoin traffic. That completely defeats the purpose.
<sipa>
I conceptually like having more mechanisms for connecting bitcoin nodes though, so if there were a viable network like that to use as an additional one - sure why not.
<sipa>
But it feels to me like the discussion there is too far removed from anything concrete.
<prayank>
hmm tbh I am not the best person to comment anything on this. I liked the idea and his follow up on mailing list. What I understand is: we do bitcoin nodes from browsers similar to one PoC by bcoin but its not safe for production. And this guy wants to make it interesting by using tor protocol for everything. I have issues with JS and WebRTC but if it can help bitcoin nodes usage I dont mind and maybe not full nodes or somethin
<prayank>
g like neurino idk
<sipa>
I don't understand what you're talking about.
<prayank>
He wants to do something similar but use different ways to achieve it
<prayank>
and tor 'protocol' will be used not browser
<prayank>
or their network
<sipa>
I don't think that's at all what he's talking about. He's saying that the communication between bitcoin core and node-tor (if it were to use node-tor rather than actual tor) would not use SOCKS.
masta`` has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<sipa>
But again, while I conceptually agree with making it easier to connect bitcoin nodes in more different ways with eachother, I don't understand the point of node-tor.
<prayank>
sipa: what I understood based on his emails. he likes browsers, js and world around it. so webtorrents kind of things for bitcoin nodes. He is from france, he is good with his project but unable to express or get funding. IDK just wanted to share it here once so that people like you who know better would be able to see if it helps bitcoin at some point. Everything is moving to browsers tbh and this is not about altcoins. I work
<prayank>
ed at microsoft when I was in college and even that had started moving from desktop applications to web apps. Core can remain same but we need a world around it.
jtrag_ has joined #bitcoin-core-dev
jtrag has quit [Ping timeout: 240 seconds]
roconnor has joined #bitcoin-core-dev
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
<jb55>
so basically a way to feed network messages in and out as plaintext, turn bitcoin into a pure function?
<sipa>
prayank: I conceptually agree with that, but it seems all unrelated to this discussion. He wants to build his own network that uses the tor protocol, but separate from the real one. I don't understand the reasons for that, or what there is to be gained, as directly shrinking the anonimity set for no reason as far as I can tell.
sdfgsdfg has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
<roconnor>
reducing the anonymity set seems pretty bad.
<prayank>
sipa: Reason IIUC he doesn't like the way Tor project uses Tor protocol and its flaws etc. but wants to make a better to for different projects and bitcoin is one of them
<sipa>
jb55 The P2P protocol is stateful, so it's not that easy. Just having ways of routing messages over some other links has some limited use (e.g. it's done by Blockstream satellite), but really supporting many networks in a full way is a lot harder, as you need the ability to discover connections and automatically create them etc.
<prayank>
roconnor: Tor is anyways centralized directory servers so i2p is better even if less nodes
Talkless has quit [Quit: Konversation terminated!]
arythmetic has quit [Remote host closed the connection]
<prayank>
The part I am interested in this project actually was not Tor. It was browser. Because I want to see people running pruned nodes or at least some neturino type nodes running from mobile and browser.
<sipa>
That's all very reasonable, but I don't think that has much to do with Bitcoin Core.
<prayank>
Hmm but he commented in that PR so I thought some changes are required or that PR is related
<sipa>
Yes, he needs a way to communicate with Bitcoin Core. The altnet stuff goes in the direction of providing that functionality. As I said, I conceptually agree with that. I still don't see the point of node-tor, but if there is more functionality for interacting with separate networks, and someone makes it work with node-tor, sure...
<sipa>
But Bitcoin Core works fine with tor itself, and tor itself also works with browsers.
<jb55>
btw satellite doesn't need to be a bitcoin fork right? couldn't it just be a block-from-space decoder + call submitblock? or is there more to it?
<sipa>
I don't know.
<sipa>
I think it may rely on the node's mempool to do fast reconstruction.
<jb55>
hmm
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
ZeroMaster has quit [Remote host closed the connection]
jtrag has joined #bitcoin-core-dev
jtrag_ has quit [Ping timeout: 240 seconds]
arythmetic has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 276 seconds]
arythmetic has quit [Remote host closed the connection]