<sugarpuff>
I don't get what he means by the reorg risk. Is he saying there's no difference? I don't think that's true, there is a difference - in the current scenario the user is completely in the dark with no guarantees whatsoever as far as when they can expect their txn to go through or be returned to them. In the proposal they do have such a guarantee. Even if their block is re-org'd out - I thought they were supposed to wait 6
<sugarpuff>
blocks anyway.
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Client Quit]
<sipa>
@sugarpuff If you want to cancel a transaction, you can pre-sign a double-spend of it.
jonatack1 has joined #bitcoin-core-dev
<sipa>
But adding expiration times to transactions means even absent double-spends, transactions can randomly become invalid if they're mined close to their expiration.
<sipa>
Because a reorg could push them to another chain's block which has a later timestamp, past the expiration.
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
jonatack1 has quit [Ping timeout: 252 seconds]
jonatack1 has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
SpellChecker has quit [Quit: bye]
SpellChecker has joined #bitcoin-core-dev
amovfx has quit [Remote host closed the connection]
amovfx has joined #bitcoin-core-dev
amovfx has quit [Ping timeout: 252 seconds]
amovfx has joined #bitcoin-core-dev
* luke-jr
wonders if reorg'd transactions will replace non-reorg'd ones right now
<luke-jr>
maybe it would make sense to block RBF on transactions that have ever been in a block
<_aj_>
luke-jr: those seem like opposite questions? the latter is "will a new tx replace a tx that was in a reorg'ed block", the former is "will a tx that was in a block that's being reorg'd replace a tx in the mempool" - but if a tx conflicts with a tx in the blockchain it shouldn't be in the mempool in the first place?
EthanHunt has joined #bitcoin-core-dev
Darknet has joined #bitcoin-core-dev
EthanHunt has quit [Ping timeout: 252 seconds]
amovfx has quit [Remote host closed the connection]
<luke-jr>
_aj_: my thought is, when we reorg, any transactions in those blocks should get "pinned" into the mempool, so they can not be replaced period
<luke-jr>
but yes, I agree, the first one seems clearly impossible to have otherwise
<_aj_>
luke-jr: seems good for the network, but not something miners would particularly want
EthanHunt has joined #bitcoin-core-dev
<_aj_>
i mean: good for the network in that, while it doesn't stop an attacker from doublespending as part of a reorg, it prevents other attackers from opportunistically taking advantage of a reorg that someone else is doing
<luke-jr>
_aj_: what is good for the network, is often good for miners too
<luke-jr>
it's unfortunate so many seem to have short-sighted views on this
Darknet has quit [Ping timeout: 252 seconds]
jonatack1 has quit [Ping timeout: 260 seconds]
jonatack1 has joined #bitcoin-core-dev
EthanHunt has quit [Remote host closed the connection]
EthanHunt has quit [Remote host closed the connection]
EthanHunt has joined #bitcoin-core-dev
ziggie has quit [Quit: Connection closed for inactivity]
PaperSword has joined #bitcoin-core-dev
Darknet has joined #bitcoin-core-dev
EthanHunt has quit [Ping timeout: 248 seconds]
EthanHunt has joined #bitcoin-core-dev
Darknet has quit [Ping timeout: 260 seconds]
<_aj_>
luke-jr: i suppose there could be a spam vector with that if you had a tx included in a low-work block during ibd which is then immediately reorged out, but gives that tx protection. i'm not sure if we ignore all blocks that aren't in a minwork headers chain; if we do that'd prevent that. could also only protect it from eviction for 2000 blocks or set it to expire at 14 days after the block's MTP
noxim has quit [Ping timeout: 252 seconds]
<PaperSword>
Is there a better way to get the length of a univalue object than .get_str.length()?
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
jonatack2 has joined #bitcoin-core-dev
jonatack1 has quit [Ping timeout: 260 seconds]
Darknet has joined #bitcoin-core-dev
EthanHunt has quit [Ping timeout: 260 seconds]
Darknet has quit [Ping timeout: 260 seconds]
sudoforge has joined #bitcoin-core-dev
sudoforge has quit [Client Quit]
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
Darknet has joined #bitcoin-core-dev
<_aj_>
PaperSword: if it's an object/vector, you want .size()? if it's a string (or number?) that seems fine?
noxim has quit [Ping timeout: 248 seconds]
<PaperSword>
I am working on merging ParseHashOrHeight into getblock() as to allow the getblock call to accept a height or a hash. Instead of just a hash.
<PaperSword>
as such I need to take the univalue for request.param[0] and determine the length. If the length == 64 then the param is a block hash. If the param is less than 64 it can be parsed as an int that represents an attempt to parse at a block height.
<_aj_>
PaperSword: past feedback has been that that's better done on the client side, so that branch implements in bitcoin-cli and the gui, rather than serverside. #16439
<gribble>
https://github.com/bitcoin/bitcoin/issues/16439 | cli/gui: support "@height" in place of blockhash for getblock on client side by ajtowns · Pull Request #16439 · bitcoin/bitcoin · GitHub
<PaperSword>
For all intents an purposes this is just to speed up one of my scripts that is getting block info for blocks 0 to tip, as such right now I am making two calls, one to get hash from height. Then passing that into getblock.
<PaperSword>
Not to sound completely ignorant why even use the @block? Can the type of param[0] be changed to height_or_hash?
<_aj_>
height_or_hash is pretty awkward with bitcoin-cli, you have to say '"00000abcdef12345.."' so that an int looks different to a string
SpellChecker has quit [Remote host closed the connection]
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
<PaperSword>
A hash will always be a str of length 64 correct?, is there any reason to not attempt to convert a str of length < 64 to an int if the value is less than the max of getInt?
<_aj_>
if you're only accepting strings, might as well have the prefix, so it's unambiguous which you're talking about? *shrug*
<_aj_>
getblockstats is the only thing that accepts a hash or a height currently, and it does it by checking the argument type
<PaperSword>
BTW thanks for your time.
<PaperSword>
Exploring the RPC has helped me learn much more about the inner workings of the RPC server, it's quite cool.
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
<PaperSword>
In regard to ambiguity, The thought I had is due to the fact that the block height will not encroach onto the same hex representation space of being 64 characters for 1.9*10^58 years. It would be hard to fathom the block height ever reaching that.
<_aj_>
you could also just say "is the first character 0? hash."
noxim has quit [Ping timeout: 252 seconds]
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
<PaperSword>
Not saying it would be useful for my implementation to optimize my dev node. If it possible to ever have a difficulty value that would accept a hash with a 0x2... or something similar. Not asking if it would ever happen, but is it possible?
<PaperSword>
Is it*
<PaperSword>
That would mean 1 in 2 hashes would produce a block.
<PaperSword>
wait wrong sorry.
<_aj_>
no, powLimit in chainparams.cpp forces 8 leading 0's (5 for signet, 1-leading-0-bit for regtest)
<PaperSword>
That is quite clever.
<PaperSword>
Thanks again for these bits of knowledge.
<_aj_>
so yeah, regtest has blocks that don't start with 0, so that wouldn't work
<PaperSword>
Regtest blocks could start with 0x0... - 0x7...
bitdex has quit [Ping timeout: 255 seconds]
bitdex has joined #bitcoin-core-dev
Darknet has quit [Ping timeout: 248 seconds]
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
gnaf has quit [Ping timeout: 252 seconds]
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
_andrewtoth_ has quit [Remote host closed the connection]
<gleb07122>
I can probably just replace wait_until bytesrecv_per_msg -> wait_until log message and see if that passes, but i kinda wanna understand what's wrong too.
SpellChecker has quit [Remote host closed the connection]
Darknet has joined #bitcoin-core-dev
EthanHunt has quit [Ping timeout: 248 seconds]
Darknet has quit [Read error: Connection reset by peer]
SpellChecker has joined #bitcoin-core-dev
EthanHunt has joined #bitcoin-core-dev
SpellChecker has quit [Quit: bye]
SpellChecker has joined #bitcoin-core-dev
noxim_ has joined #bitcoin-core-dev
noxim has quit [Ping timeout: 260 seconds]
EthanHunt has quit [Ping timeout: 260 seconds]
Guest51 has joined #bitcoin-core-dev
Guest51 has quit [Client Quit]
AaronvanW has joined #bitcoin-core-dev
NorrinRadd has quit [Ping timeout: 248 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
kexkey has quit [Ping timeout: 248 seconds]
kexkey has joined #bitcoin-core-dev
<vasild>
gleb07122: self.nodes[0].getpeerinfo()[-1] -> list index out of range
<vasild>
I am poor pythoner but I guess that means that either nodes[] or getpeerinfo()[] arrays are empty
<vasild>
I cant see how nodes[] could be empty, so it must be the getpeerinfo()[] array and if that is empty it means no peers are connected at the timem it executes
salvatoshi has joined #bitcoin-core-dev
<vasild>
what about waiting for the array to become non-empty?
<vasild>
that is to change `wait_until(lambda : "sendtxrcncl" in self.nodes[0].getpeerinfo()[-1]...` to something like `wait_until(lambda : peerinfo = self.nodes[0].getpeerinfo(); return len(peerinfo) > 0 && "sendtxrcncl" in peerinfo[-1]...`
<vasild>
this would fix it if the problem is that this wait runs too early before anybody has connected, but if the problem is elsewhere it will probably timeout after 60 secs
<gleb07122>
I think your explanation helps, thank you!
erwanor_ has quit [Read error: Connection reset by peer]
mjdietzx__ has quit [Read error: Connection reset by peer]
glozow has quit [Ping timeout: 246 seconds]
erwanor_ has joined #bitcoin-core-dev
lightlike has quit [Ping timeout: 246 seconds]
FelixWeis has quit [Read error: Connection reset by peer]
ajonas has quit [Read error: Connection reset by peer]
hugohn__ has quit [Read error: Connection reset by peer]
dergoegge has quit [Read error: Connection reset by peer]
stickies-v has quit [Read error: Connection reset by peer]
fanquake has quit [Read error: Connection reset by peer]
GoldmanSats_ has quit [Read error: Connection reset by peer]
hsmiths has quit [Read error: Connection reset by peer]
hugohn__ has joined #bitcoin-core-dev
lightlike has joined #bitcoin-core-dev
hendi has quit [Ping timeout: 260 seconds]
stickies-v has joined #bitcoin-core-dev
arik has quit [Read error: Connection reset by peer]
real_or_random has quit [Read error: Connection reset by peer]
jarolrod has quit [Read error: Connection reset by peer]
mjdietzx__ has joined #bitcoin-core-dev
rodarmor has quit [Read error: Connection reset by peer]
amiti_ has quit [Read error: Connection reset by peer]
elichai2 has quit [Read error: Connection reset by peer]
sebx2a has quit [Read error: Connection reset by peer]
rodarmor has joined #bitcoin-core-dev
elichai2 has joined #bitcoin-core-dev
GoldmanSats_ has joined #bitcoin-core-dev
dergoegge has joined #bitcoin-core-dev
arik has joined #bitcoin-core-dev
noxim_ has quit [Ping timeout: 260 seconds]
jarolrod has joined #bitcoin-core-dev
real_or_random has joined #bitcoin-core-dev
glozow has joined #bitcoin-core-dev
FelixWeis has joined #bitcoin-core-dev
amiti_ has joined #bitcoin-core-dev
fanquake has joined #bitcoin-core-dev
hsmiths has joined #bitcoin-core-dev
ajonas has joined #bitcoin-core-dev
sebx2a has joined #bitcoin-core-dev
glozow has quit [Changing host]
glozow has joined #bitcoin-core-dev
hendi has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
<vasild>
yw :)
gleb07122 has quit [Ping timeout: 248 seconds]
steve_ has joined #bitcoin-core-dev
bitdex has quit [Ping timeout: 255 seconds]
bitdex has joined #bitcoin-core-dev
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
fanquake has quit [Ping timeout: 260 seconds]
fanquake has joined #bitcoin-core-dev
dougefish has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Remote host closed the connection]
dougefish has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
_andrewtoth_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
gleb07122 has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 252 seconds]
Flow has quit [Quit: WeeChat 3.5]
Flow has joined #bitcoin-core-dev
sudoforge has joined #bitcoin-core-dev
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
jonatack2 has quit [Ping timeout: 248 seconds]
NorrinRadd has joined #bitcoin-core-dev
hg has joined #bitcoin-core-dev
Nick79 has joined #bitcoin-core-dev
Nick79 has quit [Client Quit]
salvatoshi has quit [Ping timeout: 246 seconds]
noxim has quit [Ping timeout: 252 seconds]
<fanquake>
* [new tag] v23.1rc1 -> v23.1rc1
salvatoshi has joined #bitcoin-core-dev
test_ is now known as _flood
<luke-jr>
_aj_: sounds reasonable
merlinB has joined #bitcoin-core-dev
yanmaani2 has quit [Ping timeout: 255 seconds]
yanmaani2 has joined #bitcoin-core-dev
nickler has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
gleb071225 has joined #bitcoin-core-dev
steve_ has quit [Quit: Leaving]
gleb07122 has quit [Ping timeout: 260 seconds]
Guest61 has joined #bitcoin-core-dev
Guest61 has quit [Client Quit]
Aaronvan_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 260 seconds]
salvatoshi has quit [Ping timeout: 252 seconds]
hg has quit [Read error: Connection reset by peer]
hg has joined #bitcoin-core-dev
noxim has quit [Ping timeout: 248 seconds]
merlinB has quit [Quit: Leaving...]
Talkless has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
noxim has quit [Ping timeout: 260 seconds]
tripleslash has joined #bitcoin-core-dev
<sugarpuff>
@sipa "If you want to cancel a transaction, you can pre-sign a double-spend of it." <- Does that work now? Is it enforced by all miners? If so this is the first time I'm hearing of it, and I bet it's the first time most people are hearing about it because I've never seen it implemented in any wallet, and I've never seen it mentioned in any article. Seems important.
<sugarpuff>
@sipa "transactions can randomly become invalid if they're mined close to their expiration." <- So what? Isn't this true of regular transactions too? Couldn't they be re-org'd out and not appear in the re-org'd block?
<sipa>
@sugarpuff That has always worked.
<sipa>
Since opt-in RBF.
<sugarpuff>
sipa: Why does no wallet support it?? Why is it never mentioned in any article on stuck transactions??
<sipa>
Usually the way to unstuck a transaction is to make it go through, not cancel it.
<sugarpuff>
the subsequent RBF txn might not go through either, and someone might decide they don't want to pay higher fees, or CPFP might not be supported
<sugarpuff>
Saying "RBF/CPFP is the only way to fix this" also creates an arms race in fees
<sugarpuff>
unnecessarily inflating them when someone might decide they'd prefer to cancel and try again at a later date
<sipa>
Right now there is no reason to assume a reorged transaction wouldn't end up accepted in the other chain too (assuming it wasn't double spent), because valid transactions always remain valid.
<sipa>
The complexity of reasoning about mempool transactions and recently confirmed ones is far worse for everybody is transactions can revert to being invalid.
<sugarpuff>
only if they're assuming 1-conf is something to be relied upon
<sugarpuff>
and again, normal transactions can be not included in a re-org'd block, right?
<sipa>
reorgs of more than 1 deep are also a problem
<sugarpuff>
this is a problem for regular txns too, right? they can not appear in a re-org'd block in certain situations, true?
<sipa>
and that's not the only issue .. e.g. do you relay a transaction close to its expiration, because our DoS protection relies on the assumption that something relayed is eligible for confirmation, and thus pays a nontrivial fee
noxim has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
<sugarpuff>
sure, relay something unless it's expired. that might even reduce pressure on DoS, right? since fewer transactions would be relayed, theoretically
<sipa>
this gets even worse when taking cpfp and other dependencies into account... as now you need transitive reasoning as children may become invalid as their unconfirmed parent expires
<sipa>
The same issues exist around mempool replacement... a transaction close to expiration is unlikely to be mined, and should therefore probably not be considered for replacing another transaction
<sipa>
but where do you out the threshold
<sugarpuff>
what about this question: "they can not appear in a re-org'd block in certain situations, true?" (referring to normal txns)
<sugarpuff>
("normal" i.e. without expiry)
<sipa>
What are "they" ?
<sugarpuff>
today's txns without expiry
<sugarpuff>
today's txns without expiry built into them
<sipa>
Well, yes, they could be double-spent, or the fee market after the reorg could be so radically different that miners don't pick it up.
noxim has quit [Ping timeout: 248 seconds]
<sugarpuff>
ok, so the concern you brought up earlier, of txns not being included in re-org'd blocks due to close expiry, also applies to today's non-expiring txns...
<sipa>
I don't think that's comparable.
<sugarpuff>
why not?
<sipa>
Sure, there is no guarantee that a tx after a reorg still makes it in.
<sipa>
But there is a big difference between no guarantee, and a prohibition.
sipsorcery has joined #bitcoin-core-dev
<sugarpuff>
but that is the entire point of adding an expiry - is to give users a guarantee
<sugarpuff>
they will be relieved to know that their bitcoins will be back by a certain time, or spent
<sugarpuff>
right now they will be panicking
<sipa>
It cuts both ways. I don't think this helps.
<sugarpuff>
i honestly don't see the downside
<sipa>
With expiry it's also possible that in a reorg the timestamps are lower, and thus an expired transaction becomes valid again.
<sugarpuff>
but what is the margin on this? like less than 10 min right?
<sipa>
To me, monotonicity of tx validity is such a fundamental principle underlying bitcoin, that I'd need a very good reason to even consider acking it.
<sugarpuff>
compare to the current situation: a margin or *days* not knowing whether or not your txn will be confirmed
<sipa>
And I don't think it fixes anything
<sugarpuff>
how does being given a guarantee by which time your txn will be spent or returned not fix anything? How is not knowing what happens to your coins for *weeks* a good thing?
<sipa>
You can fee bump it.
<sipa>
Many wallets today support that.
<sugarpuff>
but what if the fees are like $100???
<sugarpuff>
or more??
<sugarpuff>
what if you bought a toy for $20, and the fees are $200???
Hercules has joined #bitcoin-core-dev
<sipa>
If the tx drops out of your mempool, you can abandon it and spend the funds again later.
<sipa>
If the current fee market is so much higher than what you paid, there's no reason to assume your transaction will be included.
<sugarpuff>
so you decide to "spend the funds again later", and wait for them to return, and make decisions on the assumption that you'll be able to spend them later (whatever those decisions might be, who knows), and then after 10 days your txn confirms and your funds are gone. Now what?
<sugarpuff>
How is that a good user experience?
<sugarpuff>
If the txn had an expiry you could reason about this situation. But it doesn't
<sugarpuff>
This has to do with hard forks doesn't it?
<sugarpuff>
is adding an expiry a hard fork?
<sipa>
You can sign an RBF with higher feerate to send back to yourself too. It doesn't even need to match the current market feerate at the time of spending, just beat the transaction being replaced.
<sipa>
Either neither makes it in, or the replacement makes it in.
<sipa>
No, that can easily be done with a softfork
<sugarpuff>
but the RBF txn isn't guaranteed to go through, and the fees might be so high that you decide you don't want to pay them. so you end up deciding to just not deal with it, and not know the fate of your txn. This is frustrating to both businesses and customers and users. IMO, it should be fixed and can be easily fixed with an expiry. I'm glad to hear it's not a hard fork. even the base unit of the Internet (packets) have a
<sugarpuff>
TTL
<sugarpuff>
DNS records have a TTL... txns should too
<sipa>
Sorry, I don't find this a convincing argument
<sugarpuff>
ok, well, maybe when enough people complain you'll change your mind. i tried *shrug*
<sipa>
You don't need to convince me, thankfully.
notmandatory_ has joined #bitcoin-core-dev
<sugarpuff>
sipa: oh, one more thing, sorry I didn't realize this. You keep saying that RBF is the solution to this, but even that isn't completely true AFAIK since RBF isn't enabled by default on txns, right? So for a large number of users they literally have zero recourse right now
meshcollider has quit [Ping timeout: 246 seconds]
bohruz[m] has quit [Ping timeout: 246 seconds]
notmandatory has quit [Ping timeout: 246 seconds]
arturomf94[m] has quit [Ping timeout: 246 seconds]
kakolainen[m] has quit [Ping timeout: 246 seconds]
provoostenator has quit [Ping timeout: 246 seconds]
bitcoin-git has quit [Ping timeout: 246 seconds]
jetpack has quit [Ping timeout: 246 seconds]
BlueMatt[m] has quit [Ping timeout: 246 seconds]
harding has quit [Ping timeout: 246 seconds]
harding has joined #bitcoin-core-dev
jetpack_ has joined #bitcoin-core-dev
bohruz[m] has joined #bitcoin-core-dev
meshcollider has joined #bitcoin-core-dev
arturomf94[m] has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
provoostenator has joined #bitcoin-core-dev
kakolainen[m] has joined #bitcoin-core-dev
BlueMatt[m] has joined #bitcoin-core-dev
Hercules has quit [Quit: Leaving]
gnaf has joined #bitcoin-core-dev
hg has quit [Ping timeout: 260 seconds]
hg has joined #bitcoin-core-dev
champo has joined #bitcoin-core-dev
Talkless has quit [Ping timeout: 260 seconds]
champo has quit [Ping timeout: 260 seconds]
Guest6281 has joined #bitcoin-core-dev
champo has joined #bitcoin-core-dev
yanmaani2 has quit [Remote host closed the connection]
yanmaani2 has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
champo has quit [Ping timeout: 260 seconds]
noxim has quit [Ping timeout: 260 seconds]
Guest7 has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
noxim has quit [Ping timeout: 260 seconds]
champo has joined #bitcoin-core-dev
noxim has joined #bitcoin-core-dev
noxim has quit [Changing host]
noxim has joined #bitcoin-core-dev
noxim has quit [Ping timeout: 260 seconds]
champo has quit [Quit: Client closed]
jarthur has quit [Quit: jarthur]
kexkey_ has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 260 seconds]
hg has quit [Quit: WeeChat 3.7.1]
jonatack2 has joined #bitcoin-core-dev
gnaf has quit [Quit: Konversation terminated!]
jonatack3 has joined #bitcoin-core-dev
jonatack2 has quit [Ping timeout: 248 seconds]
jonatack has joined #bitcoin-core-dev
jonatack3 has quit [Ping timeout: 246 seconds]
<bitcoin-git>
[bitcoin] achow101 opened pull request #26467: bumpfee: Allow the user to choose which output is change (master...bumpfee-choose-change-txout) https://github.com/bitcoin/bitcoin/pull/26467
jonatack has quit [Read error: Connection reset by peer]