< wumpus>
jonasschnelli: have tried it on odroid C2, was a bit disappointed at the perfomrance - I don't have a XU4
< wumpus>
jonasschnelli: do have a i.mx8 evaluation board prototype, which seems to be really fast, but don't really dare run a bitcoind sync on it, afraid it will overheat
< wumpus>
regarding storage on the odroid C2 there's not that much options, only USB2.0, and no SATA
< wumpus>
I eventually used network block device and a SSD w/ the 1GB ethernet, but that's kind of cheating, and it still wasn't really fast, I didn't have time to investigate further
< wumpus>
also the thing overheats like crazy
< sipa>
the debug.log on my c2 is weird
< sipa>
it seems like it stopped doing anything for about 8 hours
< jonasschnelli>
eMMC would perform better?
< wumpus>
sipa: mine didn't stop for 8 hours but there were lots of unexplained pauses during block validtion
< wumpus>
jonasschnelli: not sure about eMMC speeds, I don't think they're much higher than general MMC ones
< wumpus>
at least it's just a dumb flash card (but embedded) not a real SSD
< wumpus>
ah yes eMMC5.0 is a lot faster
< wumpus>
<wumpus> 14763950080 bytes (15 GB, 14 GiB) copied, 127.03 s, 116 MB/s <- read benchmark from a eMMC on i.MX8, don't know the write speed
< kallewoof>
Does gitian require you to run inside a VM or is it possible to run it directly? I keep having issues with lxc. ("lxc-execute: start.c: lxc_spawn: 1094 Failed to find gateway addresses. / Failed to spawn container "gitian".")
< jonasschnelli>
kallewoof: I run it directly host -> LXC
< wumpus>
you don't need to run gitian in a VM but it will always spawn one level of VM at least
< kallewoof>
OK, great! At least I'm not trying to do the impossible.
< wumpus>
re: eMMC speed the problem is that this doesn't really tell how it will perform under our typical leveldb load, which is seek-heavy, not linear-write/read heavy
< jonasschnelli>
wumpus: indeed...
< kallewoof>
Gitian sidenote: is there a reason why it doesn't have #!/bin/bash at the top? I use zsh, which explodes.
< kallewoof>
(gitian-build.sh)
< kallewoof>
Running "bash bitcoin/contrib/gitian-build.sh" works fine so no biggie, just annoying.
< wumpus>
dunno, feel free to add it, shellscripting always suffers from the many different kinds of shells with slightly different syntax
< kallewoof>
OK
< wumpus>
if you use any kind of looping or conditionals please contribute a python script instead, not a shell script, it's always at least 5 iterations of bash-this-syntax-back-to-the-eighties. But anyhow we have this one and it, more or less, works.
< gmaxwell>
wumpus: imx6 has an internal thermal cut, it'll shut off if you overheat it. I assume the same for the imx8? you could put a fan on it
< wumpus>
gmaxwell: I think so! but as I only have it temporarily (to do reverse-engineering to add GC7000 support to etnaviv) I don't want to take too much risk
< Provoostenator>
I've been syncing a Xiaomi A1 Android phone using ABCore for the past week or so (with a few interruptions, but I didn't want the battery to explode while I was away). When it's done, I can mail the logs to anyone who's interested.
< wumpus>
Provoostenator: what SoC does that have?
< gmaxwell>
wumpus: awesome that you're working on it. imx8 looks pretty exciting.
< gmaxwell>
I hope someone does a novena like board with imx8, would be a lot more interesting than the original novena.
< Provoostenator>
I doubt my wifi or home internet is a bottleneck.
< wumpus>
gmaxwell: it's great hw, it seems really fast, rendering at 4k seems to be around the speed it was with 1080p on i.mx6q
< wumpus>
Provoostenator: two seconds per block at height 496K is pretty good for ARM
< wumpus>
gmaxwell: at least solidrun (from cubox) has plans to make a i.mx8 variant, also purism/librem is looking at it for their phone
< midnightmagic>
i wish linux supported the solid-run stuff more
< wumpus>
but I think it will be quite popular, I had some link to some other planned board as well but can't find it right now
< gmaxwell>
wumpus: the fact that its a53 is nice... for a long time I wondered if they'd ever existed.
< wumpus>
midnightmagic: which one? i.mx6 is fully upstream supported, as one of the few ARM SoCs?
< gmaxwell>
oh nevermind I'm confused. a57 is the out of order one.
< gmaxwell>
and imx8 is a72 which is a newer out of order one.
< wumpus>
midnightmagic: that's the cubox-i variant, I've been running stock debian on mine for years. Their first board was based on Marvell Armada 510, not sure that made it upstream.
< midnightmagic>
wumpus: The clearfog pro; the ECC version doesn't exist (in spite of saying it's available on their website) but apparently a pile of the onboard interfaces are glitchy under linux for that board.
< wumpus>
i.MX8 seems to be 4xA53, 2xA72, for the top range model
< wumpus>
midnightmagic: ah another Armada-based one, yes I wouldn't expect anything but pain :)
< midnightmagic>
wumpus: due to NDA restrictions on the documentation?
< wumpus>
midnightmagic: there's that problem, but my experience with their hw is also sort of flakey
< wumpus>
I also remember a glitchy USB interface on one of their SoCs
< wumpus>
it's not impossible that it's a driver issue, but their stance toward upstreaming drivers pretty much means you're stuck with the ancient vendor kernel forever
< shadow_walker>
hi Guys
< shadow_walker>
I need some help to create a bitcoin web wallet
< shadow_walker>
I am trying to understand what is the best approach for the same
< aserc>
hi need assistance - was sent some transaction few days ago from old wallet and transaction is not visible on explorer. Some cborg here told me to upgrade to new node and now have new node and all blockchain was rescaned or not know what was node doing. That transaction is not visible again now what is best option in node to get back that coins. could click abandon transaction but will coins than be in wallet again?
< wumpus>
yes, you try abandoning the transaction and re-spending the coins. Likely it was sent with too little fee.
< wumpus>
but ask in #bitcoin please this is not a help channel
< aserc>
not cborg but cberg
< aserc>
hi
< aserc>
after abandon transaction coins are in wallet no need for assistance for now
< wumpus>
the chance of someone testing it on windows is much higher if we merge it
< wumpus>
as the risk is limited to zeromq support, I think it's acceptable
< fanquake>
wumpus If the changes look ok to you, then I think that's fine. The one thing I was going to look at was adding --disable-curve-keygen to our build options. But that doesn't really matter if you'd just like to merge it now.
< wumpus>
fanquake: there's no rush, if you still want to make changes I'll wait
< wumpus>
we don't use curve-keygen so disabling it mgiht speed up the build by a little bit
< fanquake>
Yes, that was my thinking. I'll push that change up now.
< pbase>
is there an alternative way to keep the chain synced? it is painfully slow!
< larafale>
Hey folks, is it possible for my `bitcoind` to emit only `unconfirmed` tx via ZMQ? currently I received all tx, and when a block arrive I receive the same tx again. I'd like to filter this at the bitcoind level. thx for the feedback guys
< promag>
larafale: not currently possible
< larafale>
hum, thx :)
< promag>
larafale: you might be interested in #8549
< promag>
larafale: in the future don't paste stuff here, use pastebin or github gist for instance
< larafale>
ok no prob, I'm new i don't know the rules :)
< promag>
larafale: you mean REST?
< larafale>
no I made the call from rpc
< promag>
what call?
< larafale>
I'm issuing a getUnspentTransactionOutputs command passing 2 tx hash, above is the result i get
< larafale>
but my concern is why one of the returned utxo has a height way above chain tip
< promag>
I guess that coin is not in a block
< larafale>
you are right, now that the tx got included in a block I get a valid height. But how would you explain the height: 2147483647 when it was not included? if it's not included in a block yet what does height represent and how did that number got there?
< larafale>
is UnspentTransactionOutputs only available throught REST ? I can also run that command throught bitcoin-cli I guess?
< larafale>
I will try
< promag>
you have RPC listunspents
< promag>
listunspent (singular)
< larafale>
yes ok.
< jnewbery>
promag: no need to ping. What's the question?
< BlueMatt>
sipa: if you get particularly bored, I went down a way-too-deep rabbit hole reading mapBlocksUnlinked and pruning logic, and ended up with a few teaks to help my understanding and fix some tiny edge cases as I go....care to take a look at all but the top commit on https://github.com/TheBlueMatt/bitcoin/commits/2017-11-unlinked-blockx-fixes and tell me if its worth upstreaming?
< bitcoin-git>
[bitcoin] rawodb closed pull request #11787: Support for SegWit addresses, change addresses and UI request payment (master...pr/segwit_addresses_master) https://github.com/bitcoin/bitcoin/pull/11787
< promag>
jnewbery: how could I test parallel rescans? so that I know they are really parallel executions server side?
< erichCompSci>
Hello, I was wondering about the following problem. Miners in bitcoin verify transactions in the blockchain by hashing the previous blocks header, transaction data and a nonce value. However, the block is only considered a legitimate block
< erichCompSci>
if the final hash
< erichCompSci>
is below a certain threshold
< erichCompSci>
So...when that hash becomes as low as it can go
< erichCompSci>
how do new transactions get verified?
< erichCompSci>
?
< Murch>
That question is better suited for Bitcoin.stackexchange.com than for this channel. However, the difficulty scales on a range of 2^256, so that scenario is pretty far-fetched.
< erichCompSci>
Well, I'll move over there then, but I'm afraid I don't understand. At some point, it will become nearly impossible to create new blocks, hence miners will be unable to mine new bitcoins...so then how are transactions verified? After all, miners mine by creating the blocks in the blockchain that also verify transactions...so if miners will eventually be unable to mine new coins they must be unable to create new bloc
< erichCompSci>
I'm asking on the developer forum
< erichCompSci>
someone must be thinking of this...how are you going to do the hashing post mining era so that transactions still only take 10 min
< erichCompSci>
new blocks in the chain only take 10 min
< erichCompSci>
sorry
< erichCompSci>
otherwise you have to revisit other things like
< erichCompSci>
block chain lengths can no longer be used for consensus as the hashes don't have a specific value they have to be under...what will the new rule be?
< Murch>
erichCompSci: The sun will go out before our capacity to increase the difficulty runs out. Also, we could just make the difficulty field bigger.
< erichCompSci>
But then there won't be a fixed amount of bitcoins?
< erichCompSci>
if you increase the difficulty field?
< Murch>
erichCompSci: The difficulty is not related to the reward schedule
< erichCompSci>
Okay, thats something I didn't know...I'll look into that thanks
< jnewbery>
promag: not sure what you mean by parallel executions server side
< jonasschnelli>
promag: wumpus: I'm currently overhauling #11281 ... The parallel rescans can best be tested with an artificial temp. sleep in the inner rescan loop
< jonasschnelli>
Need also to rebase because 11281 does not cover "rescanblockchain" (new RPC) yet.
< bitcoincore-slac>
Just wanted to let everyone who has committed code to bitcoin core that there are A LOT of shout-outs and appreciation to all of you the past few days on Slack, Twitter, etc. We know what you have done and continuing to do and can't thank you enough!
< instagibbs>
can anyone point to where the wallet magic value is in the repo, if any
< Provoostenator>
One issue might be that they seem to require a real organization, with legacy world stuff like someone being able to legally represent it. So sounds like this would have to go through some random related foundation.
< Varunram>
Provoostenator: I think organisation means anything, like even a Github organisation
< Varunram>
Because every year, there are baby orgs that get a chance at SoC
< Varunram>
If we do discuss about this tomorrow, I can pitch in more info if you'd like :)
< Provoostenator>
The terms and conditions are pretty specific about legal representation though.
< Varunram>
Most probably, that's only in place to accept stuff, I'll ask around and come back though
< aj>
i think software in the public interest also works and is used by debian and others (spi-inc.org)
< Provoostenator>
aj: that might get controversial quickly. A single individual accepting and forwarding payments seems better. Ideally someone in a jurisdiction where this wouldn't have weird tax implications.
< instagibbs>
phantomcircuit, was just wondering how Core knows it's reading hte "right" bdb, talking with sipa about it now
< instagibbs>
I want to make a wallet that simply won't open with Core master, or anything in the near future
< sipa>
but still want it to be BDB?
< instagibbs>
yes
< sipa>
yes, use minversion
< instagibbs>
yeah, that's what I did for now, removed the footgun surface until its maxed out
< jimpo>
How do people typically profile/time the code on live nodes? eg. Avg validation time for the past N blocks?
< BlueMatt>
-debug=bench
< BlueMatt>
(and -logtimemicros)
< jimpo>
Ah, cool
< eck>
are there pixmaps for bitcoin testnet? i'd like to create .desktop file for bitcoin-qt -testnet=1 that uses the green logo, instead of the orange one
< eck>
nevermind, I found the code that shifts the hue in src/qt/networkstyle.cpp, I will probably submit a PR seeing if I can get testnet and regtest pixmaps checked in for this purpose
< sipa>
i believe so, but i don't think we ever use that
< sipa>
CCoinsCache certainly isn't
< jimpo>
I'm looking into building the tx index in it's own thread instead of ConnectBlock. Do you think 1) it's a bad idea altogether 2) it's safe to keep the txindex data in the blocktree database or 3) the txindex should be rebuilt in its own DB?
< sipa>
i think the txindex should be modified to use the signal mechanism the wallet uses too
< jimpo>
in case 2, multiple threads would most likely access the same CBlockTreeDB, though alternately there could be multiple wrapper objects with a shared pointer to the same underlying leveldb::DB
< sipa>
which afaik matt is moving to support multiple threads
< sipa>
and yes, a separate db sounds right to me - we'd have lower consistency guarantees then, though
< jimpo>
consistency for RPC calls? couldn't it just block until the txindex is in sync?
< jimpo>
GetRawTransaction RPC, specifically
< sipa>
jimpo: perhaps
< bitcoin-git>
[bitcoin] aaron-hanson opened pull request #11792: Trivial: fix comments for ZeroMQ bitcoind args (master...trivial-zeromq-arguments-comments) https://github.com/bitcoin/bitcoin/pull/11792
< sipa>
ideally i'd say there is a separate 'indexing subsystem' which is something you talk to explicitly (perhaps using a separate endpoint like the wallet)
< sipa>
in that case you can easily guarantee consisntency within the subsystem (e.g. you could ask what its best block is, and that would be in sync with its indexing results)
< sipa>
making the rpc block until it's caught up is probably the right approach initially but feels much less clean
< jimpo>
That might make sense for possible future indexes, but would break compatibility for GetRawTransaction, no?
< jimpo>
As far as the separate DB instead of a separate key prefix within the same DB (the current design), it would require a migration, which could be avoided if we were comfortable with concurrent access to CBlockTreeDB.