< murch>
Does signaling start with the epoch time listed in the Deployment on BIP141 or with the first difficulty retarget after the epoch time listed in deployment?
< murch>
Nevermind, reading BIP0009 now. :p
< murch>
Answer is only with the next retarget, if anyone is interested. ;)
< sipa>
murch: indeed :)
< murch>
sipa: So, did you have a chance to take a glimpse at my thesis? :)
< sipa>
murch: i haven't
< murch>
Ah, I'm really curious what you'll think.
< murch>
(if you have time)
< phantomcircuit>
wumpus: can you take another look at #8831 ?
< GitHub47>
[bitcoin] rebroad opened pull request #9082: Fix peer selection so that non-Witness peers are still connected to (master...FixPeerSelection) https://github.com/bitcoin/bitcoin/pull/9082
< rebroad>
gmaxwell, in response to your comment to #9061 - it's already ignoring getheaders - this pull make it ignore less of them
< rebroad>
wumpus, gmaxwell, just want to say thank you for all the hard work you do on bitcoin-core and apologies that I sometimes facilitate a perception of distraction from the more important duties... certainly not my intention. and apologies for the paranoia I sometimes exhibit.. I just find it so hard to understand some of your decisions but I realise you feel you have too little time to explain them fully, so it's ok
< rebroad>
I do sometimes wonder how much egos come into the weird dynamics I perceive on github, with various maintainers accusing people of trolling, when they are just trying to be constructive... I think the term "trolling" is used a little too much in general and is, IMHO, a rather unnecessary "bad faith assumption", and I would quite like to see some better standards of ettiquette if possible for github, etc
< rebroad>
but i realise we're all only human so maybe I'm setting my standards too high given the design limitation of the human race :)
< rebroad>
I just want to see bitcoin do well. I certainly don't want to see anyone burn out.. i'd rather see more collaboration rather than empire building
< Victorsueca>
rebroad: never seen "empire building" on core
< rebroad>
i think some of the recent exchanges between lead deveopers between classic and core for example are all rather silly with egos getting in the way of potential collaboration which could be awesome
< rebroad>
Victorsueca, wasn't referring specifically to core regarding that statement
< Victorsueca>
ahh, makes more sense then
< rebroad>
i just see too much competition.. e.g. core, classic, zcash... I think if forces were combined better (and outsiders accepted more readily) that something better could exist.
< rebroad>
anyway, I'll get off my soapbox now
< rebroad>
It does seem that some people are stressed... I'm not quite sure why or what's behind this. I do sometimes wonder if there are things going on in a covert attempt to sabotage the project. I'm a little concerned about the current stress levels I perceive... then again, I could also get a little less stressed when my contributions are dismissed so rapidly..!
< Victorsueca>
actually nobody cares about classic or zcash, there's no competition at all because reasonable people just ignores them, they will eventually die like all other attempts to compete with bitcoin did so nothing to worry about and nothing we can do about
< rebroad>
I guess it's hard to be enthused without being attached (in the buddhist sense)
< rebroad>
Victorsueca, I hope you are right... although I do get the impression that zcash has some quite clever technology in it... but why ddn't they help put this into bitcoin instead of an alt-coin... well.. I think I already know the answer to this... greed
< rebroad>
anyway.. all a little OT for this channel perhaps
< gmaxwell>
Speculating about that kind of stuff does no one any good. All you'll do is make yourself a target of the currency speculators that are invested in that system. Not worth your time.
< jouke>
In wallet.cpp on line 2565 I see a transaction is added to wallet, but only fails at 2582, but since it's in the wallet it get's rebroadcasted right? (which I see happening in debug log).
< gmaxwell>
jouke: if its acceptable to the memory pool ater, then I believe so...
< gmaxwell>
I think thats a little obnoxious, looks like it could cause the rpc to return an error but still have the txn go out. (though at least it whould show in listtransactions in the meantime)
< jouke>
That's excactly what's happening now
< gmaxwell>
would*
< gmaxwell>
How did you manage to construct a txn that wasn't acceptable to the mempool at the time of construction? that in and of itself is a bug.
< sipa>
indeed
< jouke>
gmaxwell: just using bitcoin core 12.0
< sipa>
i believe the source code has a "this should never happen" comment in that place
< jouke>
sipa: indeed
< jouke>
It's a big wallet
< gmaxwell>
hm. we have had bugs in the past where it could happen.
< sipa>
ah, 0.12 may have had some issue there - it had just introduced the mempool limiting, and not adapted some of the wallet code to deal with that
< gmaxwell>
and a lot of wallet things were fixed since 0.12.0
< gmaxwell>
not a very satisifying answer.
< jouke>
sipa: ah, right
< jouke>
Hmm, mempool bytes is at 10% of maxmempool
< jouke>
These was also a commit ten days ago that would provide more information about this happening.
<@wumpus>
jonasschnelli: I have no clue, haven't seen that error anywhere else, looks like a header file wasn't committed or not added to the makefile (so it doesn't get packaged0
< jonasschnelli>
It's not in the Makefile.test.include
< jonasschnelli>
But so are the other headers IMO
<@wumpus>
that could be the reason, though travis would crash on that too
< jonasschnelli>
hmm...
< timothy>
hi, which is the "reference" platform for bitcoin-core on linux? aka which distro and version is used with gitian to build it?
< jonasschnelli>
timothy: Expect of libc/c++, everything is linkes statically. You should be capable of using those binaries on (almost) all linux platforms.
< jonasschnelli>
timothy: It's built on Ubuntu trusty
< jonasschnelli>
but portable
< timothy>
not so portable since it can't work under alpine linux (mostly used for docker) :P I'll use ubuntu:trusty
< jonasschnelli>
timothy: what error you get when running on alpine?
< timothy>
alpine uses musl
< timothy>
so no glibc
< jonasschnelli>
Yes. That won't work.
< jonasschnelli>
Compile it on alpine?!
<@wumpus>
libraries need to be compatible with libgcc 4.4.0 and glibc 2.11
<@wumpus>
musl or bionic, not so much
< otium>
……………………………….. in the year 2016 before Segwit ……………………………..
< otium>
Thank you core dev for my new Bitcoin core node
< otium>
it’s fast as lightning
< otium>
it welcomes every node thats speaks Segwit fluently
< BlueMatt>
sipa: now you lost the commit message text for "Make nType and nVersion private and sometimes const"
< instagibbs>
does a block ever set CorruptionPossible?
< BlueMatt>
its similar text to the next commit, but not the same
< BlueMatt>
instagibbs: it should?!
< instagibbs>
BlueMatt, ok, rephrase, what situation :)
< BlueMatt>
instagibbs: it refers to someone having changed the block such that it is no longer the data which the miner committed to - eg my merkle tree malleability or removing witnesses
< instagibbs>
oh, like handing simply a bad merkle tree
< instagibbs>
ok
< BlueMatt>
please rename and add comments
< BlueMatt>
it was originally names obscurely to hide a bug, but this was years ago
< BlueMatt>
sipa: previously the corresponding commit text was "Make the various stream implementations' nType and nVersion private and const (except in CDataStream where we really need a setter)."
< sipa>
BlueMatt: gah
< instagibbs>
On master running rpc tests im getting a smattering of: Unexpected exception caught during testing: Exception('bitcoind exited with status 1 during initialization',)
< instagibbs>
basically a couple each time, some tests more prone than others, and it gets better if i run with only one thread
< instagibbs>
I'll open an issue :)
< morcos>
cfields_: did you ever look at maxuploadtarget.py failing? i had guessed a couple months ago that it was due to your refactor and i never really dived into it. i'm surprised no one else has had issues with it. i can look into if if you haven't?
< jm22>
just wanted to let you know that when importing private keys or addresses you need to add rescan after the address or the private key. for releases before 13.1 there was no need for that.
< sipa>
jm22: what? please file an issue
< jm22>
iam talking about importing keys or addresses with the console of bitcoin-qt.
< sipa>
yes, i know what you are saying
< sipa>
you should file an issue, so we don't forget
< jm22>
I am not familiar with filing issues. there is nothing wrong just that before there was no need to specify rescan.. just wanted to help in cse someone else have the same problem
< sipa>
click new issue, and describe what you're typing, what you expect to happen, what really happens
< sipa>
if the behaviour changed in 0.13.1, that is a bug
< jm22>
the funny thing is that after you have have try to import thekey without specifying rescan, if you try again with former release is does not work any more either
< sipa>
?
< jm22>
when I run 13.1 and try imporiting a key without rescan the app freezes. now it I reboot and use a former release the same thing happen even though beforeusing 13.1 it was working.
< sipa>
it freezes??
< jm22>
now if I take a blockchain I updated with a former release importing the key works without rescan
< jm22>
well I need to reboot to stop the app.
< sipa>
how long did you wait?
< jm22>
I have done it many times I must have waited for 1/2 or 1 hour. I cna run it again and leave it on as long as you want.
< jm22>
the dis would work but with long pauses while when you import the disk works nonstop
< sipa>
and how do you fix it?
< sipa>
"by specifying rescan"... what does that mean?
< sipa>
do you put a 'true' after the command
< sipa>
or do you restart with -rescan
< jm22>
importaddress "address" for releases before 13.1 importaddress "address" rescan for 13.1
< jm22>
importaddress "address" rescan works fine with former releases just that I never put rescan
< sipa>
just literally 'rescan' ?
< jm22>
yes
< sipa>
not 'true' or '1'?
< jm22>
no nothing else
< sipa>
the argument after address is the label to assign to ot
< sipa>
and rescan is on by default
< sipa>
putting rescan as a literal directly after the address has no effect but giving the imported address a label
< sipa>
and certainly does not affect rescanning or not
< sipa>
maybe there was some other unrelated issue that caused it to hang
< jm22>
yes but with 13.1 it did not work for me I had to add it.
< sipa>
i'm sorry but that makes no sensr
< sipa>
the way you'd pass a rescan argument would be:
< sipa>
importaddress "1abcbdaddress" "" true
< jm22>
maybe I did something wrong however I did exactly the same with former releases and 13.1 and to make it work on 13.1 I need to write rescan.
< sipa>
that makes no sense at all
< sipa>
i believe you have some unrelated issue that triggers randomly, and you mistakenly believe it has anything to do with putting 'rescan' in the command
< sipa>
anyway, if it persists, please file an issue
< sipa>
so that more people can look into iy
< jm22>
all I can tell you is importaddress 1QARJNqw4QNZwiNDEu1XVqZQreRSGzvLHB rescan works on 13.1 and
< sipa>
i urge you to try more combinations
< jm22>
importaddress 1QARJNqw4QNZwiNDEu1XVqZQreRSGzvLHB does not.
< sipa>
ok, please file an issue
< jm22>
the address is not the one I used.
< jm22>
ok I did not mean to make a fuss I just wanted to help and sipa I really appreciate your dedication and work
< sipa>
i appreciate it, but saying "nothing but X" works when it's obvious it is unrelated, is not helpful
< sipa>
i don't mean to tell you there is no problem
< sipa>
but it has nothing to do with putting 'rescan' in the command
< sipa>
and if you want to further resolve the problem, file an issue
< sipa>
with the actual commands
< jm22>
the command I gave you were exactly what I specified except I change the address.
< jm22>
ok thanks.
< sipa>
jm22: i believe you, but it still has nothing to do with the rescan being there. can you try a few morw times without? my expectation is that sometimes it will work and sometimes it won't
< sipa>
jm22: if that is the case, there is a really issue we need to solve
< sipa>
if you want to help with that, please file an issue so people can look into it in more detail than i can right now
< jm22>
ok I will.
< sipa>
thanks!
< gmaxwell>
jm22: what release do you believe what you're describing worked in? 0.13.0 ?
< jm22>
gmaxwell wel / importaddress "address" has always worked since I have been using it, however when I troed to do it with 13.1 it would just freeze and had to reboot manually to stop it. It could be something else ofc. I will try again.
< sipa>
jm22: but what was the last version you know of that does not have this problem?
< jm22>
13.0
< jm22>
maybe it comes from the way I work since I work exclusively off line, so matbe I screwed up something I will go over that again with the different releases.
< gmaxwell>
if you are exclusively offline what are using importaddress for?
< jm22>
just to create watchonly wallets
< sipa>
if you're offline, what are you watching?
< jm22>
I actually really use it to import keys
< sipa>
oh, the importaddress is on the online machine, while the private keys are on the offline one?
< jm22>
I do both on offline, actually I almost do everything offline except for broadcasting
< jm22>
that is why I thing bitcoin-qt is amazing and safe.
< sipa>
then how do you learn about incoming payments?
< jm22>
watchonly wallets
< sipa>
BlueMatt: fixed the commit messages... i hope
< BlueMatt>
sipa: damn, now I lost my partial-review....fuck github
< jm22>
sipa I probably screwed up something because after rebuilding a new blockchain from stored blockchain that I keep, I do not seem to have any problem with importkey that I encountered yesterday. mea culpa.