< 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/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
< 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/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