< bitcoin-git>
bitcoin/master 1343c86 Seleme Topuz: test: Update wait_until usage in tests not to use the one from utils
< bitcoin-git>
bitcoin/master d841301 Seleme Topuz: test: Add docstring to wait_until() in util.py to warn about its usage
< bitcoin-git>
bitcoin/master 28f4e53 MarcoFalke: Merge #19752: test: Update wait_until usage in tests not to use the one fr...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19752: test: Update wait_until usage in tests not to use the one from utils (master...master) https://github.com/bitcoin/bitcoin/pull/19752
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19816: test: Rename wait until helper to wait_until_helper (master...2008-testWaithelper) https://github.com/bitcoin/bitcoin/pull/19816
< bitcoin-git>
bitcoin/master f36140d fanquake: build: use patch rather than sed in bdb package
< bitcoin-git>
bitcoin/master 335bd7f fanquake: build: use patch rather than sed in Boost package
< bitcoin-git>
bitcoin/master 865cb23 fanquake: build: use patch rather than sed in fontconfig package
< bitcoin-git>
[bitcoin] fanquake merged pull request #19761: build: improve sed robustness by not using sed (master...maximum_sed_robustness) https://github.com/bitcoin/bitcoin/pull/19761
< _0x0ff>
wumpus: noted, thanks for clarifying. I needed testnet unfortunatelly, but everything is OK now.
< vasild>
sipa: any advices on which sha3-256 implementation to import in src/crypto/? (sha3-256 is needed to create torv3 addresses from the 32 byte address public key which we are going to be sending and storing)
< sipa>
sipsorcery vasild wumpus: ethereum doesn't actually use sha3, but keccak with parameters that were proppsed for sha3 before it was finalized (and changed afterwards)
< sipsorcery>
sipa: yes that's what I found out the hard way. it gets called sha3 in lots of places in the ethereum docs and code comments.
< sipsorcery>
*that should be the C++ geth code base and docs (I didn't look over ALL the ethereum code)
< jonasschnelli>
I finally fixed the macOS build on bitcoinbuilds.org, github integration is next (since it was running more or less without troubles for months, except the missing macOS sdk which is a config problem)
< hebasto>
jonasschnelli: many thanks!
< elichai2>
MarcoFalke: ha! thanks :)
< wumpus>
jonasschnelli: thank you!
< jonatack>
jonasschnelli: nice one!
< Bullit>
Bitcoin QT keeps closing at startup, it crashed suddenly during a youtube, i restarted my computer now Bitcoin QT does not proceed further then blockindex
< Bullit>
nope Bitcoin QT still fails to load into full blockchain
< luke-jr>
vasild: I don't understand why we need to do the SHA3 on our end. Shouldn't we be able to give Tor the private key, and it give us back an address?
< wumpus>
Bullit: what causes it to shut down? can you upload the last part of debug.log to some pastebin?
< wumpus>
luke-jr: please read back this discussion; the .onion urls contain a sha-3 hash as checksum, but in addrv2 only the 32 bytes of raw address data is sent (to save bandwidth), not this checksum, so it needs to be computed client side
< sipa>
right, this is not about computing our onion address, but to convert between the bip155 encoding and onion addresses
< sipa>
vasild: happy to help find a sha3 implementation, if needed
< wumpus>
indeed, it's not needed for determining our own address
< wumpus>
Bullit: that's really the end of the log? no error message?
< wumpus>
Bullit: in any case, the only advice I can give is to reindex using -reindex-chainstate, it's pretty clear thechainstate is currupt due to the sudden crash
< stevenroose>
Is the coinbase maturity of regtest different than 100?
< Bullit>
wumpus: yes the log really ends in that 0% warning. just before the crash my mouse pointer indicates a loading, I register that loading as a normal interval
< MarcoFalke>
stevenroose: no it should be 100
< MarcoFalke>
COINBASE_MATURITY isn't even a chain param
< stevenroose>
k yeah couldn't find it but wasn't sure if I got the name right
< stevenroose>
MarcoFalke: thanks
< jonatack>
stevenroose: some explanation in test/functional/interface_bitcoin_cli.py:17: # COINBASE_MATURITY (100) blocks. Therefore, after mining 101 blocks we expect
< jonasschnelli>
Bullit: no error on screen? What OS are you using? What version of Core?
< Bullit>
jonasschnelli: A small load on my mouse pointer, and sudden crash, no error log, I am using Windows 10 (15 years experience) I have bitcoin QT 0.20, in the log it says QT 5.9.8
< bitcoin-git>
bitcoin/master a99a3c0 pasta: rpc: Validate provided keys for query_options parameter in listunspent
< bitcoin-git>
bitcoin/master b987e65 MarcoFalke: Merge #19169: rpc: Validate provided keys for query_options parameter in l...
< jonasschnelli>
Bullit: have you ran older versions of Core before? Or freshly installed for the first time on your system?
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19169: rpc: Validate provided keys for query_options parameter in listunspent (master...bitcoin-validate-keys-listunspent) https://github.com/bitcoin/bitcoin/pull/19169
< Bullit>
I ran Bitcoin QT 0.18 on a Linux laptop, which failed early august during the heat, I then installed Bitcoin QT 0.20 on this Windows machine
< jonasschnelli>
Bullit: you can try to remove the data directory (where the local blocks, wallet, etc. is stored). Gives it kind of a fresh start. ONLY DO THIS IF YOU HAVEN'T USED THE WALLET
< Bullit>
jonasschneli: the data directory is on my NAS, downloading and verifying of the blocks gave no problem, but in a Heavy Youtube about British Parliament bitcoin suddenly crashed
< wumpus>
it's well known that bitcoin is one of the heaviest things to run and and excellent CPU burn in test, any subpar hardware will fail on it, I'd suggest you get better hardware first
< wumpus>
otherwise you'll keep having this over and over again
< MarcoFalke>
Are NAS supported even?
< MarcoFalke>
I keep hearing corruption issues with remote disks
< Bullit>
wumpus: my graphix card is from a 2014 litecoin miner, why would the hardware not suffice?
< wumpus>
it's not a problem in itself depending on the file sytem, sometimes there's file locking problems, but otherwise it should work fine (as long as you don't have power loss or CPU overheats etc ofc but that's always)
< wumpus>
Bullit: not cooled well enough if it crashes with heat
< Bullit>
wumpus: watercooling with a i7 intell
< wumpus>
still it sounds like a hardware issue
< wumpus>
in any case: try reindexing, it'll probably make the problem go away until the next time things overheat
< Bullit>
wumpus: the Bitcoin QT crashes at startup, I do not see an opportunity to go into console without seeing my wallet first
< vasild>
wumpus: not yet next PR to review, it would have been the next commit in https://github.com/bitcoin/bitcoin/pull/19031 but when I looked at it again I realized we can't to CNetAddr::ToString() of a TORv3 and this is where the sha3-256 came. I almost integrated some of the files from crypto++, they are in the public domain. I hope to be able to open a PR tomorrow.
< vasild>
s/can't to/can't do/
< wumpus>
Bullit: no need for that, you need to pass -reindex on the command line to the executable itself
< Bullit>
wumpus: I used a shortcut with -reindex, the Client opens and is reindexing, thanks for the advice
< MarcoFalke>
wumpus: Jup, the code change looks fine obviously. Though, it is also boost. A previous version of the patch forgot to catch and re-throw boost::thread_interrupted
< MarcoFalke>
I'd rather have a known bug that is well understood than an newly introduced intermittent unknown bug
< wumpus>
is there any urgency to do another 0.19 release at all?
< jeremyrubin>
reject filtering?
< MarcoFalke>
wumpus: Not really. Not sure how urgent the reject filtering needs to go out
< jeremyrubin>
that was the main motivator iirc?
< sipa>
i don't think that's urgent
< wumpus>
not urgent enough to rush and skip other fixes at least
< jonasschnelli>
Anything to add to 0.19.2? (MarcoFalke)
< MarcoFalke>
Not really. Everything should be tagged already.
< jonasschnelli>
#topic Status of signet implementation in Bitcoin Core (MarcoFalke)
< MarcoFalke>
Pretty much a short topic. I only wanted to ask if anyone plans to ACK/NACK/review it.
< jeremyrubin>
i played around with the impl yesterday. It's pretty good but currently lacking the contrib tools
< MarcoFalke>
From my view it seems close to ready
< jeremyrubin>
It was hard for me to fully test it without the contrib tooling
< MarcoFalke>
jeremyrubin: I'd say Bitcoin Core is the wrong place to add contrib tools for the signet maintainers.
< MarcoFalke>
They can have their own repo
< jeremyrubin>
MarcoFalke: disagree -- we should be able to produce blocks for signet
< wumpus>
we have a maintainer tools repo just add it there
< jeremyrubin>
But I care that I can't test a signet that I created
< sipa>
i'm not sure it's really a maintainer tool
< MarcoFalke>
I agree they should be public
< jeremyrubin>
I'm saying that it's a bit of a merge precondition. I would ACK if I could finish testing it
< wumpus>
it's pretty much free for all for anything maintainers need, no need to put signet tools anywhere else
< sipa>
the expectations may be unclear, but i hope that over time various private signets get spun up - it could even replace regtest over time
< michaelfolkson>
Can't test jeremyrubin? What can't you test exactly?
< jeremyrubin>
Well I made my own signet script and network
< MarcoFalke>
michaelfolkson: Mining blocks
< jeremyrubin>
And i cannot produce blocks
< jeremyrubin>
So I can't test peering it and seeing that it works
< sipa>
doesn't mean it needs to be in the repo right now, but i don't think it'd be unreasonable to have the scripts for working/spining up a signet in the main repo
< wumpus>
no big objection either, but I would say that there need to be tests for them if you'd put them in the main repo, there's already too many quasi-unmaintained tools
< sipa>
agree
< michaelfolkson>
Yeah I'm hazy about what should be in Core, what is covered by Core but I'm sure it will become clearer to me over time
< jeremyrubin>
Yeah the tools could be somewhere, I'm just commenting that I can't finish testing and ACK without having block producing scripts.
< sipa>
wumpus: yes, let's not merge things that are untested and then go broken without anyone noticing
< wumpus>
in any case that doesn't seem necessary for the PR that is open now
< MarcoFalke>
If they get added to the repo, I hope they are not written in bash at least *hides
< jeremyrubin>
wumpus: one cannot tested ACK the current code
< sipa>
jeremyrubin: i don't think that's a blocker for signet itself - the tools are available, right?
< sipa>
just not in the PR
< jeremyrubin>
I don't think so AFAIK
< wumpus>
wait, the tools are not available *at all*?
< wumpus>
okay, that seems like a blocker
< jeremyrubin>
I think they are quasi available
< wumpus>
why not just ask kallewoof for them
< jeremyrubin>
In that they exist against a prior version of Signet
< jonasschnelli>
I guess kallewoof is asleep
< jonatack>
signet is certainly the PR i've spent the most time doing re-reviews of these past 6 months. it would be nice to begin reviewing follow-ups instead of the whole thing every time.
< jeremyrubin>
I think they're still finishing them
< jeremyrubin>
And it's fine if we want follow up work to add the full tools
< michaelfolkson>
Is it a blocker? There will be future Signet related PRs
< jeremyrubin>
but if people are wondering why I haven't ACKd it
< wumpus>
in any case, in including the tools in bitcoin core's repo (+tests) should imo not be a requirement for this PR
< jeremyrubin>
(which is more or less the current topic)
< wumpus>
but they need to be available somewhere
< jeremyrubin>
that's why
< sipa>
jeremyrubin: seems very reasonable
< jeremyrubin>
wumpus: +1, I'm happy with them being anywhere
< MarcoFalke>
jonasschnelli: There was a previous version that signed the block, not transactions
< MarcoFalke>
I'd bet the current one would be easier to write from scratch
< sipa>
i think it would be good if the signet consensus PR included a trivial python based functional test... even if it's a super simple one with just OP_TRUE as script or so
< wumpus>
yes
< sipa>
i don't see any actual testing apart from a fuzz test?
< MarcoFalke>
sipa: I was planning to write some tests as a follow-up
< instagibbs>
sipa, could have all tests run with --signet, and it handles it in background using generate* aliased? :)
< instagibbs>
s/all/some/
< wumpus>
re-running every test seems like overkill
< wumpus>
right
< MarcoFalke>
instagibbs: They'd run for years with that POW
< sipa>
yeah, i just want to make sure the signet code is exercised in tests
< sipa>
that does not seem to be the case in the current PR
< instagibbs>
MarcoFalke, sigregtest ... right
< MarcoFalke>
heh, regtest should already mimic mainnet in most params
< jeremyrubin>
michaelfolkson: those tools don't seem to be current
< MarcoFalke>
Jup, anything that was written before august is outdated
< instagibbs>
aj and kallewoof have the current block keys, for final might be worth having keys in EU/US for timezone arbitrage
< michaelfolkson>
Volunteering? :)
< instagibbs>
I'm moving their timezone, probably, so no
< instagibbs>
lol
< instagibbs>
voluntelling achow to run a node
< MarcoFalke>
ack
< jeremyrubin>
instagibbs: nack
< jeremyrubin>
I think we shouldn't try to offer signet as any sort of "use the main one thing"
< jeremyrubin>
let a thousand ships sail ;)
< michaelfolkson>
Disagree. But I will post on the mailing list and you can disagree with me there
< jeremyrubin>
ok
< achow101>
instagibbs: what am I being voluntold to do?
< jeremyrubin>
also note that for signet there's not ~that much value in the current multisig setup
< jeremyrubin>
it's 1 of N
< michaelfolkson>
Third signer on Signet blocks being mined. Congrats achow101
< jeremyrubin>
there's no M of N cordination
< jeremyrubin>
so you can literally do a 1 of 1 and send anyone the key
< instagibbs>
jeremyrubin, right it's less crucial but "hey bump your server"
< instagibbs>
well, then it becomes 1 of 1 over time, anyways, not a huge deal
< achow101>
chaincode should run a signet node then
< MarcoFalke>
I'd presume it is 1 of 2 to protect against power outages
< jeremyrubin>
it's current 1 of 2, which has no security improvement over 1 of 1 where two people know the 1
< instagibbs>
it's not security
< instagibbs>
it's outages
< instagibbs>
hence timezone comment
< instagibbs>
not nation :)
< jeremyrubin>
it has no outages improvement
< sipa>
i think you guys are talking past each other
< jeremyrubin>
unless I'm missing something where you want to know which node created the block
< michaelfolkson>
It does. If one signer is down blocks can still be mined using sigs from the other signer
< sipa>
yeah, i think the only difference is accountability
< instagibbs>
"why not" but also "I've stopped caring" :)
< sipa>
not sure that matters
< instagibbs>
so I'll concede i appear to care less and relent
< jeremyrubin>
Yeah I'm not sure how to make my point more clear but I'll cede the balance of my time (too much CSPAN)
< instagibbs>
you could softfork out on of the keys(haha)
< instagibbs>
(100% not serious)
< * jeremyrubin>
groans
< MarcoFalke>
1 of 2 also gives debugability. (You'll see which miner didn't produce blocks)
< jeremyrubin>
you already get that with coinbase message if you want
< sipa>
MarcoFalke: yeah, that's commonly called accountability
< jeremyrubin>
there's maybe an edge on debuggable v.s. provably accountable if the miner-id is a unverified message
< sipa>
i think this is getting off topic
< jonasschnelli>
any other last minute topics?
< jonatack>
so, signet is near-mergeable, just needs a sanity check functional test?
< jonatack>
jonasschnelli: About 0.19.2 backports -- not a bugfix per se but perhaps #19455. It accompanies the cli -generate addition, which was in 0.19.
< luke-jr>
re 18284 I don't get why we would intentionally *not* merge a bugfix
< MarcoFalke>
luke-jr: Because of the risk that it introduces new bugs
< jonasschnelli>
jonatack: 19455 is not really a bugfix?
< luke-jr>
it's one thing if people don't give it reviews needed, but once it has review, it doesn't make sense to leave it out
< jeremyrubin>
jonatack: I think one should be able to stand up a net and generate blocks, which might be a subset of that functional test. That's my watermark for tested ACK
< wumpus>
I don't think it's particularly risky
< jonatack>
jonasschnelli: it explains to people that run the former RPC generate that it is now CLI -generate instead
< wumpus>
then again I ACKed it
< jonasschnelli>
jonatack: I'd say no need to backport this... but no strong opinion.
< jonatack>
because several tutorials online still mention rpc generate and it might be confusing for them. Yep, no worry, just mentioning.
< MarcoFalke>
Yeah, I see it has two ACKs
< jonasschnelli>
jonatack: Yes. That is a good point.
< wumpus>
jonatack: I doubt meany people following tutorials will use a new 0.19.x
< jonasschnelli>
yeah,.. that
< wumpus>
not opposed to backporting it, but, these kind of backport releases tend to be used for old software on servers
< sipa>
if used at all
< luke-jr>
well, some end users intentionally hold back on major updates too; but still unlikely they'd be using the old version for something like this
< sipa>
right
< wumpus>
they're definitely downloaded looking at torrent seed server stats etc
< sipa>
wumpus: good to know
< jonasschnelli>
#endmeeting
< lightningbot>
Meeting ended Thu Aug 27 19:55:02 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< achow101>
the original goal of that line was to have `m_hd_chain.nVersion <= CHDCHain::VERSION_HD_CHAIN_SPLIT` but I think that doesn't always work as well
< achow101>
s/<=/<
< yanmaani>
How do I build bitcoin using depends/ bdb4.8 but system qt / boost / whatever?
< bitcoin-git>
[bitcoin] dhruv opened pull request #19825: rpc: simplify setban and consolidate BanMan functions (master...consolidate-ban-functions) https://github.com/bitcoin/bitcoin/pull/19825