jespada has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
c_arc has joined #bitcoin-core-dev
lightlike has quit [Quit: Leaving]
instagibbs has joined #bitcoin-core-dev
vnogueira has joined #bitcoin-core-dev
<instagibbs>
prayank the mempool is only an "orderbook" if everyone has the same relay policy forever. There's a reason why the first cut of estimation was to use mempool->block measurements
<instagibbs>
e.g., if you are a softfork behind(or censorship, same difference), you may over-bid by competing against things that won't confirm. I think a simple improvement could be to take the min of mempool and block estimates, but I'm not sure that solves what problem you're trying to solve
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
earnestly has quit [Ping timeout: 264 seconds]
c_arc has joined #bitcoin-core-dev
<dviola>
when I receive a tx in bitcoin core 22.0.0 the clock icon (before the date field) in the Transactions tab says I have 1 of 6 confirmations
<dviola>
but if I double click on the tx it says "Status: 3/unconfirmed"
<dviola>
bug?
<dviola>
I mean the tooltip and the icon is wrong
c_arc has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<sipa>
dviola: sounds like a bug; open an issue on the gui repo if there isn't one yet
copumpkin has quit [Remote host closed the connection]
copumpkin has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<dviola>
sipa: ok
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Yihen has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 264 seconds]
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
vnogueira has quit [Remote host closed the connection]
vnogueir- 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
first_mersible has quit [Quit: Leaving]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Yihen 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
cdecker has quit [Ping timeout: 265 seconds]
c_arc has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<prayank>
instagibbs: 1. Not sure tbh how will things change if different mempool policies are used however it looks less likely in near future looking at the trend. Most users will run Bitcoin Core and they will use defaults. 2. Things are simple. There are blocks which get mined every few minutes. Blocks have limit based on vsize or weight. So everyone is bidding and competing to get their transactions confirmed. There is nothing to estimate or predict but
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<paulo>
is there a "wishlist" of features I can possibly work on?
c_arc has joined #bitcoin-core-dev
dviola has quit [Ping timeout: 264 seconds]
dviola has joined #bitcoin-core-dev
<meshcollider>
paulo: Best thing to do would be to check out the "issues" list on github :) there are tonnes of ideas there
goatpig has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
instagibbs has quit [Ping timeout: 246 seconds]
Guyver2 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bairen has quit [Ping timeout: 276 seconds]
bairen has joined #bitcoin-core-dev
<shiza>
paulo: Stay away or you risk becoming maintainer!
<paulo>
shiza: what do you mean, is that a joke?
<paulo>
meshcollider: thanks!
<paulo>
I mean, I don't even C++
<shiza>
paulo: Yes it is a joke.
<shiza>
paulo: Don't C++. It's legacy.
<shiza>
That was a joke. I'll go away now.
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #23060: release: increase minimum compiler and lib(std)c++ requirements (master...23_0_min_compiler_libcpp_requires) https://github.com/bitcoin/bitcoin/pull/23060
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
earnestly has joined #bitcoin-core-dev
Henrik has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
midnight has quit [Quit: quit]
cold has quit [Quit: Quitting...]
midnight has joined #bitcoin-core-dev
<prayank>
paulo: if you have things in wishlist that improve privacy in bitcoin core but you don't feel like creating an issue in the repository, feel free to write them down in a gist and share the link here. Will be helpful.
cold has joined #bitcoin-core-dev
<meshcollider>
prayank: I think they want to work on something, not add to the wishlist, based on the message :)
<prayank>
Sorry I misunderstood
<prayank>
paulo: There are lot of things to work on. You can start with https://github.com/bitcoin/bitcoin/issues/22368 (It's less than 20 lines of code if correctly done but nobody wants to work on it for some reason)
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
<shiza>
prayank: If you know it's less than 20 lines of code, why wouldn't you code it yourself? Maybe the issue you describe is not an important issue for paulo, and it's not labeled as good first issue and even have no concept ACKs. If you direct a newcomer towards a poorly welcomed issue, chances are his efforts could end up being for naught.
<prayank>
shiza: I tried. Failed. Have shared the details in the Stackexchange link.
<prayank>
This is an important issue. Improves privacy and pending since 2012.
<prayank>
It can get more than 10 concept ACKs if few influential devs ACK it or its discussed in core pr review club if you need ACKs before improving privacy
<shiza>
I know it's not the point right now, but there is no such thing as influential developers in peer directed projects.
<prayank>
I disagree and it's better if we don't discuss this. Efforts to fix this issue won't go waste.
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
jespada 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
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #23064: fuzz: Fix memory leak in system fuzz target (master...2109-fuzzMemLeakSys) https://github.com/bitcoin/bitcoin/pull/23064
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] meshcollider opened pull request #23065: Allow UTXO locks to be written to wallet DB (master...202109_lockunspent_persistence) https://github.com/bitcoin/bitcoin/pull/23065
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<meshcollider>
prayank: ^
bitdex has quit [Quit: = ""]
bairen has quit [Remote host closed the connection]
bairen 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
dviola has quit [Changing host]
dviola has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
yyaac has joined #bitcoin-core-dev
yyaac has quit [Client Quit]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
yyaac has joined #bitcoin-core-dev
c_arc_ has joined #bitcoin-core-dev
c_arc has quit [Remote host closed the connection]
TheCharlatan has quit [Ping timeout: 250 seconds]
vasild has quit [Ping timeout: 276 seconds]
TheCharlatan has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake closed pull request #22966: doc: Improve documentation around the ACK statement (master...ack-documentation) https://github.com/bitcoin/bitcoin/pull/22966
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
vasild has quit [Remote host closed the connection]
kappa has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
<Bullit>
at 952.5 Volt a transistor in the cubic grid of the uk intents that that doesnt matter that it is more than 420k in euro... 8.553Fractal balance deducted from 3KWmEuAXy8HauiZRhUJLVdn4eFKvoGCtap 1AG SXY
Bullit was kicked from #bitcoin-core-dev by ChanServ [Banned: spam]
<michaelfolkson>
Presumably not using http with UNIX socket support was how c-lightning got it to work without needing the PR to libevent?
<michaelfolkson>
I'm guessing it has to be http for some reason but not sure why
<sipa>
michaelfolkson: c-lightning just calls bitcoin-cli
<sipa>
and you can implement HTTP without libevent; it's just a pain to get right
<sipa>
as for why JSON-RPC has to be HTTP.. i guess that's the standard approach, but just using a plain line based protocol could work too... that would be easier to implement, but perhaps breaks compatibility with other intended applications?
goatpig has quit [Quit: Konversation terminated!]
<sipa>
this sort of stuff is generally up to whoever ends up implementing it... and i suspect laanwj lost interest in it
<darosior>
I think michaelfolkson refered to C-lightning's JSONRPC interface in which case the answer is: C-lightning doesn't use HTTP, it just sends the JSONRPC messages through the socket
sipsorcery has joined #bitcoin-core-dev
<sipa>
ah, i see
<michaelfolkson>
darosior: Right, I guess there are different configurations of the server-client relationship. Server=Core Client=c-lightning is one. Server=c-lightning Client=c-lightning plugins is another.
<michaelfolkson>
And with UNIX sockets in Core you could maybe do Core plugins or at least a Python client connecting to Core
<sipa>
you can already have a python client connecting to corr
<sipa>
that's what the functional test framework uses
<darosior>
And plugins ala C-lightning is orthogonal to the transport used
c_arc has joined #bitcoin-core-dev
<sipa>
yes, they just some means of communication
Guest9472 has joined #bitcoin-core-dev
<michaelfolkson>
Ok thanks. So the answer to my original question is most likely breaking compatibility, makes sense. And that's most likely why laanwj stuck with http and went the libevent PR route
<sipa>
yes, this is mostly a non-technical issue
<sipa>
*anything* could have been chosen for bitcoin core's RPC interface, but the one that was chosen was json-rpc over http with user/pass authentication
<sipa>
and it's reasonable to expect that to keep working
<sipa>
in any case, back on topic: i don't see any problem personally with adding support for unix sockets rpc server / client that uses plain json-rpc lines, if someone wants to work on that
kappa has quit [Quit: Client closed]
<michaelfolkson>
Oh in addition rather than as a replacement.... yes that could work. Perhaps downsides of code replication, maintenance burden of having two approaches?
<sipa>
unix sockets is inherently limited to local communication, so it would always be in addition to
c_arc has joined #bitcoin-core-dev
Guest9472 has quit [Quit: Client closed]
<michaelfolkson>
It is recommended to not enable Core RPC connections over public internet but UNIX sockets wouldn't allow that use case at all and we want to support that if it is SSL wrapped?
<sipa>
but yes, that's the advantage of using http-based json-rpc... being able to reuse more code (then again, line-based is so simple that there is probably just not that much to add)
<sipa>
you can also use bitcoin core RPC in a local trusted network
<sipa>
or over a VPN or so
<michaelfolkson>
Gotcha, thanks
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
smartin has quit [Ping timeout: 252 seconds]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
hex17or has quit [Ping timeout: 276 seconds]
hex17or has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<jeremyrubin>
I think what we'd want is to remove the http support from Bitcoin core and then build a separate binary with a simple http proxy to it
<jeremyrubin>
That doesn't even have to live in core.
<sipa>
that's also a possibility, but probably not a short-term one
<sipa>
(also, unix domain sockets don't exist on windows...)
<jeremyrubin>
It would be a breaking change so would be a maj release
<jeremyrubin>
I think they have something that can be used the same way these days
<sipa>
right, but we'd need that too :)
<jeremyrubin>
I think it's basically the exact same
<darosior>
Windows does support Unix Domain Sockets since W10
<jeremyrubin>
Just different headers and negative FDs
sipsorcery has quit [Ping timeout: 260 seconds]
<jeremyrubin>
I think over the span of a few releases could reasonably do deprecated, not built by default, removed.
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
<laanwj>
yes, modern windows has them too
<laanwj>
i might give 'simple line protocol over UNIX socket' a try, if there is really enthousiasm for adding such a thing; at least i don't have to fight libevent's http client then, that's what i lost interest in
AaronvanW has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<laanwj>
i guess the only context information from HTTP that is used inside RPC calls is the wallet name from the path, in case of wallet RPC calls
<laanwj>
but would be straightforward to wrap in an object that provides the context otherwise, e.g. { 'wallet': 'name', 'params': {...} }
Talkless has joined #bitcoin-core-dev
kexkey has joined #bitcoin-core-dev
yyaac has quit [Read error: Connection reset by peer]
yyaac has joined #bitcoin-core-dev
yyaac has quit [Read error: Connection reset by peer]
lightlike has joined #bitcoin-core-dev
<jeremyrubin>
i guess the only other question is the rest API thing?
dunxen has joined #bitcoin-core-dev
<jeremyrubin>
that also seems like stuff that should just be a proxy over core tho
<jeremyrubin>
(or just removed and see if anyone complains?)
<laanwj>
rest is very closely bound to http, how i imagine this would purely be for RPC calls (all information on rest is also available through RPC it's 'extra')
<laanwj>
i think that could very well be an optional thing that people can enable if they want it
<laanwj>
sharing the http server between rest and the json-rpc interface was always a bit questionable, they are separate things
<jeremyrubin>
laanwj does anyone use the rest interface in practice?
<laanwj>
i have no idea
<jeremyrubin>
i've never heard of anyone using it either
<laanwj>
it's much faster than JSON-RPC for some things as it saves on formatting and the info can (basically) directly be dumped to the socket
<laanwj>
though it's not as great as it sounds, i wanted to add a rest call for streaming utxo data once (without buffering it in memory first), but libevent's http server wouldn't let me due to not really being thread safe
Guest7230 has joined #bitcoin-core-dev
<laanwj>
mostly it's not even issues with http itself we run against, but issues with libevent's http, but adding another dependency for http would be not nice
sipsorcery has quit [Ping timeout: 264 seconds]
c_arc has joined #bitcoin-core-dev
<jeremyrubin>
laanwj i think given that there are few users for rest (most likely) we could ship a /share script with a python http proxy for rest, altho performance might suffer a bit (maybe we add a raw response mode for the json rpcs if it's a concern?)
<laanwj>
yes...
earnestly has quit [Read error: Connection reset by peer]
earnestly has joined #bitcoin-core-dev
<laanwj>
in the case where we directly 'own' the socket, and the protocol is up to us to define, in principle it could reply in a different way than a line with JSON on it if so requested, this does make clients that want to support that more complex, so everything should at least support JSON line in JSON line out
<laanwj>
honestly that kind of thing seems far enough away, i'm not sure it's worth spendng time on, it works as it does now, not sure about the added benefit of doing things slightly different
<laanwj>
i think my reply on twitter was more hypothetical, in a perfect clean-slate world where you don't have to balance so many different concerns and backwards compatibility, it would have been nice
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
sipsorcery 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
vnogueir- has joined #bitcoin-core-dev
vnogueir| has joined #bitcoin-core-dev
vnogueira has quit [Remote host closed the connection]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
sipsorcery 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]
lightlike has quit [Quit: Leaving]
c_arc has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
tla2k21 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
yanmaani1 has quit [Quit: yanmaani1]
yanmaani has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 246 seconds]
<fanquake>
Looking for opinions on whether we want to merge #22858 and cut an rc3 for 0.21.2. As we we really should get that out soon. If not, we could just about tag final.