bitcoin-qt: Reindexing Blocks on Disk : Bitcoin

bitcoin-qt: Reindexing Blocks on Disk

Do I have to do this every time I start up bitcoin-qt or can I save it's progress somehow?
submitted by KevinKelbie to Bitcoin [link] [comments]

bitcoin-qt: Reindexing Blocks on Disk /r/Bitcoin

bitcoin-qt: Reindexing Blocks on Disk /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Bitcoin mentioned around Reddit: The REINDEXING BLOCKS ON DISK again (and again, and again.) /r/pivx

Bitcoin mentioned around Reddit: The REINDEXING BLOCKS ON DISK again (and again, and again.) /pivx submitted by HiIAMCaptainObvious to BitcoinAll [link] [comments]

Reindexing Bitcoin Core

Is there a way to reindex your local blockchain with txindex=1, but not need to verify all the blocks again? The "Reindexing Blocks on Disk" went by quickly enough, but the "Processing Blocks on Disk" is taking forever. Is there a way to tell Bitcoin Core that it's already verified the downloaded blocks after a reindex? Been trying with assumevalid={{ blockhash }}, but it's still seems like redundant and slow work.
submitted by yankthrough to Bitcoin [link] [comments]

Running a Monero Node vs Bitcoin

Edit: warning, rant
Has anyone else had the experience that running/maintaining a Monero node is much easier than Bitcoin? I've been dorking around since July, doing everything in the terminal on a Qubes VM.
Monero comes with simple monerod status and monerod sync_info commands to give you a range of useful info and overview of the current state of your node. Bitcoin has a bunch of individual commands you can aggregate to partially deduce progress, which I have arranged into my own little script. But I didn't find the target block until parsing through the log file. And you have to use other terminal commands like du - ahmd 1 | grep .bitcoin and then run a timer, just to see what your dl speed is, whereas Monero tells you outright. This is important for monitoring your connection over multiple days of download.
I had a hard time finding a BTC wallet that could remotely connect to my own damn node without installing additional software (such as electrum server). I had the silly idea that I could just point a mobile SPV wallet to my own remote node. Hell, the BTC core wallet didn't even have code separation between the node and wallet until just a few months ago.
And now I'm restoring an old Bisq wallet which I only have the seed for. While Bisq was scanning my node, it got hung up at corrupt blk01234.dat file, which actually crashes my Bitcoin node when it receives the data request. So my node had a corruption for 2 months without it knowing, which I only found caz Bisq (I think occurred during a hiccup in transfer from 512GB SD card to SSD).
I tried to drop/replace the blk and rev files, then reindex. But once again, stupid reindex doesnt show progress with any obvious terminal commands. Monitoring disk space, it seemed to be progressing abysmally slow with most my CPU/RAM dedicated to it. I was close to done until a power outage overnight and not enough battery to complete. And even though Bitcoin Core stores everything as individual files, seems it lacks the ability to detect corruption/discard corrupt files and go backwards to the last good file. So I get to start over.
At this point Im actually syncing from scratch in a separate VM while simultaneously reindexing just in case reindex doesnt fix the problem. I give it 50/50.
I know this is kind of a rant. But I wanted to share my experience with some people who can relate or at least understand. It's weird that for a project like Bitcoin, that the core software and UI would be so rudimentary, non-versatile, and even fragile.
Given the ease to configure Monero (including using Qubes qrexec to isolate the wallet in an offline VM), it's straightforward UI and documentation, that it was designed to have separate node and wallet functions, I'm guessing that these problems are much more rare, and easily fixed. That's just an educated wild ass guess of course, since I haven't had any problems.
At any rate, props to the Monero devs for making software that is straightforward and easy to use.
submitted by bawdyanarchist to Monero [link] [comments]

Issues with bitcoin-qt

I know this is frequently posted, but I'm incensed at how absurdly slow reindexing becomes. There's got to be something wrong with the sync mechanism.
I was 100% synced a week ago on my MacBook Pro. Latest version of the client (v0.17.0.1). I rsync'd the whole bitcoin dir (blocks, chainstate, index, etc) to another disk, ran a node on another machine using that copy for a couple of hours, then I stopped the node and rsync'd back to the Mac.
Bitcoin-qt did not like the updated blockchain. The other machine didn't like its blockchain either. Oh well, I thought, maybe it didn't shutdown properly and borked the last block. I'll let it reindex, in a few minutes it'll be grand.
But no. Bitcoin-qt decided that it was time to start over from scratch, ignoring the flawless 99.999% of data on disk. Yay.
That was 10 days ago. At one point several days ago it was about 3 hours from finishing, with a progress of around 19% per hour. A day later progress was at 0.25%. This can't be right, I thought, maybe there's a bug, a memory leak or something. I'll shut it down and restart it. Of course it's going to restart from where it left, right? Right?
No. It started from 0% again.
Several days later, it's at 0.14% and predicting it'll finish sometime next week. CPU is 96% idle, RAM is at 25%, bandwidth is 120 Mb/s and the disk is used by bitcoin-qt and nothing else. It's the only thing running on this Mac and has been for the past two weeks. NOTHING is different between 19% and 0.14% in terms of bandwidth, CPU, RAM, or disk I/O. This very machine, under the exact same conditions, was able to process 19% of the blockchain in one hour.
In the meantime, I can't move my BTC because my wallet, which has all the blocks including the ones containing the transactions with my BTC in them, doesn't believe the blocks are there.
Bitcoin-qt is broken in more ways than one. First, something is causing this absurd variation in performance. Second, it's not saving state, which is particularly painful when it takes ages to get to the end to the blockchain. Is state only kept in RAM? I've seen other threads suggesting a change in the config (dbcache seems to be the main one), but I can't just change the setting without restarting, and restarting is not an option because I'll lose everything again.
Sorry, this is extremely frustrating. I'm thinking of extracting the private key and abandoning the idea of running my own wallet. It's unusable.
submitted by jungle to Bitcoin [link] [comments]

I keep reading people say bitcoin development is stalled

But in practice there's more going on right now than there's ever been in the last few years. You just have to look in the right places. Here's a few days of documented github activity from the bitcoin slack and I've a feeling there are hundreds more people working on Bitcoin projects outside of the work being done by core:
github BOT [6:28 PM] [bitcoin:master] 2 new commits by Daniel Kraft and 1 other: f93c2a1 net: Avoid duplicate getheaders requests. - Daniel Kraft 8e8bebc Merge #8054: net: Avoid duplicate getheaders requests. - Wladimir J. van der Laan
[6:28] [bitcoin/bitcoin] Pull request closed: #8054 net: Avoid duplicate getheaders requests. by laanwj
[6:31] [bitcoin:master] 6 new commits by Pieter Wuille and 1 other: d253ec4 Make ProcessNewBlock dbp const and update comment - Pieter Wuille 316623f Switch reindexing to AcceptBlock in-loop and ActivateBestChain afterwards - Pieter Wuille fb8fad1 Optimize ActivateBestChain for long chains - Pieter Wuille d3d7547 Add -reindex-chainstate that does not rebuild block index - Pieter Wuille b4d24e1 Report reindexing progress in GUI - Pieter Wuille Show more...
[6:31] [bitcoin/bitcoin] Pull request closed: #7917 Optimize reindex by laanwj
Joshua Unseth [9:55 PM] joined #commit-activity. Also, @sjors joined and left.
----- May 19th -----
github BOT [12:08 AM] [bitcoin/bitcoin] Pull request submitted by EthanHeilman

8070 Remove non-determinism which is breaking net_tests #8069

If addrmanUncorrupted does not have the same nKey every time it will map addrs to different bucket positions and occasionally cause a collision between two addrs, breaking the test.
github BOT [1:00 AM] [bitcoin/bitcoin] Pull request closed: #7716 [0.11] Backport BIP9 and softfork for BIP's 68,112,113 by morcos
Eragmus You Should Probably Stop Modding [1:12 AM] joined #commit-activity. Also, @buttmunch joined, @icandothisallday joined, @misnomer joined, @coreneedstostop joined, @xchins joined, @jbeener joined, @jbleeks joined, @whalepanda joined, @grinny joined, @alex_may joined, @mr_e joined.
github BOT [2:46 PM] [bitcoin:master] 5 new commits by Warren Togami and 1 other: 00678bd Make failures to connect via Socks5() more informative and less unnecessarily scary. - Warren Togami 0d9af79 SOCKS5 connecting and connected messages with -debug=net. - Warren Togami 94fd1d8 Make Socks5() InterruptibleRecv() timeout/failures informative. - Warren Togami bf9266e Use Socks5ErrorString() to decode error responses from socks proxy. - Warren Togami 18436d8 Merge #8033: Fix Socks5() connect failures to be less noisy and less unnecessarily scary - Wladimir J. Show more...
[2:46] [bitcoin/bitcoin] Pull request closed: #8033 Fix Socks5() connect failures to be less noisy and less unnecessarily scary by laanwj
github BOT [3:56 PM] [bitcoin:master] 3 new commits by EthanHeilman and 2 others: f4119c6 Remove non-determinism which is breaking net_tests #8069 - EthanHeilman 2a8b358 Fix typo adddrman to addrman as requested in #8070 - Ethan Heilman 7771aa5 Merge #8070: Remove non-determinism which is breaking net_tests #8069 - Wladimir J. van der Laan
[3:56] [bitcoin/bitcoin] Pull request closed: #8070 Remove non-determinism which is breaking net_tests #8069 by laanwj
github BOT [5:18 PM] [bitcoin/bitcoin] Pull request submitted by MarcoFalke

8072 travis: 'make check' in parallel and verbose

• 'make check' in parallel, since the log will take care of clean output • 'make check' verbose, so that test failure causes aren't hidden
Fixes: #8071
github BOT [7:56 PM] [bitcoin/bitcoin] Pull request submitted by rat4

8073 qt: askpassphrasedialog: Clear pass fields on accept

This is usability improvement in a case if user gets re-asked passphrase. (e.g. made a typo)
Victor Broman [8:01 PM] joined #commit-activity. Also, @bb joined, @ziiip joined.
----- May 20th -----
github BOT [12:34 PM] [bitcoin/bitcoin] Pull request submitted by jsantos4you

8075 0.12

debug.data.txt
[12:37] [bitcoin/bitcoin] Pull request closed: #8075 0.12 by sipa
github BOT [3:37 PM] [bitcoin/bitcoin] Pull request closed: #7082 Do not absolutely protect local peers and make eviction more aggressive. by gmaxwell
github BOT [3:44 PM] [bitcoin:master] 2 new commits by Cory Fields and 1 other: 401ae65 travis: 'make check' in parallel and verbose - Cory Fields 1b87e5b Merge #8072: travis: 'make check' in parallel and verbose - MarcoFalke
[3:44] [bitcoin/bitcoin] Pull request closed: #8072 travis: 'make check' in parallel and verbose by MarcoFalke
github BOT [3:58 PM] [bitcoin/bitcoin] Pull request closed: #7093 Address mempool information leak and resource wasting attacks. by gmaxwell
github BOT [6:11 PM] [bitcoin/bitcoin] Pull request submitted by sdaftuar

8076 VerifyDB: don't check blocks that have been pruned

If a pruning node ends up in a state where it has very few blocks on disk, then a node could fail to start up in VerifyDB. This pull changes the behavior for pruning nodes, so that we will just not bother trying to check blocks that have been pruned.
I don't expect this edge case to be triggered much in practice currently; this is a preparatory commit for segwit (to deal with the case of pruning nodes that upgrade after segwit activation).
@sipa
Erik Hedman [6:20 PM] joined #commit-activity
github BOT [8:46 PM] [bitcoin/bitcoin] Pull request submitted by jtimon

8077 Consensus: Decouple from chainparams.o and timedata.o

Do it for the consensus-critical functions:
• CheckBlockHeader • CheckBlock • ContextualCheckBlockHeader Show more...
github BOT [9:26 PM] [bitcoin:master] 3 new commits by MarcoFalke: fac9349 [qa] Remove hardcoded "4 nodes" from test_framework - MarcoFalke fad68f7 [qa] Reduce node count for some tests - MarcoFalke 8844ef1 Merge #8056: [qa] Remove hardcoded "4 nodes" from test_framework - MarcoFalke
[9:27] [bitcoin/bitcoin] Pull request closed: #8056 [qa] Remove hardcoded "4 nodes" from test_framework by MarcoFalke
github BOT [9:48 PM] [bitcoin/bitcoin] Pull request submitted by petertodd

8078 Disable the mempool P2P command when bloom filters disabled

Only useful to SPV peers, and attackers... like bloom is a DoS vector as far more data is sent than received.
null radix [10:15 PM] joined #commit-activity
github BOT [11:34 PM] [bitcoin:master] 2 new commits by MarcoFalke: fab5233 [qa] test_framework: Set wait-timeout for bitcoind procs - MarcoFalke 37f9a1f Merge #8047: [qa] test_framework: Set wait-timeout for bitcoind procs - MarcoFalke
[11:34] [bitcoin/bitcoin] Pull request closed: #8047 [qa] test_framework: Set wait-timeout for bitcoind procs by MarcoFalke
github BOT [11:48 PM] [bitcoin/bitcoin] Pull request closed: #7826 [Qt] show conflicts of unconfirmed transactions in the UI by jonasschnelli
[11:50] [bitcoin/bitcoin] Pull request re-opened: #7826 [Qt] show conflicts of unconfirmed transactions in the UI by jonasschnelli
----- May 21st ----- Rentaro Matsukata [1:56 AM] joined #commit-activity. Also, @evilone joined, @cryptop joined, @thomas5 joined.
github BOT [1:54 PM] [bitcoin/bitcoin] Pull request submitted by gmaxwell

8080 Do not use mempool for GETDATA for tx accepted after the last mempool req.

The ability to GETDATA a transaction which has not (yet) been relayed is a privacy loss vector.
The use of the mempool for this was added as part of the mempool p2p message and is only needed to fetch transactions returned by it.
github BOT [5:48 PM] [bitcoin/bitcoin] Pull request submitted by gmaxwell

8082 Defer inserting into maprelay until just before relaying.

Also extend the relaypool lifetime by 1 minute (6%) to 16 minutes.
This reduces the rate of not founds by better matching the far end expectations, it also improves privacy by removing the ability to use getdata to probe for a node having a txn before Show more...
Sergey Ukustov [9:17 PM] joined #commit-activity. Also, @stoicism joined.
----- Yesterday May 22nd, 2016 -----
github BOT [5:59 AM] [bitcoin/bitcoin] Pull request submitted by jonasschnelli

8083 Add support for dnsseeds with option to filter by servicebits

Opposite part of https://github.com/sipa/bitcoin-seedepull/36. Including new testnet seed that supports filtering.
Required for SW #7910.
Junseth Sock Puppet Account [6:13 AM] joined #commit-activity
github BOT [1:59 PM] [bitcoin/bitcoin] Pull request submitted by gmaxwell

8084 Add recently accepted blocks and txn to AttemptToEvictConnection.

This protect any not-already-protected peers who were the most recent to relay transactions and blocks to us.
This also takes increases the eviction agressiveness by making it willing to disconnect a netgroup with only one member.
github BOT [5:04 PM] [bitcoin/bitcoin] Pull request submitted by theuni

8085 p2p: Begin encapsulation

This work creates CConnman. The idea is to begin moving data structures and functionality out of globals in net.h and into an instanced class, in order to avoid side-effects in networking code. Eventually, an (internal) api begins to emerge, and as long as the conditions of that api are met, the inner-workings may be a black box.
For now (for ease), a single global CConnman is created. Down the road, the instance could be passed around instead. Also, CConnman should be moved out of net.h/net.cpp, Show more...
github BOT [5:14 PM] [bitcoin/bitcoin] Pull request submitted by sipa

8086 Use SipHash for node eviction

github BOT [5:50 PM] [bitcoin/bitcoin] Pull request closed: #6844 [REST] Add send raw transaction by lclc
----- Today May 23rd, 2016 ----- yannie888 [5:21 AM] joined #commit-activity. Also, @myco joined, @er_sham joined, @ethdealer joined.
github BOT [3:23 PM] [bitcoin/bitcoin] Pull request submitted by pstratem

8087 Introduce CBlockchain and move CheckBlockHeader

[3:23] [bitcoin/bitcoin] Pull request submitted by pstratem

8088 Avoid recalculating vchKeyedNetGroup in eviction logic.

Lazy calculate vchKeyedNetGroup in CNode::GetKeyedNetGroup.
submitted by BillyHodson to Bitcoin [link] [comments]

Help appreciated: bitcoin-qt runs fine on mac, copy dir to linux, bitcoind doesn't like it.

TL;DR: It's ok to ignore this post, you're not my personal tech support. :)
I've been running a full bitcoin-qt core node on and off on my mac without issues for years (well, until I hosed my blockchain, had to reindex and came here to vent about how slow it was - fixed thanks to yogibreakdance).
I'm trying to move it to a Raspberry Pi so I can have it running full time inside a closet and have the blockchain always up to date, available to sync back to the mac to move my BTC when I need to.
After copying the whole bitcoin dir to the RPI, bitcoind immediately throws "Error initializing block database", removes most of the chainstate contents and stops.
I tried changing file permissions, deleting everything except the blocks and chainstate dirs, using a config file appropriate for the RPI... No change.
If I run bitcoind -reindex-chainstate, it seems to work. At least it starts reindexing, but I don't have the patience to wait till it finishes, it might take months.
Some possibly relevant info: On the mac side the blockchain is stored on a 4 TB Mac OS Extended external disk, on the RPI side it's stored on a 1TB Ext4 external disk, published through samba and mounted on the mac. I use "rsync -rt --size-only" to move the files. Both bitcoin clients are v0.17.0.1. Empty wallet on both sides. On the RPI side, dirs are 777 and files 600 (I tried 777 too).
A couple of weeks ago I had it running, the only difference was that the RPI drive was formatted as NTFS. I switched to Ext4 because NTFS was slow and didn't play nice with the mac.
My google-fu got me nowhere. Hoping someone here might point me in the right direction.
submitted by jungle to Bitcoin [link] [comments]

TECH HELP: Wallet conflict! Need help retrieving missing BTC from Bitcoin Core Qt wallet after trying to also install and sync BitcoinABC Qt wallet.

Hey guys,
It seems I'm one of those newbies who's dove into the pool before learning how to swim.
A couple of weeks ago I installed the Bitcoin Core wallet and deposited a small amount of BTC to get it off the exchange. After buying some BCH I decided to download ABC Qt wallet to store my BCH.
After installing and running ABC, I noticed the wallet had a transaction in its history showing the exact denomination I had deposited into my BTC wallet, but in BCH!!! (so not the same value) And it was already encrypted.
After waiting a night for it to sync with the network ('processing blocks on disk', and then 'reindexing blocks on disk') the syncing stalled at 81ish percent and I decided to give up on it. I closed the program and opened up the preexisting Bitcoin Core wallet to find that the value had dropped to 0, and it also could not connect to the network and has its network progress stuck at 81ish percent. There seems to be a conflict between the two that's causing the problem because the I was running a full node the the Bitcoin Core wallet which was 100 percent synced last night!
During installation, I noticed the ABC wallet had a transaction in its history showing the exact denomination I had deposited into my BTC wallet, but in BCH!!! (so not the same value)
It seems that the computer recognises the two programs as the same. And now the funds are stuck in limbo. How the hell can I resolve the issue to at least retrieve my funds?
I haven't deleted the ABC app yet in case that makes my funds irretrievable.
(fyi: using an MacBook Pro)
submitted by basedspaceman to btc [link] [comments]

Bitcoin Core 0.10.1 Released

Bitcoin Core version 0.10.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.10.1/
This is a new minor version release, bringing bug fixes and translation updates. If you are using 0.10.0, it is recommended to upgrade to this version.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.

Notable changes

This is a minor release and hence there are no notable changes. For the notable changes in 0.10, refer to the release notes for the 0.10.0 release at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md

0.10.1 Change log

Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates.
RPC:
Block (database) and transaction handling:
P2P protocol and network code:
Validation:
Build system:
Wallet:
GUI:
Tests:
Miscellaneous:

Credits

Thanks to everyone who contributed to this release:
As well as everyone that helped translating on Transifex.
submitted by harda to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.1.2.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.1.2.0, November 12, 2017) from:
 
https://www.bitcoinunlimited.info/download
 
This release is compatible with the Bitcoin Cash with the upcoming planned hard fork that will take place on Nov 13th
 
The main change of this release is the introduction of a new difficulty adjustment algorithm (DAA) that replaced the old EDA (Emergency Difficulty Adjustment). If you are interested in more detail about the new DAA you could find more details in the technical specification.
Another major change is the introduction of a new format to store the UTXO (chainstate) database. The UTXO storage has been indexed per output rather than per transaction. The code has been ported from the Bitcoin Core project. This feature brings advantages both in terms of a faster reindex and IBD operation, lower memory consumption, on the other hand the on-disk space requirement increased of about 15%.
Other notable changes:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/BitcoinCash/doc/release-notes/release-notes-bucash1.1.2.0.md
 
Ubuntu PPA is in the process of being updated.
submitted by s1ckpig to btc [link] [comments]

[dev] A quick update, and a work in progress smart contracts guide

As much as it seems odd saying this with a sticky at the top of the subreddit, I do know some people don't read stickies, so - Dogecoin Core 1.10.0 IS OUT NOW and it's a huge security update you really do need. However, it does require reindexing the blocks on disk, and if you absolutely cannot do so (i.e. you run a service that can't handle the downtime right now), there's also Dogecoin Core 1.8.3 which has the most important parts back ported to it. If you use Dogecoin Core, you need to upgrade to one of these two, seriously.
On that note, we've got about 20-25% upgraded now; there's an (approximate) pie chart at https://docs.google.com/spreadsheets/d/1qPqLy0FFp2mApJBh9a-_cDERCGxP40pnJIdQwGSDYMo/pubchart?oid=208198724&format=image that you can watch if you're really curious. I'm seeing 1.10.0 nodes come online then go offline - if you can keep a 1.10.0 node online, it would be much appreciated. I've got a few EC2 nodes online while the update rolls out, as well, to help support the numbers.
Enough of that, what's coming next? bitcoinj & Multidoge HD work is more or less just rolling along quietly waiting primarily on others at the moment. We're planning out Dogecoin Core 1.11, which will be based on Bitcoin Core 0.12. The big new thing in there will be OP_CHECKLOCKTIMEVERIFY (often shortened to CLTV), which finally lets us use smart contracts securely on the main Dogecoin block chain. It's going out to Bitcoin in their 0.11.2 release, however as we've just released a client, we're going to skip that one (or, it may be produced as a version we test but never release).
I promised everyone a guide to smart contracts, and... well it's gone a bit awry. What I thought would be around 6 pages is now at 9 pages and growing, so it's going to take a while to finish. However, it does cover the basics, and hopefully is enough to both let a general audience understand what smart contracts are, and a more technical audience understand how they can use smart contracts. The document so far is up at https://docs.google.com/document/d/1gk74C_AOfRwmhq1WeTHBxMo3Lelh0QQY6iJLj8tQFzI/pub but there should be further revisions later.
Lastly, testnet - there's still a lot of old nodes on testnet, please update to 1.10.0, especially if you're mining (because someone's generating old v2 blocks and they're causing problems).
I'm away the weekend of the 29th, so that update is likely to be on the 30th instead, but I'll try to get something out that weekend. Might be quiet for a bit while the dust settles on the new release, anyway!
submitted by rnicoll to dogecoin [link] [comments]

Myriad 0.11.2

There you go, it's out there now.

TL;DR. Just give me the bits

Would be great if someone who has the skills & tools could generate us a nice stable MacOS build? Anyone?

Recommended Action

Backup your wallet before using this. You've probably already done that, as I am sure you backup your wallet on a regular basis, right?
Something bad happens, your wallet is destroyed AND you didn't take a backup? Don't blame me.

Naming

A lot of stuff has been renamed to 'Myriad' - however there are a couple of exceptions for reasons of compatibility with older existing versions:

Compilation Notes

If you are compiling yourself, please configure with something like this:
CFLAGS="-O2 -fPIC" CPPFLAGS="-O2 -fPIC" ./configure 
otherwise you'll probably get some errors later on. Additionally, if your CPU supports SSE2, and most modern CPU's do, use this:
CFLAGS="-O2 -fPIC -DUSE_SSE2" CPPFLAGS="-O2 -fPIC -DUSE_SSE2" ./configure 
That will enable the SSE2 version of the Scrypt algorithm. This may reduce the CPU load when syncing the blockchain.
Oh, and there's still some tests that fail if you build and run the testsuite. I've been unable to find the issue, so please, when you fix it, submit a pull request.

Special Thanks

A big thanks to cryptapus and 8bitcoder for their help in getting this release completed. Obviously we must also thank all of the contributors to the Bitcoin Core project, as that is the base that this is all built upon.
And again thanks to 8bitcoder for starting Myriad in the first place.

Downgrading warning

Because this release is based on Bitcoin Core 0.10.0 and upwards, it makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with older versions of Myriad Core or other software:
If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.11.2 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.

Notable changes (Borrowed from Bitcoin Core's Release Notes)

Faster synchronization

Myriad Core now uses 'headers-first synchronization'. This means that we first ask peers for block headers and validate those. In a second stage, when the headers have been discovered, we download the blocks. However, as we already know about the whole chain in advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On recent hardware with a decent network link, it can be as little as 3 hours for an initial full synchronization. You may notice a slower progress in the very first few minutes, when headers are still being fetched and verified, but it should gain speed afterwards.
A few RPCs were added/updated as a result of this: - getblockchaininfo now returns the number of validated headers in addition to the number of validated blocks. - getpeerinfo lists both the number of blocks and headers we know we have in common with each peer. While synchronizing, the heights of the blocks that we have requested from peers (but haven't received yet) are also listed as 'inflight'. - A new RPC getchaintips lists all known branches of the block chain, including those we only have headers for.

RPC access control changes

Subnet matching for the purpose of access control is now done by matching the binary network address, instead of with string wildcard matching. For the user this means that -rpcallowip takes a subnet specification, which can be
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address matches one of them.
For example:
0.9.x and before 0.10.x
-rpcallowip=192.168.1.1 -rpcallowip=192.168.1.1 (unchanged)
-rpcallowip=192.168.1.* -rpcallowip=192.168.1.0/24
-rpcallowip=192.168.* -rpcallowip=192.168.0.0/16
-rpcallowip=* (dangerous!) -rpcallowip=::/0 (still dangerous!)
Using wildcards will result in the rule being rejected with the following error in debug.log:
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). 

Watch-only wallet support

The wallet can now track transactions to and from wallets for which you know all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a possibly vulnerable system. In addition, it can help for (manual) construction of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to importprivkey, but instead takes an address or script (in hexadecimal) as argument. After using it, outputs credited to this address or script are considered to be received, and transactions consuming these outputs will be considered to be sent.
The following RPCs have optional support for watch-only: getbalance, listreceivedbyaddress, listreceivedbyaccount, listtransactions, listaccounts, listsinceblock, gettransaction. See the RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require -txindex, scales better, integrates better with the wallet, and is compatible with future block chain pruning functionality. It does mean that all relevant addresses need to added to the wallet before the payment, though.

myriadcoin-tx

It has been observed that many of the RPC functions offered by myriadcoind are "pure functions", and operate independently of the myriadcoind wallet. This included many of the RPC "raw transaction" API functions, such as createrawtransaction.
myriadcoin-tx is a newly introduced command line utility designed to enable easy manipulation of myriad transactions. A summary of its operation may be obtained via "myriadcoin-tx --help" Transactions may be created or signed in a manner similar to the RPC raw tx API. Transactions may be updated, deleting inputs or outputs, or appending new inputs and outputs. Custom scripts may be easily composed using a simple text notation, borrowed from the bitcoin test suite.
This tool may be used for experimenting with new transaction types, signing multi-party transactions, and many other uses. Long term, the goal is to deprecate and remove "pure function" RPC API calls, as those do not require a server round-trip to execute.
submitted by nzsquirrell to myriadcoin [link] [comments]

Pre-release of the v2.7.0 client for testing

Pre-release of the v2.7.0 client based on the Bitcoin 0.13 codebase. Do not use this release in a production environment, it is purely for testing and will be followed by a Release Candidate.
XBC (Bitcoin Plus) has been ported directly to the Bitcoin 0.13 codebase to allow us to enable SegWit and CSV on the XBC network. This pre-release has Proof-of-Stake block generation implemented and enabled and Secure Messaging via RPC only.
Please note that due to the major changes to block storage on disk that the blockchain has to be reindexed when first run over an already populated data directory from the 2.6 or before client, this process can take several hours so please be patient during this time.
You can download the Windows binary for testing from the following release page. The test release is numbered 2.7.99.0.
https://github.com/bitcoinplusorg/xbcwalletsource/releases/tag/v2.7.99.0
To download ore review source code use the link below, note that the 2.7.0 source code is on the master-2.7 branch.
https://github.com/bitcoinplusorg/xbcwalletsource/tree/master-2.7
Please port questions or feedback from testing the client to the new Telegram group or on this Reddit post.
Telegram - https://t.me/xbcplus
submitted by Bushstar to BitcoinPlus_XBC [link] [comments]

ElectrumX 1.0 released

I have just released version 1.0 of ElectrumX:
https://github.com/kyuupichan/electrumx/
and includes many other goodies.
A single dual-core CPU and 2GB of RAM is all you need to run your own Electrum server; it is light on resource consumption, and runnning it on a separate machine to bitcoind hardly affects performance. ElectrumX will use a little under 20GB on disk for its indices and metadata; this grows by perhaps 1GB every 5-6 weeks.
bitcoind must be a full node without pruning, all you need is to set txindex=1 if it isn't already and reindex. bitcoind's databases currently take up around 125GB on disk.
I'd like to thank hsmiths, bauerj and JWU42 in particular for their help testing the software and running it in various configurations.
submitted by persimmontokyo to btc [link] [comments]

Dogecoin Core 1.10 Beta 1

Dogecoin Core 1.10 Beta 1

Dogecoin 1.10 is a complete rebuild based on Bitcoin 0.11. This means in terms of the code-base we introduced all the changes between Bitcoin 0.9 and 0.11 into this version of Dogecoin Core. We therefore suggest to read the release notes of both Bitcoin 0.10 and Bitcoin 0.11

Upgrading

To upgrade from any version below 1.10 you will need to re-index once, as the block database format has changed. If you run the Qt GUI client, it will prompt you to do so on the first start after the update. If you run a dogecoind daemon, you will need to start it with the parameter -reindex once after you updated. This process can take a few hours, depending on the performance of your machine.

Mining

For this beta release, we decided to disable AuxPoW mining, while further testing is completed. The functionality will be re-enabled in a later release candidate. EDIT: This does not mean we turned off AuxPoW. Just that mining is not possible with this version of the client ;) It will work just like before for everyone else, so this is solely of interest for pool admins.

Notable changes

For further explanation of these, see the above mentioned Bitcoin release notes.

Faster synchronization

Dogecoin Core 1.10 introduces headers-first and parallel block synchronization to greatly reduce the initial blockchain synchronization time.

Watch only address support

It is now possible to add public keys to your wallet that will be held in a "watch only" state. This means you will get information about incoming/outgoing transactions and resulting balance changes. Especially useful to keep track of your paper wallets.

Strict signature encoding (BIP66)

One of the reasons why mining is disabled on this release is the introduction of BIP66 which enforces strict rules about how transaction signatures are encoded and therefore will introduce a new block version (3). These rules will only activate once a certain number of blocks are mined with this new version. To not let this happen too early, mining is disabled for now. NOTE: This is not a hard fork, as all existing wallets will accept version 3 blocks, although they'll fail to enforce the new requirements.

Block file pruning

It is possible to run a Dogecoin node without keeping the full blockchain on your disk. This is currently incompatible with having a wallet on that client due to the fact that some actions regarding a wallet require the full block data. The minimum amount of kept blocks has been changed from Bitcoin to reflect our shorter block times.

General comments

Please backup your wallet regularly and especially before performing this upgrade. Do not copy your wallet.dat while Dogecoin Core is open. Instead you should either use the backup feature you find in the "File" menu or shut down Dogecoin Core completely before you make a copy of your wallet.dat.

Download

You can find all downloads here: https://github.com/dogecoin/dogecoin/releases/tag/v1.10-beta-1
Please let us know about any bugs you find. Either here or on GitHub :) Thanks everyone for their continued support!
submitted by langer_hans to dogecoin [link] [comments]

[Programming Assistance] How can I re-index with the instructions in this article?

Set up instructions
Ran into a problem this morning when I checked the status of the node. The docker container running bitcoind has exited due to an error after only downloading 1/3 of the blockchain. I believe it might be due to a hardware failure according to the link below.
If you try to re-start the docker container that is currently exited, it will stall out again.
When I run docker logs bitcoind_mainnet --tail "100" I'll see an error similar to this
Specifically, ERROR: ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=522, nPos=124229782) (SIMILAR ERROR BUT NOT MINE EXACTLY) I think mine has nfile = a 300 number. I'm at work now and don't have the exact error.
It seems like an easy fix. I have my own bitcoin/lightning node on a local machine and have used the -reindex flag before. I tired using the attached instructions, different than how I implemented my own node, for digital ocean and here I am.
I'm new to docker and still learning. From my understanding, the docker that is running bitcoind is based off the entry point file we created in the medium article instructions.
I need a way to run bitcoind with the -reindex flag. Any suggestions?
submitted by ILIKEWHATUGOT to Bitcoin [link] [comments]

Progress on the block version upgrade

We're at 94% version 3 blocks being mined, vs 6% version 2: http://dogeversion.plddr.eu/
At 95%, any further version 2 blocks which are mined will be rejected by the network (the sort fork). This is important to do because it fixes the security issue that led to Peercoin forking back in November: https://wiki.peercointalk.org/index.php?title=Peercoin_blockchain_fork_of_2015-11-09
If you are running Dogecoin Core 1.8.3 or 1.10, Multidoge 0.16 or the Android wallet (latest), you're fine.
If you're running any older version of Dogecoin Core, and especially if you're mining, you MUST update. There's a lot of security fixes in the new clients, as well as this block update. If you can move to Dogecoin Core 1.10, please do so, and 1.8.3 is available as an alternative for anyone who cannot. On first run 1.10 will reindex the blocks you've already downloaded (rebuilding the index used to find blocks quickly on disk), which takes a while, but it only happens the first time - while this runs it will show you your balance as of the last block it's indexed, so don't panic if your balance isn't correct until the reindex finishes. As always, back up your wallet before starting.
Lastly, one of the big pools that's out of date is CleverMining, and we haven't had any luck contacting them to get them to upgrade. If you have contact details for them, and could pass along this notice, it would be appreciated. If you're mining with them, please check if they're paying out correctly, their BitcoinTalk thread is filling with people with problems: https://bitcointalk.org/index.php?topic=448649.5980
submitted by rnicoll to dogecoin [link] [comments]

Lore v2 QT on Raspberry Pi

Hello,
 
To follow up to mindphuk's excellent piece on building the headless client on Raspberry Pi (https://www.reddit.com/blackcoin/comments/6gkjrw/wip_blackpi_a_stake_device_based_on_raspberry/), I thought if anyone was interested I'd show you how to get the full QT version running on the Pi on the Jessie with Pixel desktop. This works and has been soak tested for several days now on a standard Raspberry Pi 3. I have since added some coins and it stakes a handful of times a day.
 
Running staking Lore clients paves the way for some of the future use cases of BLK utilising the Bitcoin 0.12 (and newer) core tech, including colored coins. So I'm going to leave this one going indefinitely to kickstart the number of Lore clients staking. It's certainly not mandatory but it will be good in the longer term to have a nice distribution of Lore staking clients.
 
The cross-compile which lets you create binaries for multiple platforms didn't work for the QT version on the Pi, so there is more to do than just running the binary unfortunately, as below. There are folks working on some much cleaner solutions than this for the Pi, with a custom front end, and where you won't have to do any mucking about. That is coming soon. In the meantime, if you enjoy a fiddle with such things, here's how to get this QT client working on your Pi.
 
These instructions assume you are starting from scratch with a completely blank OS.
 
Download Jessie with Pixel from: http://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/2017-07-05-raspbian-jessie.zip
 
Note they have since (August 2017) released a version called 'Stretch' which does not work with this guide. I'll see if I can come up with something new for that at some point and link to it here when I have. In the meantime the guide should work with the Jessie image above.
 
Unzip the file and extract the .img file to burn it onto Fresh SD card to boot from (to be safe, use 16GB or larger), using a tool like win32diskimager or Etcher.
 
Assuming you have keyboard/mouse and monitor plugged into your pi, boot it up and the Jessie Desktop will show.
 
Before we do anything else, you should increase the default swap size on the pi, as compiling certain libraries can exhaust the RAM and get stuck otherwise. To do this, launch a Terminal window and type:
 
sudo nano /etc/dphys-swapfile 
 
and Change the CONF_SWAPSIZE from 100 to:
 
CONF_SWAPSIZE=1024 
 
Exit nano with control + x to write out the file.
 
Then, run the following to restart the swapfile manager:
 
sudo /etc/init.d/dphys-swapfile stop sudo /etc/init.d/dphys-swapfile start 
 
Now, launch the browser and download the Lore 2.12 binaries for ARM here: https://mega.nz/#!k2InxZhb!iaLhUPreA7LZqZ-Az-0StRBUshSJ82XjldPsvhGBBH4 (Version with fee fix from 6 September 2017)
 
(If you prefer to compile it yourself instead, it is possible by following the instructions in the original article by Mindphuk just taking into account this is the newer version of the Lore client than when that was written (https://github.com/janko33bd/bitcoin/releases) and the versions of Boost and the Berkeley DB need to be the same as below.)
 
Double click the zip and extract the Lore binary files. Yes, at the moment they are all called 'bitcoin', not 'blackcoin' or 'Lore' - this is because the code derives from a recent bitcoin core implementation so this has not yet been updated. You can place these wherever you like.
 
In the Terminal window, change directory to where you put the binaries, e.g.:
 
cd Downloads/lore-raspberrypi-armv7-jessie-pixel chmod +x * 
 
That marks the binaries as executable.
 
Now, we need the Boost libraries installed for any of the Lore binaries to work. The project was done with Boost 1.62.0. Unfortunately the Jessie repository only goes up to 1.55, so we need to download and build 1.62 manually on the device.
wget https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.gz/download tar -xvzf download cd boost_1_62_0 sudo ./bootstrap.sh sudo ./b2 install 
 
(This will take almost 2 hours. Have a nice cup of tea and a sit down.)
 
When I came to run the binaries, I found they couldn't find Boost. Running this command fixes that:
sudo ldconfig 
 
Now we are going to install the packages which aren't already included in the default OS installation which the binaries need in order to run:
sudo apt-get install qrencode libprotobuf-dev libevent-pthreads-2.0-5 
 
Now we need to install the Berkeley Database version 6.2.23. This is the version Lore v2 uses. Bitcoin still uses 4.8 which is 10 years old! This doesn't take too long.
wget http://download.oracle.com/berkeley-db/db-6.2.23.tar.gz tar -xvzf db-6.2.23.tar.gz cd db-6.2.23/build_unix ../dist/configure --prefix=/usr --enable-compat185 --enable-dbm --disable-static --enable-cxx 
 
I find this next section of the Berkeley instructions worked better just switching to root, which can be fudged by running sudo su before the rest:
sudo su make make docdir=/usshare/doc/db-6.2.23 install chown -v -R root:root /usbin/db_* /usinclude/db{,_185,_cxx}.h /uslib/libdb*.{so,la} /usshare/doc/db-6.2.23 
 
Now we're going to go up a couple of directories to where the binaries were:
cd ../.. 
 
Then run the client!
./bitcoin-qt 
 
And there you have it. Should hopefully end up looking a bit like this: http://imgur.com/a/eEHGa
 
Using the Bootstrap can save a while syncing. Download it at: https://www.reddit.com/blackcoin/comments/6b3imq/blackcoin_bootstrapdat_up_to_block_1631800
 
Place the bootstrap.dat file into the ~/.lore directory.
 
Run ./bitcoin-qt again, it will say 'Importing Blocks' rather than 'Synchronising with Network'. My pi sync'ed fully in about 5-6 hours.
 
If you want peace of mind that Lore will always start on bootup into the Jessie w/Pixel desktop (i.e. after a power cycle), then you need to create a .desktop file in the following place.
sudo nano ~/.config/autostart/Lore.desktop 
 
And in it, enter the following (tailoring the Exec line below to the whereabouts of your bitcoin-qt file):
[Desktop Entry] Name=Blackcoin Lore Comment=Mining without the waste Exec=/home/pi/Downloads/lore-raspberrypi-armv7-jessie-pixel/bitcoin-qt Type=Application Encoding=UTF-8 Terminal=false Categories=None; 
 
Power usage and payback time
 
After a good while leaving it going by itself, the CPU load averages got down to almost zero, all of the time. Idling, the Pi uses a bit less than 3 watts. This means it would take two weeks to use one 1Kw/h of electricity.
 
If you pay e.g. 12.5 cents a unit, that's what you'd expect this to cost to run in a fortnight. That's around $0.25 a month or $3 a year. Green and cheap and helping to secure the BLK network. I paid for the year's worth of electricity in 2 days staking with 25k BLK. Makes mining look silly, huh? ;)
 
Securing your Pi
 
With staking, your wallet needs to be unlocked and as such, the keys to your wallet are on the device. In a clean and newly installed environment as described above, and if you don't allow others to use your device and there is no other software or nasties running on it, there is no real cause for concern. However, there are some basic security precautions you can take.
 
Firstly, if you have enabled SSH and are playing with your pi across your LAN (or worse, the Internet), you should immediately change the password for the default 'pi' user (which is preconfigured to be 'raspberry'). Simply log in as normal, then type:
 
passwd 
 
You'll be prompted to enter the old and the new passwords.
 
Security by default
 
Your Pi is likely, by default, to not be exposed to incoming connections from the outside world because your router is likely generating a private address range for your LAN (192.168.x.x or 10.0.x.x or 172.x.x.x) which means all incoming connections are effectively blocked at the router anyway unless you set up a 'port forward' record to allow packets arriving on certain ports to be forwarded to a specific internal IP address.
 
As for accessing your Pi across the internet, if you have set up a port forward, this likely has security ramifications. Even basic old fashioned protocols have proven in recent times to have uncaught flaws, so it's always advisable to lock down your device as much as possible, and even if you only plan to access the Pi over your LAN, install a firewall to configure this. I used one called ufw, because it's literally an uncomplicated firewall.
 
sudo apt-get install ufw sudo ufw allow from 192.168.0.0/16 to any port 22 sudo ufw --force enable 
 
This allows just port 22 (SSH) to be open on the Pi to any device on my LAN's subnet (192.168.0.x). You can change the above to a single IP address if paranoid, or add several lines, if you want to lock it down to your LAN and a specific external static IP address (e.g. a VPN service you use). To find out what subnet your router uses, just type:
 
ifconfig 
 
and you'll see on the interface you are using (either hard wired or wifi) the 192.168 or 10. or 172. prefix. Change the above rule so it matches the first two octets correctly (e.g. 10.0.0.0/16 if you're on a 10.0. address).
 
You may already use VNC to access your Pi's desktop across your LAN, this uses port 5900. Add a line like above to lock it down to an internal address. It's not a good idea to expose this port to the wider world because those connections are not encrypted and potentially could be subjected to a MITM attack.
 
You can query the status of the firewall like this:
ufw status 
 
And of course, try connecting remotely once you change the rules to see what works. You should consult the official documentation for further options: https://help.ubuntu.com/community/UFW
 
Back up & Recovery
 
There are again many ways to tackle this so I'll just speak about my basic precautions in this regard. Don't take it as a be-all-and-end-all!
 
The wallet.dat file is the key file (literally) containing all the private/public keys and transactions. This can be found in:
 
~/.lore 
 
You can navigate there using Jessie w/Pixel's own file manager or in a terminal window (cd ~/.lore). You can copy this file or, if you'd rather keep a plain text file of all your public and private keys, use the 'dumpwallet' command in the console. In Lore, go to Help > Debug Window > Console and type 'dumpwallet myfilename' where myfilename is the file you want it to spit out with all your keys in it. This file will end up in the same place you launch bitcoin-qt from.
 
The instructions earlier on, when running Lore for the first time intentionally left out encrypting your wallet.dat file because in order for the wallet to stake upon startup, it needs to have a decrypted key already. This isn't perfect, but after a power cycle, it would never stake unless you left it decrypted. So the best practice here is as soon as the wallet.dat file has left your device, i.e. you copy it to a USB stick for example, put it in an encrypted folder or drive (or both).
 
In Windows, one way is to use Bitlocker drive encryption for the entire drive. You should follow the instructions here to encrypt your flash drive before your wallet.dat is on there, and don't forget the password!!
http://infosec.nmsu.edu/instructions-guides/how-to-enable-bitlocker-to-go-for-external-hard-drives-and-usb-flash-drives/
 
On the Mac, I use a software package called Concealer to encrypt files I store on the Mac itself: http://www.belightsoft.com/products/conceale   There are almost certainly free packages with similar functionality, I have just used that one for years.
 
Either way, if you want to just make sure your USB drive is encrypted, you can do so in one-click in Finder before you put the sensitive files on it: http://lifehacker.com/encrypt-a-usb-stick-in-finder-with-a-click-1594798016
 
Note that these disk encryption methods may mean having to access the USB stick on a PC or Mac in order to retrieve the files in the event of a disaster. Be aware this may mean exposing them to more security issues if your computer is in any way compromised or someone nefarious has access to your computer. There are more 'manual' ways of backing up and recovering, such as literally writing down private/public key pairs which this guide doesn't go into, but may suit you better if paranoid about your setup.
 
Recovery
 
The wallet.dat file has everything in it you need to recover your wallet, or if you used 'dumpwallet', the file you saved out has all the keys.
 
Wallet.dat method: Install Lore as normal then replace any auto-generated wallet.dat in ~/.lore directory with your backup. If a lot of time has elapsed and many transactions have occurred since your backup, launch lore with:
./bitcoin-qt -rescan 
 
And if that doesn't do the job, do a full reindex of the blockchain:
 
./bitcoin-qt -reindex 
 
If you used the dumpwallet command, install Lore then place the file containing all the keys that you saved out in the same directory as bitcoin-qt. In Lore, go to Help > Debug Window > Console and type 'importwallet myfilename' where myfilename is that file containing all the keys. The wallet should automatically rescan for transactions at that point and you should be good to go.
 
There are a million ways to do effective security and disaster recovery, but I hope this shows you a couple of basic precautionary ways. There are discussions about better ways to stake without compromising too much security which are happening all the time and developments in this regard will happen in time.
 
In the meantime, feel free to comment with your best practices.
 
submitted by patcrypt to blackcoin [link] [comments]

Transferring bitcoins before syncing?

Should start off by pointing out I am a fairly mid-level technical person, and a bit out of date with bitcoin. This is really a post just asking for a bit of help to get up and running again with bitcoin. Ive bolded the items I really want help on, but also just rambled on about other issues I have been facing.
I have only used one wallet, (Bitcoin Core 0.10, on a machine that rarely gets turned on, .dat file backed up) mainly for a number of purchases back around Jan 2014. When things were going south, I decided to setup an alert to let me know when I was back in the green. That day happened about a week ago. I want to now start to use some of this (several joints in Melbourne popped up that take BTC).
Turning this machine back on, I had a number of issues.
Firstly Bitcoin Core would not connect to any clients. The old 'no block source available' message. From looking at other posts, and trying a number of things, have upgraded to 0.12.1 and started a reindex on my database.
This reindex has been running for 10 hours and still 2 years behind reindexing blocks on disk. I can see I am connected to 8 peers but over 10hrs only 211mb has been received? This does not sound too efficient? Anything I can do to speed this process up? I am running on Windows and not using TOR. Can I shut my machine down mid-index, and it picks up where it left off when I boot up again?
I would like to move away from Bitcoin Core. Its taking up huge amounts of disk space (which I hear 0.12 can get around) but I have heard great things in another post about Electrum.
Do I have to wait for Bitcoin Core to catch up syncing with the Blockchain before I can send any money?
I was wondering if I could download and install Electrum alongside Bitcoin Core. Send money from Bitcoin Core wallet to Electrum. Uninstall Bitcoin Core. Would there be any issues with this approach?
Appreciate any help. Will be spending the weekend doing some more background reading on 'hot wallet' options for iOS, but would like to keep the majority of my BTC stored on this offline machine, but was not expecting it to take days to get money off it. Thanks!
EDIT Its been stuck at reindexing blocks on disk 2 years & 3 weeks for over 18 hours now. Whats the next step?
submitted by jakc13 to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.1.2.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.1.2.0, November 12, 2017) from:
 
https://www.bitcoinunlimited.info/download
 
This release is compatible with the Bitcoin Cash with the upcoming planned hard fork that will take place on Nov 13th
 
The main change of this release is the introduction of a new difficulty adjustment algorithm (DAA) that replaced the old EDA (Emergency Difficulty Adjustment). If you are interested in more detail about the new DAA you could find more details in the technical specification.
Another major change is the introduction of a new format to store the UTXO (chainstate) database. The UTXO storage has been indexed per output rather than per transaction. The code has been ported from the Bitcoin Core project. This feature brings advantages both in terms of a faster reindex and IBD operation, lower memory consumption, on the other hand the on-disk space requirement increased of about 15%.
Other notable changes:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/BitcoinCash/doc/release-notes/release-notes-bucash1.1.2.0.md
Ubuntu PPA is in the process of being updated.
submitted by s1ckpig to bitcoin_unlimited [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.1.2.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.1.2.0, November 12, 2017) from:
 
https://www.bitcoinunlimited.info/download
 
This release is compatible with the Bitcoin Cash with the upcoming planned hard fork that will take place on Nov 13th
 
The main change of this release is the introduction of a new difficulty adjustment algorithm (DAA) that replaced the old EDA (Emergency Difficulty Adjustment). If you are interested in more detail about the new DAA you could find more details in the technical specification.
Another major change is the introduction of a new format to store the UTXO (chainstate) database. The UTXO storage has been indexed per output rather than per transaction. The code has been ported from the Bitcoin Core project. This feature brings advantages both in terms of a faster reindex and IBD operation, lower memory consumption, on the other hand the on-disk space requirement increased of about 15%.
Other notable changes:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/BitcoinCash/doc/release-notes/release-notes-bucash1.1.2.0.md
 
Ubuntu PPA is in the process of being updated.
submitted by s1ckpig to Bitcoincash [link] [comments]

Bitminter.Com ile Coin Kazanmak Cryptography with End to End Encryption. Block Chain Mail is John McAfee SwiftMail part1 Blockchain/Bitcoin/Altcoin - YouTube DIY Home Security - ON A BUDGET! - YouTube Bitcoin & Crypto vs Scam of the Dollar – Bitcoin: A REVERSE Wealth Transfer. A Deflationary World.

I've added an assertlockheld(cs_main) in coins.cpp, and I get the following stack trace when trying to reindex: Assertion failed: lock cs_main not held in coins.cpp:194; locks held: #3 0x54beb616 in AssertLockHeldInternal (pszName=0x0, p... The command attempts to sync with the network by reusing as many blocks as possible that are already written to the disk, which may very well include damaged or partially written ones. Any experience with speeding this up. Increasing the dbcache will speed up reindexing, putting it at 2G (dbcache=2048) would not be an unreasonable choice given you have the memory. This is about all you can do ... Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up. Sign up to join this community. Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Bitcoin . Home ; Questions ; Tags ; Users ; Jobs; Unanswered ; Block data error, reindexing blocks. Ask Question Asked 7 years, 4 months ... Bitcoin Reindexing Blocks On Disk . Apr 16, 2018 DTN Staff. twitter. pinterest. google plus. facebook. Reindexing Blocks On Disk ... Stored are actual Bitcoin blocks, in network format, dumped to disk raw. blkindex.dat [Versions prior to v0.8.0] Indexing information used with blkxxxx.dat; __db.xxx. Used by BDB; db.log ; debug.log Bitcoin's verbose log file. Automatically trimmed from time to time. wallet.dat Storage for keys, transactions, metadata, and options. Please be sure to make backups of this file. It contains the ...

[index] [15329] [29150] [19954] [25694] [40662] [14111] [9173] [27313] [26217] [15048]

Bitminter.Com ile Coin Kazanmak

block.one is developing a new resource and technology called “DISK” for their EOSIO software. This will allow cheap storage of much larger amounts of database information for dApps and smart ... In this video I'll be showing you how to make a low cost DIY home security setup using recycled laptop webcams! Don't forget to add security to your internet... Bitcoin mail app at no charge. Alphanumeric id replaces email address. No metadata. 256-SHA elliptical encryption. Get your FREE swiftmail wallet at www.johnmcafeeswiftmail.com Support development ... Sapphire Block Erupter - USB Bitcoin Miner 330 Mhash @ 2,5 W - Duration: 2:25. SwiftDK 48,308 views. 2:25 . Professor Eric Laithwaite: Magnetic River 1975 - Duration: 18:39. Imperial College ... Skip navigation Sign in. Search

#