< tloriato>
Hello. Good morning/night. I was wondering where I could find a Javascript documentation on how to interact with a Bitcoin full node via JSON RPC? Sorry if I'm in the wrong place, I'm new to the space and trying to develop some things
< sipa>
#bitcoin or bitcoin.stackexchange.com
< tloriato>
thanks!
< kallewoof>
After a day of stats, I have some updates regarding the mempool optimization for fees. Still WIP but looks interesting so far. Blocks 482344 ~ 482418:
< kallewoof>
[bench::fees ( conservative|non-mempool)] 11940 ests, 11940 overshoots (313659 more sat/k/tx), 0 undershoots (0 less sat/k/tx)
< kallewoof>
[bench::fees (non-conservative|non-mempool)] 12198 ests, 11940 overshoots (187298 more sat/k/tx), 258 undershoots (14414 less sat/k/tx)
< kallewoof>
[bench::fees ( conservative| mempool)] 12745 ests, 11913 overshoots (85940 more sat/k/tx), 820 undershoots (23188 less sat/k/tx)
< kallewoof>
[bench::fees (non-conservative| mempool)] 13102 ests, 11879 overshoots (56938 more sat/k/tx), 1216 undershoots (23577 less sat/k/tx)
< kallewoof>
For mempool use, 6.5% undershot (conservative) / 9.3% undershot (non-conservative) (<-- still needs work)
< kallewoof>
On average 227719 sat/k (72.6%) was saved for conservative / 130360 sat/k (30.4%) for non-conservative.
< meshcollider>
15,999 stars on bitcoin repo, so close to 16k lol
< wumpus>
luke-jr: also I'd hope libevent-based P2P is really coming for 0.16
< luke-jr>
wumpus: right, but we'd hoped that for 0.14 (0.13?) as well
< luke-jr>
I agree nobody probably really cares about building without libevent tho :p
< luke-jr>
even the person asking me to make it available in Core, didn't want to uninstall libevent to test a patch
< wumpus>
yes, let's hope a bit more in the direcction of cfields :)
< wumpus>
heh
< wumpus>
btw thanks fanquake achow101 meshcollider for being so quick to do gitian builds (and cfields for uploading the sigs quickly), we're getting really fast at doing rcs/releases :)
< luke-jr>
does that mean we should up the sig requirement to 5 signers? :p
< wumpus>
would make sense to do that for final releases
< wumpus>
vmbuilder should be reasonably easy to build from source IIRC
< luke-jr>
upgraded since the Talos "1" that never happened
< wumpus>
"Expected to ship Q4 2017"
< wumpus>
once they actually ship something I might
< luke-jr>
IIRC they're saying they might not do a second batch. ☹
< wumpus>
bleh, if not, I wouldn't really feel comfortable owning it in the first place, will be impossible to get either hardware or software support for a one-off product
< luke-jr>
at least the CPU isn't one-off :p
< luke-jr>
I suppose if it's successful, there will probably be another one-off next-gen in 5 years or so
< wumpus>
I'll just keep waiting for a reasonably fast RiscV board, heck even if only on par with current ARM SoC would be enough to do *something*, especially with a bunch of them
< wumpus>
you get your gitian result 2 week late but at least it was built on secure hw :P
< luke-jr>
ME neutering seems to make good progress otoh
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11190: [tests] Remove unused imports (script.OP_0 and script.sha256) (master...remove-unused-import-op_0) https://github.com/bitcoin/bitcoin/pull/11190
< bitcoin-git>
[bitcoin] AkioNak opened pull request #11191: RPC: Improve help text and behavior of RPC-logging. (master...fix_rpc_logging) https://github.com/bitcoin/bitcoin/pull/11191
< instagibbs>
jnewbery, a number of folks I think, including btcdrak
< jnewbery>
btcdrak - is @bitcoincoreorg blocking people? If so, why? Seems counter to an open development culture
< btcdrak>
jnewbery: Jeff isnt blocked anymore. It was a relic from a long time ago.
< jnewbery>
thanks btcdrak
< instagibbs>
"// The mining code doesn't (currently) take children into
< instagibbs>
// account (CPFP)"
< instagibbs>
this isn't true anymore, right?
< jnewbery>
correct - mining codes looks at packages of transactions
< instagibbs>
should this commit be revisited in light of that? fc8c19a07c20ab63f6a69f7494f486204d8f2b7a
< cencen>
voila... bitcoin price is up!
< cencen>
hello, Yogaqueef
< Lauda>
cencen wrong channel
< kanzure>
"Can't read block from disk" is probably stale block?
< sdaftuar>
kanzure: i don't think stale blocks would trigger that in general -- just disk corruption or pruning i think.
< jnewbery>
instagibbs: bitcoind wallet doesn't allow fees to be bumped for transaction that have descendants in the wallet or mempool, so in practice I don't think it's much of an issue. sdaftuar would be the man to ask
< kanzure>
sdaftuar: if no pruning enabled then it would have to be disk corruption ya?
< sdaftuar>
kanzure: i think so. only other case i can think of is if you upgraded a pre-segwit node after segwit activated, triggering the rewindblockindex code. i assume that's not something you did?
< kanzure>
testnet node in this case
< kanzure>
no recent upgrade
< sdaftuar>
then yeah disk corruption sounds like the culprit
< kanzure>
is it terribly unhealthy to do fast bitcoind kills in succession and will that cause disk corruption
< sipa>
what kind of hardware?
< kanzure>
embarrassing
< kanzure>
is there an easy way to fix this? delete latest block file somewhere?
< sipa>
nope
< sdaftuar>
kanzure: restore from your last backup?
< sipa>
sorry, the block files are needed to even rewind the utxo set
< kanzure>
other than restore, what is the hard way?
< sdaftuar>
restart with -reindex
< kanzure>
oh that's doable
< sdaftuar>
did you get that error in response to an rpc call?
< kanzure>
2017-08-29 17:25:07 ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=77, nPos=109816002)
< sdaftuar>
ouch
< sdaftuar>
oh that's a pretty recent file at least
< kanzure>
well i am getting the error in a loop, if you refer to the timestamp, heh
< sdaftuar>
i think -reindex is the way to go
< kanzure>
great thank you
< sdaftuar>
instagibbs: jnewbery: yeah i think that code could be revisited now that the mining algorithm is better. i don't think there's any real DoS potential there, but i think there's room to be more conservative to ensure that miner income is being maximized.
< sdaftuar>
instagibbs: probably the easiest thing to do would be to add one more check, that the ancestor feerate of the new transaction is higher than that of all the transactions being replaced.
< sdaftuar>
and maybe we could loosen the requirement that all the new inputs already be confirmed
< instagibbs>
ok, not knowledgeable enough to really dive into improvements, was having a discussion that revolved around bip125/Core design of replacement
< ryanofsky>
kallewoof, if you want to post your overshoot/undershoot code somewhere, I could combine it with #10443 and test it with data going back to july
< gmaxwell>
Can someone who understands twitter better explain to me what blocking someone does there... what would blocking someone on the bitcoin core account accomplish?
< instagibbs>
it's an annoying feature tbh, all it does is stop a logged in account that is blocked from seeing messages and/or pinging notifications
< instagibbs>
which is easily routed by just loading twitter not logged in...
< gmaxwell>
Then why would any role account (like bitcoincoreorg) ever block anyone? Seems like all it would do is create offense for no gain.
< instagibbs>
Perhaps to sift through mentions easier, although muting does this, and doesn't offend
< instagibbs>
muting is just so you don't "hear" about that person talking about your account, or see their tweets when people RT them
< instagibbs>
I think a policy of "only muting" is totally appropriate, regardless of motivations
< gmaxwell>
I suppose it may have the effect of lowering the incidence of crap posting your announcements, but just causing them to not see them more often.
< gmaxwell>
But otherwise it seems completely useless.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11193: Terminate string *pszExePath after readlink and before passing to operator << (master...null-terminate-after-readlink) https://github.com/bitcoin/bitcoin/pull/11193
< jnewbery>
I *think* blocking would also prevent the blocked party from replying to your tweets, so other people won't see their crap. So I think it is appropriate to block pure trolls/impersonators.
< gmaxwell>
If it blocks replies then is serves a real purpose.
< gmaxwell>
So, lets assume for a moment that we do that.
< gmaxwell>
We put announcements of new releases out on twitter, if there is an account that constatly replies the the announcements with offtopic fudding than then diverts the replies into noise arguing with the... I think blocking them would be appropriate.
< gmaxwell>
(arguing with them)
< gmaxwell>
People doing that, incidentally, was one of the reasons I wasn't super excited about the project having a twitter account to begin with.
< luke-jr>
yes, Twitter blocks prevent replies, which is why I actually block people on it (typically I don't)
< luke-jr>
(personally)
< gmaxwell>
You can actually see jgarzik going into offtopic conspiracy fud stuff in his response to morcos too, ... :(
< bitcoin-git>
[bitcoin] jnewbery closed pull request #10882: [Do not merge] Stop advancing best block and shutdown node if keypool drops below critical threshold (master...keypool_topup) https://github.com/bitcoin/bitcoin/pull/10882
< jnewbery>
yes, all a bit disappointing (and totally unnecessary). I think the twitter account is fine and useful if it's used purely to push technical information about the project. And I agree that blocking blatant trolls is totally appropriate.
< cfields>
morcos: ^^ the quick speedup I forgot to push last week
< gmaxwell>
cfields: tip: try to make the oneline git summaries maximally useful, "optimize decay" is a little opaque, e.g. it coudl mean making the esimator more accurate by changing the delay constants.
< cfields>
gmaxwell: ack
< gmaxwell>
cfields: aside. have you caonsidered branch that skips decay processing when there is no data?
< cfields>
gmaxwell: see pr description. I figured morcos/sdaftuar would know immediately where to stick that, so I didn't look too hard. i wasn't satisfied that my quick hack wouldn't break something.
< cfields>
gmaxwell: on a different note, do you happen to have any fun simulation, or even live node that would be good for stress-testing high connection counts?
< cfields>
I'm finally happy enough with the functionality of these libevent changes. Been working well locally for the past few days
< cfields>
It doesn't show much benefit here, but I'm assuming it will be much more obvious with a few hundred peers
< sipa>
cfields: i believe sdaftuar or morcos have a replay-network-traffic simulation
< cfields>
sipa: ooh, good thinking
< sdaftuar>
sipa: cfields: i don't actually...
< cfields>
sipa: back to your corner.
< sdaftuar>
my replay network traffic simulation mocks out the network to test the rest of bitcoind
< cfields>
ah
< sdaftuar>
i suppose we could build a simulator that plays back historical data via p2p
< gmaxwell>
cfields: I don't really, unfortunately, not much more than your prior fuzztester.
< cfields>
hmm, i guess something as dumb as ~500 peers sending over-sized (1mb or so) pings might cut it
< cfields>
sdaftuar: that could be helpful. I'll think on it.
< esotericnonsense>
not sure if this is offtopic for the channel. is there a discussion anywhere surrounding why bitcoin uses bdb 4.8? it seems to me that the only real concern with using 5.x is that users would not then be able to downgrade wallet software, but how likely/useful is that anyway (and also, providing recompiled binaries for older releases with 5.x seems possible now?)
< Dizzle>
It's not off-topic. A fine question. My guess is it's also a pain to come up with an upgrade mechanism as well.
< esotericnonsense>
it already works, 5.x can use 4.8 wallets but not vice versa