< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13395: rpc: Avoid "duplicate" return value for invalid submitblock (master...Mf1806-rpcMiningSubmitblock) https://github.com/bitcoin/bitcoin/pull/13395
< bitcoin-git> [bitcoin] glaksmono closed pull request #13322: Fixing texts in the "encrypt wallet" GUI process (master...bitcoin-gui-13245) https://github.com/bitcoin/bitcoin/pull/13322
< bitcoin-git> [bitcoin] Empact opened pull request #13396: Drop unused uint 256 not operator (master...drop-bool-not) https://github.com/bitcoin/bitcoin/pull/13396
< skeees> just a quick post that #12934 which we discussed at the IRC meeting a few weeks ago (https://bitcoincore.org/en/meetings/2018/05/03/) is now in a reviewable state
< gribble> https://github.com/bitcoin/bitcoin/issues/12934 | [net] [validation] Call ProcessNewBlock() asynchronously by skeees · Pull Request #12934 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0de7cc848e07...861de3b518ad
< bitcoin-git> bitcoin/master 989c899 Giulio Lombardo: Rename “OS X” to the newer “macOS” convention
< bitcoin-git> bitcoin/master 861de3b Wladimir J. van der Laan: Merge #13366: Docs: Rename “OS X” to the newer “macOS” convention...
< bitcoin-git> [bitcoin] laanwj closed pull request #13366: Docs: Rename “OS X” to the newer “macOS” convention (master...osx-renaming) https://github.com/bitcoin/bitcoin/pull/13366
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/861de3b518ad...7c7508c268fa
< bitcoin-git> bitcoin/master 81bbd32 practicalswift: build: Guard against accidental introduction of new Boost dependencies
< bitcoin-git> bitcoin/master 7c7508c Wladimir J. van der Laan: Merge #13385: build: Guard against accidental introduction of new Boost dependencies...
< bitcoin-git> [bitcoin] laanwj closed pull request #13385: build: Guard against accidental introduction of new Boost dependencies (master...lint-boost) https://github.com/bitcoin/bitcoin/pull/13385
< Roybent> #worldchat
< provoostenator> While trying to get bitcoind to run on one the many *-pi's out there, I wondered: has anyone ever tried to design a system on chip that's optimal for this?
< echeveria> provoostenator: the optimal processor is anything other than a raspberry pi. lets take this to #bitcoin.
< Roybent> Invitation Age of sail at #AdventuresofChat
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c7508c268fa...2140f6cbc5e9
< bitcoin-git> bitcoin/master fa36aa7 MarcoFalke: wallet: Prevent segfault when sending to unspendable witness
< bitcoin-git> bitcoin/master 2140f6c MarcoFalke: Merge #13351: wallet: Prevent segfault when sending to unspendable witness...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13351: wallet: Prevent segfault when sending to unspendable witness (master...Mf1806-walletUnspendableWitnessIsMine) https://github.com/bitcoin/bitcoin/pull/13351
< Roybent> Invitation Age of sail at #AdventuresofChat
< wumpus> provoostenator: you mean secp256k1 specific instructions? people have been thingking about it, could be done on a FPGA, but I don't think it's ever been done
< provoostenator> echeveria seems to believe sha256 is the bottleneck (see #bitcoin), but also that anything outside the CPU would be too slow I/O to be worh it.
< echeveria> I looked at the Zynq combination FPGA / ARM devices a long time ago and came to the conclusion that the copy time even on the shared memory bus between the two chips would make it non viable. I'd enjoy being proved wrong though.
< Roybent> Invitation Age of sail at #AdventuresofChat
< sipa> Roybent: not here
< wumpus> provoostenator: well sha256 extension instructions exist for ARM (supported on newer SoCs), I intend to add support for them at some point. But I would be surprised if that is the biggest bottleneck in validation.
< wumpus> echeveria: yes, if there is high-bandwidth communication between two chpis that tends to dominate. I was thinking of, say, RiscV extensions for secp256k1 validation so it's in-core.
< wumpus> for ARM it's somewhat unlikely at this time
< sipa> secp256k1 validation only needs 6 Mbyte/s or so bandwidth to be faster than regular cpu cores
< wumpus> even an USB2.0 secp256k1 dongle would work then
< provoostenator> Many of these boards have DDR2-SODIMM sockets that you stick something into...
< echeveria> my conclusion was that it would take longer to copy than to do it on the CPU
< echeveria> perhaps that's not true.
< echeveria> I wasn't able to find any research on doing ECDSA on a FPGA that looked promising though
< wumpus> M.2 expansion slots are also becoming quite common (though there are lots of different "keys" which makes it unclear what is uncompatible, but some of them include PCI-e lanes)
< provoostenator> Well, I just got my Nanopi Neo Plus 2, an Orange Pi Plus 2E is underway, as well as the octacore Khadas VIM2 Max... so if anyone needs something benchmarked.
< echeveria> secp256k1's benchmark will say "slow"
< wumpus> echeveria: I could find some research on that, but for specific curves this is not something that tends to exist as open source :)
< provoostenator> At least they have wifi support, so I can put them in the freezer to keep the CPU's from downclocking :-)
< echeveria> wumpus: for non specific curves the research presented speeds slower than a small ARM core sadly
< wumpus> echeveria: right - the hardware would really need to be optimized for a specific properties, otherwise it's not going to help compared to just a sw implementation
< wumpus> echeveria: the secp256k1 library isn't easy to compete against I suppose
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2140f6cbc5e9...f0fd39f37630
< bitcoin-git> bitcoin/master 6aa33fe Ben Woosley: Drop UpdateTransaction in favor of UpdateInput...
< bitcoin-git> bitcoin/master f0fd39f Wladimir J. van der Laan: Merge #13269: refactoring: Drop UpdateTransaction in favor of UpdateInput...
< bitcoin-git> [bitcoin] laanwj closed pull request #13269: refactoring: Drop UpdateTransaction in favor of UpdateInput (master...update-transaction) https://github.com/bitcoin/bitcoin/pull/13269
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13399: rpc: Add submitblockheader (master...Mf1806-rpcBlockHeader) https://github.com/bitcoin/bitcoin/pull/13399
< sipa> cfields: going to PR that SSE4 speedup?
< sipa> gmaxwell: the 4-way code is actually SSE4, not SSSE3
< sipa> (it uses pinsrd)
< sipa> gmaxwell: i think that could be avoided, though if really desired
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f0fd39f37630...264efdca74f2
< bitcoin-git> bitcoin/master fa4760f MarcoFalke: qa: Increase includeconf test coverage
< bitcoin-git> bitcoin/master 264efdc Wladimir J. van der Laan: Merge #13367: qa: Increase includeconf test coverage...
< bitcoin-git> [bitcoin] laanwj closed pull request #13367: qa: Increase includeconf test coverage (master...Mf1806-qaIncludeconf) https://github.com/bitcoin/bitcoin/pull/13367
< promag> sipa: have you shared the benchmark code mentioned in #13386?
< gribble> https://github.com/bitcoin/bitcoin/issues/13386 | SHA256 implementations based on Intel SHA Extensions by sipa · Pull Request #13386 · bitcoin/bitcoin · GitHub
< Silva> Hello !
< Silva> Does Bitcoin implements Multi Signature?
< sipa> promag: bench/bench_bitcoin
< promag> sipa +1
< Silva> sipa, the bench implements mult_sig ?
< sipa> Silva: not here, this channel is for development
< Silva> actually I would like to know where in the code is this implementation for Multisig ?
< sipa> Silva: if you have general questions about how bitcoin works, see the #bitcoin irc channel, the developer documentation on https://bitcoin.org/en/developer-documentation, or ask on https://bitcoin.stackexchange.com
< sipa> Silva: that's not something i can answer in 3 sentences
< reca> hello why this issue is locked: https://github.com/bitcoin/bitcoin/issues/13387 ?
< cfields> sipa: sure. I spent some time trying to understand why it didn't apply to the avx2 path, and poking at intel's other suggested optims
< sipa> cfields: let me know if you have more things to benchmark
< cfields> sipa: thanks, but I think it's a bit too far out of my wheelhouse. If you're comfortable with the speedup being generic and expected, I'll just PR as-is.
< phantomcircuit> reca, it says in the issue why it's locked
< reca> phantomcircuit: could you copy/paste here the exact resason pls because seriously I don't see it and in general I don't understand why you closed it
< cfields> sipa: in particular, I'm not understanding why Round() operates on 128/256bit vectors rather than uint32_t's? Is it just the cost of moving them in/out of the larger registers?
< sipa> cfields: hmm?
< sipa> cfields: the __m128i act like 4 parallel 32 bit integers
< sipa> so 'Add' does 4 additions in parallel, Xor does 4 parallel xors in parallel, ...
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/264efdca74f2...a589f536b5e1
< bitcoin-git> bitcoin/master ebec731 Ben Woosley: Drop the chain argument to GetDifficulty...
< bitcoin-git> bitcoin/master a589f53 Wladimir J. van der Laan: Merge #13288: rpc: Remove the need to include rpc/blockchain.cpp in order to put `GetDifficulty` under test...
< sipa> cfields: operating on uint32's would lose the SIMD speedup
< bitcoin-git> [bitcoin] laanwj closed pull request #13288: rpc: Remove the need to include rpc/blockchain.cpp in order to put `GetDifficulty` under test (master...get-difficulty) https://github.com/bitcoin/bitcoin/pull/13288
< reca> sipa: where are this official git mirrors of the bitcoin core ?
< sipa> reca: git clone
< cfields> sipa: yes, I understand that. It just doesn't look how I would expect.
< sipa> reca: there is no urgent issue; we can have a discussion about alternatives, but the ownership of github doesn't affect us
< sipa> reca: if microsoft would start making invasive changes to the platform, then of course that changes
< sipa> reca: as explained in the issue, we don't actually rely on github for maintaining the integrity of the code
< sipa> cfields: what would you expect?
< reca> sipa: for me it doesn't really matter who owns Github the problem is that this tool is not open-source
< wumpus> I'd like to invite Empact (Ben Woosley) and ken281222 (Chun Lee) to the organizations, as they've been contributing very actively, everyone agree?
< achow101> wumpus: ack
< sipa> wumpus: ack
< cfields> ack
< sipa> reca: that's a fair point, but not an urgent issue
< wumpus> thanks
< wumpus> reca: I just started a mirror on a Tor hidden service FWIW
< reca> sipa: maybe it's no an urgent issue but it would be nice to have some official git mirrors as a reference to Github
< sipa> reca: i agree!
< reca> wumpus: thx
< phantomcircuit> wumpus, why is that so long? new .onion format?
< wumpus> phantomcircuit: yes, v3 have longer pubkeys
< sipa> ed25519, right?
< cfields> sipa: not sure, I suppose
< sipa> cfields: do you see the semantics of each of the helper functions at the beginning of the file?
< wumpus> sipa: indeed!
< cfields> sipa: sure, I see how those operate on multiple values.
< sipa> cfields: same for Round :)
< sipa> each of the a,b,c,d,e,f,g,h variables contains 1/8th of the state for each of the 4 hashes being computed
< cfields> sipa: I just don't see where distinct values are actually loaded, other than wX.
< sipa> Read4
< sipa> it returns a 128-bit value which contains 32 bits from each of the 4 input blobs
< sipa> the w0...w16 variables are a moving window of the last 16 round constants
< sipa> which are the expanded form of the input
< cfields> sipa: aha, there it is. Yes, I was misunderstanding. Thank you.
< cfields> sipa: I kept getting caught up on the fact that it looks like Sigma0/Sigma1 could be computed in-parallel for 3 or 4 values at a time.
< sipa> yup, and it is :)
< cfields> so I was expected the loads to be more local that way
< gmaxwell> sipa: I don't think anyone cares much about SSSE3 vs SSE4 support.
< sipa> gmaxwell: okay!
< bitcoin-git> [bitcoin] theuni opened pull request #13400: sha256: small speedup for sse4 path. (master...sha2-avx1) https://github.com/bitcoin/bitcoin/pull/13400
< gmaxwell> sipa: ^ you should see if thats a speedup on ryzen. :P
< sipa> gmaxwell: good idea!
< cfields> sipa: I thought that's what your 5% number was?
< sipa> gmaxwell: actually, that's totally irrelevant, as AVX2 will be used there
< sipa> the benchmark was just a way to spot check that cfields' benchmark wasn't too specific for his system
< sipa> but i can test there too
< gmaxwell> Yes, sure but it would be interesting. If its slower on ryzen it's probably also slower on other AMD that doesn't have avx2.
< sipa> gmaxwell, cfields: ugh, 10% slower on Ryzen
< gmaxwell> lol.
< cfields> sigh
< sipa> sense, it makes none.
< gmaxwell> I think wumpus has some pre-ryzen amd stuff?
< sipa> but cpu scheduling is complicated
< wumpus> yep
< sipa> wumpus: does it have AVX2?
< sipa> ("avx2" in /proc/cpuingo)
< wumpus> AMD A9-9420
< wumpus> oh let me see
< wumpus> sipa: it does
< sipa> wumpus: dang :)
< wumpus> I have two other AMD systems I can check though
< sipa> wumpus: ideally we find an SSE4 capable system that does not have AVX2
< sipa> ("sse4_1" in /proc/cpuinfo)
< wumpus> this is a "AMD FX-8370" with only "avx" (also sse4_1 sse4_2)
< sipa> cool! can you benchmark bench_bitcoin -filter=".*SHA256D64.*" there before and after #13400 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/13400 | sha256: small speedup for sse4 path. by theuni · Pull Request #13400 · bitcoin/bitcoin · GitHub
< wumpus> also an even older one, but that doesn't have sse4_x
< wumpus> sure
< sipa> thanks!
< cfields> woohoo, thanks wumpus!
< gribble> https://github.com/bitcoin/bitcoin/issues/13400 | sha256: small speedup for sse4 path. by theuni · Pull Request #13400 · bitcoin/bitcoin · GitHub
< cfields> whoa
< cfields> ok, closing. Not worth playing that game.
< wumpus> sorry
< cfields> no worries. It was a cheap/easy boost, but not enough to miss.
< wumpus> just repeated the test, same result, kind of counter-intuitive, but yes it's how these things go
< cfields> uhmm, whoa...
< cfields> wumpus: mind testing one more time, adding -mavx to SSE41_CXXFLAGS ?
< wumpus> yes, will try
< wumpus> with the patch or both with and without?
< cfields> I just tested with, and got a ~65% speedup. Haven't tested without yet.
< cfields> (also haven't investigated where it comes from yet)
< sipa> cfields: whoa!
< wumpus> will try both then
< sipa> should we provide an sse4+avx implementation (just the same code with mavx enabled)?
< cfields> sipa: if that's reproducible, I'd say that's justifiable. I'm assuming it's pebcak for now though :)
< gmaxwell> that seems bonkers
< sipa> AVX adds 256-bit registers
< sipa> which perhaps the compiler uses as extra register space (instead of spilling to stack)
< wumpus> cfields: this has the results added with -mavx - https://0bin.net/paste/ReThQTAAWhKYfH7x#K99wDsZBBbtqEnc1N44e9UWz2E-t1y2jDhByhD8BBZe - not much difference from before
< cfields> huh. I've repeated mine several times now.
< sipa> looking at the generated code, with -mavx -msse4, the 4-way SSE asm code uses 256-bit registers extensively
< sipa> so it's not unreasonable to expect that on some systems, its performance is affected
< cfields> sipa: do you see an improvement over master?
< sipa> haven't benchmarked yet
< wumpus> cfields: well either it's due to this system, or I'm doing something wrong
< wumpus> -AX_CHECK_COMPILE_FLAG([-msse4.1],[[SSE41_CXXFLAGS="-msse4.1"]],,[[$CXXFLAG_WERROR]])
< wumpus> +AX_CHECK_COMPILE_FLAG([-msse4.1],[[SSE41_CXXFLAGS="-msse4.1 -mavx"]],,[[$CXXFLAG_WERROR]])
< wumpus> that's the correct patch?
< sipa> it's also not unreasonable that the impact of such changes is wildly different on Intel vs AMD cpus
< sipa> wumpus: yup
< cfields> wumpus: yep, didn't mean to imply that you did something wrong :)
< bitcoin-git> [bitcoin] theuni closed pull request #13400: sha256: small speedup for sse4 path. (master...sha2-avx1) https://github.com/bitcoin/bitcoin/pull/13400
< wumpus> I vaguely remember earlier troubles with AVX sha256 and this particular computer
< cfields> well at least it's no worse
< wumpus> bleh, at some point you'd need to benchmark on every specific vendor and model seperately to see what is the best way
< Rebo> hi does anyone here has experience with setting up a bitcoin full node on an azure virtual machine?
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #13402: Document validationinterace callback blocking deadlock potential. (master...2018-05-abc-scheduler-docs) https://github.com/bitcoin/bitcoin/pull/13402
< wumpus> Rebo: better ask in #bitcoin
< Rebo> ah thank you