< gurjeet>
I am looking bitcoin developer tatorial how i can setup bitcoin exchange
< gurjeet>
can any body advise me
< meshcollider>
gurjeet: you should probably take this to #bitcoin not here
< gurjeet>
thanks
< jonasschnelli>
Has anyone experimented with Jetson TX1 (NVIDIA) and Bitcoin Core?
< kabaum>
Why are the sequence of other inputs zeroed when signing an input with SIGHASH_NONE or SIGHASH_SINGLE?
< GAit>
jonasschnelli: isnt the jetson just some arm board with some reasonably powerful gpu for opencl/cuda? most use cases ive seen involved opencv
< jonasschnelli>
GAit: it's just a SOC. You either need the dev kit or your custom ext.
< jonasschnelli>
GAit: The GPU power would go pretty much unused for a full node.
< jonasschnelli>
GAit: but the CPU, SATA feature and memory would make it a good choice for a full node in a bbox
< jonasschnelli>
But a custom board with LAN, I2C for a little b/w screen, SATA/SSD, etc. would something that would have to been built
< GAit>
jonasschnelli: maybe lemaker banana pro, has eth, has sata, doesn't have the powerful gpu but we don't need that. Otherwise x86 the apu2c4 isn't too bad (maybe a bit old nowdays)
< GAit>
non that many boards out there with sata and decent amounts of ram unfortunately
< bitcoin-git>
bitcoin/master b167951 Karl-Johan Alm: [rpc] Allow getrawtransaction to take optional blockhash to fetch transaction from a block directly.
< bitcoin-git>
bitcoin/master 434526a Karl-Johan Alm: [test] Add tests for getrawtransaction with block hash.
< promag>
wumpus: yes, there are a couple of early returns taht
< promag>
that happen when there is an interrupt
< promag>
or something fails
< wumpus>
promag: strange, maybe the !.. is inherited from the time when that was not the case, otherwise it makes kind of little sense. Though I'm surprised that it causes a crash.
< promag>
actually fRequestShutdown is checked multiple times while the block index is loaded
< wumpus>
ideally returning false, even at the end of the init process, should not cause a crash. But if this works around it, fine.\
< promag>
crash aside, i think at that point it should return true
< wumpus>
it should check that flag at any time that the process is interruptible
< wumpus>
meshcollider: yep
< promag>
wumpus: right, at that point it's not interruptible
< wumpus>
promag: agree
< wumpus>
GAit: jonasschnelli: indeed, it seems any reasonably modern ARM board, even with a USB stick or SD card for storage, can keep up with the chain once it's synchronized. Additional i/o and CPU speed will contribute to the initial sync, and when catching up after it's been off.
< wumpus>
(as well as towards serving blocks to others if you want that)
< Sentineo>
yeah I am running a full node on an odroid for 7 months now
< Sentineo>
and mainly the assembler optimisation helps a lot
< wumpus>
we should probably consider making the assembly optimization be the default on ARM
< CubicEarth>
sat/byte seems to have become the default way people talk about fees. What about we changing the fee selector / estimator in core to display fees in those same terms?
< wumpus>
that's just a factor 100, right?
< CubicEarth>
from the 'recommended' selector, yes, factor of 100.
< CubicEarth>
For the custom part, there is no 'satoshi' option, and there is no 'byte' option
< wumpus>
were it to be redesigned from scratch I'd agree with you. I think changing it now is too dangerous.
< wumpus>
for the RPC interface people already have software that uses the current convention, for the GUI people already have the habit of entering /kb numbers, it's kind of a fight upstream to change it
< CubicEarth>
because of confusion from the change?
< wumpus>
yes
< wumpus>
I do agree that for new users it would be less confusing
< CubicEarth>
Well, perhaps just some addition information beside what is given. 1.24291 mBTC/kB (124.291 satoshis/byte)
< CubicEarth>
It's the double conversion that makes it 'harder'
< wumpus>
that's ok with me
< CubicEarth>
giving the extra information?
< Sentineo>
yeah a conversion info would be enough I think - better than no option
< Sentineo>
and wumpus yeah, making the asm optimisation on arm the default would be cool. It realy make noticable difference.
< wumpus>
CubicEarth: yes
< CubicEarth>
Cool! I'll see if I can follow the proper protocol on github to make the idea legit
< wumpus>
I don't personally think at least that adding the information in another unit and mentioning that unit will cause confusion. The danger is mostly when entering fees (e.g. the custom fee).
< luke-jr>
can anyone think of a reason that might cause block=00000000000000000961eb789c07cc05be9609821e9c3e5bcc4094c332a22d4f height=383488 log2_work=83.598077 date=2015-11-14 06:58:23 to be rejected for missing/spent inputs? :/
< wumpus>
weird? corrupted database? has 114442 confirmations so it's safe to say it should be valid
< luke-jr>
yeah. user says he's having problems syncing on two different machines (TBD if it's the same height)
< wumpus>
the only thing I can think of is either a corruption that happens to have excised that record (maybe in the bloom filter portion of the leveldb file?), or that it somehow was missed while writing to disk
< CubicEarth>
Did they sync directly from one machine to the other?
< wumpus>
or miscellaneous problems caused by malfunctioning hardware, though I'd usually expect a CRC error first
< luke-jr>
CubicEarth: not sure, but that shouldn't matter
< luke-jr>
he said new install, so I assumed latest.. guess I should tell him to try that
< wumpus>
the 'dirty' part worries me
< wumpus>
also that commit is not part of our repo
< wumpus>
maybe knots?
< luke-jr>
yeah, looks like it's Knots 0.14.0
< luke-jr>
still old either way
< Sentineo>
are the leveldb keys documented somewhere? Having hard time to find it.
< wumpus>
leveldb *keys*?
< Sentineo>
for the chainstate
< wumpus>
ohh that kind of keys
< luke-jr>
Sentineo: txdb.cpp
< wumpus>
right, that one has all the (de)serialization logic and prefixes
< Sentineo>
ah cool!
< Sentineo>
thanks
< wumpus>
if you're trying to write external troubleshooting code in python this might be of help: https://github.com/laanwj/blockdb-troubleshoot Though currently there's nothing for chainstate in there, just block indexes.
< wumpus>
but it builds a leveldb python module that can be used to inspect bitcoind's files without making it incompatible, as most system leveldbs would do
< Provoostenator>
CubicEarth: #11564 (I'll link to the above chat there)
< wumpus>
oh we already had an issue open for that, thanks Provoostenator
< Sentineo>
ah even better, I am trying to understand how the db is set up, I would like to extract the fees only somehow. Right now I have an app that shows fees in real time and it kills my odroid. So I will have to create a separate db just to get the fees, as it creates too much stress on the system to RPC all inputs and compute the fee.
< wumpus>
be aware that the databases are not an interface, the format might change at any time, so please don't parse them in a production app
< Sentineo>
not a production app, just a learning tool
< Sentineo>
but goot to know
< wumpus>
then it's fine
< Sentineo>
RPCing would take ages, but is much safer, agree
< wumpus>
RPC batching helps if you need to do a lot of queries
< wumpus>
if you really need the whole utxo set, well I tried adding functionality for that once in #7759, but streaming safely seems impossible with the current http server
< wumpus>
the only documentation of it is in ./configure. secp256's configure at that, not bitcoin's.
< hkjn0>
hm, right. so I guess that L1289-1290 in bitcoin's configure.ac would be where to pass through the config flags to secp256k1: AC_CONFIG_SUBDIRS([src/secp256k1])
< wumpus>
yes
< wumpus>
I also discovered that by accident, FWIW
< wumpus>
would make sense to document it somewhere though I'm not sure where
< hkjn0>
yeah, I am new to some of these tools myself, but the wiring of automake/autoconf with several different projects is definitely not trivial
< wumpus>
aj: we might do completely away with the priority labels, I don't anyone is using them for anything in practice
< wumpus>
priorities really only make sense if they're discussed weekly in the meeting, and we already have a 'high priority for review' project which is what someone should be looking for if they want to do something high priority
< aj>
wumpus: makes sense
< BlueMatt>
jonasschnelli: there are two ReadBlockFromDisk's - one requires cs_main to read non-const CBlockIndex fields, one does not
< Provoostenator>
The transaction does show up on the Transactions screen and Overview screen. I'm assuming they use the same table, but assuming stuff is generally a bad idea :-)
< Provoostenator>
What's a good practice for adding debug log statements to this area of the code?
< Provoostenator>
Receiving funds on a legacy (testnet) address doesn't trigger a notification either.
< Provoostenator>
Instagibs: I wonder if this is related to the pending balance issues
< instagibbs>
might be
< instagibbs>
I'm seeing issues too
< Provoostenator>
Maybe a transaction not getting fully commited to a db?
< instagibbs>
it's entering mempool but not being applied to balance, randomly
< Provoostenator>
Or some flushing thing.
< instagibbs>
I don't think so
< instagibbs>
my guess is the p2sh stuff is tripping up ISMINE logic somewhere
< instagibbs>
confirming it makes it stick, which means it's some mempool/unconfirmed interaction
< Provoostenator>
IsMine is done at the wallet level right? So are you able to produce these issues with just RPC?
< instagibbs>
yep
< Provoostenator>
Ok, that narrows is down a lot
< instagibbs>
ok, I just sent confirmed coins from p2sh to p2sh, stopped, restarted, it's gone
< instagibbs>
easy to reproduce here
< instagibbs>
2017-12-06 15:57:30 Imported mempool transactions from disk: 1 succeeded, 0 failed, 0 expired, 0 already there
< instagibbs>
so it hits mempool, yet wallet is barfing
< Provoostenator>
"gone" means the bug is gone?
< instagibbs>
no, funds are gone from unconfirmed or confirmed
< instagibbs>
i believe they should be considered confirmed, since they're from yourself
< Provoostenator>
I think so too. I'm recompiling master now, but when I tried that a few days ago on master, sending to self is not shown as pending. Total balance is just reduced by fees. Presumably because the wallet is allowed to spend unconfirmed change.
< Provoostenator>
However even on master, restarting changes what's displayed. I can't remember how though, will try again in a bit.
< Provoostenator>
I there any way to boost compilation speed by spinning up a few EC2 nodes?
< Provoostenator>
Back in my iOs days, this type of buggy behavior usually was a result of using the database on the wrong thread.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11838: qa: Add getrawtransaction in_active_chain=False test (master...Mf1712-qaRpcRawTx) https://github.com/bitcoin/bitcoin/pull/11838
< Provoostenator>
But obviously it could be something completely different here.
< instagibbs>
ugh, getbalance api. what a trainwreck
< instagibbs>
going to debug once it re-compiled with --enable-debug...
< instagibbs>
conclusion: unconfirmed to-self payments will never enter balance on restart, fixing
< achow101>
instagibbs: is that present in current master?
< achow101>
or just 11403
< instagibbs>
master
< instagibbs>
remind me again where triggering rebroadcast is done during normal operation?
< instagibbs>
wallet rebroadcast*
< instagibbs>
IIRc it's a signal somewhere I cannot find, heh
< instagibbs>
yeah found old PR where ryanofsky thought it was unused code and tried removing it
< achow101>
hah, lol
< instagibbs>
wondering why ReacceptWalletTransactions doesn't use RelayWalletTransaction
< ryanofsky>
heh, that was a more embarrassing pr
< instagibbs>
eh, i had a hard time finding it again on my own
< instagibbs>
:P
< instagibbs>
I have a minimal fix for it, but wondering if we can do better. Seems brittle.
< Provoostenator>
#11839 for anyone interested
< gribble>
https://github.com/bitcoin/bitcoin/issues/11839 | dont attempt mempool entry for wallet transactions on startup if alr… by instagibbs · Pull Request #11839 · bitcoin/bitcoin · GitHub
< cluelessperson>
is bitcoin core planning on implementing lightning built in?
< sipa>
i don't know, are you? :)
< BlueMatt>
jamesob: wait, are you seeing this on reindex
< BlueMatt>
or during normal operation?
< sipa>
BlueMatt: looks like reindex to me
< sipa>
(it's processing blocks from 2015 in his dump)
< jamesob>
yep, reindex
< BlueMatt>
sipa: hmm, my rss is reliably 500MB+ more than dbcache listed in debug.log
< BlueMatt>
and thats true of 0.15.1 too, afaict
< sipa>
sure, but not 5GB
< BlueMatt>
yea
< sipa>
during early reindex it's around 300MB on top of dbcache for me on 0.15.1
< sipa>
near the end of the chain it's probably a bit more
< hkjn0>
just curious, do we currently have graphs somewhere of memory consumption / other resource usage over time for nodes built at different commits on master?
< hkjn0>
even if it took many hours to gather the data and only could be done rarely (say once per day) it might limit the range of commits where a leak could sneak in..
< BlueMatt>
not afaik :/
< sipa>
that would be nice to have
< sipa>
heap usage during reindex graphs
< sipa>
as well as performance graphs
< hkjn0>
cool, I'll start taking notes / hacking something up on that..
< BlueMatt>
zcash has some stuff to do that
< BlueMatt>
may want to look into copying their stuff, dunno
< hkjn0>
hmm, maybe this is going on a tangent, but would such regular measurements that also showed IBD time be useful? or is that measured automatically somewhere? (i know people have done one-off measurements of different releases..)
< sipa>
hkjn0: no, that would be awesome to have, and we currently don't have it
< jamesob>
hkjn0: +1
< jonasschnelli>
hkjn0: that would be nice. sdaftuar once mentioned that he has something like a network bypasser...
< jonasschnelli>
Because you want to measure IBD without measuring the network stack
< jonasschnelli>
(that would be another thing though)
< sipa>
you can benchmark reindex-chainstate instead
< sipa>
jonasschnelli: ReadBlockFromDisk itself doesn't, but reading the disk pos information from CBlockIndex does
< sipa>
(as it's mutable data in case you're pruning)
< jonasschnelli>
sipa: that means that pindex->GetBlockPos() (accessing nFile, nPos) needs cs_main?
< sipa>
yes
< jonasschnelli>
Oh.. then ReadBlockFromDisk should be refactored to allow the actual disk access without cs_main
< BlueMatt>
<BlueMatt> jonasschnelli: there are two ReadBlockFromDisk's - one requires cs_main to read non-const CBlockIndex fields, one does not
< BlueMatt>
<BlueMatt> jonasschnelli: most obvious cs_main-needing-bit: GetBlockPos reads CBlockIndex.nChainState
< jnewbery>
aj: delayed pong
< aj>
jnewbery: nice
< aj>
jnewbery: i guess you've seen pr 4 on your repo now?
< jnewbery>
aj: I hadn't, I'm a little behind. I'll take a look now
< aj>
jnewbery: okay, well that's the content of the ping :)
< jonasschnelli>
BlueMatt: thanks. Got it. will update the PR soon
< jnewbery>
aj: thanks - I've commented on your PR. Looks good to me
< cfields>
jonasschnelli: still around by any chance?
< aj>
jnewbery: i guess the right approach for dropping LEEWAY is for me to go through all the outstanding PRs and comment on the ones that add tests to fix the name, and drop LEEWAY once the second PR goes in and there aren't any pending PRs that haven't adopted the newnaming scheme. should be easy to semi-automate
< cfields>
jonasschnelli: please ping me when you have a few min to look at the signing cert stuff
< jonasschnelli>
cfields: currently on the go.. will be back at my desk in about 9hs
< cfields>
jonasschnelli: np. Not sure if I'll still be around, though. I'll try to hop on before bed.
< jonasschnelli>
okay.. I'll ping you and we will see
< cfields>
jonasschnelli: thanks!
< BlueMatt>
sipa: typo?
< BlueMatt>
#11825 is definitely not fixed by "final TODOs for release notes for 0.15"
< gribble>
https://github.com/bitcoin/bitcoin/issues/11825 | When running bitcoind I keep getting - boost::filesystem::space: Operation not permitted · Issue #11825 · bitcoin/bitcoin · GitHub