< Ironeo>
Does anyone know of any Bitcoin ATM's in Evansville, Indiana ??
< Ironeo>
Guess not.
< sipa>
#bitcoin
< LumberCartel>
Ironeo: Patience is a virtue. It's common for many folks on IRC to lurk for hours before responding to questions.
< * LumberCartel>
agrees with sipa that #bitcoin is the better place to ask that particular question.
< Ironeo>
My sincere apology
< Ironeo>
LumberCartel, Thx
< kakobrekla>
say you have a transaction with multiple outputs and multiple inputs resulting two inputs getting assigned the same amount, how do you uniquely identify those two 'subtx'es (preferably using bitcoind rpc)?
< jonasschnelli>
kakobrekla: what do you mean with "uniquely identify"?
< jonasschnelli>
And what is a 'subtx'?
< kakobrekla>
so in one 'transaction' (one txid) you 'move' btcs from multiple outputs to multiple inputs, correct?
< kakobrekla>
one transaction (has unique id) could have outputs o1, o2 and o3... 'reasigning' the coins to i1, i2, i3...
< kakobrekla>
and it could be that i1 'used' in that tx twice
< kakobrekla>
so i1 can get same amount assigned twice, all inside one tx
< kakobrekla>
(iirc i had such case happening a few months ago, struggling to find the 'offending' tx atm)
< kakobrekla>
i want to make sure that im not processing a tx twice so i have a limitation of unique key over 3 fields (txid, input address and amount)
< kakobrekla>
but this can malfunction because of the case mentioned above
< meshcollider>
kakobrekla: if I understand what you're asking correctly... Outputs of a transaction are referenced by index as well as txid, in the order they are given in the raw transaction (e.g. index 0, index 1...) Not by amount. So with a transaction with two outputs of equal amount, each can be uniquely identified
< meshcollider>
But this question should probably be directed at bitcoin.stackexchange.com
< luke-jr>
FYI, apparently Debian is planning to put Bitcoin Core back into stable.. :x
< NielsvG>
why is that a bad thing?
< luke-jr>
they don't actually really support their stable releases
< luke-jr>
stuff often tends to just stagnate even if there's fixes available
< * luke-jr>
wonders how they're handling libraries these days
< promag>
luke-jr: regarding the dynamic ui from string, also possible with qml, not sure if it pays off
< wumpus>
NielsvG: yeah the problem is that stable never gets updated, so they end up with age-old releases of bitcoin core, even though it's kind of important to stay up to date because of security updates, network behavior etc
< wumpus>
being stuck with gcc 4.x is one thing, but being stuck with an old bitcoin core version can be actively harmful. It's the same situation that browsers are in.
< wumpus>
you don't really want to be running a firefox from 2013
< wxss>
BlueMatt: doesn't the client try to re-download a corrupt block?
< gmaxwell>
wxss: not if the node corrupted it itself.
< gmaxwell>
if it came in corrupt, sure.
< gmaxwell>
but if it came in, you saved it, then read it again and find it corrupt... no.
< wxss>
ty, good to know
< BlueMatt>
we're not good at recovering from hardware errors, but, really, we shouldnt be good at recovering from hardware errors...if your hardware errors, you should fix your hardware before trying to rely on it for storing money......
< gmaxwell>
well there are only a limited set that can be recovered from.
< gmaxwell>
if an output goes missing, for example, there can be no recovery but a reindex.