< BlueMatt>
grrrr why is practicalswift not in the contributors list so I can auto-complete his long-ass name
< luke-jr>
that would be too … practical
< * luke-jr>
hides
< BlueMatt>
lol, oh so punny
< * sipa>
hoped:
< sipa>
* luke-jr hides swiftly
< gmaxwell>
luke-jr: you live!
< BlueMatt>
(and have internet)
< BlueMatt>
lol errrr maybe not
< kallewoof>
he made puns, so he seems to be doing okay. :) i dont think i'd be punning if i was in trouble.
< BlueMatt>
kallewoof: well he ping-timeout'd, so at least the internet part may not be so stable :p
< kallewoof>
he'll be okay. he was trained in the art of no internet at tokyo core dev when he was without his computer for basically an entire day.
< BlueMatt>
:O
< kallewoof>
yeah. *shudders*
< kallewoof>
Running a modified master but I just ran into EXCEPTION: 15dbwrapper_error and Database corrupted abd Corruption: not an sstable (bad magic number) etc. I can provide access to the machine with the node if someone feels intrigued by this, or I will just try to fix it. sipa etc?
< sipa>
meshcollider: you should be able to restart travis jobs now
< kallewoof>
^Cing gave Error: Error: A fatal internal error occurred, see debug.log for details a few times.
< sipa>
kallewoof: very little i can do...
< kallewoof>
Okay. Seemed like a nice debugging opportunity, but ah well.
< sipa>
i'd like to hear about the circumstances that led to the corruption though
< kallewoof>
Node crashed due to my code (which was logging stuff to a file).
< kallewoof>
It was also running from gdb. I suspect that may have been a problem too.
< sipa>
ouch.
< sipa>
that shouldn't cause corruption
< kallewoof>
To clarify, I ran in gdb, hit the crash, killed process, and then restarted node and it started spewing these.
< kallewoof>
My kill may have caused it?
< sipa>
killing a process shouldn't cause db corruption
< kallewoof>
Yeah, I've done it all the time. I didn't really do anything else noteworthy.
< kallewoof>
As a sidenote, despite the "see debug.log for details" message, there was nothing in the debug.log related to this.
< sipa>
wow, that must be very old, and referring to bdb's debug log?
< kallewoof>
Ohhh..
< sipa>
or perhaps not
< kallewoof>
It's in AbortNode in validation.cpp so seems to be about bitcoin, yeah.
< kallewoof>
This is on a digital ocean instance, btw, which I assume us running everything RAIDed, so an actual disk corruption doesn't sound likely.
< sipa>
that's also irrelevant; it's not the OS or the hardware that crashed, just a process
< kallewoof>
If an actual disk error (bad block/sector/etc) was present surely it could cause a corruption in the db
< kallewoof>
In case someone else has the issue, restarting the node actually solved it on my side.
< sipa>
should the "this wallet is segwit" flag be a version number or a separate key in the wallet?
< MarcoFalke>
sipa: If it is a new version, we'd have to backport the usehd change to 0.15.1. Is that desired?
< sipa>
MarcoFalke: if it's not a new version, downgrading to 0.15.0 may cause lost funds
< sipa>
(not disagreeing with you, but there are issues both ways - i'm just wondering whether this was discussed already)
< MarcoFalke>
right. So there will only be segwit HD wallets
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11305: [doc] Update release notes and manpages for 0.16 (master...Mf1709-doc016) https://github.com/bitcoin/bitcoin/pull/11305
< bitcoin-git>
[bitcoin] danra opened pull request #11306: Refactor: Move core files from src root to src/core and improve inclu… (master...refactor/core-files) https://github.com/bitcoin/bitcoin/pull/11306
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11307: wallet: Display non-HD error on first run (master...Mf1709-walletHDfirst) https://github.com/bitcoin/bitcoin/pull/11307
< morcos>
sipa: Why would it cause funds loss? Isn't it adding the segwit scrips to the wallet, which would be recognized by lower versions of wallets?
< morcos>
Yes old backups wouldn't work, but that's true for 0.15.1 as well
< morcos>
I thought the idea was to fix that with 0.16.0 by essentially tripling every existing key in the wallet (for all the segwit scripts)
< morcos>
I think it would be helpful to write up an issue the explains the whole 0.15.1 wallet plan in one place (in english) and the 0.16.0 wallet plan. just so we can think through everything now
< meshcollider>
morcos: by tripling, do you mean one P2PKH, one P2SH and one BIP173?
< meshcollider>
+1 for doing a write up
< morcos>
yes, P2SH wrapped segwit script for the middle one.. (and that's not exactly right, b/c i think we might add more than P2PKH for the legacy, but thats the idea)
< meshcollider>
so will P2SH-P2WPKH will be treated identically to the same address in P2PKH from the users perspective
< morcos>
meshcollider: the goal is no. you should not get paid at an address you did not give out. so if you give out a P2PKH, then that is how you should be paid and no one should be trying to wrap that up in some script or program and paying you to it
< morcos>
but for backwards compatibility with the way 0.15.0 and previous wallets worked, once we implement that functionality, then on upgrade your wallet will treat it as if you've given out all 3 variations for pre existing keys
< morcos>
but future keys will only be used for 1 variation
< morcos>
but we need the writeup to make sure it all makes sense... seems like sipa was assuming that some level of upgrade is happening at 0.15.1 , but i thought there was no upgrade until 0.16.0, and that we weren't marking 0.15.1 wallets as special
< morcos>
other than that we'd be adding segwit addresses to them by default
< BlueMatt>
sipa: yea, what morcos said...I didnt think we were adding a "this wallet is segwit" flag for 0.15.1
< BlueMatt>
(and then a version bump in 16ish when we do a second hd split
< BlueMatt>
)
< RealM9>
What? ae you going to release 0.15.1 with SW address support?
< RealM9>
Are*
< MarcoFalke>
jnewbery: I don't think we should be encouraging refactoring pulls that change all apostrophes into quotation marks in python code
< MarcoFalke>
Also, we don't bulk-rename vars to snake_case in python.
< MarcoFalke>
All of this is a pain to review
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11308: [qa] zapwallettxes: Wait up to 3s for mempool reload (master...Mf1709-qaZap3s) https://github.com/bitcoin/bitcoin/pull/11308
< BlueMatt>
does anyone have numbers on transaction confirmation for rbf replacement txn? I have a feeling it might be time to start tracking those in fee estimation
< jnewbery>
MarcoFalke : sure. I didn't push back because the PR also does the useful job of updating the os.path calls in the same file. I'm not too concerned about accepting those changes but saying 'in general we don't accept style-only PRs', but if you want to take a harder line I think that's also fine.
< MarcoFalke>
I am not keen on reviewing that. If you feel like making sure that all the refactoring parts preserve functionality 100%, go ahead. I am not aware of a good way to do that when it is not a scripted diff. And a scripted diff is overkill for those formatting changes
< jnewbery>
MarcoFalke : can you merge #11230 ? dbcrash.py is still failing