< bitcoin-git>
[bitcoin] sipsorcery opened pull request #16505: Changes verbosity of msbuild from quiet to normal in the appveyor script (master...appveyor_verbosity) https://github.com/bitcoin/bitcoin/pull/16505
< bitcoin-git>
bitcoin/master 0646ca5 Aaron Clauson: Changes the verbosity of msbuild from quiet to normal in the appveyor scri...
< bitcoin-git>
bitcoin/master f891136 MarcoFalke: Merge #16505: Changes verbosity of msbuild from quiet to normal in the app...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16505: Changes verbosity of msbuild from quiet to normal in the appveyor script (master...appveyor_verbosity) https://github.com/bitcoin/bitcoin/pull/16505
< bitcoin-git>
bitcoin/master 73b692b João Barbosa: doc: Add release note for the deprecated totalFee option of bumpfee
< bitcoin-git>
bitcoin/master 3f288a1 MarcoFalke: Merge #16504: doc: Add release note for the deprecated totalFee option of ...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16504: doc: Add release note for the deprecated totalFee option of bumpfee (master...2019-07-release-notes-15996) https://github.com/bitcoin/bitcoin/pull/16504
< sdaftuar>
phantomcircuit: regarding the bip 30 optimization
< sdaftuar>
it’s important to enforce bip30 on potential “alternate” chains, because if there is a utxo “overwrite” from a duplicate transaction, then the utxo set will be potentially incorrect when reorging from that chain to some other chain (eg because you’ll have removed an entry from the utxo set that should still be there, if you’d never connected the block that overwrote the transaction in
< sdaftuar>
the first place).
< sdaftuar>
on the bitcoin main chain, this is not actually a problem (modulo the hypothetical future problem we can have after block 1.9M or whatever it is)
< sdaftuar>
Anyway this would be a simple fix to your PR — just ensure that you only skip the bip30 checks if assume valid is set and the assume valid block hash builds on the known bip34 activation block hash; that would ensure that we only skip the bip30 checks on blocks we know to be safe from this issue
< sdaftuar>
but as i mentioned on the pr, i don’t think it’s worth making any changes for a 22 second speedup during IBD.
< jnewbery_>
laanwj MarcoFalke: if you're in a merging mood, then I think #16452 is good to go
< dongcarl>
wumpus: How should addrv2 clients handle ::FFFF:0:0/96 IPv4-mapped addresses?
< dongcarl>
More specifically, 1. Should they be accepted (I think yes) 2. Should they be internally parsed into IPv4 addresses, or stay internally as IPv6 addresses that still return true for `IsIPv4()`?
< bitcoin-git>
bitcoin/master 9bc8b28 Antoine Riard: refactor : use RelayTransaction in BroadcastTransaction utility
< bitcoin-git>
bitcoin/master 7821821 MarcoFalke: Merge #16452: refactor: use RelayTransaction in BroadcastTransaction utili...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16452: refactor: use RelayTransaction in BroadcastTransaction utility (master...2019-07-reuse-relay-tx) https://github.com/bitcoin/bitcoin/pull/16452
< sdaftuar>
phantomcircuit: really, assumevalid has nothing to do with the optimization -- it'd be enough to check to see if a block is an ancestor of the known-bip34-activation blockhash, and if so, skip the check. i think. but this is all so complicated that i think it's best not to risk changes here...
< phantomcircuit>
sdaftuar, my principle motivation was to make measuring leveldb calls vs dbcache size easier
< phantomcircuit>
i just thought it was a nice optimization as well
< phantomcircuit>
but yeah i hadn't considered that it would erase a utxo entry that wouldn't be restored by the undo blocks
< elichai2>
should I impose the lex ordering over the tapdescriptor? meaning. should I fail a desc because it wasn't ordered correctly? on one hand this means it's really hard to constructe desc by hand(if that's even a thing?) on the other if we don't have this than there's no longer 1-1 mapping (multiple desc ordered differently will result in the same scriptPubKey)
< sipa>
elichai2: good question
< wumpus>
dongcarl: that's a good point, i think it should reject (ignore) them, addrv2 has its own way of sending IPv4 addresses that should be used
< wumpus>
dongcarl: for Tor I do specify this explictly in the BIP"
< wumpus>
dongcarl: e.g. " Clients SHOULD ignore OnionCat (<code>fd87:d87e:eb43::/48</code>) addresses on receive if they come with the <code>IPV6</code> network ID."
< wumpus>
dongcarl: should probably add the same for IPv4 addresses encoded as IPv6
< sipa>
wumpus: that makes sense
< dongcarl>
that sounds good :-)
< bitcoin-git>
[bitcoin] instagibbs closed pull request #16500: GetFee should round up to avoid undershooting feerate (master...fix_filter_mempool_mistmatch) https://github.com/bitcoin/bitcoin/pull/16500
< sipa>
elichai2: it's kind of annoying for human construction if the branches need to be well-ordered (which is effectively random)
< sipa>
elichai2: on the other hand, inferring a descriptor from comtext information will only possibly find one order
< sipa>
so... i don't know
< elichai2>
sipa: hmm generally the inferring isn't a fun problem. but it actually makes it a little bit simpler if you don't care about the order. you can compare paths to identify siblings
< elichai2>
(so siblings are gonna have the same script path except the last part(which will be the hash of each other), you can then combine them together to a new "script path" as a node, remove the last part of the path and find they're sibling. that way you reconstructe from the bottom up without verifying order)
< sipa>
sure, you can compare things in multiple ways
< sipa>
i'm just wondering if the inconvenience of forcing an essentially random (and hard for humans to create) order weighs up against the added variance in descriptors (which will be wiped out by canonicalizing/infering)
< sipa>
i think we should permit both orders
< sipa>
there are already non-canonical things in descriptors
< elichai2>
sipa: are there any non-canonical things *withou* addr and raw?
< sipa>
elichai2: the h vs ' for hardened paths
< elichai2>
(altough parsing a raw descriptor and then infering back the scriptPubKey might end you up with a different desc then the one you started with)
< elichai2>
right
< sipa>
yeah
< emilengler>
Hi, how can I detect in the qt debug window if the console tab is open? Is there a function which returns a bool for it or something similar?
< wumpus>
emilengler: though usually you shouldn't need to worry what tab is open
< emilengler>
wumpus: Well how does bitcoin-qt then detects when Ctrl+L is pressed? It only works when the console tab is open
< wumpus>
I suppose it only works when the console's input widget is selected
< wumpus>
that's kind of the idea, to use qt's event propagation, it's very rare that you need to go outside that
< emilengler>
The console also clears wiht Ctrl+L if the textbox isn't selected if this is what you've meant
< wumpus>
<property name="shortcut">
< wumpus>
<string notr="true">Ctrl+L</string>
< wumpus>
</property>
< wumpus>
looks like the clearButton has that as shortcut
< wumpus>
I *think* a button will only trigger if it is visible
< wumpus>
so that explains it
< emilengler>
Oh interesting this explains a lot... I searched exactly for this for so long haha
< bitcoin-git>
[bitcoin] instagibbs opened pull request #16507: feefilter: Compute the absolute fee rather than stored rate (master...feefilter_match_mempool) https://github.com/bitcoin/bitcoin/pull/16507
< bitcoin-git>
[bitcoin] hebasto opened pull request #16508: Use ArgsManager::ALLOW_BOOL flag explicitly (master...20190731-allow-bool) https://github.com/bitcoin/bitcoin/pull/16508
< jonatack>
emilengler: git grep Ctrl+L (git grep is your friend :)...)
< emilengler>
jonatack: Well I tried the Unix grep but I searched for "Qt::CTRL" and "Qt::Key_L" I thought it was using a QShortcut or something similar
< phantomcircuit>
sdaftuar, actually would that be right either? is it true we can't reorg backwards past an overwritten utxo entry?
< sdaftuar>
phantomcircuit: if you reorg past an overwritten utxo, then your utxo state is incorrect/different from if you never connected the block that did the overwrite
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16509: test: Adapt test framework for chains other than "regtest" (master...1908-testChainName) https://github.com/bitcoin/bitcoin/pull/16509
< emilengler>
When I call QTabWidget::widget where can I get the index in rpcconsole.cpp?
< phantomcircuit>
hmm i was thinking we could drop the leveldb bloomfilter if the bip30 checks aren't running but actually that makes bogus transactions sent to us much more expensive to handle
< phantomcircuit>
currently mostly that's just cpu and bandwidth used, but without the bloomfilters it's potentially also disk access
< phantomcircuit>
and that type of transaction, missing utxo can't result in a peer being banned so it's an actual issue
< BlueMatt>
#proposedmeetingtopic is transaction.nVersion signed or unsigned?
< BlueMatt>
dongcarl: ^ gets to handle that one :)
< emilengler>
promag: I'm trying to check if the user is in a specific tab
< promag>
why?
< emilengler>
Because I want to add a shortcut which should only work in a specifc tab in the debug window
< emilengler>
In the console to be correct
< emilengler>
In bitcoin-qt
< sipa>
a shortcut to do what?
< emilengler>
I want to add a shortcut to close the debug window when the user is in the console
< emilengler>
Ctrl+D
< emilengler>
Like in any other terminal :P
< promag>
you mean close the dialog?
< sipa>
is there a close button?
< promag>
ESC closes (at least on mac)
< emilengler>
Yes esc closes
< sipa>
emilengler: that seems confusing; to anyone not familiar with a unix console that wouldn't be natural, while every OS probably has its native keybinding already to close windows
< emilengler>
I'm thinking of adding a Ctrl+D beside the esc
< emilengler>
I always get confused for a second or so if I press Ctrl+D and nothing happens
< emilengler>
So I thought it would be a good addition
< sipa>
(feel free to ignore my comments, i never use the UI)
< luke-jr>
well, Ctrl-D is EOF, not "close window"
< * luke-jr>
wonders what happens if you Ctrl-D in a cmd.exe window
< luke-jr>
emilengler: if you do add it, it probably should only work if the text entry has focus specifically
< sipa>
i guess Ctrl-J and Ctrl-M should also newline then
< promag>
emilengler: even if your idea is accepted it won't have the same behavior
< emilengler>
But the most common control-chars are Ctrl+D and Ctrl+L (at least in my case)
< emilengler>
promag: Why because it won't use a key event or because it wont send an EOF?
< emilengler>
QKeyEvent
< sipa>
emilengler: L = 12th position in alphabet, Ctrl-L = ASCII 12 = form feed = clear page
< sipa>
emilengler: D = 4th position in alphabet, Ctrl-D = ASCII 4 = end of transmission
< sipa>
emilengler: J = 10th position in alphabet, Ctrl-D = ASCII 10 = new line
< sipa>
eh, Ctrl-J
< emilengler>
sipa: thank you this explains a lot of stuff but Ctrl+L does not transmit this singal IIRC
< promag>
emilengler: because you can't "terminate" the bitcoin-qt terminal
< sipa>
emilengler: i don't know what you mean
< promag>
emilengler: you would just hide/close the dialog
< emilengler>
promag: But you can close the window the idea was a "synonym" for the esc
< promag>
I'm sure you can find other stuff to improve on the gui
< emilengler>
You might be right :) but when we already have Ctrl+L why not Ctrl+D then
< promag>
feel free to submit the PR, I just think that on the gui ESC is more natural, people are used to close dialogs with ESC
< sipa>
emilengler: can't you add a shortcut to a button in Qt? if so, that should be enough
< sipa>
without trying to infer what tab you're on
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #16513: Switch CTransaction::nVersion to an unsigned integer (master...2019-07-unsigned-tx-ver) https://github.com/bitcoin/bitcoin/pull/16513
< emilengler>
promag: Sure but for people who are there whole day in terminal emulators Ctrl+D is more natural I think
< emilengler>
sipa: Sure but there is no close button in the qt gui
< emilengler>
Only the window manager close button
< sipa>
yeah ok
< sipa>
and adding one would be redundant
< promag>
not sure if it would work but try adding a QAction with the respective shortcut to the tab
< emilengler>
promag: Already read that something like this is possible but tbh I'm a bloody beginner in Qt. I'm completely unable to design something that's why I always stick to cli programming
< tryphe>
emilengler, i've been using Qt for 20 years and i still prefer cli :p
< emilengler>
tryphe: You may love or may hate gui design there is nothing inbetween
< tryphe>
emilengler, to me, a cli is somewhere between having a gui and no interface, where later on you'd just build the gui on the same interface the cli uses
< emilengler>
tryphe: It depends what do you mean by cli something like an interactive shell (like the openbsd installer), a curses(-like) application or just a program which you start with some args and prints log infos in the console
< tryphe>
emilengler, yes, all of those
< emilengler>
tryphe: Same in my definition a cli application is everything which displays text in a console
< bitcoin-git>
[bitcoin] promag opened pull request #16515: gui: Close console with CTRL+D ala terminal (master...2019-07-console-ctrld) https://github.com/bitcoin/bitcoin/pull/16515
< promag>
emilengler: I can add you as co author if you like, or if you prefer you can pick that commit, re-work it and submit another pr (I'll close mine in that case)