< meshcollider>
promag: it seems like that is the only one he has commented on
< meshcollider>
other than one review and one utACK on other PRs
< phantomcircuit>
jonasschnelli, i believe leveldb is designed to survive sudden power loss
< phantomcircuit>
however in general the rpi series of hardware randomly corrupts sdcards
< gmaxwell>
echoing what phantomcircuit said, I left a system going on a perpetual reindex loop for months with a remote power switch killing the system every one in a while, and never corrupted anything.
< gmaxwell>
but if your SD card or whatever goes spamming nonsense in unrelated places when its power cut during a write than nothing reasonable is going to save it.
< esotericnonsense>
so unless i'm just being really daft one issue with RPi is that it's not obvious that it's even off.
< esotericnonsense>
on my RPi2 if you issue a shutdown then the LEDs etc. externally look the same whether it's fully booted but not doing anything, or shutdown but with power connected.
< esotericnonsense>
if you have say, a screen connected to i2c it'll keep power and persist whatever was displayed on it
< esotericnonsense>
i wouldn't be surprised if people (including me) without even knowing pull the plug whilst it's mid-write because there is no 'simple' way of knowing you can unplug power now
< phantomcircuit>
esotericnonsense, the issue with the rpi's isn't so much about sudden power off without shutdown events, but rather that during power off they seem to write gibberish to the sdcard randomyl
< esotericnonsense>
nice. don't think i've ever had that but then, i wouldn't know. :P
< phantomcircuit>
i've seen systems where everything was set readonly come back up with corrupt sdcards
< phantomcircuit>
and yeah most of the time you wouldn't notice because it's corrupted something irrelevant
< esotericnonsense>
i have zfs on an sdcard here. haven't tried scrubbing it. that might be fun. not on the rpi though. can't be arsed.
< phantomcircuit>
the rpi's specifically seem to trash sdcards
< phantomcircuit>
i honestly have no idea why
< gmaxwell>
phantomcircuit: I dunno if that's rpi's fault as much as just SDcards being ... consumer hardware.
< phantomcircuit>
gmaxwell, i've had it happen with cards that were fine in other applications
< phantomcircuit>
like in an apu2 as the main filesystem where i forgot to reduce the volume of log messages
< phantomcircuit>
but then that card instantly failed in an rpi3
< TD-Linux>
rpi runs its cards at 3.3v
< TD-Linux>
so they tend to run hotter than systems that crank it down to 1.8v
< TD-Linux>
that said, 3.3v is totally in spec.
< jb55>
my rpi has killed like 3 sdcards so far
< TD-Linux>
it also does help to get more expensive ones in my experience.
< tradermyx>
If the "wallet/blabla.dat" part is used for a non-wallet-specific call, it will still work, right? The "documentation" is very vague on this, but I don't wanna have to keep track of what kind of call it is for no good reason.
< tradermyx>
And I assume only the basename() is to be used for the "wallet name", since it can now be a path since v0.17?
< sipa>
tradermyx: what do you mean with "usin" part of a wallet name on a non-wallet-sprcific call?
< phantomcircuit>
sipa, iirc bitcoin-cli accepts a -- style parameter
< tradermyx>
No... Talking about the API.
< tradermyx>
With the RPC URL having that added to it.
< sipa>
tradermyx: all non-wallet RPCs are included in the wallet-specific URLs
< tradermyx>
Good...
< phantomcircuit>
ooh
< phantomcircuit>
hmm maybe that's what bitcoin-cli is doing
< sipa>
phantomcircuit: yes, if you specify -rpcwallet it changes the URL
< phantomcircuit>
sipa, are people still in tokyo?
< sipa>
yes
< kanzure>
discussing wallet stuff at the moment
< echeveria>
TD-Linux: better advice is just not to try to run bitcoind on a RPI in general, it’s a miserable experience and doesn’t really serve any purpose. coin selection alone takes tens of seconds.
< echeveria>
it’s something close to a denial of service attack on the network to have people encouraged to run garbage-tier listening peers. god forbid you end up with them as your compact blocks peer.
< TD-Linux>
echeveria, dunno, I'll take it over an aws node
< MarcoFalke>
wumpus: I put up a draft for the next release schedule #14438
< tradermyx>
provoostenator: Somebody told me that it's automatically generated from the in-application help data.
< tradermyx>
provoostenator: Which makes me wonder why it's not up instantly and automatically after 0.17 was released.
< sipa>
tradermyx: there is a tool to generate the website from the rpc output
< sipa>
that tool is not run automatically
< sipa>
it'sjsut some guy (karelb) doing it
< karelb>
indeed
< karelb>
there is a PR on bitcoincore.org now
< tradermyx>
That is very strange.
< tradermyx>
Should be part of the "release script" or "build process" or whatever.
< tradermyx>
It's little things like this that makes me worried/concerned about the future of Bitcoin.
< tradermyx>
(Not "whining"...)
< tradermyx>
The actual program seems to have tons of improvements and stuff.
< tradermyx>
As if there are really people working to improve it.
< midnightmagic>
... I wish you'd just pick a nickname and stick with it, dude.
< tradermyx>
It's been enormously tricky to figure out how to "integrate" with the Bitcoin Core API, though.
< gwillen>
tradermyx: that kind of thing is practical in a commercial envrionment where the same people have universal permissions across everything involved in making a release
< gwillen>
that kind of automation is not very practical in an open source release process
< tradermyx>
I guess.
< gmaxwell>
"perform more release work in secret and without public participation, please, so that no one can see that all steps aren't executed perfectly at the same time... as the centerally adminstered reveal would make it all look atomic and instant..."
< aj>
gmaxwell: ?
< karelb>
tradermyx: yeah I have added the rpc docs into the release process recently.
< karelb>
it could maybe be automated by travis or Jenkins or something like that, maybe?
< phantomcircuit>
karelb, i dont so much reason since the help is in the very tool people are trying to use
< karelb>
true but... sometimes people just google stuff
< karelb>
like me :)
< karelb>
I often Google stuff even if it would be simpler to just type "help" (or "man")
< tradermyx>
Nobody with a brain would do that.
< tradermyx>
Stop promoting that evil fucking company and their shitty spam generator.
< karelb>
....ok
< karelb>
anyway, you can also think "hmm the new bitcoind has some new PSBT API, I want to know how it looks like before I install it"
< karelb>
"I wonder what the new scanutxoset is about"
< karelb>
etc
< jamesob>
is `make clean` inexplicably deleting src/test/scriptnum10.h for anyone else?
< luke-jr>
jamesob: already diagnosed; I think MarcoFalke and fanquake_ are fixing
< promag>
should ask in stackoverflow instead? or ask for more details?
< tradermyx>
Question: why is the wallet name specified in the actual URL in the calls to the RPC API? Why isn't it just another parameter?
< tradermyx>
Not that it makes a huge difference, but it's an odd design choice to me.
< phantomcircuit>
wumpus, is your brain working again? :P
< tradermyx>
Anyone?
< phantomcircuit>
tradermyx, it's not a parameter you want to explicitly specify everytime you use it
< tradermyx>
phantomcircuit: But it's a dedicated function anyway?
< tradermyx>
phantomcircuit: AKA you never specify all the stuff each time, but only the uniqueness about the call (AKA the command and its parameters).
< phantomcircuit>
tradermyx, it's so you can have an rpc connection object which knows which wallet it's using in the caller
< tradermyx>
phantomcircuit: But it already knows that if I use it part of the POST parameters?
< tradermyx>
But alright... there is "some good reason" which I simply don't understand right now.
< sipa>
tradermyx: it's so that existing applications don't need code changes; they only need to be configured to use a different url
< tradermyx>
I see. In my case, it would be an identical amount of work, though.