< gwillen>
achow101: can you explain the comment "Get all of the previous transactions" in rawtransaction.cpp (in finalizepsbt)?
< gwillen>
it appears to be just using SignPSBTInput to check if inputs are signed -- is it also intentionally mutating the transaction in some way or something?
< gwillen>
or is it safe to replace with "is PSBT input signed"?
< achow101>
that's very likely to be the result of copy-paste from some other rpc
< * sipa>
guesses: the comment was copied from rpcwallet.cpp
< wumpus>
midnightmagic: well... currently only run OpenBSD in VM; and yes, bitcoin builds fine on OpenBSD, there's special instructions for that, which fanquake updated for 6.4 and I'l like to test out but couldn't yet
< midnightmagic>
if I could get netbsd into my talos somehow, I'd be testing in there.
< wumpus>
fanquake: thanks for investigating; glad you could narrow it down to a specific automake change
< wumpus>
midnightmagic: yeah would love to run *BSD on my SiFive board, but that's a pipe dream for now, even a linux kernel that works is hard to find :)
< midnightmagic>
you mean the hifive unleashed?
< midnightmagic>
did you get the expansion board too?
< wumpus>
it's the first time I bothered with fedora as that seems to be the best supported distro for it
< wumpus>
yes that one
< midnightmagic>
i wonder if that page-fault-computing usenix method can be used on the sifive stuff
< wumpus>
FWIW it runs a bitcoin + lightning node + tor fine :D
< midnightmagic>
wow, nice.
< wumpus>
yes it's kind of cool; I do use nbd for storage, though—no expansion board was too late for that
< midnightmagic>
still unavailable, too, apparently.
< wumpus>
I got one of the last unleashed boards, literally a week later the option to order them was closed :)
< midnightmagic>
This kind of hardware, I don't mind learning new assembly for.
< sipa>
that's risc-v?
< midnightmagic>
yeah
< sipa>
nice
< wumpus>
midnightmagic: yeah it's not much work either, the instruction set is super straightforward
< midnightmagic>
runs bitcoin okay? how long did it take to sync with nbd..?
< wumpus>
the only thing I really had to get used to, is that loading longer immediates is split over multiple instructions instead of in-line (such as auipc and jlr for jump)
< wumpus>
midnightmagic: I don't think so!
< midnightmagic>
you have to do weird things like load in addresses in four pieces, carefully shifting them and arranging them..
< wumpus>
at least I hope risc-v is the last assembly language I ever have to learn and it will take over everything xD
< wumpus>
yes, bitcoin runs ok, syncing doesn't go super fast but it was a bit faster than most ARM boards from a few years ago I've tried on
< midnightmagic>
wumpus: it's *huge*. The PowerISA reference manual is 1240 pages.
< wumpus>
the SD card driver was kind of broken so that's why I'm using nbd, nbd in contrast to nfs is very easy to set up, no need to bother with username mappings, rpc servers, and horrible stuff like that
< midnightmagic>
"Appendix F. Power ISA Instruction Set Sorted by Mnemonic" => 17 pages is tiny little writing.
< wumpus>
that's kind of much for a *reduced* instruction set platform
< wumpus>
though it's still less than Intel's multi-volume bibles
< midnightmagic>
56 opcodes per page.
< midnightmagic>
What the hell does "Transaction Abort Doubleword Conditional Immediate & record" even mean lol and yet, after discovering the weird futureAlienTech IBM put into it. Dude.
< wumpus>
heh those pages are either scribbled with occult markings or ▓███▒▓█-censored ... nah, sounds like some combinatorial complexity blowup
< wumpus>
'let's make 2^n variants of instruction and all document them separately, that's a way to fill a book'
< midnightmagic>
If a pcie card tries to twiddle ram without a dma properly setup, the power chips intercept it and helpfully fire off an OS handler do you can decide what to do about it yourself. I guess on normal hardware it just lets it get away with it.
< wumpus>
anyhow, risc-v is nice and clean, though if it really catches on with many vendors i'd expect ehere might be a cambrian explosion of (even proprietary) extensions at some point though
< midnightmagic>
I have a supermicro sas card here that tried to munge main memory *on boot* and had to be disabled by the pre-OS checks. wtf.
< sipa>
wumpus: i just learned from wikipedia that the r in risc does not refer to the size of the instruction set, but to how complex operations per instruction can be (in particular, how many memory accesses)
< midnightmagic>
well I sure hope so.
< wumpus>
sipa: oh! TIL too
< sipa>
and there have been CISC platforms with just 8 instructions
< wumpus>
midnightmagic: I agree, it'd be a form of open competition which is good
< ossifrage>
I thought early RISC was along the lines of what can be done in an cycle (with most instructions being register to register)
< midnightmagic>
still burns me atmel dropped avr for arm. wumpus: well if it does anything interesting with the bitcoin node, I know I at least would love to hear about it.
< ossifrage>
I always found it cleaner to decouple memory to register instructions from register to alu to register instructions
< wumpus>
ossifrage: apparently yes that's what it means
< wumpus>
definitely, having, all the addressing modes for every instruction is a lot of complexity, and then you end up with things like 'MOV is turing-complete'
< ossifrage>
If you don't have a pipeline writing a RISC CPU in verilog is surprisingly simple.
< wumpus>
yes handling timing and pipelines is where it gets complex
< fanquake>
MarcoFalke If you want to merge #14497 I think that's ready to go.
< wumpus>
maybe they'll re-open production at some point! at least the unleashed board, despite the outrageous price, were popular enough for a new batch
< wumpus>
midnightmagic: it's reassuring that the IOMMU on that board is consistent and doesn't make an exception for boot-time memory twiddling
< wumpus>
midnightmagic: btw re: POWER cna you weigh in on #14066 please
< fanquake>
wumpus Would we be able to fork emil-e/rapidcheck to github.com/bitcoin-core/?
< midnightmagic>
sure
< fanquake>
Marco has a fork that we currently use for depends, however it'd be good to move to a newer version for some bug fixes and a potentially simpler build.
< fanquake>
We need the fork so we can create our own archive, because emil-e/rapidcheck isn’t tagging releases yet.
< wumpus>
fanquake: yep; do we need our own fork of that?
< * luke-jr>
wonders if we really need to ban regexs due to reviewer regex-illiteracy :x
< wumpus>
banning regexps above a certain complexity would make sense, I think, also because it's usually symptomic of a deeper issue
< wumpus>
e.g. *why* is the underlying data so complex, does it need a real lexer/parser (because it's a programming language or markup language), or is the data mangled in an earlier step (which might be avoided in the first place)
< wumpus>
and yes long regexps are extremely hard to read, though most regexp engines provide means of splitting them into lines and commenting them, but still
< promag>
MarcoFalke: should provide fs::relative implementation to our source? :/
< luke-jr>
wumpus: I'm not seeing any non-forking-the-code way to use readelf as a library; the regex is fairly straightforward
< fanquake>
Chris_Stewart_5 See the channel history, we've forked rapidcheck to bitcoin-core, could be a chance to use the new make install method etc. You should have gotten invite to /bitcoin and /bitcoin-core as well.
< luke-jr>
[06:55:43] <fanquake> We need the fork so we can create our own archive, because emil-e/rapidcheck isn’t tagging releases yet. <-- uh, that's no reason for a fork - am I missing something?
< luke-jr>
if you want an archive, just use the ones github generates..
< wumpus>
luke-jr: there are some python modules that can do elf parsing, but agree it's suboptimal to introduce such a dependency; nm might be a good suggestion though depending
< wumpus>
... on whether its output is better
< luke-jr>
its output seems far worse
< luke-jr>
same column-based output, but with single letter stuff you need the manpage to understand
< wumpus>
luke-jr: ok, I think it's not *that* complex understanding what it does
< wumpus>
regarding fs::relative, is this a new API that did get introduced in a new c++ standard? does anyone know why doesn't it exist on xenial?
< wumpus>
oh wait—it's a *boost* thing, fs is boost::fs
< promag>
right, 1.58 doesn't have it
< wumpus>
we need to support 1.47 according to dependencies.md
< wumpus>
so using that is really out of the question
< wumpus>
at least without fallback
< luke-jr>
I thought we were trying to avoid boost anyway?
< promag>
1.47?
< promag>
ah right, min version
< promag>
err,
< promag>
I'll submit a fix
< wumpus>
luke-jr: really can't in this case until there's a replacement for boost::filesystem
< wumpus>
(which would require a newer c++ than 11)
< wumpus>
it's fairly straightforward to redefine the fs namespace then
< luke-jr>
oh well
< wumpus>
promag: thanks!
< wumpus>
luke-jr: I know it gets tiring but moving away from boost is really a long-term project
< wumpus>
it needs to be done without interfering with anything else and there's so many different concernt to juggle
< luke-jr>
wumpus: well, if it serves a purpose, I'm fine with it :p
< luke-jr>
better than re-inventing
< wumpus>
yes, exactly,
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14530: scripted-diff: Use RPCHelpMan on RPCs with no args (master...Mf1810-rpcHelpMan) https://github.com/bitcoin/bitcoin/pull/14530
< Sentineo>
hm does anybody else have a different behavior with multiwallets in testnet vs mainnet?
< Sentineo>
the testnet version ignores multiple wallets, even though they are specified with testnet.wallet directive. Loading a wallet from rpc works, then wallet.dat is marked as [default]. When I try to make "loadwalelt wallet.dat" again it crashes - core dumped. On mainnet bitcoind correctly tels me the wallet is already loaded + does not ignore the wallet directives in the config file.
< bitcoin-git>
[bitcoin] promag opened pull request #14531: Replace fs::relative call with custom GetRelativePath (master...2018-10-getrelativepath) https://github.com/bitcoin/bitcoin/pull/14531
< promag>
wumpus: MarcoFalke ^
< bitcoin-git>
[bitcoin] luke-jr opened pull request #14532: Never bind INADDR_ANY by default, and warn when doing so explicitly (master...rpcbind_explicit) https://github.com/bitcoin/bitcoin/pull/14532
< kakobrekla>
< karelb>
MarcoFalke thx for feedback on the RPC stuff, will reply tomorrow after I sleep on it
< phantomcircuit>
wumpus, they're unlikely to do another run of the same chips for sifive, im guessing that was recouping the cost of the smallest run they could get
< phantomcircuit>
wumpus, but that also means the next one might be a more fully baked thing
< bitcoin-git>
[bitcoin] mrwhythat opened pull request #14533: wallet: ensure wallet files are not reused across chains (master...wallet-file-reuse-prevention) https://github.com/bitcoin/bitcoin/pull/14533
< wumpus>
phantomcircuit: on one hand I hope they do improve it, on the other, I hope it doesn't mean my board is no longer supported
< phantomcircuit>
wumpus, i mean what does supported even mean for a dev board like that
< phantomcircuit>
usually you're lucky to get insanely hacked together kernel source
< wumpus>
welll fedora and debian distributions target it now because it's the only RISC-V board that supports Linux
< phantomcircuit>
how about a 2.6.x branch with random bits from 4.x in it?
< phantomcircuit>
which is no joke the norm for embeded type dev board things
< wumpus>
kernel is just a matter of time, they're working on getting everything upstreamed
< phantomcircuit>
yeah that's my point
< phantomcircuit>
it seems documented enough to actually do that
< wumpus>
they more or less did, got it to boot but had some problem with the network interface
< wumpus>
(with mainline kernel I mean)
< wumpus>
it's *certainly* not as bad as some ARM boards, as you say with ancient kernels
< phantomcircuit>
wumpus, also it seems most of the poll() issues have to do with unconnected sockets and using it as a sleep
< wumpus>
but you're right, it's not that big a concern in this case, I'm just too use to ARM SoCs where the next thing means the previous one is dropped
< phantomcircuit>
which im avoiding completely now
< phantomcircuit>
so im thinking we can use poll() on windows as long as it's not used on unconnected sockets
< wumpus>
using unconnected sockets as a sleep wut?!?
< wumpus>
well unconnected sockets shouldn't be emitting any events I guess
< wumpus>
but it should be unnecessary to pass them to poll/select, you can use either function as a sleep by not passing anything...
< wumpus>
as for using poll() on windows, be careful, I don't think that's very common, either because it's known as flaky or because it's only been introduced in more recent versions
< gmaxwell>
It's also not terribly important on widows. Select uses a linked list there and doesn't have an FD range limit.
< wumpus>
exactly...
< phantomcircuit>
wumpus, no im saying the main select/poll loop doesn't have any sockets which haven't connected
< phantomcircuit>
we have another thing that does that
< phantomcircuit>
or maybe im misunderstanding the way this is all setup
< phantomcircuit>
the windows bug is about sockets where you call connect non-blocking and then select it
< wumpus>
but things like this is why I preferred using libevent, it chooses the best polling abstraction for the OS, and is pretty well tested because it's used by Tor
< wumpus>
introducing this into our own code means having to handle all who-knows-what OS dependent edge cases ourselves
< phantomcircuit>
wumpus, the first step to using libevent is to move to a callback style
< phantomcircuit>
which we cna do while still using the loop
< phantomcircuit>
(which is what libevent is doing internally)
< wumpus>
yes, cfields was working on this at some point
< wumpus>
to be clear I think it's fine to move to poll but I *expected* it to be much less of a hassle
< wumpus>
I think it makes sense to focus on UNIXish OS and forget windows just leave that at select
< wumpus>
it seems like you're trying to extend the scope of this too much
< phantomcircuit>
wumpus, im just thinking about what to do next, need to cleanup the current pr a bunch before it's ready
< phantomcircuit>
so i was thinking if i was going to do anything that would make that harder on accident
< bitcoin-git>
[bitcoin] jbampton opened pull request #14534: Enable flake8 rule E225 which checks for missing whitespace around op… (master...flake8-fix-E225) https://github.com/bitcoin/bitcoin/pull/14534
< booyah>
btw, why not asio, instead of all this problems with pool/libevent and all
< phantomcircuit>
booyah, asio and libevent are both callback based
< phantomcircuit>
while the current logic is polling based
< phantomcircuit>
improving what's there is less error prone than switching the entire paradigm
< sipa>
one step at a time
< wumpus>
asio used to be used for the RPC server, that was pretty awful, also we don't really want to add any boost dependencies
< booyah>
wumpus: what was afful there, in that rpc?