< jeremyrubin> Has anyone been able to build bitcoin on recent amazon linux?
< jeremyrubin> i tried recently under clang and gcc and had no luck
< fanquake> jeremyrubin: I've never tried. Want to post the logs/issues somewhere?
< jeremyrubin> hmm I destroyed the logs... maybe when i have an hour sometime
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/30568d3f1e23...28f4e53e168f
< 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] fanquake pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/28f4e53e168f...2562d5d23863
< 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
< bitcoin-git> [bitcoin] fanquake opened pull request #19817: build: libtapi 1100.0.11 (master...libtapi_1100011) https://github.com/bitcoin/bitcoin/pull/19817
< wumpus> "improve sed robustness by not using sed" is still in the run for best commit message ever
< bitcoin-git> [bitcoin] jonatack opened pull request #19818: p2p: change `CInv::type` from `int` to `uint32_t`, fix UBSan warning (master...CInv-type-refactoring) https://github.com/bitcoin/bitcoin/pull/19818
< _0x0ff> did testnet reset recently? none of the txs in mempool seem to be added into new blocks
< _0x0ff> did testnet reset recently? none of the txs in mempool seem to be added into new blocks
< _0x0ff> my apologies for a double message, wrong window
< _0x0ff> seems to be working now
< wumpus> testnet can't just 'reset', it's unreliable though sometimes because of flaky miner behavior, this is one of the reasons for signet
< bitcoin-git> [bitcoin] S3RK closed pull request #19774: wallet: deactivate descriptor (master...wallet_deactivate_descriptor) https://github.com/bitcoin/bitcoin/pull/19774
< _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)
< vasild> https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki#Appendix_B_Tor_v3_address_encoding -- I guess another option would be to send PUBKEY+CHECKSUM instead of just PUBKEY and never calculate the checksum, if adding sha3-256 would be undesirable
< vasild> wumpus: ^
< wumpus> vasild: I don't really mind adding it; I think the more compact representation is elegant
< wumpus> vasild: I had just forgotten about it sorry
< sipsorcery> vasild: a year or so ago, when doing some ethereum work, I ran into issues with different sha3 implementations.
< vasild> yes, I agree
< sipsorcery> I think most of the problem comes from keccak and sha3 being used interchangeably.
< vasild> what issues?
< sipsorcery> given sha3 is only going to be for tov3 addresses wouldn't the safest issue be to take the sha3 source from the tor code base?
< vasild> ah, you mean if our sha3-256 produces different results than the tor's sha3-256?
< sipsorcery> All I can recall about the issue is that calling "sha3" from two different code bases gave different hashes.
< vasild> one of the libraries I am considering is cryptopp and it contains this comment:
< sipsorcery> I think within the keccak family different parameters can be set for the hash function.
< wumpus> that's curious, be careful to check against test vectors from the standard
< vasild> The Crypto++ implementation conforms to the FIPS 202 version of SHA3 using F1600 with XOF d=0x06
< vasild> Previous behavior (XOF d=0x01) is available in Keccak classes.
< wumpus> and against tor itself of course
< sipsorcery> Part of the issue seems to be that people started calling keccak derived function sha3 before the nist standard came out
< sipsorcery> but i'm no expert, I just recall it being a pain at the time.
< wumpus> I suppose in our case as we will only use sha3 for tor, it's okay if it matches just what they happen to call sha3
< vasild> I already checked that "openssl sha3-256" produces same hash as the one used in torv3
< wumpus> I remember doing a similar experiment with Python
< sipsorcery> yes, could always call it tor-sha3 or something if there was likely to be doubt.
< bitcoin-git> [bitcoin] fanquake closed pull request #19700: wallet: Replace -zapwallettxes with wallet tool command (master...zapwallettxes-wallettool) https://github.com/bitcoin/bitcoin/pull/19700
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/2562d5d23863...91af7ef831d3
< bitcoin-git> bitcoin/master a13cafc João Barbosa: wallet: GetWalletTx requires cs_wallet lock
< bitcoin-git> bitcoin/master d8441f3 João Barbosa: wallet: IsMine overloads require cs_wallet lock
< bitcoin-git> bitcoin/master b8405b8 João Barbosa: wallet: IsChange requires cs_wallet lock
< bitcoin-git> [bitcoin] laanwj merged pull request #19289: wallet: GetWalletTx and IsMine require cs_wallet lock (master...2020-06-wallet-less-locks) https://github.com/bitcoin/bitcoin/pull/19289
< wumpus> in any case I would be really surprised if Tor would get SHA3 wrong/non-standard :)
< wumpus> vasild: do you have a replacement for #19628 in high prio for review?
< gribble> https://github.com/bitcoin/bitcoin/issues/19628 | net: change CNetAddr::ip to have flexible size by vasild · Pull Request #19628 · bitcoin/bitcoin · GitHub
< MarcoFalke> #proposedmeetingtopic Status of 0.19 minor release https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+backport+%280.19%29%22+is%3Aclosed
< MarcoFalke> #proposedmeetingtopic Status of signet implementation in Bitcoin Core
< elichai2> how does the `version`message work? how does it know my own IP address? (in the eyes of the receiving node)
< MarcoFalke> elichai2: It should be all zeros or another constant
< elichai2> ohh, and I thought `CService` has some magic I can't figure out lol
< MarcoFalke> There certaily is magic, but #8740 changed what is sent
< gribble> https://github.com/bitcoin/bitcoin/issues/8740 | net: No longer send local address in addrMe by laanwj · Pull Request #8740 · bitcoin/bitcoin · GitHub
< 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
< bitcoin-git> [bitcoin] dongcarl opened pull request #19822: chain: Fix CChain comparison UB (master...2020-08-chain-comparison-UB) https://github.com/bitcoin/bitcoin/pull/19822
< Bullit> wumpus: I have uploaded the result of the log of a new crash to pastebin, this is the link>https://pastebin.com/embed_iframe/RWbeCz16
< luke-jr> wumpus: oh :x
< 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] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/91af7ef831d3...b987e657cda9
< 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
< jonasschnelli> just remove the complete folder
< 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
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b987e657cda9...15886b08aa5f
< bitcoin-git> bitcoin/master b6dcc6d Hennadii Stepanov: gui: Clarify block height label
< bitcoin-git> bitcoin/master 15886b0 MarcoFalke: Merge bitcoin-core/gui#40: Clarify block height label
< 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
< bitcoin-git> [bitcoin] Z5483 opened pull request #19823: WIP: ci: check if scripted diff is using BSD sed syntax (master...master) https://github.com/bitcoin/bitcoin/pull/19823
< meshcollider> meeting?
< MarcoFalke> meeting!
< achow101> meetin'?
< sipa> meeting¿
< jonasschnelli> #startmeeting
< lightningbot> Meeting started Thu Aug 27 19:03:12 2020 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< MarcoFalke> lekker
< hebasto> hi
< jonatack> hallo
< meshcollider> hi
< sipa> hi
< wumpus> hi
< sipsorcery> hi
< amiti> hi
< MarcoFalke> hi
< achow101> hai
< * MarcoFalke> waiting for the mass-ping
< jonasschnelli> Am I right that the only proposed topics are form MarcoFalke? (0.19 minor release / signet)?
< wumpus> jonasschnelli: correct
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
< wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< jonasschnelli> #topic High priority for review
< jonasschnelli> is there anything you want to add or remove or replace?
< MarcoFalke> add #19717 :)
< gribble> https://github.com/bitcoin/bitcoin/issues/19717 | rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump) by MarcoFalke · Pull Request #19717 · bitcoin/bitcoin · GitHub
< wumpus> MarcoFalke: replace #19629?
< gribble> https://github.com/bitcoin/bitcoin/issues/19629 | refactor: Keep mempool interface in validation by MarcoFalke · Pull Request #19629 · bitcoin/bitcoin · GitHub
< MarcoFalke> jup, removed the other
< jonasschnelli> done
< MarcoFalke> thx
< jonasschnelli> currently 10 blockers, 3 chasing concept ACK (same as last week)
< jonasschnelli> #topic Status of 0.19 minor release (MarcoFalke)
< MarcoFalke> Well, we should probably wrap that up and ship?
< wumpus> sounds good to me, I had no idea that was ready?
< MarcoFalke> though, there is still some tagged for backport: https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+backport+%280.19%29%22
< jonasschnelli> #19681 looks ready for merge
< gribble> https://github.com/bitcoin/bitcoin/issues/19681 | 0.19: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19681 · bitcoin/bitcoin · GitHub
< wumpus> agree
< wumpus> so does #18284?
< gribble> https://github.com/bitcoin/bitcoin/issues/18284 | [0.19] scheduler: Workaround negative nsecs bug in boosts wait_until by luke-jr · Pull Request #18284 · bitcoin/bitcoin · GitHub
< MarcoFalke> 18284 isn't a backport, though
< jonasschnelli> if we want to have the http race also fixed in 0.19.2, we should mark #19033 0.19.2,... otherwise move 18856
< gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
< wumpus> it's labeled 0.19.2 and targetted for 0.19 thugh
< MarcoFalke> The bug is not a regression in 0.19, so I am not sure if we *need* to fix it
< MarcoFalke> and it doesn't happen on servers
< wumpus> why didn't you never comment that on the PR?
< wumpus> it has only ACKs now
< wumpus> so it looks ready to go at least
< MarcoFalke> ok, will leave a comment now
< wumpus> it's fine with me to not do it at all, but if no one comments that in months that's not very clear to the author
< jeremyrubin> it should only happen if you're mocking the time right?
< jonasschnelli> #19033 is ready for merge IMO.. a backport to 0.19.2 should be easy to fix 18856
< gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
< MarcoFalke> jeremyrubin: No only if you hibernate/suspend
< jamesob> Can I have #19806 added?
< jeremyrubin> probably fine to fix then
< gribble> https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub
< jeremyrubin> jamesob: added to 0.19 backport?
< MarcoFalke> high prio
< wumpus> the code change itself looked ok to me
< jonasschnelli> jeremyrubin: sure. Adding...
< jamesob> Oops, we're still on highprio right?
< wumpus> it's always possible to argue it's not *worth* fixing, but I think it's kind of strange if there is already a patch
< wumpus> if it can happen with hiberbate/suspend that seems like a legit issue?
< jonasschnelli> jamesob: no. 0.19.2 (but it's fine)
< 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> I don't care where the tools are
< 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
< sipa> at some point
< 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
< michaelfolkson> There is this too for setting up your own Signet https://github.com/kallewoof/signet-platform
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/19455 | rpc generate: print useful help and error message by jonatack · Pull Request #19455 · bitcoin/bitcoin · GitHub
< 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)
< jonasschnelli> \o
< jonatack> o/
< sipa> /o\
< jonasschnelli> \Ɵ (masks in public space, folks!)
< * sipa> hands jonasschnelli a really big /128 mask
< jonasschnelli> heh
< wumpus> hehe
< midnight> o7
< sipa> achow101: 415afcccd3e5583defdb76e3a280f48e98983301 seems pointless
< sipa> + if (m_storage.CanSupportFeature(FEATURE_HD_SPLIT) && CHDChain::VERSION_HD_CHAIN_SPLIT) {
< achow101> sipa: indeed
< sipa> i'm not sure what it's supposed to do
< achow101> upgradewallet is slightly broken. see #18836
< gribble> https://github.com/bitcoin/bitcoin/issues/18836 | wallet: upgradewallet fixes and additional tests by achow101 · Pull Request #18836 · bitcoin/bitcoin · GitHub
< sipa> ok
< 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