< cfields>
wumpus: ping. around? we're hanging out around a conference table in hk. anything that may be helpful to discuss?
< wumpus>
dunno
< cfields>
ok, no worries
< wumpus>
for 0.13 I think we should look into deprecating the external comparison tool, as we have a similar framework in-tree now (thanks to sdaftuar), which is easier to update along with code changes. But it's not clear to me what tests still have to be transferred to the new framework.
< wumpus>
gmaxwell: the ping-interferes-with-transaction-relay issue should definitely be solved, we want #7125 for 0.12 then
< gmaxwell>
wumpus: I think so.
< gmaxwell>
when we were in the merge flurry for 0.12 pieter asked me privately if that attack was widely going on and I said I didn't know; but since this was logically a bugfix we didn't need to rush at that moment.
< dcousens>
out of interest, why do we have compat/endian ?
< dcousens>
Isn't that in most stdlibs?
< dcousens>
ah, its Linux only aye
< dcousens>
nvm
< wumpus>
dcousens: the reason we have most compat stuff is for non-POSIX OSes
< wumpus>
(which in practice amounts to "just windows" these days, all others at least put up a veneer of POSIXism)
< dcousens>
those bastards, lol, yeah no worries, jsut wanted to quickly compile something and realised I had to put include "config/bitcoin-config.h" in a bunch of files just to stop it exploding
< wumpus>
gmaxwell: yes actually seeing the attack changes things, makes me wonder what other sneaky things are going on, adding these kind of traffic statistics to the P2P layer has turned out very useful
< gmaxwell>
I've observed it before; just from logging all network traffic. "I see the matrix" ... but the stats are helpful.
< wumpus>
yes that can certainly be useful, I had a set of hacks to just log traffic from certain suspicious nodes for a while, though it's also easy to miss the forest for the trees when looking at detailed logging output
< Luke-Jr>
wumpus: speaking of the external comparison tool, I can't get it to pass on 0.11 :/
< GitHub113>
bitcoin/master a3c3ddb Jonas Schnelli: [Qt] add InMempool() info to transaction details
< GitHub113>
bitcoin/master 00b4b8d Wladimir J. van der Laan: Merge pull request #7154...
< GitHub51>
[bitcoin] laanwj closed pull request #7154: [Qt] add InMempool() info to transaction details (master...2015/12/qt_conflicts) https://github.com/bitcoin/bitcoin/pull/7154
< gmaxwell>
Luke-Jr: there have been webpages that do that... :(
< gmaxwell>
we should probably log the relevant settings in the wallet.
< jonasschnelli_>
Maybe my lol was inappropriate (I thought he is using a different wallet (Nucleul Bitcoin versiunea v0.11.0 (32-bit)), but looks like core. Could be that the user really face an issue/bug.
< phantomcircuit>
jonasschnelli_, it seems likely that he adjusted the relay fee
< phantomcircuit>
and he's basically screwed without RBF
< wumpus>
jonasschnelli_: hehe in Dutch it's called "Bitcoin Kern"
< MarcoFalke>
Should I encourage to double spen?
< jonasschnelli_>
phantomcircuit: zapwallettxes is probably his best friend now
< wumpus>
which has the same meaning as 'Nucleul'
< jonasschnelli_>
Why do we translate "core"... Hah
< wumpus>
zapwallettxes would be the first step
< jonasschnelli_>
nucleul sounded after a reasonable Bitcoin wallet name...:-)
< wumpus>
then if possible spend one of the inputs to yourself
< MarcoFalke>
An update to 0.11.2 should be sufficient
< wumpus>
(to make sure it doesn't go through at some point in the future)
< * jonasschnelli_>
needs to check the GUI state when smartfees are not available because of not enough blocks
< MarcoFalke>
command line is a pain in windows, not sure if the user wants to go through this
< MarcoFalke>
an update can hurt anyway
< phantomcircuit>
wumpus, it's probably not safe to tell him to do that...
< wumpus>
would be great to have a RPC to nuke a single transaction from the wallet
< jonasschnelli_>
wumpus: agree
< wumpus>
instead of this zapwallettx which, admittedly, is kind of scary
< phantomcircuit>
it's what the software should do but is unlikely something he can do manually
< jonasschnelli_>
archivetransaction
< wumpus>
MarcoFalke: upgrade can't hurt.
< MarcoFalke>
*can't
< MarcoFalke>
right
< wumpus>
jonasschnelli_: yeah, possibly, translating the name of the software is not a good idea. Then again, it's what has already happened, suddenly reverting it would be even more confusing to foreign users
< Luke-Jr>
let's rename to Nucleul Bitcoin in all languages. it sounds nicer.
< wumpus>
it does :)
< GitHub35>
[bitcoin] luke-jr opened pull request #7192: Unify product name to as few places as possible without major changes (master...single_prodname) https://github.com/bitcoin/bitcoin/pull/7192
< jonasschnelli_>
<Luke-Jr>[11:56:41] let's rename to Nucleul Bitcoin in all languages. it sounds nicer.: <-- haha
< MarcoFalke>
+1 ;)
< phantomcircuit>
wumpus, it's potentially more confusing in the short term, but long term it's got to be more confusing to have different names
< morcos>
wumpus: close your ears
< morcos>
so i think there was a slight regression in 6898 that i hadn't quite thought about
< morcos>
i was under the assumption that there had to be a bug in the code for an invalid block to be assembled (but still fail TBV)
< morcos>
however, if someone runs with policy that is looser than a soft fork that is about to activate, and then that soft fork activates
< morcos>
we're not checking those txs against what is now the new consensus rules in assembly
< morcos>
ok, so i take that back, its not a regression, but its still a problem
< morcos>
the old code is also unaware of soft forks that have activated when assembling a block
< morcos>
maybe this is a known problem
< morcos>
but means if you're running with policy looser than activated or soon to be activated soft forks, you will assemble blocks which would fail those soft forks. this would be caught in TestBlockValidity
< morcos>
maybe i need to go look at the versionbits implementation
< morcos>
seems like there has to be a better way to do this
< morcos>
CodeShark: ping?
< CodeShark>
Hey, morcos
< CodeShark>
What's up?
< morcos>
I want to versionbits do I look at just 6816 or all 3 pulls?
< morcos>
to review that is
< CodeShark>
are you referring to 6774 and 6747?
< morcos>
ha, thats what i'm asking
< morcos>
i saw you have 3 PR's open, i see now 6747 builds on 6774
< morcos>
how does 6816 fit in with 6747?
< morcos>
where is review wanted?
< CodeShark>
6816
< morcos>
also i want to understand the implementation to think about the changes i'm making to BIP 68 implementation
< CodeShark>
what are you changing?
< morcos>
In BIP 68 I'm proposing to change the implementation to break out sequence checks from locktime checks (see 7184). Also changing the semantics to use MTP always for sequence checks.
< morcos>
Just up in the history, I'm worried about maintaining mempool consistency after a soft fork activates. Motivated by the way I'm implementing BIP 68, but a concern for any soft fork
< CodeShark>
I'll take a look at 7184
< morcos>
sure, thx, mostly i just wanted to know what to look at to review versionbits to think about the problem i discuss in the scrollback. mostly independent from 7184, just motivated by it.
< morcos>
CodeShark: It looks to me from reading the code that a bit can't be used again until the expire time even if the soft fork activated. But I thought from BIP and discussion that it could be used after the activation delay.