< bitcoin-git>
[bitcoin] jtimon closed pull request #10822: RPC: Also serve txo from gettxout (not just utxo and mempool) (master...b15-rpc-txo) https://github.com/bitcoin/bitcoin/pull/10822
< esotericnonsense>
a question which I think is related to core dev, apologies if not
< esotericnonsense>
so the RPC interface should only be exposed to trusted clients in the sense of wallet commands etc
< esotericnonsense>
however, is it otherwise expected to be hardened? e.g. if I have some software running in a VM or on another machine, and give it access to the RPC, would it be reasonable to assume that it shouldn't be able to raise privileges and execute commands on the host
< esotericnonsense>
(basically, if i'm -disablewalleted, should I worry about anything other than possible DoS
< jonasschnelli>
esotericnonsense: Even without your wallet enabled you should threat your RPC interface private.
< jonasschnelli>
If you want to access it remotely, use VPN, SSH, stunnel or something.
< jonasschnelli>
Don't expose the RPC interface to the public internet
< esotericnonsense>
jonasschnelli: indeed. i suppose essentially what i'm wondering is how carefully I need to vet software which interfaces with the RPC.
< jonasschnelli>
(you could use an Apache or so reverse proxy with SSL auth)
< jonasschnelli>
I would do it carefully... use a VPN, reverse proxy or connect via SSH and use bitcoin-cli
< esotericnonsense>
for example, core node running on host1, host2 runs some software which interfaces with host1, but host2 is malicious for whatever reason; can host1 be broken into (overflows on rpc commands, etc)
< esotericnonsense>
i guess the actual answer is to run the core node in a sandbox to avoid this coming up at all
< jonasschnelli>
if host2 is assumed to be malicious then it should not be capable to access to the RPC interface
< esotericnonsense>
understood
< esotericnonsense>
for reference i'm going to play around with writing some nodejs code to interface with the RPC and I find npm an utter clusterf.ck to deal with in terms of security :P
< bitcoin-git>
[bitcoin] instagibbs opened pull request #11252: when clearing addrman clear mapInfo and mapAddr (master...recreateaddrman) https://github.com/bitcoin/bitcoin/pull/11252
< cam9956>
i had a question, when i relese the coin does it have to be mined for anybody to get some or when i release it i get a few coins to sell out
< cam9956>
yeah this is about bitcoin, i want to devalop my own coin with the bitcoin source
< meshcollider>
Again, this is for bitcoin *core* development, not general questions sorry :)
< cam9956>
what do you mean by "core development" and is there a irc i can contact for this?
< praxeology>
cam9956: probably #bitcoin would be your best bet
< cam9956>
ok
< praxeology>
oh, your own coin
< cam9956>
yeah with the bitcoin source code
< praxeology>
go to #yet_another_bitcoin_fork
< cam9956>
basically distributing
< cam9956>
as the channel?
< Chicago>
cam9956, They're saying go find another channel because clone coins are off-topic for here as they do not generally pertain to Bitcoin Core development.
< cam9956>
what is bitcoin "core development" though
< meshcollider>
Bitcoin Core is the reference client for bitcoin
< cam9956>
oh ok bye!
< cam8857_>
when i release the coin does it have to be mined for anybody to get some or when i release it i get a few coins to sell out?
< Chicago>
cam8857_, you can have a 100% premine. Just let us know when you release so that we can buy them on the open market.
< kallewoof>
signraw works but sendraw fails in some cases.
< kallewoof>
This function is supposed to find those cases and tell you without actually sending the tx to the network.
< dcousens>
kallewoof: right, but the OP doesn't want to send at all, so that is OK?
< dcousens>
signraw doesn't send either
< dcousens>
?
< kallewoof>
Idea is, you sign, then you verify and if everything is cool you do whatever other last minute checks (double check addy or such) and then you finally sendraw.
< kallewoof>
Or you mkae a tx using custom software and you just wanna see if it will relay without actually sending it.
< kallewoof>
(signing using said custom sw)
< dcousens>
kallewoof: right, but you can still use signrawtransaction in the custom software case
< dcousens>
(I do)
< dcousens>
I leave the private keys blank, and don't have a bitcoind w/ wallet support, and it verifies whether the tx is complete or has errors etc
< dcousens>
kallewoof: eg I just created a tx with bitcoinjs, signed it using bitcoinjs, then signrawtx [txhex, inputs, []], complete: true, then I modified inputs to have a different id, same txhex, and I get a checksig error
< kallewoof>
dcounsens: there are cases where signraw succeeds and sendraw fails, though. This is meant to catch those. Am I misundersatnding you?
< dcousens>
kallewoof: right, signraw will fail for policy reasons, which is why I suggested, why not just a policy check flag?
< dcousens>
rather than a new RPC command
< dcousens>
uh, won't fail***
< dcousens>
signraw won't fail for policy reasons
< sipa>
signraw _only_ checks script validity
< sipa>
not transaction validity
< sipa>
things like locktime, feerate, inputs unspent, input value >= output value, ...
< bitcoin-git>
bitcoin/master 37495e0 Jeremy Rubin: Reorder C{,Mutable}Transaction for better packing
< bitcoin-git>
bitcoin/master 59e1789 Wladimir J. van der Laan: Merge #8330: Structure Packing Optimizations in C{,Mutable}Transaction...
< GAit>
is github user promag in IRC?
< GAit>
oh he usually is just not now, fair enough
< sipa>
sometimes
< sipa>
he's here now :p
< promag>
:)
< promag>
´
< promag>
sup?
< promag>
GAit: need something?
< GAit>
oh I just wanted to say I am not ignoring your suggestion re: 11099 with the multiple failure modes of DumpMempool, i.e. the test doesn't exercise the "return false" within the exception handler but i think that's much harder to cause and i wanted to minimize changes to DumpMempool or how it affects other callers
< GAit>
and also i wanted to thank you for all the feedback, very valuable
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11260: travis: Check that default datadir is never created, Check SHAs only once (master...Mf1708-travisYaml) https://github.com/bitcoin/bitcoin/pull/11260
< wumpus>
looks like we have a few new warnings:
< wumpus>
base58.cpp:308:6: warning: ‘bool {anonymous}::CBitcoinAddress::IsScript() const’ defined but not used [-Wunused-function]
< wumpus>
base58.cpp:298:6: warning: ‘bool {anonymous}::CBitcoinAddress::GetKeyID(CKeyID&) const’ defined but not used [-Wunused-function]
< wumpus>
promag: mind to addresss ^^ in #11259?
< promag>
np
< wumpus>
at least, if it's not result of a bug or something, haven't looked in detail yet
< wumpus>
so the compiler can identify unused *methods* now? that's interesting - i guess because it's local to the file
< wumpus>
that was with gcc 6.3.0, btw
< promag>
wumpus: rebased, new commit
< promag>
wumpus: I think so too
< wumpus>
promag: thanks, will rebuild to check
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11261: scripted-diff: Use <cxxx> instead of deprecated <xxx.h> when including C compatibility headers (master...cinclude) https://github.com/bitcoin/bitcoin/pull/11261
< promag>
is it me or github mail notifications are lagging?