< gwillen>
is there a document or a cohesive policy on how exceptions are used in Core? I am refactoring stuff out of RPC handlers so it can be used in the GUI, and it throws exceptions with descriptive text for the RPC server to return.
< gwillen>
and I'm not sure what to do with them. I can convert them to more generic exceptions, but I assume throwing exceptions out into UI code would do something bad.
< mryandao>
bitcoind uses whatever libsnappy that's provided through the host system yes?
< mryandao>
libsnappy being a dependency of leveldb.
< gmaxwell>
bitcoind doesn't use libsnappy at all.
< sipa>
mryandao: no, our own fork of leveldb has libsnappy support disabled to simplify dependencies
< sipa>
if you build against system leveldb, it will still disable libsnappy at runtime
< gmaxwell>
(also because libsnappy hurt performance for us IIRC)
< mryandao>
ah thank you for that.
< bitcoin-git>
[bitcoin] dongcarl opened pull request #14864: test: Run scripted-diff in subshell (master...2018-12-unset-commit-script-check) https://github.com/bitcoin/bitcoin/pull/14864
< dongcarl>
Looking at our shell scripts... I see a lot of fragile syntax that shellcheck would pick up on. Is it an acceptable PR to refactor those scripts to conform to shell script best pratices?
< gwillen>
dongcarl: maybe step 1 is to propose a change to the coding guidelines to use shellcheck as a linter for shell scripts?
< dongcarl>
Seems like lint-shell.sh already does so
< dongcarl>
Just some warnings are disabled
< gleb>
What currently happens if I get tx INV, send GETDATA and never hear a TX back from that peer?
< sipa>
who is 'i'?
< gleb>
A Bitcoin core node :)
< sipa>
you mean what does bitcoin core do if it doesn't hear back from a tx getdata request?
< gleb>
Yeah, I'm missing the part of code where waiting for a TX message time-outs or something
< sipa>
there is a 2 minute timeout, and then permit asking another peer afaik
< gmaxwell>
gleb: see the logic at the bottom of void CNode::AskFor(const CInv& inv)
< gmaxwell>
lol bottom of void.
< gleb>
Got it, for some reason I thought that if a node sends one GETDATA, it won't send the second one after the same INV from another peer.
< gleb>
That would be highly susceptible :)
< gmaxwell>
right there is a delay... the logic is a bit dumb but sufficient.
< gmaxwell>
e.g. it can't handle the case that it asks and gets disconnected except by waiting for the timeout...
< gleb>
gmaxwell: wait, but if a node gets 2 INVs at the same, it will send 2 GETDATAs, right? (from different peers)
< gleb>
2 INVs with the same hash at the same time*
< gmaxwell>
gleb: no.
< gmaxwell>
well depending on what you mean at the same time.
< gmaxwell>
the will only send one getdata unless someone times out.
< gmaxwell>
which of the two peer gets it depends whos inv the node processed first.
< gleb>
I can censor propagation of your txs then? Once I see your tx in the network, I can start INVing everybody about it and not give TX.
< gmaxwell>
gleb: for two minutes
< gleb>
And if I have 2 IPs then for 4 minutes?
< gmaxwell>
potentially.
< gmaxwell>
(another way the handling is dumb, after timeout the available offers should be considered in random order.
< gmaxwell>
)
< gleb>
gmaxwell: If I start attacking early enough, that won't significantly increase the cost of an attack, because only few nodes will be INVing it along with me. You can think that relay happens "in waves" (just as bitconnect)
< gwillen>
hmm, that's kind of bad for lightning unilateral channel closes, isn't it?
< gwillen>
the attacker already knows the txid before you ever start broadcasting it
< gwillen>
so they can start poisoning the network before they even start the attack
< gwillen>
(it still seems like a nearly-infeasible amount of broadcast spam, which would be detected immediately and network-wide)
< gleb>
If a botnet is 10k nodes and starts before 10% of the nodes knew about a tx, I expect us easily to get 10 minutes delay. It's a very cheap attack in terms of traffic, and requires very trivial mimicking of BTC protocol
< gleb>
I'm saying even IF we implement the trick gmaxwell mentioned (random selection of next peer). If not, it's cheap to delay a transaction forever.
< gwillen>
but since such an attack would be very obvious to everyone, it wouldn't be hard to get consensus to fix it permanently soon after. So it would really only work once.
< gwillen>
(And there are probably more profitable things you can do with a 10k node botnet.)
< ujjwalt>
Hey, I’m new here and I want to start developing Bitcoin apps. I have basic idea about the protocol - enough to understand how the system largely works (keys, basic crypto etc) but where and how do I start if I want to make an app around this. I have a full node running now.
< NicolasDorier>
harding: " I suggested connecting over SPV to a single node that the user trusted."... Then if your trusted node go down, your service go down with it. And what is the advantage of doing it at all? If you have a trusted node, just run getutxosetinfo on both side and you have proof my utxoset has the same UTXOs as your trusted node
< gleb>
This no TX timeout thing also may cause topology inference attacks (similar to "doublespending topology inference" from FC18).
< gleb>
I acknowledge that alternative solutions might be more harmful than the issue I'm bringing up, just thought it's worth mentioning here.
< bitcoin-git>
bitcoin/master 8042bbf Zain Iqbal Allarakhia: p2p: allow p2ptimeout to be configurable, speed up slow test
< bitcoin-git>
bitcoin/master 48b37db Zain Iqbal Allarakhia: make peertimeout a debug argument, remove error message translation
< bitcoin-git>
bitcoin/master 8844588 Wladimir J. van der Laan: Merge #14733: P2P: Make peer timeout configurable, speed up very slow test and ensure correct code path tested....
< bitcoin-git>
[bitcoin] laanwj closed pull request #14733: P2P: Make peer timeout configurable, speed up very slow test and ensure correct code path tested. (master...p2ptimeout) https://github.com/bitcoin/bitcoin/pull/14733
< bitcoin-git>
[bitcoin] laanwj opened pull request #14869: scripts: Add trusted key for Samuel Dobson (master...2018_12_meshcollider) https://github.com/bitcoin/bitcoin/pull/14869
< kanzure>
stevenroose: i'm actually not sure.
< kanzure>
stevenroose: are you asking "can i make multiple rpc requests from other processes and threads?"
< stevenroose>
kanzure: yes
< stevenroose>
well, individual calls are obvious, if you do createrawtransaction and before you can fund, sign and send it, another thread does the same, of course that will fail
< stevenroose>
but more like, f.e. if you fire two sendtoaddress calls at the same time, will they try to spend the same utxos?
< stevenroose>
it appears that sendtoaddress is doing this safely
< stevenroose>
so question would be if the interface claims to be safe for this in all calls
< stevenroose>
or if it says you should not use it concurrently
< kanzure>
stevenroose: i wouldn't expect concurrent use to work. for createrawtransaction/fundrawtransaction if you're planning multiple transactions then usually i've found i need to plan them separately outside of bitcoind.
< stevenroose>
yeah for createraw/fundraw/signraw/sendraw I understand
< stevenroose>
but ok we fixed our issue in elements and have an approach similar to sendaddress, so we should be at least as concurrency-safe as sendtoaddress which is enough :)
< promag>
hebasto: ping
< promag>
regarding #14854, can you detail your steps to see if I can reproduce?
< gleb>
gmaxwell: Yes, 2 minutes per dishonest hop, but adding a new peer to a node is trivial and cheap. Anyway, perhaps I should allocate some time and try inferring the topology :)