yanmaani has quit [Remote host closed the connection]
yanmaani has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
hashfunc95e has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
prayank has joined #bitcoin-core-dev
<prayank>
kanzure: if you or your algo bans people because you do not like their thoughts, either leave responsibility to decide for others when you are already making so called "privacy coins" to get rich. Or allow different opinions so that we can see how people react to something.
<prayank>
1. One person had emailed me about bad ports it was not updated
<prayank>
2. My email about mempool was not updated
<prayank>
If this continues we will find better solutions and this will become irrelevant
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
grettke has quit [Read error: Connection reset by peer]
grettke has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
cold has joined #bitcoin-core-dev
<kanzure>
what?
prayank has joined #bitcoin-core-dev
<prayank>
kanzure: Asking for reasons why 1 and 2 was not updated
<prayank>
might be offtopic and I have emails
<prayank>
"I disapprove of what you say, but I will defend to the death your right to say it." please follow this
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
hashfunc95e has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
prayank has joined #bitcoin-core-dev
<prayank>
I did not receive any answer in last few huours. pleaase do one thing: stay away from me and associated devs. I won't care.
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
bitdex has joined #bitcoin-core-dev
<kanzure>
emails don't/can't get updated once sent
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
sudoforge has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
bairen has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
<achow101>
prayank: the bitcoin-dev list has greylisting active. messages from new emails will be in a moderation queue and need to be manually approved before being sent to the list. messages that are not approved will appear here: https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ I don't see the email in question there, so it's probably just still in the queue waiting for someone to get to it
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
sudoforge has joined #bitcoin-core-dev
grettke has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
sudoforge has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
jarthur has quit [Ping timeout: 240 seconds]
jarthur has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
sipsorcery has joined #bitcoin-core-dev
Guest3980 has left #bitcoin-core-dev [WeeChat 3.4]
dviola has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mikehu44 has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
bitcoin/master ddcac22 jarolrod: doc: cleanup doc on need of Developer Account to obtain macOS SDK
<bitcoin-git>
bitcoin/master 5f7f2f7 fanquake: Merge bitcoin/bitcoin#24241: doc: cleanup doc on need of Developer Account...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake merged pull request #24241: doc: cleanup doc on need of Developer Account to obtain macOS SDK (master...macdeploy-readme-cleanups) https://github.com/bitcoin/bitcoin/pull/24241
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bomb-on has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
robertspigler has quit [Quit: You have been kicked for being idle]
Kaizen_Kintsugi_ has quit [Ping timeout: 252 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
bfsfhkacjzgcytf has quit [Quit: Ping timeout (120 seconds)]
bfsfhkacjzgcytf has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 252 seconds]
bfsfhkacjzgcytf has quit [Ping timeout: 250 seconds]
bfsfhkacjzgcytf has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
kexkey has quit [Ping timeout: 240 seconds]
kexkey has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
bfsfhkacjzgcytf has quit [Ping timeout: 256 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 256 seconds]
<michaelfolkson>
prayank: Firstly please be less accusatory in tone until you fully understand what has occurred. kanzure and others have kept the mailing list going for years voluntarily and shouldn't have to jump to IRC to defend themselves against premature conclusions
<michaelfolkson>
Secondly, this is the wrong IRC channel for these discussions. We've set up #bitcoin-dev for discussion on BIPs, mailing list posts. This is not a Core development issue
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<hebasto>
just wrote to support+ci@cirruslabs.org about `arm_container` failure in CI
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<Murch>
For a single selection that's of course optimal
<Murch>
It's probably not optimal for the long-term, though
<S3RK>
not always, because consolidation could be better if fees are low
<S3RK>
but I understand the challenge
brunoerg has quit [Remote host closed the connection]
<S3RK>
maybe we can punish such solutions by some fixed waster
<S3RK>
idk
<Murch>
Right, but that wouldn't be minimizing fees
<Murch>
But rather minimizing waste :)
brunoerg has joined #bitcoin-core-dev
<Murch>
mh.
<S3RK>
well... I mean the algo searches for the minimum fee solution
<S3RK>
but the final result is selected by waste
<Murch>
ah yes
<S3RK>
which means that the algo won't always win
<Murch>
Right, but it would also mean that we would usually get a single input solution for anything above 10 sat/vB
<S3RK>
I agree it might skew the selection too much. just an idea
<Murch>
Occasionally, maybe a BnB solution with two inputs that has better waste
<Murch>
Yeha, sorry, I'm not trying to dissuade brain storming
<Murch>
I was just considering it as well, but I think it would basically get rid of almost all other solutions
<Murch>
(for the high feerate case, that is)
<S3RK>
oh! what if we do run knapsack with a few change targets?
<S3RK>
the problem now is that if there is an exact match knapsack quits
<achow101>
I thought we were plannin on ditching knapsack
<S3RK>
I'm not sure SRD + bnb only cover all cases, like the one we are dicussing no
brunoerg has quit [Ping timeout: 252 seconds]
<Murch>
achow101: Yeah, but isn't it currently providing something like 60% of all selection solutions? We should probably find something that beats Knapsack before getting rid of it
<Murch>
I don't like how computationally inefficient it is, but it currently seems to be the best solution per waste metric most of the time
<Murch>
mh. If there is an exact match, we should also find it with BnB.
<Murch>
Perhaps we could just kick that out of Knapsack's terminal conditions?
<S3RK>
we do, but the waste sucks. and BnB preffers to drop 250k sats to fees
<Murch>
Oh, you mean in the case that we get an input set with tons of inputs
<S3RK>
yes
<Murch>
Well, that would be more of a bug than intended behavior, wouldn't it?
<achow101>
if I understand correctly, both bnb without limit and knapsack find solutions that suck, when there is a better one?
<S3RK>
indeed
<S3RK>
the scenario is like this
<achow101>
for some definition of better that doesn't quite include waste?
<S3RK>
we have one big coin and tons of small ones
<S3RK>
we send an amount that is exact match of 100 small coins AND just under big coin
<Murch>
Isn't it more like "BnB without limit finds always a solution, but they suck sometimes"?
<S3RK>
bnb without limit finds a solution when we use one big coin and drop the rest for fees
<S3RK>
knapsack finds exact match which is bad
<S3RK>
the optimal is to take one big coin + maybe a few small and create change
<achow101>
hmm, maybe we need a knapsack replacement that doesn't do exact match
<S3RK>
SRD could find it, but if there are tons of coins that the chances are not in our favor
<Murch>
Right
<Murch>
Makes sense
<achow101>
knapsack also does a couple different things, perhaps we should split it up. e.g. the "lowest larger" part of it sounds like it would solve this problem
<Murch>
Has any of you ever looked into the "blackjack" algo?
<S3RK>
Murch saying just having lowet larger would skew selection too much
<S3RK>
didn't look into "blakjack" algo
<Murch>
achow101: lowest larger would probably almost always win the waste metric for high feerate cases
<S3RK>
but what about running knapsack (or any other algo which optimizes for amount match) two times
<S3RK>
one time with the target amount and another with that + some change target
<Murch>
So it would highly favor short term optimal solutions but encourage fragmentation of the wallet in the long run
<S3RK>
(stupid me, this doesn't help)
<achow101>
Murch: what about lowest larger without a change target?
<achow101>
(i.e. burn the excess)
<S3RK>
that's bnb-without-limit
<Murch>
Blackjack in a couple sentences: continuously pick the largest coin smaller than the missing amount. When no such coin exists, add smallest larger
<Murch>
So, it'll always pick a few inputs, but in the end will always find a solution
<S3RK>
will it find solution in the scenario I described above?
<S3RK>
sounds like no
<Murch>
It should also be somewhat consolidatory at low feerates
<Murch>
mhh.
<Murch>
S3RK: Ugh, you're right
<Murch>
Maybe if you limit the first part to ~5 or ten inputs
<achow101>
I'm slightly confused. I think I need to look at an actual input set
<S3RK>
yes, it's difficult to keep in the head
<achow101>
need a whiteboard :)
<S3RK>
I'll do a PR once I clean up the code
<S3RK>
helped me a lot to reason about it
<S3RK>
that's all from me
<achow101>
ok, I'll wait for that
<Murch>
achow101: You have 100× 1 m₿ and 1× 102.5 m₿. Select for 100 m₿
<achow101>
#topic Better name for `sweepwallet` RPC (Murch)
<core-meetingbot`>
topic: Better name for `sweepwallet` RPC (Murch)
<Murch>
Okay
<Murch>
Well, the proposed RPC was first named `sweep`, and multiple people said that their first instinct was that its function was to take the funds from an external privKey and send the funds into the wallet
<Murch>
So we renamed it to `sweepwallet` thinking that this would distinguish it, but the comment has come up again :)
<Murch>
So, I'm open for people proposing a better name for an RPC that has the function of:
<Murch>
• Take a set of UTXOs and send all of it to a recipient deducting fees
<S3RK>
sendcoind/sendutxos?
<achow101>
I think sweepwallet is fine
<S3RK>
sweepwallet is also fine with me fwiw
<Murch>
Mh. `sendcoins` does kinda work for me
<Murch>
Anyway, I don't want to dwell on it too much. If people have ideas, please dm me, or post on the PR.
<Murch>
If we don't come up with something much better, I'd just stick with it, though
<warren>
Murch: "emptywallet" seems abundantly clear in intent?
<jonatack>
Murch: if you're not targeting v23 (it seems to be too late), at least we'll have some time to correct the RPC name, and the options vs positional args thing, if people prefer to
<Murch>
Yeah, I think it'll not make the feature freeze
<warren>
To clarify the existing SFFA used with manual Coin Control selection is not going away right? I use that a lot.
<achow101>
warren: you can specify specific inputs in sweep and it will spend only those inputs
<warren>
Will I no longer be able to click the inputs I want in the Coin Control window?
<achow101>
the gui is currently not changing
<warren>
OK, Coin Control + SFFA will continue to work?
<achow101>
yes
<warren>
Coin Control GUI + SFFA
<warren>
k thanks
sipsorcery has joined #bitcoin-core-dev
<jonatack>
warren: +1, i use SFFA a lot
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
yanmaani has quit [Ping timeout: 276 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]