# How to Speed Up New Bitcoin Wallet Synchronization ...

• How to Speed Up New Bitcoin Wallet Synchronization ...
• Extremely slow syncing speed while starting bitcoin-qt on HDD
• 5 Steps to Install Bitcoin-Qt Faster - Bitcoin-en.com
• Bitcoin-QT taking too long to sync! : Bitcoin
• Wallet won't sync - Beginners Guide to Bitcoin, Blockchain ...
##### Full node sync speed

I'm syncing a full node on a Raspberry pi 4 with 8GB memory, external disk drive (not ssd), broadband internet. It's going extremely slow--estimated time about 4 years.
dbcache=4096 (setting aside half my ram)
blocksonly=1
banscore=10
listen=0
par=-1
When I run top, I see bitcoin-qt is only using about 12% of the CPU. When it boots and is loading the block index, I see that go up to 100+%. So for whatever reason, it's not fully utilizing the CPU on the machine while processing blocks.
I tested my internet connection and have 56Mbps down, 6Mbps up.
My only theory is that the external hard drive is being the bottleneck. Is there anything else to do, or should I order a SSD?

##### How I synced on a 2013 ultrabook in a few days

Note: I don't know exactly how long it took because I didn't do it in one go. I guess it was like 4,5 days doing it only at night. At some points(2015Q3, 2018Q2) it slows down and ETA goes up to 16 weeks or something.
The main bottleneck is IO. My 2013 mobile i3 has enough processing power to sync, I only used 3 threads and most of the time only one was close to 100%. The two directories that need to be written and read from intensively are chainstate and blocks/index. I pruned to 2GB and chainstate didn't go much over 3GB during the entire process. blocks/index is like 100MB.
The best solution is to move chainstate and blocks/index to a ramdisk. If you don't have enough ram the linux kernel has a thing called zram. Zram creates a compressed swap(cache) file in ram, this effectively increases your ram size at the cost of a bit of processing power and access speed(of the compressed part). On my machine I can net a bit more than 1GB of extra ram. That's right, with linux you can download more ram! The second best solution is to leave chainstate and block/index on a sdd. From what I've tested it should take up between 5 whole days and 2 weeks.
With regards to config, I didn't see much benefit in increasing the db cache over the default 450MB in bitcoin-qt. If I recall correctly, smaller prune sizes make chainstate larger.
After the initial sync keeping up to date is very easy on resources. You can catch up a week in a few minutes. At the moment bitcoind is using 400MB but I'm still working on bringing that number down.
Remember: If you want safety or if you want to help the network you need o run a full node. A full node is a node that verifies all transactions. A pruned node is a full node.
Edit: bitocoind really likes to hover around 400MB, sometimes it gets higher than that, some times it get's lower. A lot of that is data, not code, so if you start running out of ram your OS should drop those pages and get down to 250~300MiB. If you really want the memory to be this low all the time, on linux, you can either: Use cgroups to set the swappiness of the process to 99 so all data gets swapped but not code does; Use systemd and set MemoryLimit=300MiB(for example) so almost all data gets swapped but no code. I don't think any of those options are worth the small setup hassle.

##### Full and Pruned Node Transfer Question

Hello. I am running full node Bitcoin Core qt on my HDD, it is pretty old HDD so it is very slow, takes a lot of time to sync every day (even with 8GB database cache set).
On the same PC I have SSD from where I run OS but it is only 150GB. Is it possible to create a pruned node from my HDD and transfer it to SSD for everyday use (will be faster sync etc.) but still keep my full node on my HDD?

Edit: Solved this by transferring chainstate dir to SSD and using mklink /D chainstate ?:\path\to\chainstate command. It works a lot faster now, 30 mins sync on my old HDD = 2 mins sync now with chainstate dir on SSD.

# Intro

This thread is an update to my first Reddcoin staking tutorial that was written 7 months ago.

The reason for the update
My Reddcoin Core software crashed and became unusable. My Raspberry Pi 3B would lag and freeze, I couldn't stake anymore.

Instead of just redoing everything the same way, I wanted to see if I could improve on 3 points:
• Use an OS that was lighter
• Update the Reddcoin Core software (2.0.0.0 => 2.0.1.2)
• Make improvements to the configuration.

• OS: using Lubuntu instead of Ubuntu MATE. Lubuntu uses less resources (130 MB RAM vs. 190 MB RAM on initial boot).
• Reddcoin Core: v2.0.1.2-a8767ba-beta instead of v2.0.0.0-92768f9-beta.
• Swap: using a swap partiton instead of a swap file. Also adjusting the swap size: from 1 GB to 2 GB, after reading the comments to my previous tutorial.
• All data to USB: Blockchain data and the swap are now stored on the USB drive, instead of the SD card.

If you would like to tip me
Writing a tutorial like this takes time and effort; tips are appreciated. My Reddcoin address: RqvdnNX5MTam855Y2Vudv7yVgtXdcYaQAW.

# Overview

• Hardware: Raspberry Pi 3 Model B.
• OS: Lubuntu 16.04.2 (Xenial).
• Storage space: I am using an 8 GB microSD card for the OS, and a 128 GB USB drive for data. Minimums I would recommend: 8GB SD card and 32 GB USB drive.
• Reddcoin Core client version: v2.0.1.2-a8767ba-beta (most recent version at this moment). ↳ Screenshot

# Steps

• You need software to write the OS to the SD card. I use Etcher. Download Etcher: https://etcher.io/.
• Run Etcher.
• Select image: select the lubuntu-16.04.2-desktop-armhf-raspberry-pi.img.xz file.
• Select drive: select your microSD card.
• Flash.

• Plug the SD card into your Raspberry Pi and power it up.
• Lubuntu should boot up.
• Set up Lubuntu, connect to the internet (wired or wireless). ↳ As username, I chose "rpi3b". You will see this username throughout this whole tutorial.
• Make sure date and time are correct ([Menu] > System Tools > Time and Date). ↳ Click on Unlock to make changes. I personally change Configuration to "Keep synchronized with Internet servers". ↳ Screenshot
• Reboot ([Menu] > Logout > Reboot). I am connected to wifi, but have issues getting wifi to work on initial boot. A reboot solves this issue.

• Make sure system is up-to-date, install never versions.
• Open LXTerminal ([Menu] > System Tools > LXTerminal). ↳ Screenshot
• Enter the following in LXTerminal: sudo apt update && sudo apt upgrade ↳ Screenshot
• You will be asked if you really want to continue. Enter Y (yes).
• Updates are being installed! Wait until it's finished.

• Install programs that will be used in this tutorial.
• GParted: to partition the USB drive.
• Htop: to see the amount of memory (RAM) and swap that is in use.
• Enter the following in LXTerminal to install these 2 programs. sudo apt install gparted && sudo apt install htop ↳ Screenshot

• Create 2 partitions on the USB drive: 1) Swap partition 2) data partition (for the Reddcoin blockchain)   The swap partition is necessary: The Reddcoin wallet can be memory intensive. To prevent any crashes or freezes, add 2 GB of 'virtual' memory by creating a swap partition.
• Important: Backup your USB drive if needed. The USB drive will be formatted, so the data on the USB drive will be wiped.
• Please use the USB drive solely for this purpose, do not combine it with other stuff.
• Keep your USB drive plugged in, do not (randomly) plug it out.
• Plug your USB drive in.
• GParted will be used to create the partititons. Start GParted via LXTerminal: sudo gparted ↳ Screenshot
• In GParted, switch from your SD card (default) to your USB drive. ↳ ScreenshotScreenshot
• You will now see the all the partition on USB drive. Delete every partition (right mouse click). If you can't select Delete, do an Unmount first. ↳ ScreenshotScreenshot
• After deleting all partition, you will only see 'unallocated' space on your USB drive. ↳ Screenshot
• Create the first partition: the swap partition. Right click on the blank space, select New and enter the following:
• New size (MiB): 2048
• File System: linux-swap
• Click on Add. ↳ Screenshot
• Create the second partition: the data (blockchain) partition. Richt click, select New and enter:
• File system: ext4
• Label: usb
• Click on Add. ↳ Screenshot
• Apply the changes. Click on the check mark or select Edit > Apply All Operations. ↳ ScreenshotScreenshot
• Important: The name of the swap partition is needed later, so please write it down. Mine is /dev/sda1 (first partition on first drive (drive 'a')). ↳ Screenshot
• Reboot. After the reboot, the data partition you just created should be visible on your desktop. ↳ Screenshot

• The swap partition is created, so now we can enable and use it.
• The swap in use can be monitored with the program Htop. Open Htop ([Menu] > System Tools > Htop) to see the 'Swp' (swap) in use. ↳ Screenshot   By default, swap is not used, so 0K. ↳ Screenshot   You can leave Htop open.
• To enable the swap partition, open LXTerminal and enter the following commands: (Assuming /dev/sda1 is your swap partition.)
• You've enabled the swap partition. Switch back to Htop and check the 'Swp' (swap) value. It should read '2.0G'. ↳ Screenshot

• To make sure the swap file is persistent (so it survives a reboot), you have to add a line to the /etc/fstab file.
• In LXTerminal, enter the following command to open the file in Leafpad (text editor): sudo leafpad /etc/fstab ↳ Screenshot
• In Leafpad, add this text in a new line: /dev/sda1 swap swap defaults 0 0 ↳ Screenshot (I've added spaces to vertically align the text.)
• Save and close the file.
• To see if the swap partition is in use after a reboot, open Htop ([Menu] > System Tools > htop) and check the 'Swp' (swap) value. It should read '2.0G'. ↳ Screenshot

• So, the swap partition is enabled and in use, and the data partition is prepared. We now can install the necessary software for the Reddcoin wallet; enter the following commands into LXTerminal:
• sudo apt-get update && sudo apt-get install git build-essential libqt4-dev libprotobuf-dev protobuf-compiler libtool autotools-dev autoconf libssl-dev libboost-all-dev wget pkg-config ↳ Screenshot
• sudo add-apt-repository ppa:bitcoin/bitcoin ↳ Screenshot
• sudo apt-get update
• sudo apt-get install db4.8 ↳ ScreenshotScreenshot
• sudo apt-get install libminiupnpc-dev ↳ Screenshot
• sudo apt-get install libqrencode-dev ↳ Screenshot

• After the reboot, open LXTerminal again. Download, unpack, configure, build and install Berkeley DB.
• Set the working directory to your USB drive: cd /media/rpi3b/usb (rpi3b is the username I chose; if you have a different username, change it to yours.) ↳ Screenshot
• sudo tar xfvz db-4.8.30.NC.tar.gz ↳ Screenshot
• cd db-4.8.30.NC
• cd build_unix
• sudo ../dist/configure --enable-cxx
• sudo make This took about 10 minutes for me.
• sudo make install

• Set BerkeleyDB variables (in LXTerminal):
• export CPATH="/uslocal/BerkeleyDB.4.8/include" ↳ Screenshot
• export LIBRARY_PATH="/uslocal/BerkeleyDB.4.8/lib" ↳ Screenshot
• sudo leafpad /etc/ld.so.conf.d/daemon-libs.conf ↳ Screenshot
• Save and close the file.
• Back in LXTerminal: sudo ldconfig ↳ Screenshot

• Set the working directory to your USB drive: cd /media/rpi3b/usb (rpi3b is the username I chose; if you have a different username, change it to yours.)
• Unzip the file: sudo unzip arm_support_v2.zip ↳ Screenshot
• rename the folder from ''unzip arm_support_v2'' to ''reddcoin'' (easier to use when needed) sudo mv reddcoin-arm_support_v2/ reddcoin/ ↳ Screenshot
• cd reddcoin ↳ Screenshot
• sudo ./autogen.sh ↳ Screenshot
• sudo ./configure --disable-tests --enable-sse2=no ↳ Screenshot
• sudo make ↳ ScreenshotScreenshotScreenshot (This will take some time; with me it took just over 1 hour.)
• sudo make install ↳ ScreenshotScreenshot

• Speed up synchronizing with the Reddcoin blockchain by bootstrapping.
• Set the working directory to your USB drive: cd /media/rpi3b/usb (rpi3b is the username I chose; if you have a different username, change it to yours.)
• Unpack the file (large file, takes around 15 minutes to unpack): sudo xz -d bootstrap.dat.xz ↳ Screenshot
• After a successful unpack, your will find the file bootstrap.dat in your USB root folder. ↳ Screenshot

• On the first run of the Reddcoin Core client, it will ask for a data directory to store the blockchain and wallet data.
• Start the Reddcoin Core client: sudo /media/rpi3b/usb/reddcoin/src/qt/reddcoin-qt ↳ Screenshot
• The welcome screen will appear and ask you about the data directory. I suggest a new folder on your USB drive, I picked blockchain. The directory will be created with all the necessary files. ↳ Screenshot
• Select Use a custom data directory. ↳ Screenshot
• Click on the three dots (...) on the right. ↳ Screenshot
• Click on Create Folder at the upper right corner. Type and enter in the folder name. (In my case: blockchain.) Click on Open. ↳ ScreenshotScreenshotScreenshot
• After selecting the directory, the Reddcoin Core client will start. Wait till it's fully loaded and close it.

• Move the bootstrap.dat file to your data directory you selected in the previous step. By doing this, Reddcoin Core will use the bootstrap.dat file to import the blockchain, which speeds up syncing. sudo mv bootstrap.dat /media/rpi3b/usb/blockchain/ (Assuming blockchain as data directory.) ↳ Screenshot

• The Reddcoin Core client set up is completed, but you still have to sync fully with the blockchain before you can send, receive and stake.
• Launch the Reddcoin Core client again: sudo /media/rpi3b/usb/reddcoin/src/qt/reddcoin-qt ↳ ScreenshotScreenshot
• Keep the client running until it's fully synchronized. It will use the bootstrap file first, and download the rest of the blockchain to complete the sync. This can take some time (it took 2 days for me). Syncing the blockchain uses a lot of resources, so the software may react slow.
• You can see the progress in the debug window (Help > Debug window). ↳ Screenshot
• When the synchronization is completed, the red (out of sync) will disappear on the Overview screen! ↳ Screenshot

• When synchronization is complete, you can start staking your Reddcoins.
• For staking, your wallet needs to be encrypted: Settings > Encrypt... Do not forget your password!ScreenshotScreenshotScreenshotScreenshotScreenshot
• Your wallet will be encrypted, and the Reddcoin Core client will be closed. Launch the Reddcore Client again. sudo /media/usb/reddcoin/src/qt/reddcoin-qt
• Settings > Unlock Wallet...Screenshot
• Make sure "For staking only" is checked before clicking OK. ↳ Screenshot
• You can only stake with Reddcoins that have matured: coins have to be at least 8 hours in your wallet to mature.
• The grey arrow at the bottom should be green when staking. Hover over that icon to see the progress of staking. ↳ Screenshot

# Video

This video shows how long it takes to start Reddcoin Core.   TL;DR:
• [01:11] Reddcoin Core started (sudo password entered).
• [10:14] Message shown on screen: Verifying blocks...
• [13:13] Reddcoin Core ready to use.

# Extra

Backup
Backup your wallet to prevent losing the RDDs in your wallet! There are two methods to backup, do both. Make new backups if you create a new receiving address!

• Method 1: Backup your wallet.dat. Open Reddcoin Core. Use the menu to backup: File > Backup Wallet... ↳ Screenshot

• Method 2: Backup your private keys. In case you lose your wallet.dat backup, you still can import your private keys later when needed.
• To extract your private keys:
• If you have a passphrase on your wallet, unlock your wallet first. Settings -> Unlock Wallet... (make sure 'For staking only' is not checked) ↳ ScreenshotScreenshot
• Extract your private keys. Debug window -> Console -> dumpprivkey Screenshot
• You can write down your private key or copy and save it in a document. Make sure you save it somewhere only you can access it.
• To import later: Debug window -> Console -> importprivkey [label] [label] is optional. ↳ Screenshot (without a label) ↳ Screenshot (with a label)

Boot with only 1 USB drive plugged in:
Make sure only the USB drive (with the swap partition and data partition) is plugged in when you boot up your Raspberry Pi. This to make sure the swap partition (/dev/sda1) is recognized correctly.   If you boot up with multiple USB drives, Lubuntu might see the USB drive with the swap partition as the second drive (instead of the first drive), and ignore the 2 GB swap partition. If this happens, starting Reddcoin can render the Raspberry Pi unresponsive.

Connection issues If you have issues syncing the blockchain because you have 0 network connections, please follow the instructions in this thread.

Start Reddcoin Core easier
Run a shell script (.sh file), so you can start Reddcoin just by double clicking on an icon on your Desktop.
• Right Click on your Desktop and select Create New -> Empty File. ↳ Screenshot
• Enter a file name, make sure it ends with .sh, and click on OK. I've chosen for Reddcoin.sh. ↳ Screenshot   The file will be created on your Desktop. ↳ Screenshot
• Add the command to start Reddcoin to the file.
• Right click on the file, select Leafpad (to open the file in a text editor). ↳ Screenshot
• Add the following to the file and save the file: sudo /media/rpi3b/usb/reddcoin/src/qt/reddcoin-qt ↳ Screenshot
• To be able to execute the shell script (.sh), it has to have 'execute permissions'.
• Right click on the file, and select Properties. ↳ Screenshot
• Click on the Permissions tab.
• For Execute, select Anyone, and click on OK. ↳ Screenshot
• To start Reddcoin Core, double click on the file. A new window will pop-up, asking you what you want. Execute in Terminal is what we want, so you can click on enter. ↳ Screenshot   Reddcoin Core will now start. Do not close the Terminal window, you can minimize it if needed.

Minimization options
Adjust minimization options, so you can safely press on the X button (the close/exit button on the upper right corner).
• Activate 'Minimize on close'. Settings -> Options... -> Window (tab) -> Minimize on close. ↳ Screenshot   Reddcoin will still run when you click on the X button.   To close/exit Reddcoin, right click on the Reddcoin icon in the system tray (bottom right corner). ↳ Screenshot

RealVNC VNC Viewer (client) and VNC Connect (server): To remote connect to the Raspberry Pi, I use VNC Viewer ad VNC Connect from RealVNC.
• To run the VNC Connect once:
• Open [Menu] > Run, and enter: vncserver-x11 ↳ Screenshot
• To auto run on startup:
• Open Default applications for LXSession ([Menu] > Preferences > Default applications for LXSession). ↳ Screenshot
• In LXSessions configuration, select Autostart in the menu left.
• Under Manual autostarted applications, enter vncserver-x11 and click on + Add. ↳ ScreenshotScreenshot
• Reboot your Raspberry Pi and check if VNC Connect is started automatically after the reboot.
• When VNC Connect is running, you'll see a VNC icon on the right bottom corner. Double click the icon to open VNC Connect and to see the IP address you need to enter to connect to your Raspberry Pi. ↳ Screenshot

Chromium as browser: The updates break Firefox, the browser crashes when you try to run it. Install another browser, Chromium, to solve this issue.
• In LXTerminal, enter: sudo apt install chromium-browser ↳ Screenshot
• You can run Chromium via [Menu] > Internet -> Chromium Web Browser ↳ Screenshot

If Software Updater shows up and tells you that there is updated software available, do not install the updates using Software Updater. Use LXTerminal to update Lubuntu.
• Open LXTerminal and enter this command to update: sudo apt update && sudo apt upgrade ↳ Screenshot

# Credits:

• cryptoBUZE on reddit.com; for getting the official arm_support_v2.zip to work.
• worstkaas on reddit.com; for his suggestion of using 2 GB instead of 1 GB for the swap space.

Credits in previous tutorial:
• My main source: damsal01 on reddcointalk.org. His RDD address for donation: Rqd8xDv6oV9BYFaVrLdkWcR5JU6sPPZTKs.
• joroob on Github.com. He made some adjustments to the reddcoin wallet source code so it will compile on ARM cpus. His RDD address for donation: Rb8754QZvpbw6DjrMV1qX9SnHzYnSyXRMC.

##### 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.

##### How do you import a Bitcoin Core (QT)-made wallet.dat file into another wallet?

So I have a wallet.dat made a while ago and wanted to check what was in it, problem is it was made in the bitcoin core QT client, which I can't even load up because it occasionally freezes and usually won't even sync up, at an absurdly slow rate.
When I replace that wallet file into the default data directory, and start bitcoin-qt.exe with the -rescan command, it just starts but no addresses show up in my wallet file and i noticed the wallet.dat file size changes when the bitcoin core client starts up, seemingly modifying something to make it slightly bigger, don't know why.
How do I check this wallet.dat? I tried importing it into the latest electrum 3.2.3 wallet and it won't accept it.

##### 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.

##### PIVX Core v3.0.6 released (November 30th) - Optional Upgrade

Github release info and binaries
Forum Post
Important information about the automint and zPIV backup requirements

This release is optional but recommended. The latest mandatory upgrade is v3.0.5.1, but if you have any problems with earlier versions the latest version is recommended.
If you are running an older version, gracefully 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/PIVX-Qt (on Mac) or pivxd/pivx-qt (on Linux).
There are no special steps needed like config file changes but a backup is always a good idea.
A note from presstab in case it gets buried in the comments
Command line install and upgrade guide

# Notable Changes

(but you should still read the release notes on Github)

### Automated Database Corruption Repair

There have been cases of blockchain database corruption that can occur when PIVX client is not closed gracefully. The most common cases of corruption have been identified and the wallet will now automatically fix most of these corruptions. Certain corruption states are still unable to be fixed, but now provide more detailed error messages to the user as well as prompting the user to reindex their database.

### More Accurate Error Messages

Some error messages in the wallet have been too vague and done little to help developers and the support team properly identify issues. Error messages have been refined and are now more specific.

### Reduction of Debug Log Spam

Many 3rd party services have reported that their debug logs have been overloaded with messages about unknown transaction types. This log spam has been fixed.

### Removal of Heavy Running Transaction Search Code

Many areas of the block validation code use a "slow" transaction search, which searches redundantly for transactions. This "slow" search has been removed upstream in Bitcoin and is now removed in PIVX. This provides a more efficient syncing process and generally better performing wallet.

### Sync Fix for Block 908000

Many wallets were having trouble getting past block 908000. This block recalculates certain aspects of the money supply and zPIV transactions, and is known to take longer to sync. Code has been added to allow block 908000 to be validated without the user needing to enter any special commands into the debug console.

### Working Testnet

Testnet is now accessible with this release of the wallet. Testnet can be accessed using the -testnet startup flag.

### zPIV Spending Fix

zPIV that were minted between block 891730 and 895400 were experiencing an error initializing the accumulator witness data correctly, causing an inability to spend those mints. This has been fixed.

# Credits

Thanks to everyone who directly contributed to this release:
• Fuzzbawls
• Jon Spock
• Mrs-X
• Patrick Collins
• PeterL73
• presstab
• sonic
• whateverpal
As well as everyone that helped translating on Transifex.

##### A Guide to Keeping Keys Offline Using Armory +rPi

Hi Redditors.
I am going to post in this thread my experiences in getting my Desktop (Debian) machine running Armory in watch-only mode, and coupling that with an offline Raspberry Pi (which holds my private keys) for signing the transactions previously made in watch-only mode.
I actually compiled Armory from source directly on my Pi. This guide is probably more for the bitcoin 'power user', as to run Armory online, and broadcast the signed transactions, you need to have a bitcoin full node running (bitcoind).
Basic requirements:
• Online machine - running a full node (bitcoind)
• Raspberry Pi - I used an old Pi 1 Model B with just 512Mb memory, and 2 USB slots.
• 2x USB thumb-drives. One for wallet backups, the other for transferring unsigned tx's to the rPi, and signed tx's back to the Desktop.
Aimed-for Setup:
• Armory 0.96.4 for the Raspberry Pi 1, Model B (512Mb RAM, 2xUSB) (compiled from github sourcecode on the Pi itself!)
• Using the Pi as an offline complement to a Debian Desktop "watch-only" Armory install.
• Desktop Debian Armory watch-only talks to my full node, bitcoind, which is also on the Debian desktop.
I'll post the guide in digestible sections...

# Section 1

I should begin by saying I installed source code from git, and got Armory to build the DB on my desktop initially, WITHOUT creating a wallet.. (This allowed me to debug what was going on a little!)
• I am using Armory 0.96.4
• Desktop: Debian 9, Dual-Core, 2Gb Memory, 2Gb Swap.
• Pi : Pi 1, Model B (512Mb RAM, 2x USB, Ethernet)
Go to Bitcoin.org, select Armory..
https://github.com/goatpig/BitcoinArmory/releases
Followed the procedure for Linux Debian verify code, compile, install, all straight-forward..
Began by running bitcoind, and telling Armory where to find it. This is the command I used, obviously it was all on one line and didn't include the arrows/explanations!:
python ArmoryQt.py \ --satoshi-datadir=/BlockChain/chain20180414/blocks \ # <-----(where my bitcoind blocks live) --datadir=/ArmoryDataDi \ # <-----(this is instead of ~/.armory) --dbdir=/ArmoryDataDidatabases # <-------(again, non std. place used for Armory's databases.. my choice.)
So, on the Desktop, after the initial "build databases"
(NB the initial "Build Databases" took about 1.5h and my two CPUs were maxed the whole time, Temps up to 62C. Not ideal; Im not in a rush!)
I then wanted to import a watch-only wallet.
Before I did this, I took a full backup of the Armory data dir:
(or ~/.armory in a default installation).
I'd hate to have to make Armory do another full sync with the bitcoind node!

# Section 2

Next step: offline wallet (with Private Keys) is on a Raspberry Pi.
I downloaded the source and managed to compile it on the pi itself! :)
Though there were some gymnastics needed to setup the Pi.
My Pi is running Raspbian based on Wheezy.. quite old!
I did the following on the Pi:
apt-get update apt-get upgrade (<---took about an hour!) apt-get install autotools-dev apt-get install autoconf
Then I followed the instructions exactly as I had done for my Debian Desktop machine, EXCEPT:
I had to increase the Pi's swap space. I upped it from 100Mb to 400Mb.
The compilation took 7 hours, and my poor SD card got a thrashing.
But after compilation, I put the Swap back to 100Mb and Armory runs ok with about 150Mb of memory (no swap needed).
Swap increase on the Pi:
use your favourite editor, and open the file /etc/dphys-swapfile
CONF_SWAPSIZE=400
Then, REBOOT the Pi:
sudo shutdown -h -P now
Once the compilation was done on the Pi, put the swap back, rebooted and created an Armory wallet.
I added manual entropy and upped the encryption 'time' from 250ms to 2500ms - since the Pi is slow, but I'll be happy to wait for more iterations in the Key Derivation Function.
Once the wallet was created, it obviously prompts you for backup.
I want to add a private key of my own (i.e. import), so don't do the backup until this is over.
I import my Private Key, and Armory checks that this corresponds to a Public Key, which I check is correct.
This is the point now where the Pi storage medium (e.g an SD card) has to be properly destroyed if you ever get rid of it.
I had thought that now would be a good time to decide if your new wallet will generate Segwit receiving addresses, and also addresses used to receive 'change' after a transaction..
But it seems Armory WON'T let you switch to P2SH-P2WPKH unless your Armory is connected to a node offering "WITNESS" service.
Obviously, my Pi is offline and will never connect to a node, so the following will not work on the Pi:
• x Use File Settings Fee and address types.
• x Also Set the "Change Address" to P2SH-P2WPKH for left-over loose change!
NB: I thought about setting this on the Debian "watch-only" wallet, but that would surely mean doom, as the Pi would not know about those addresses and backups might not keep them.. who knows...
So, end result:- no segwit for me just yet in my offline funds.

# Section 3

Ok, now this is a good point to back up your wallet on the Pi. It has your imported keys. I choose a Digital Backup - and put it on a USB key, which will never touch the internet and will be stored off-site. I also chose to encrypt it, because I'm good with passwords..
NB: The Armory paper backup will NOT back up your imported private keys, so keep those somewhere if you're not sweeping them. It would be prudent to have an Armory paper backup anyway, but remember it will likely NOT help you with that imported key.
Now for the watch-only copy of the wallet. I want to get the "watch-only" version onto my Desktop Debian machine.
On the Pi, I created (exported to a USB key) a "watching-only" copy of my wallet.
I would use the RECOMMENDED approach, export the "Entire Wallet File".
As you will see below, I initially exported only the ROOT data, which will NOT capture the watching-only part of the Private Key I entered manually above (i.e. the public Key!).
Now, back on the Debian Desktop machine...
I stopped all my crontab jobs; just give Armory uninterrupted CPU/memory/disk...
I also stopped bitcoind and made a backup prior to any watch-only wallet being imported.
I already made a backup of Armory on my Desktop, before any wallet import.
(this was needed, as I made a mistake.. see below)
So on the Debian Desktop machine, I begin by firing up bitcoind.
my command for this is:
./bitcoind -daemon -datadir=/BlockChain/chain20180414 -dbcache=400 -maxmempool=400

# Section 4

I try running Armory like this:
(I'm actually starting Armory from a script - StartArm.sh)
Inside the script StartArm.sh, it has the line:
python ArmoryQt.py --ram-usage=4 --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases
I know from bitter experience that doing a scan over the blockchain for a new wallet takes a looong time and a lot of CPU, and I'd like it to play nicely; not gobble all the memory and swap and run my 2xCPUs both at 100% for four hours...
So... I aim to run with --ram-usage=X and --thread-count=X
(For me in the end, X=1 but I began with X=4)
I began with --ram-usage=4 (<--- = 4x128Mb)
The result is below...
TypeError: cannot concatenate 'str' and 'int' objects
It didn't recognise the ram-usage and carried on, crippling my Debian desktop PC.
This is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up, and it can take over 30 minutes just to exit nicely from bitcoind and ArmoryDB.
So, I ssh to the machine from another computer, and keep an eye on it with the command
"free -h"
I'd also be able to do a "sudo reboot now" if needed from here.

# Section 5

So, trying to get my --ram-usage command recognised, I tried this line (added quotes):
python ArmoryQt.py --ram-usage="4" --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases
But no, same error...
Loading Armory Engine: Armory Version: 0.96.4 Armory Build: None PyBtcWallet Version: 1.35 Detected Operating system: Linux OS Variant : ('debian', '9.4', '') User home-directory : /home/ Satoshi BTC directory : /BlockChain/chain20180414 Armory home dir : /ArmoryDataDi ArmoryDB directory : /ArmoryDataDidatabases Armory settings file : /ArmoryDataDiArmorySettings.txt Armory log file : /ArmoryDataDiarmorylog.txt Do wallet checking : True (ERROR) ArmoryUtils.py:3723 - Unsupported language specified. Defaulting to English (en) (ERROR) ArmoryQt.py:1833 - Failed to start Armory database: cannot concatenate 'str' and 'int' objects Traceback (most recent call last): File "ArmoryQt.py", line 1808, in startArmoryDBIfNecessary TheSDM.spawnDB(str(ARMORY_HOME_DIR), TheBDM.armoryDBDir) File "/BitcoinArmory/SDM.py", line 387, in spawnDB pargs.append('--ram-usage=' + ARMORY_RAM_USAGE) TypeError: cannot concatenate 'str' and 'int' objects

# Section 6

So, I edit the Armory python file SDM.py:
if ARMORY_RAM_USAGE != -1: pargs.append('--ram-usage=4') #COMMENTED THIS, SO I CAN HARDCODE =4 # ' + ARMORY_RAM_USAGE)
Running it, I now have acknowledgement of the --ram-usage=4:
(WARNING) SDM.py:400 - Spawning DB with command: /BitcoinArmory/ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/BlockChain/chain20180414/blocks" --datadir="/ArmoryDataDi" --dbdir="/ArmoryDataDidatabases" --ram-usage=4
Also, even with ram-usage=4, it used too much memory, so I told it to quit.
It took over 30 minutes to stop semi-nicely. The last thing it reported was:
ERROR - 00:25:21: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unexpected fcgi header version
But that didn't seem to matter or corrupt the Armory Database, so I think it's ok.
So, I get brave and change SDM.py as below, and I make sure my script has a command line for --ram-usage="ABCDE" and --thread-count="FGHIJ"; the logic being that these strings "ABCDE" will pass the IF criteria below, and my hardcoded values will be used...
if ARMORY_RAM_USAGE != -1: pargs.append('--ram-usage=1') #COMMENTED THIS, SO I CAN HARDCODE =1 # ' + ARMORY_RAM_USAGE) if ARMORY_THREAD_COUNT != -1 pargs.append('--thread-count=1') #COMMENTED THIS, SO I CAN HARDCODE =1 #' + ARMORY_THREAD_COUNT)
So, as usual, I use my script and start this with: ./StartArm.sh
(which uses command line:)
python ArmoryQt.py --ram-usage="ABCDE" --thread-count="FGHIJ" --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases
(this forces it to use my hard-coded values in SDM.py...)
So, this is the command which it reports that it starts with:
(WARNING) SDM.py:400 - Spawning DB with command: /BitcoinArmory/ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/BlockChain/chain20180414/blocks" --datadir="/ArmoryDataDi" --dbdir="/ArmoryDataDidatabases" --ram-usage=1 --thread-count=1
Again, this is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up. So I ssh to the machine and keep an eye on it with:
"free -h"

# Section 7

So, on the Debian Desktop PC, I inserted the USB stick with the watch-only wallet I exported from the Pi.
Start Armory...
Import "Entire Wallet File" watch-only copy.
Wait 4 hours..
YAY!!!
After running Armory for about 30m, the memory usage dropped by 400m... wierd...
It took ~2 hours to get 40% completion.
After 3.5 hours it's almost there...
The memory went up to about 1.7Gb in use and 900Mb of Swap, but the machine remained fairly responsive throughout, apart from a few (10?) periods at the start, where it appeared to freeze for 10-30s at a time.
(That's where my ssh session came in handy - I could check the machine was still ok with a "free -h" command)
Now, I can:
Create an unsigned transaction on my Desktop,
Save the tx to USB stick,
Move to the Pi,
Sign the tx,
Move back to the Desktop,

# Section 8

My initial Mistake:
This caused me to have to roll-back my Armory database, using the backup. so you should try to avoid doing this..
On the Pi, I exported only the ROOT data, which will NOT capture the watching-only part of the Private Key
It is RECOMMENDED to use the Digital Export of Entire Wallet File from the Pi when making a watch-only copy. If you just export just the "ROOT data", not the "Entire Wallet File", you'll have problems if you used an imported Private Key in the offline wallet, like I did.
Using the ROOT data text import, after it finished... my balance was zero. So,. I tried a Help->Rescan Balance (Restart Armory, takes 1minute to get back up and running) No Luck. Still zero balance.
So, I try Rescan Databases.. This will take longer. Nah.. no luck.
So, I tried again, thinking it might be to do with the fact that I imported the text "root data" stuff, instead of following the (Recommended) export of watching-wallet file.
So, I used my Armory backup, and wound back the ArmoryDataDi to the point before the install of the (zero balance) wallet. (you should not need to do this, as you will hopefully use the RECOMMENDED approach of exporting the "Entire Wallet File"!)

##### Bitcoin Core painfully slow sync times + missing bitcoin.conf file?

So I've always had trouble syncing my bitcoin qt client, the times are painfully slow, (if it's even progressing at all) and I found out that the bitcoin.conf file is not created automatically and couldn't find out how to create one, there are so many flags to use. Any help?

##### Ravencoin Open Developer Meeting - 2/15/2019

RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:02 PM
Hello everybody!

## theking - Last Friday at 2:02 PM

Seems likes it’s been so long since this meeting was held. At least a month 📷

Hi all!!!

## Tom - Last Friday at 2:02 PM

Big boss is here !(edited)

Oh hi

Hi @Tron

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:04 PM

Topics for today: Release 2.2.2, Mobile Wallet, Restricted Assets, SLC Raven Meetup📷1

hello

Release 2.2.2 GO

Hey

Hi all

## Chatturga - Last Friday at 2:05 PM

Blondefrogs has been working on the 2.2.2 update. He isnt here today, but he left this tidbit for the meeting:(edited)"Release 2.2.2 has a bunch of new updates. The sync speed fix that was released in 2.2.1 has been updated even more to use less memory/ram and uses less CPU. Each node used to hold all addresses that contained an asset as well as the amount in those addresses. That is now optional with the -assetindex flag. Which can be put into the raven.conf or added as a parameter when starting the wallet. Some other wallet issues were also fixed with this memory update. This is considered an mandatory update, especially if you haven't updated to 2.2.1 which resolved a potential fork bug fix. I would still suggest updating to 2.2.2 even if you are on 2.2.1."📷6

wen source?📷1

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:07 PM

There's a PR that was just moved to Develop.When is now

great 📷

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:08 PM

It'll be merged by the devs to master and then binaries should be posted soon

## truedev - Last Friday at 2:09 PM

any idea when dividends will be functional?

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:09 PM

A bunch of testing has been happening and is currently running on the seed-nodes.

## Tron - Last Friday at 2:10 PM

No timeline for dividends, but it is the one function that doesn't need any changes to consensus. And it can be done on tier 2 with a python script. The plan is still to build in a rpc call.📷2

alright

## SpyderDev - Last Friday at 2:12 PM

We have been focusing on sync performance and have been running many tests. I've added an image of the results of this testing. Currently we still want to work on getting the Windows QT sync times faster (at least closer to what they are using just ravend). Overall we are very happy with the speeds and hope it will help people that have struggled getting their nodes up to date.(edited)📷

## Jeroz - Last Friday at 2:13 PM

Yeah that table completely puzzled me

hello!📷6

## Jeroz - Last Friday at 2:13 PM

Fast branch is 2.2.1? or 2.2.2? Develop branch is 2.2.0?

## SpyderDev - Last Friday at 2:15 PM

Sorry, should have clarified that. I was testing while it was still under development. On the table the top is the new-sync code, the bottom is the old "assets" release. As of about 5 minutes ago all of this code is on the develop branch.

## Jeroz - Last Friday at 2:15 PM

Although syncing is mostly bottlenecked by cpu speed, that 16 core windows-qt still looks off to me. I synced windows Qt using 2.2.2 in ~2h on a i5-7600K.ok

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:17 PM

Okay, we good to move to the Mobile update?

## SpyderDev - Last Friday at 2:17 PM

The Windows box is an AWS instance and there is some concern that the remote desktop could be slowing the QT UI down causing the horrible sync times. I am working on getting a local Windows 10 resource and will have updated information once that is ready (early next week).

## Jeroz - Last Friday at 2:18 PM

ah that might explain. Ubuntu qt was 45 mins for me

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:18 PM

CoolOkay, Mobile!Go!

📷📷1

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:19 PM

@[Master] Roshii has been working closely with some of the other devs to get the iOS version out the door.Android will follow closely.

## Jeroz - Last Friday at 2:20 PM

is android an easy port?

## J. | ravenland.org - Last Friday at 2:20 PM

Usually its the case(?), i mean easier 📷(edited)

## SpyderDev - Last Friday at 2:20 PM

Just copy and paste right Roshii 📷

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:20 PM

LOLNo, usually its a completely new development effort.For the RVN Wallets they are both written in native iOS/Android code.

## [Master] Roshii - Last Friday at 2:21 PM

So the iOS and Android use the same Core SPV module written in C, and it's the most difficult part.I have already did some work when it comes to Android, and it's 70% finishedHave also to port all the changes we lately did to the iOS wallet ...

## boatsandhoes - Last Friday at 2:21 PM

yeah, unfortunately its not as easy as cut and paste for ios to android

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:21 PM

Anybody interested in installing the TestFlight version and helping us test?

yes

## J. | ravenland.org - Last Friday at 2:22 PM

For android? sure.

## BW__ - Last Friday at 2:22 PM

Android? yes.(edited)

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:22 PM

I'll talk to Apple about adding Android support to TestFlight.Might be a while.

lol

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:22 PM

Anybody on here using iOS?

Yeh me

besides me...

## [Master] Roshii - Last Friday at 2:23 PM

Android is very close, fortunately I'll have enough coffee in Morocco to finish the wallet in two weeks.(edited)📷4📷5

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:23 PM

https://testflight.apple.com/join/NTVQ2FfY (400 installs available)Join the RVN Wallet betaAvailable on iOS📷

## theking - Last Friday at 2:23 PM

I will test iOS if needed

@shiny

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:24 PM

Some of the devs have been doing a bunch of testing on iOS but we would love others to help.Bugs can be reported on GitHubhttps://github.com/RavenProject/ravenwallet-iosGitHubRavenProject/ravenwallet-iosContribute to RavenProject/ravenwallet-ios development by creating an account on GitHub.📷

## truedev - Last Friday at 2:25 PM

how confident are you that apple will allow it on the appstore

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:25 PM

It's already in the App store.

ok

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:25 PM

That wasn't easy though.

## truedev - Last Friday at 2:26 PM

yah figured, a lot of coins have been completely rejected(edited)

## Chatturga - Last Friday at 2:26 PM

The devs already jumped through Apples 152,315 flaming hoops to get it in there.

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:26 PM

Yup, many meetings and phone calls.

## J. | ravenland.org - Last Friday at 2:26 PM

wen rvn modular phone

Looking good📷📷7

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:28 PM

Okay, any questions about iOS release?

## jaysonb - Last Friday at 2:28 PM

seed word format changed? i seem to have to have same words. did i need to delete and install fresh?

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:29 PM

No, it used your old ones.Always have your 12 words. especially when testing.

I’ve got iOS

## Tron - Last Friday at 2:30 PM

If you use your 12-words, and then sync, and you're missing funds. Go here: https://medium.com/@tronblack/ravencoin-testing-ios-wallet-b713deb2c800MediumRavencoin — Testing iOS Wallet – Tron Black – MediumThank you for helping us test the Ravencoin iOS mobile wallet. Since you are in an early group of testers, you might have used the…

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:30 PM

Sweet, install and report bugs.

## Tron - Last Friday at 2:30 PM

Or just go there...

## jaysonb - Last Friday at 2:30 PM

that article scared me so i moved everything off.but i'll put some back on now

📷

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:31 PM

That's unfortunate. You don't need to be scared ever if you have your 12 words.

## [Master] Roshii - Last Friday at 2:31 PM

android current state(edited)📷

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:32 PM

Here's the install link one more time for those that have joined late: https://testflight.apple.com/join/NTVQ2FfYJoin the RVN Wallet betaAvailable on iOS📷Okay, Tron's topic: Restricted Tokens

## Tron - Last Friday at 2:33 PM

I have an idea.(edited)📷7📷6

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:34 PM

That several other devs have helped with. 📷

📷

and lawyers

## Tron - Last Friday at 2:34 PM

When the project started, ICOs were the big thing. Now it is STOsThe main difference is the legal wrapping and rules around securities.If Ravencoin has two more token types (Tags and Restricted Assets), there are lots of ways to make compliant tokens.Importantly, it doesn't affect the existing tokens at all.Tags - Tokens that can be sent only by the issuer once (with metadata).These tokens start with (hashtag)(edited)📷8

^(octothorpe)

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:40 PM

So Ravenland will have to buy a bunch more spam tokens.📷4

#ravenland.

## DeejayQQ - Last Friday at 2:41 PM

Can the same name have different token type?Sorry need time to digest

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:42 PM

Still working out the details. Tron will be posting additional info about the idea soon.

Cool

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:42 PM

Feedback is wanted!

## Tron - Last Friday at 2:42 PM

Q: Was this originally the plan for Ravencoin? A: No. This is in response to the regulatory ramp up in 2018 in some jurisdictions which requires that only known individuals or entities to operate peer-to-peer on certain tokens. For jurisdictions that allow unrestricted peer-to-peer transfer, we strongly encourage use of the original Ravencoin assets. The Restricted Assets are an adaptation to satisfy burdensome, privacy-destroying regulations, with a goal of reducing information replication which makes Ravencoin Restricted Assets a better alternative to those being promoted now.

## jaysonb - Last Friday at 2:43 PM

all nodes will validate the transactions not just those interested in the transaction - i assume all will validate..

## boatsandhoes - Last Friday at 2:43 PM

so essentially any name already secured in the hopes of having that functionality are worth less because they wont be able to?

## theking - Last Friday at 2:44 PM

Can the restricted assets be time based in any way? For instance, in some STO regulated environment, there is a lockup for some period of time after issuance, but then after a certain period of time the restriction goes away and the securities can be traded. Is that contemplated at all?

## DeejayQQ - Last Friday at 2:44 PM

If I already have Tron as my asset, there could be another Tron but under a different token type such as restricted assets?

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:44 PM

Yes all nodes will do consensus checks.

## Tron - Last Friday at 2:45 PM

Regarding the lockup....

## boatsandhoes - Last Friday at 2:45 PM

how many RVN for that?

## Tron - Last Friday at 2:45 PM

Rule 144 under the Securities Act of 1933 This is an important rule to be aware of in terms of privately held securities. This rule provides the most commonly used exemption for holders to sell restricted securities (Note: For context, a restricted security is a security sold in an exempt offering, except for Reg A+). The general idea is that you can publicly resell your “restricted” (privately sold) securities only when the restricted legend is removed. The solution Ravencoin Restricted Assets provides is the ability for the Iissuer to Freeze the asset ininto the holders account. The qty will be visible, and the frozen status will be visible. The meta-data for a Freeze can specify 144_Restricted. The issuer can Unfreeze to release the 144 restriction.Similar for Reg D 1-year lockup.@theking

@theking ^^

## DeejayQQ - Last Friday at 2:46 PM

What is the timeline for this restricted asset to be implemented?📷1

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:46 PM

No timelines yetStill in the ideation phase.

## SpyderDev - Last Friday at 2:46 PM

Fresh off the press...

## DeejayQQ - Last Friday at 2:46 PM

Ok, idea for nowGot it

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:46 PM

Wanting input for the idea.

## boatsandhoes - Last Friday at 2:47 PM

a preset for lock up settings would be nice

## Jeroz - Last Friday at 2:47 PM

What about the ability to move an asset from restricted to unrestricted after grace period similar to the reissue ability? By the issuer(edited)

## DeejayQQ - Last Friday at 2:48 PM

If this restricted assets would help underlying token listed on exchanges for trading by satisfying the legal requirements, I don’t see why not. There are only benefits📷2

yeah, win win

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:48 PM

There is something similar in vote tokens.

## corby - Last Friday at 2:48 PM

@Jeroz the issuer would be able to "reissue" and relax restrictions

## DeejayQQ - Last Friday at 2:48 PM

Just throwing things out here. Can we just make all existing tokens crested so far restricted assets?*created

## BW__ - Last Friday at 2:50 PM

Is it fair to assume that tags can be standardized for specific purposes? If so, should we create something akin to an 'ERC' in git repo?

## Jeroz - Last Friday at 2:50 PM

@Tron sounds cool

## truedev - Last Friday at 2:50 PM

honestly, I think you should be able to buy/create an asset in a set, with all types(edited)

^that part

## Hans_Schmidt - Last Friday at 2:51 PM

Since the #KYC tag is just locked to an address, what prevents someone from selling their address and thereby the KYC?

## corby - Last Friday at 2:51 PM

The "#" types won't trade -- they're just stamps to stamp addresses as qualified-to-hold-some-stuff..

## Tron - Last Friday at 2:51 PM

The tags are created by the users. The system is still jurisidiction agnostic.

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:51 PM

@Hans_Schmidt nothing really, the same thing as selling your username password to any other existing financial app account.

## corby - Last Friday at 2:51 PM

@Hans_Schmidt Real world networks, high cost of entry (for serious applications)For non-serious applications, nothing

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:51 PM

You still have the liability associated with that account though.

## Chatturga - Last Friday at 2:56 PM

I dont know that we have the ability to make it interactive as far as Q&A goes, but I'll look into it. We should have it live streaming. @J. | ravenland.org(edited)📷2

## BW__ - Last Friday at 2:56 PM

@Tron Is there same kind of logic layer to restricted assets?(edited)

## Tron - Last Friday at 2:57 PM

@theking I like that idea.

## Jeroz - Last Friday at 2:57 PM

Quick question that is offtopic but I think deserves an answer because it was asked a couple of times earlier this week: Will unique assets get a reissuable function? To change IPFS.(edited)📷2

## Tron - Last Friday at 2:57 PM

@BW__ Yes. Simple and, or, not and parenthesis - limited in length.(edited)

## boatsandhoes - Last Friday at 2:57 PM

@theking thats a good idea

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:58 PM

@Jeroz There is not a way to do that currently.

## BW__ - Last Friday at 2:58 PM

@Tron That makes sense. Thank you.

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 2:58 PM

Just make sure your changes to the information have the same hash as the previous data and your golden. 📷📷1

## Jeroz - Last Friday at 2:59 PM

Any plans on changing that, perhaps when introducing new types of assets?

## boatsandhoes - Last Friday at 2:59 PM

i like that it cant be changed

Thanks everyone!

## theking - Last Friday at 3:00 PM

@Tron there was some info floating around about a 2nd later KYC solution ( from your recent podcast w Crypto Koala). Is that a separate solution someone is working on or part of this new concept?📷1

## Tron - Last Friday at 3:01 PM

Starting with the introduction of messaging, every transaction can have an IPFS hash. Can be used as an public invoice, details about the transaction, etc.@theking The same new concept.

Ok, we're done.

## Steelers - Last Friday at 3:02 PM

How would Raven handle for instance a stock split?

## BW__ - Last Friday at 3:02 PM

Are there sync concerns if a restricted asset logic layer is added?

## Tron - Last Friday at 3:02 PM

@theking The KYC provider would store the KYC info, and send the Tag to an address with meta data that specifies that they're holding the KYC data. The KYC data would not be public, but could be audited.

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 3:02 PM

That way you could update information about the original unique asset with each transaction.@Steelers Just a simple re-issue of the asset

## Tron - Last Friday at 3:03 PM

@bw_ The logic layer is only a small db that stores the meta-data about the Restricted Asset, and enforces the restriction in the consensus rules. Rule returns true/false.(edited)

## RavencoinDev (Jesse/Wolfsokta) - Last Friday at 3:03 PM

Thanks everybody! I have to run.

## Jeroz - Last Friday at 3:04 PM

I'm looking forward to the discussions to let this take shape. Thanks all! 📷📷4

## Tron - Last Friday at 3:05 PM

@BW__ It would work very similarly to the way the units works now. Each asset has number of units and any transaction that makes it too granular (more satoshis) will fail in consensus -- even if it gets past the RPC checks.Signing off. Thanks all!!!📷9📷4📷9

##### Ravencoin Open Developer Meeting - 1/4/2019

[14:04] Hi everyone! [14:04] :dabbitwave: [14:04] Hey Everybody! [14:04] Hello 😃 [14:04] Sorry we're getting started a bit late. [14:04] Topics: SLC Meetup (March 15th) [14:04] 👋 [14:04] Roadmap breakdown - posted to github [14:05] IPFS (integration) [14:05] greetings 👋 [14:05] So, SLC Meetup on the 15th! [14:05] Great! [14:05] Hi! [14:06] Hi all — a special thanks to the developers and congratulations on an amazing first year!!! # [14:06] <[Dev] Blondfrogs> Hello Everyone! [14:07] We have a tentative agenda with @Tron , @corby speaking. [14:08] We would like to have nice walkthrough of the Raven DevKit for the meetup. [14:08] We are planning on hosting a meetup in SLC at the Overstock building on March 15th from 6:00pm-9:00pm. It is free admission, but there is a page on meetup.com where people can rsvp so that we have a somewhat accurate headcount for food. [14:08] sup guys [14:08] hey russ [14:09] We are planning on having a few speakers and have allotted a bit of time at the end for people to meet and greet each other. [14:09] can you guys link us to the page somewhere when thats available? 😄 [14:10] free food?! [14:10] todays topic? [14:10] yeah can we indicate pepperoni pizza [14:10] Sounds good to me @Jeroz Nothing ordered yet though. 😃 [14:10] only pepperoni pizza is served at true blockchain meetings right [14:10] :blobhide: [14:10] Absolutely. The itinerary just needs to be finalized and then I'll make a broad post about the rest of the details. [14:11] https://www.meetup.com/Salt-Lake-City-salt-lake-city-Meetup/ [14:11] 😭 so far away [14:11] West Coast! [14:11] @MTarget But there's pizza, so worth the travel time. [14:11] lol [14:12] I'll be watching the stream if its available since i'm from montreal/canada 😛 [14:12] Ah yes, I love $300 pizza 😉 [14:12] as long as I get to see your smiling faces @Tron @RavencoinDev then it's worth the time [14:12] We'll be there. [14:12] We'll be messaging additional details as they get finalized. [14:12] Greeting and salutations! [14:12] sup [14:13] Hey,$300 is considerably cheaper than 2 $3,700,000 pizzas. [14:14] Ok, switching topics... [14:14] yeah its a way to fly, [14:14] question is whether those piza's will be paid for in RVN coin or not :ThinkBlack: [14:14] Roadmap [14:14] It hasn't changed, just added some detail. [14:14] https://github.com/RavenProject/Ravencoin/tree/masteroadmap [14:15] nice [14:15] This now links to a breakdown for messaging, voting, anti-spam, and rewards (dividends) [14:15] will there be any additional RPC functionality coming in the future, thinking in terms of some functions that are only available in ravencore-lib [14:15] apologies if now is not time to ask questions, i can wait for later [14:15] "Phase 7 - Compatibility Mode" - that's new 😮 [14:15] The protocol for messaging is pretty well established, but the rest isn't in stone (code) yet. [14:16] can you give us details on compatibility mode? [14:16] In broad brush strokes. [14:17] The idea is to allow ravend to act as a daemon that looks like a single coin. [14:17] so ravend that only works with the bitcoin asset? [14:18] interesting [14:19] So you start it with an option to only work with a single asset/token account or something? [14:19] hmm compelling what is the reason for this? some kind of scale or performance? [14:19] ^ [14:19] Example: Configure ravend to listen for transfer RPC call for senttoaddress or sendfrom, but for a specific asset. This would allow easy integration into existing system for assets. [14:20] Only the daemon or the whole wallet UI? [14:20] yeah thats great, rpc functions dont allow us to do this yet, if i recall [14:20] or at least we depend more on ravencore lib [14:20] so like asset zmq [14:20] that's smart [14:20] @Tron it also sounds like it makes our life easier working with RPC, instead of core all the time for some functionality [14:21] if i understand correctly anyways [14:21] So you could run numerous instances of ravend each on their own network and RPC port, each configured for a different asset. You would need some balance of RVN in each one to cover transaction fees, then. [14:21] id be curious to know what all the advantages are of this [14:21] one more question, how would i decentralize the gateway between bitcoin mainnet/ravencoin mainnet? in the current RSK implementation they use a federated gateway, how would we avoid this? [14:21] it sounds neato [14:21] Just the daemon. The alternative is to get exchanges to adapt to our RPC calls for assets. It is easier if it just looks like Bitcoin, Litecoin or RVN to them, but it is really transferring FREE_HUGS [14:22] That makes sense. Should further increased exchange adoption for each asset. [14:22] hmm yeah its just easier for wallet integration because its basically the same as rvn and bitcoin but for a specific asset [14:22] so this is in specific mind of exchange listings for assets i guess [14:23] if i understand rightly [14:23] @traysi Gut feel is to allow ravend to handle a few different assets on different threads. [14:23] Are you going to call it kawmeleon mode? [14:23] Lol [14:23] I read that as kaw-melon mode. [14:24] same lol [14:24] so in one single swoop it possible to create a specific wallet and server daemon for specific assets. great. this makes it easier for exchanges, and has some added advantages with processing data too right? [14:24] Still keeping a RVN balance in the wallet, as well, Tron. How will that work is sendtoaddress sends the token instead of the RVN? A receive-RVN/send tokens-only wallet? [14:25] @traysi Yes [14:25] sendtoaddress on the other port (non RVN port) would send the asset. [14:25] This will be a hugely useful feature. [14:25] ^ [14:26] @Tron currently rpc function not support getaddresses senttowallet and this has to be done in ravencore lib, will this change you propose improve this situation [14:26] Config might look like {"port":2222, "asset":"FREE_HUGS", "rpcuser":"hugger", "rpcpass":"gi3afja33"} [14:26] how will this work cross-chain? [14:28] @push We'd have to go through the rpc calls and work out which ones are supported in compatibility mode. Obviously the mining ones don't apply. And some are generic like getinfo. [14:28] ok cool 👍 cheers [14:29] for now we continue using ravencore lib for our plans to keep track i just wondering if better way [14:29] as we had some issue after realising no rpc function for getting addresses of people who had sent rvn [14:29] @push | ravenland.org all of the node explorer and ravencore-lib functionality is based on RPC (including the addressindex-related calls). Nothing you can't do with RPC, although I'm not sure of the use cases you're referring to.. [14:29] interesting, so ravencore lib is using getrawtransaction somehow [14:29] i thought this may be the case [14:29] that is very useful thankyou for sharing this [14:30] look into addressindex flag and related RPC calls for functions that operate on addresses outside your wallet [14:30] thank you that is very useful, tbh i am not very skilled programmer so just decoding the hex at the raven-cli commandline was a challenge, i shall look more into this, valued information thanks as this was a big ? for us [14:31] Ok, things have gone quiet. New topic. [14:31] IPFS (integration) [14:31] GO [14:33] ... [14:33] <[Dev] Blondfrogs> So, we have been adding ipfs integration into the wallet for messaging. This will allow the wallets to do some pretty sweet stuff. For instance, you will be able to create your ipfs data file for issuing an asset. Push it to ipfs from the wallet, and add the hash right into the issuance data. This is going to allow for a much more seamless flow into the app. [14:34] <[Dev] Blondfrogs> This ofcourse, will also allow for users to create messages, and post them on ipfs and be able to easily and quickly format and send messages out on the network with ipfs data. [14:34] It will also allow optional meta-data with each transaction that goes in IPFS. [14:34] will i be able to view ipfs images natively in the wallet? [14:34] <[Dev] Blondfrogs> Images no [14:34] We discussed the option to disable all IPFS integration also. [14:35] @russ (kb: russkidooski) Probably not. There's some risk to being an image viewer for ANY data. [14:35] No option in wallet to opt into image viewing? [14:35] cool so drag and drop ipfs , if someone wanted to attach an object like an image or a file they could drag drop into ui and it create hash and attach string to transaction command parameters automatically [14:35] We could probably provide a link -- with a warning. [14:35] nomore going to globalupload.io [14:35] :ThinkBlack: [14:35] I understand that the wallet will rely on globalupload.io. (phase 1). Is it not dangerous to rely on an external network? Or am I missing something? [14:36] hmm [14:36] interesting, i suppose you could hash at two different endpoints and compare them [14:36] if you were that worried [14:36] and only submit one to the chain [14:36] You will be able to configure a URL that will be used as an IPFS browser. [14:36] Oh ic [14:36] you wont flood ipfs because only one hash per unique file [14:36] <[Dev] Blondfrogs> There are multiple options for ipfs integration. We are building it so you can run your own ipfs node locally. [14:36] <[Dev] Blondfrogs> or, point it to whatever service you would like. e.g. cloudflare [14:36] this is very cool developments, great to see this [14:37] Just like the external block explorer link currently in preferences. [14:37] @[Dev] Blondfrogs what about a native ipfs swarm for ravencoin only? [14:37] We have discussed that as an option. [14:37] @push | ravenland.org Considering having a fallback of upload through globalupload.io and download through cloudflare. [14:37] <[Dev] Blondfrogs> @russ (kb: russkidooski) We talked about that, but no decisions have been made yet. [14:37] yeah, i would just use two endpoints and strcompare the hash [14:37] as long as they agree good [14:37] submit tran [14:38] else 'potentially mysterious activity' [14:38] ? [14:38] if you submitted the file to ipfs api endpoints [14:38] Will the metadata just be a form with text only fields? [14:39] and then you would get 2 hashes, from 2 independent services [14:39] that way you would not be relying on a central hash service [14:39] and have some means of checking if a returned hash value was intercepted or transformed [14:39] i was answering jeroz' question [14:40] about relying on a single api endpoint for upload ipfs object [14:40] We have also kicked around the idea of hosting our own JSON only IPFS upload/browse service. [14:41] I have a service like this that is simple using php [14:41] we only use it for images right now [14:41] but fairly easy to do [14:41] Yup [14:42] Further questions about IPFS? [14:43] contract handling? file attach handling? or just text fields to generate json? [14:44] trying to get an idea of what the wallet will offer for attaching data [14:44] Probably just text fields that meet the meta-data spec. [14:44] ok noted [14:44] What do you mean by contract handling @sull [14:45] We won't prevent other hashes from being added. [14:45] asset contract (pdf etc) hash etc [14:45] <[Dev] Blondfrogs> also, being able to load from a file [14:45] got it, thanks [14:47] Let's do some general Q&A [14:48] Maybe just a heads up or something to look for in the future but as of right now, it takes roughly 12 hours to sync up the Qt-wallet from scratch. Did a clean installation on my linux PC last night. [14:48] Any plans or discussions related to lack of privacy of asset transfers and the ability to front run when sending to an exchange? [14:48] ^ [14:48] Is there a way to apply to help moderate for example the Telegram / Discord, i spend alot of time on both places, sometimes i pm mods if needed. [14:49] Any developed plans for Asset TX fee adjustment? [14:49] also this^ [14:49] @mxL86 We just created a card on the public board to look into that. [14:49] General remark: https://raven.wiki/wiki/Development#Phase_7_-_Compatible_Mode = updated reflecting Tron's explanation. [14:49] @mxL86 That's a great question. We need to do some profiling and speed it up. I do know that the fix we added from Bitcoin (that saved our bacon) slowed things down. [14:50] Adding to @mxL86 the sync times substantially increased coinciding with the asset layer activation. Please run some internal benchmarks and see where the daemon is wasting all its cycles on each block. We should be able to handle dozens per second but it takes a couple seconds per block. [14:50] @BW__ no plans currently for zk proofs or anything if that's what you're asking [14:50] You are doing a great job. Is there a plan that all this things (IPFS) could be some day implemented in mobile wallet? Or just in QT? [14:50] i notice also that asset transactions had some effect on sync time as we were making a few. Some spikes i not analysed the io and cpu activity properly but will if there is interest [14:51] we are testing some stuff so run into things i am happy to share [14:51] @BW__ Might look at Grin and Beam to see if we can integrate Mimble Wimble -- down the road. [14:51] yeees [14:51] @J. | ravenland.org work with the telegram mods. Not something the developers handle. [14:51] i love you [14:51] @J. | ravenland.org That would be best brought up with the operators/mods of teh telegram channel. [14:51] @corby @Tron thnx [14:51] @S1LVA | GetRavencoin.org we're planning on bumping fees to... something higher! [14:51] no catastrophic failures, just some transaction too smals, and mempool issues so far, still learning [14:52] @corby i thought that this may happen :ThinkBlack: [14:52] @corby x10? 100x? 1000x? Ballpark? [14:52] Definitely ballpark. [14:52] 😃 [14:52] 😂 [14:52] Is a ballpark like a googolplex? [14:53] @push | ravenland.org asset transactions are definitely more expensive to sync [14:53] yes yes they are [14:53] they are also more expensive to make i believe [14:53] 10,000x! [14:53] as some sync process seems to occur before they are done [14:53] @traysi ★★★★★ thanks for the suggestions we are going to be looking at optimizations [14:53] But, it is way slower than we like. Going to look into it. [14:53] i do not understand fully its operation [14:53] 1000x at minimum in my opinion [14:53] its too easy to spam the network [14:54] yes there has been some reports of ahem spam lately [14:54] :blobhide: [14:54] 😉 [14:54] cough cough ravenland [14:54] @russ (kb: russkidooski) we're in agreement -- it's too low [14:54] default fee 0.001 [14:54] ^ something around here [14:54] @corby yep we all are i think [14:55] waaay too low [14:55] meaningful transactions start with meaningful capital expense [14:55] though there is another scenario , there are some larger volume, more objective rich use cases of the chain that would suffer considerably from that [14:55] just worth mentioning, as i have beeen thinking about this a lot [14:55] there are some way around, like i could add 1000 ipfs hashes to a single unique entity, i tested this and it does work [14:56] @russ (kb: russkidooski) What would you suggest. [14:57] I had a PR for fee increase and push back. [14:57] Ignore the push back. 0.001 RVN is not even a micro-farthing in fiat terms [14:57] definitely around 1000x [14:57] Vocal minority for sure [14:57] ^ yep [14:57] @russ (kb: russkidooski) That sounds reasonable. [14:57] Couple hundred Fentons [14:58] right now an asset transaction is 0.01 of a penny essentially [14:58] 1 RVN would work now, but not when RVN is over$1. [14:58] yes exactly [14:58] Hi. Late to the party. [14:58] We are also talking about a min fee. The system will auto-adapt if blocks fill up. [14:58] im thinking tron, some heavy transaction use cases would fall out of utility use if that happened [14:58] so whats the thinking there [14:59] is there a way around the problem, bulked ipfs hash transactions? [14:59] 1000x would put us around btc levels [14:59] maybe a minimum 500x? [14:59] @russ (kb: russkidooski) Agreed. [14:59] <[Dev] Blondfrogs> It is time to wrap it up here. Everyone. Thank you all for your questions and thoughts. We will be back in 2 weeks. 😃 [14:59] Small increase and review. [14:59] Thanks all! [14:59] Cheers. [15:00] yeah sorry for 1 million questions guys hope i didnt take up too much time [15:00] cheers all 👍 [15:00] Thanks everyone [15:00] Thanks everyone for participating!!! [15:00] That is what we are here for [15:00] 100x-500x increase, 1000x maximum [15:00] 🍺

##### Reddcoin Core 2.1

Reddcoin Core 2.1 will be an update to the core components of Reddcoin : reddcoin-qt and reddcoind. One of the key improvements is expected to be a speedup for the blockchain synchronization process - something we read a lot of negative comments about - and understandably so. I have a 2011 vintage laptop which I use for testing. It takes more than a few days to chew through the blockchain sync. Old though it may be, it’s my favorite benchmark of acceptable performance.
First let me explain why blockchain sync is slow, then explain what will be done to speed it up.
The Reddcoin blockchain is up to block 1760528 whereas Bitcoin is up to block 472265 (as I write this). That the Reddcoin blockchain is 3.7 times longer despite only having been alive since 21 Jan 2014 versus Bitcoin’s birth in 2009 may come as a surprise, until you remember that Reddcoin’s block time of 60s is one tenth’s of Bitcoin’s 10min block time. Under normal operating conditions on recent hardware you are unlikely to notice any performance hit. But the blockchain synchronization process cruelly throws the spotlight on one of the more CPU intensive aspects of maintaining a blockchain - block validation - something every network node does whether a new block is propagating through the network or an old block is being synced from either a bootstrap file or a network peer. Whatever performance issues Bitcoin 0.9 had during blockchain synchronization, Reddcoin necessarily suffers 10x worse.
Whilst making Bitcoin comparisons, it’s useful to recall the origins of our current Reddcoin Core 2.0.
Reddcoin Core 2.0 is based on Bitcoin 0.9 with the PoSV code from Reddcoin 1.4 reintegrated - work that @Gnasher completed almost a year ago specifically to incorporate the OP_RETURN feature from Bitcoin 0.9 which is a key enabler for Redd-ID. Peering at the Github tea leaves it is evident that synchronization performance was thought to be an issue in Bitcoin 0.9 because there were features introduced in later versions to address specifically this concern. And it is precisely these features we plan to integrate into Reddcoin Core 2.1 as part of the overall strategy of shadowing the Bitcoin code base as and when the need arises to move things forwards. My personal dream is getting SegWit live on Reddcoin, but clearly with rather empty blocks and 10x the capacity of Bitcoin, we’re way off needing something like a Reddcoin Lightening Network yet. But it is good to know we have that option open to us in our future road map.
Therefore the work currently underway for Reddcoin 2.1 is expected to include two features that will accelerate the blockchain synchronization process:
1 - “headers first” synchronization taken from Bitcoin 0.10
2 - Removal of the openssl lib dependency and replacing that very generic and slow elliptic curve crypto code with an optimized internal implementation originally developed for Bitcoin 0.12.
Whether this work will get Reddcoin Core all the way up to Bitcoin 0.12 remains to be seen. The base target is Bitcoin 0.10 with at least one 0.12 feature.
I don’t yet know what kind of speedup we should expect from this, but I am hopeful of something significant. I plan to publish timing comparisons once I have a beta of 2.1 with these features working. Anyone eager to know sooner is welcome to test Bitcoin 0.9 vs. Bitcoin 0.12.
Meanwhile with Redd-ID close to entering beta testing and a great mobile wallet team taking shape off the back of the recent upsurge of interest in Reddcoin, we can expect 2017 to be a good year for Reddcoin.
Keep on staking !

##### My first experience with bitcoin was NOT positive :( + Questions

After seeing an interesting comment on /funny in which bitcoin currency is used to make tips across reddit I started to investigate and learn about the Bitcoin. I had heard about it before but I didn't know how it worked or what I had to do in order to use it.
A dozen Bitcoin Wiki entries later I download bitcoin-qt and create my first wallet. The system seemed very easy and straightforward and I had already started to apply for "free starter bitcoins" when I met "synchronization".
Now synchronization is not necessarily a deal breaker but it was annoying as hell. I'm using an old computer and it seemed as if it would take at least a day if not more to complete the whole process... and during that time my computer was getting slow as hell.
Now I'm quite a tech savy person and I know why in this P2P based system this is important, but for anyone else this would be unacceptable. Imagine elder people or not so tech savy persons trying out the system for the first time and noticing that they can't use it without occupying 2+ GiB of their HardDrive and having to wait a lot.
I did not complete the sync and tried to use the multibit instead. But since I had already applied to the Free starter bitcoins on some websites I wanted to keep my old wallet. I try to look for an import/export button but it seems that Bitcoin-qt doesn't support exportation and I needed to use a third party application called pywallet (command line!) to export my wallet and convert it into another plaintext format since the format used by bitcoin-qt was not supported by multibit.
And one would assume that the first thing you do when creating such a currency is to define a standard for the wallet and the applications. Again, I know how to use the command line but anyone who doesn't and who just wants to try out the system for the first time would be inmediately turned off by this limitation.
These are all issues that need to be fixed and addressed. Also, at the current situation it is much more comfortable and easier to set up an e-wallet than using standalone software on my computer. And if you ask me, it beats the purpose of creating a decentralized currency when in the end the most popular e-wallet services are going to hold most bitcoins and suppose a great security risk.
So I ask you: do you know any solutions to the above mentioned problems? Is there any way to reduce the impact by those hindrances?
And now to the questions:
Since I'm a very inquisitive mind and I'm still very much interested in bitcoins I would like to ask some questions I couldn't find properly answered in the wiki about the nature of the bitcoin system and how exactly it works.
I'd be very grateful if you could answer any of the following questions:
1. What exactly is a bitcoin? A string of text? A hash? A file with a string of text?
2. If I'm not mistaken, a bitcoin wallet is made of a public key and a private key. If I want to transfer my wallet from one program to another or a piece of paper... would I need to export or print out the strings of text that form the bitcoins itself or do I just need those two keys?
3. How does the bitcoin system know how much balance is inside an wallet/account. Does it typically ONLY check it against the chainblock or does it also make use of any bitcoin strings stored inside the wallet?
4. Cryptographically speaking... what happens when I transfer bitcoins?
Thank you!
*Please don't downvote me just because my first experience was negative. I'm still very interested and would like to learn a lot more. *
Edit: Thank you very much for all your answers! I can't reply to all of you (mainly because it's very late over here) but I feel that I understand the concept much better and also feel much more comfortable knowing that the only thing I ever need is my private and public key. It makes me care much less about software and wallet.data files, knowing that I can have everything I need written on piece of paper or saved in an encrypted file of my own. Then, when I need to spend bitcoins or check my balance I can use whatever software I deem best at the moment.
Thank you!

##### The Monero Missives (weekly report) - September 16th, 2014

Original post is here
Monero Missives
September 15th, 2014
Hello, and welcome to our twelfth Monero Missive! This is our first Missive after a bit of a break whilst we thwarted two related blockchain attacks. Nonetheless, we have not sat by idly, we have been finalising and completing a brand new aspect of Monero designed to protect your privacy now and in the future: the Monero Research Lab
1. The Monero Research Lab is an open collective and a multi-faceted academic group focused on the ongoing improvement of Monero. Membership is not fixed, and comes and goes as researchers become interested in Monero. This isn't a group focused on the addition of "features" to Monero, but rather the analysis and improvement of the underlying core of Monero to make sure that the theories and cryptography behind Monero continue to remain robust and sound. With that in mind, we are proud to announce the release of the first two publications out of the Monero Research Lab: MRL-0001 - A Note on Chain Reactions in Traceability in CryptoNote 2.0 - this is a research bulletin that investigates how a chain reaction could weaken the blockchain resistance properties of CryptoNote's ring signatures if low mixin values are consistently chosen MRL-0002 - Counterfeiting via Merkle Tree Exploits within Virtual Currencies Employing the CryptoNote Protocol - in this research bulletin we investigate how the block 202612 attack occurred and what it exploited, and also covers the permanent fix we have put in place
2. This week Friday we're going to have our second #Monero-Dev Fireside Chat this week Friday, September 19th, 2014, at 10:00 EST which is 14:00 UTC and 16:00 UTC +2. For a full table of the time zones you can refer to this image, or you can use this online tool to add your city and make sure you have the correct starting time. Please note that this is a developer event, and so most of the focus will be from that perspective.
3. To pick up where we left off with our last Missive, we are also happy to announce the availability of Monero merchandise on the Monero Gear store, powered by Zazzle. The advantage of us using Zazzle is that it is on-demand and we never have to worry about print runs or stock or anything. In return we get 15% of each sale as a "royalty" that will go towards enabling further Monero development, although Zazzle do not (yet!) accept Bitcoin or Monero. We hope to add new designs to the store on a regular basis. You can check the store out here: http://www.zazzle.com/monerogear* or take a peek at some of the new designs right here
4. We are also pleased to announce the release of URS, a Monero project written in Go that allows you to sign messages using ring signatures as part of a group. The signature can be verified, but it cannot be determined which one of the signatories in the group did the actual signing (just like Monero uses for transactional unlinkability!). You can take a look at the project here: https://github.com/monero-project/urs, and the Bitcointalk thread dedicated to the project is here: https://bitcointalk.org/index.php?topic=768499.0
5. We have a new tagged release, 0.8.8.4, available for download (binaries: Windows, Mac, Linux, FreeBSD). This adds the following features: Testnet: we now have an operating testnet. When using bitmonerod or simplewallet you can now use the --testnet flag to use testnet instead of mainnet. Feel free to run a mining node or just a testnet node, we will be setting up email alerts for testnet nodes when an update is pending (although having a few older testnet nodes on the network won't hurt testing). FreeBSD Compatability: Monero now works on FreeBSD out the box. We will add it to the ports tree soon. At the moment compilation is no different from regular Linux and Unix compilation, and the same dependencies apply. GPG commits: we have begun GPG-signing commits and merges. This is an important step in maintaining the integrity of the codebase, and will ensure that any compromise of our computers or even the github account won't allow a malicious attacker to push code to the repository without the unsigned commits being spotted. Verification can be done by running 'git log --show-signature', which will show and verify signatures. An example of what you should see can be found here Versioning: versioning is a lot easier, now, as tagged releases from 0.8.8.4 onwards will show version-final (eg. 0.8.8.4-final) as their version, and those built between tagged releases will show version-commithash (eg. 0.8.8.4-9088ea1). We expect this will greatly aid in debugging problems, as we can immediately pinpoint the actual version / commit a user is on. Logging: default log levels have been adjusted so that non-critical warnings are now relegated to log-level 1 and above. Apart from the normal reorganisation notifications, the only messages in red that should show up in the daemon are actual errors.
6. We have slowed down development on the GUI to give us a bit more time to focus on the Monero internals. This is especially important given the recent attack. However, work has not come to a complete halt, and so we wanted to show off a couple of pages from the first start wizard. Bear in mind that these aren't mockups, this is the actual running Qt interface: http://i.imgur.com/jzUvSEP.jpg, http://i.imgur.com/Bj1PTcU.jpg, http://i.imgur.com/oirzi9n.jpg, http://i.imgur.com/ACDmOFJ.jpg
7. Monero has been added to another exchange, Coin Swap. You can find the market here: https://coin-swap.net/market/XMBTC
Dev Diary
Core: because of all of the rapid changes that we had to merge into master to deal with the aftermath of the block 202612 attack, we have to bring the development branch in sync. At this stage the development branch should not be considered usable until the rebase is complete.
Build: the big change is FreeBSD compatibility, as mentioned above. A more subtle change is that the build will now first look for miniupnpc on the local system, and use that if found. If it fails to find miniupnpc it will fall back to the local copy.
Build: there is a new Makefile target, release-static, that builds statically linked binaries for redistribution. At this stage it forces 64-bit builds, once we have the embedded database working cleanly we can remove this.
Wallet: per-kb fees are nearly complete, and will be deployed to testnet within the next week or so. Once some thorough testing has been done on testnet we can merge this into master, and transaction fees can return to "normal".
Blockchain: this took a bit of a backseat with the blockchain attacks. Now that things are back to some semblance of normality, the first implementation can be written. We have chosen LMDB for the initial implementation, as this will allow us to rapidly write a Berkeley DB interface based off of it (they use similar APIs) and thus have a baseline for performance comparisons.
Core: all non-critical "errors" and warnings have been moved to log-level 1. As a developer, you may find it useful to run log-level 1 or 2 as your default.
Until next week!

##### My experience with bitcoins - why it won't take off and replace "fiat currencies"

I have been experimenting with bitcoins for more than 2 years now and I returned to see where my experiment stood after the recent twittering in the copper lines.
When I first used bitcoins a few years ago, there was one client and the transactions were not much. Now there are a plethora of clients to use and each comes with its own set of headaches. I tried Bitcoin-QT (the "official" client), electrum and multi-bit.
Guess what? chicken butt!
Storage space: I installed Bitcoin-QT and it has used up 12GB of my hard disk space and still has not synced up. The issues with this "official" or most popular client is acknowledge here
Imagine if everybody in the world started using bitcoins and this preliminary set up takes a week or so now, even more later on, how easy it would be for financial transactions. It is definitely not like transferring "fiat money" electronically or just walking over and handing cash.
Problems with safety and security: I did this mistake once in my early days - I wiped off my hard disk without proper backup (who backs up roaming profiles - unnecessary in the real world, but paramount in bitcoin world) and I lost my bitcoins. It wasn't worth much, so cheaper than losing some coins in my sofa.
There have been atleast 3 instances reported this month of coins stolen, supposedly through the bitcoin-qt client - read about it here
The most common analogy given is, you wouldn't let your real life wallet lying around, but it is just not the same as taking all precautions and still losing bitcoins because the technology involved is just too much for the common man. Just read through the friendly instructions given on how to do a secure transaction. The corresponding shitty analogy in real life will be - keep your wallet under layers of clothes, possibly tied to a chain around your waist. If you want to give someone money, walk into a secure room, remove clothes to access chain, remove wallet from chain, take out the money, secure wallet to chain around waist, wear clothes, walk outside to the room, and give money to the concerned party.
Transaction fees: Right now it is voluntary for transferring money, but of course, transfers can be "expedited" by simply "donating" a small fee (wink wink, nudge nudge, eh?). A few years ago, when bitcoin was not more than $20, it was a fraction of cents; today it is 1/1000th or 1/100th of a cent. Imagine if bitcoin reaches$100,000 as some claim, this "speed fees" or as they call baksheesh or bribe in my country, could be a good chunk of money. This is documented here
Ease of use, huh, what's that?? As I mentioned earlier, there are 3 different clients recommended (each with its own headache, of course,) but none of them are user friendly.
One has a huge set up time, one needs you to turn on certain features, and the third connects to a server to validate transactions, which is like, I need to be online whenever I need to do this "transaction thingie." In a country where there are powercuts for upto 10 hours in some cities, or where there are frequent brownouts, and the internet speed is abysmally slow, the ease of cold hard cash, even if it is undervalued, triumphs all the proponents' arguments.
Read the analogy about IRL wallet in 'safety and security' for this 'ease of use'
Corruption: Let's see, corruption is not widespread in USA (I guess it is called lobbying over there, loosely regulated and even encouraged), bribe/speed money/baksheesh is a way of life. Right now, we have anti-corruption wings of the state police and national investigation agency successfully nailing down a handful of perps by using marked banknotes and tracking electronic transactions through banks to a good degree. Most of it is let slide, but when they want, they get their man. Imagine what will happen with bitcoins - corruption will rocket through the sky, bundled with all the problems mentioned above, and will make life worse than it is.

##### [Guide] Python-Trezor on cold offline Raspberry Pi

I am happy to report that the python-trezor command line scripts work successfully on a Piper which is really a Raspberry Pi running Debian wheezy.
This does require you to connect your Piper online initially, so I recommend buying a new 4GB SD card and flashing the piper firmware if you have already used piper to generate cold offline keys. You'll need this for the hexagonal screws and this for the wiring
You can download the latest firmware ISO here and here is how you burn the image
From there I did sudo apt-get update and installed the Trezor dependencies including cython, libusb, python-trezor, cython-hidapi, trezor-common and ran sudo python setup.py build/install as per these 2 guides edit : and pip install trezor as per stickac (I have not yet tried the electrum 2 beta parts of the guides, as I don't require cold offline electrum 2)
https://bitcointalk.org/index.php?topic=122438.msg9262821#msg9262821
This still does not install the english wordlist which you will need to do manually.
Edit : Adding BIP39 library should also install english.txt
You might also want to download my hidden passphrase/PIN entry python-trezor fork
Lastly I needed to unplug the USB mouse from my keyboard hub, in order to provide Trezor with adequate power.
Confirm that everything is working
./cmdtr.py list
./helloworld.py
Pull out the Ethernet cable, and never plug it back in (without first wiping the SD card)
Congratulations you can now initialize and restore Trezor - in a fully cold offline environment - and if you wish, provide your own entropy
Expert tips :
semi-securely delete files off SD flash
Version 2 :
I have added support for the latest electrum 2.0 beta, trezor support and btchip support
Update to the newest github versions
navigate to /python-trezor and git pull navigate to /python-mnemonic and git pull
Update libraries
sudo apt-get update sudo apt-get upgrade sudo apt-get install -f
Install dependencies
sudo apt-get install python-qt4 python-dev pyqt-dev-tools python-pip sudo apt-get install python-usb libusb-dev sudo pip install --upgrade pyusb
Install btchip support
mkdir btchip cd btchip get https://hardwarewallet.com/zip/add_btchip_driver.sh sudo bash add_btchip_driver.sh git clone https://github.com/btchip/btchip-python cd btchip-python sudo python setup.py install
Tests
cd samples python getFirmwareVersion.py cd ../btchip python btchipPersoWizard.py
btchipPersoWizard.py should bring up a GUI setup wizard if core.usb is setup properly
cd ../.. git clone https://github.com/btchip/btchip-c-api.git cd btchip-c-api mkdir bin make cd bin ./btchip_getFirmwareVersion
Install electrum 2.0 Beta
git clone https://github.com/spesmilo/electrum cd electrum sudo python setup.py install pyrcc4 icons.qrc -o gui/qt/icons_rc.py python setup.py sdist --format=zip,gztar electrum
File > New > Hardware wallet. Both Trezor and btchip work as they do on OSX, apart from the Pi's slow CPU taking ages to generate the HD tree and Sync.
Limitations
At this stage a Pi is too slow to receive btchip's 2fa OTP confirmation code, with the auto-type saturating the text buffer. I'm confident Nicholas can fix this in firmware. Edit: an ipad2 + Apple CCK is too slow to buffer the seed about 1/4 times. Edit 2: an iPhone5/retina iPad mini + Lighning to USB camera cable works with btchip with iOS 8.1 with selected text editors.
You can use btchipPersoWizard.py to restore a BIP39 mnemonic, however btchip's HW1 is unable to support on-device BIP39 seed+passphrase, but this feature might be added to the electrum plugin later.
I don't know if greenaddress CRX will work on piper, there doesn't seem to be an official armhf build available from google, and the latest sudo apt-get install chromium version is v22 whereas Chrome is at v38. (it might be possible to download https://github.com/greenaddress/WalletCrx and pack/drag-drop the extension manually in developer mode)

##### Is it possible to "transfer" a bitcoin-qt wallet to an online wallet?

First off, a big hello to everyone, it is my first time posting here or anywhere for that matter.
Now, about a year ago I installed a bitcoin-qt wallet to recieve some coins.Everything sync'd up, I got my coins, spent some and left the rest in the wallet. Today I updated the bitcoin-qt to version 10.2 and after starting it up I am about a year and 10 weeks behind on syncing up. The problem is it is going very slowly. At first it was barely syncing then it accelerated to about a weeks worth of transactions every 15 minutes and then slowed down to a crawl again.At its fastest it would take me 18 hours of non-stop syncing to catch up and that is assuming it doesn't slow down again. It could be that my laptop is too old (9y), or that my connection is acting up even though i can surf without a problem. Whatever the case I would rather not leave my laptop running all night less something overheats, so my question is:
Is it possible to export the wallet.dat or private keys or whatever part of bitcoin-qt needs exporting and import it to an online wallet like electrum and if it is how do I do it?

##### Help recovering missing coins old BTC client didn't send.

Situation: I was cleaning out an old HDD and came across a folder that had Bitcoin-qt 0.8.5 installed. For shits and giggles I fired it up, let it sync to the blockchain and much to my surprise there was just under 3BTC in it. This wallet is from a few years ago when coins were in the \$25 range.
Anyhow, I didn't think anything of it other than, "Score!" Got an address for a web wallet, sent over the balance, carried on with my day feeling rather pleased with myself. Easy enough, right?
I noticed an hour or so later I had zero confirmations, even with a 0.00015 fee. I decided to wait, figuring it was just being slow. Holidays or something. Now, four days later the transaction isn't showing on blockchain.info, there is still no coin in the web wallet and the coin is still gone from my wallet. I've spent the last few hours trying to figure this out because hey, this time of year those few coins is a nice little find. I've had no luck with google. I have whatever info bitcoin-qt 0.8.5 will provide but that is it. Those three surprise coins seem to be lost in the vast seas of 1s and 0s.
Does anyone have any suggestions? My wallet is the only thing that seems to know this transaction took place and at this point I'm going in circles. Hopefully I'm just missing something simple.

##### dogecoin-qt Ubuntu 14.04 Sync slows to a halt until wallet restarted.

Hi,
I have a problem with the QT wallett on Ubuntu.
If you let the wallett just try and sync on its own eventualy it slows down to the point it just stops.
The connections will continue to go up but this just seems to make it worse until eventualy it just stops, and the client has to be exited and restarted at which point the moment it starts new connecions it syncs at normal speed for a while until eventualty it happens again.
Litecoin and Bitcoin behave the same on the same machine. I have completely rebuilt the machine again from scratch and the problem still occurs. I have used the precompiled binaries, and the problem still occurs.

##### Bitcoin Core 0.13.1 released | Wladimir J. van der Laan | Oct 27 2016

Wladimir J. van der Laan on Oct 27 2016:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.13.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.13.1/
Or through bittorrent:
This is a new minor version release, including activation parameters for the
segwit softfork, various bugfixes and performance improvements, as well as
updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
https://bitcoincore.org/en/list/announcements/join/
Compatibility
Microsoft ended support for Windows XP on April 8th, 2014,
an OS initially released in 2001. This means that not even critical security
wallet on a XP machine is irresponsible at least.
In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is not clear
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.
We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.
No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.
• From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+,
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.
Notable changes
Segregated witness soft fork
Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:
• Elimination of unwanted transaction malleability: Segregating the witness
allows both existing and upgraded software to calculate the transaction
identifier (txid) of transactions without referencing the witness, which can
sometimes be changed by third-parties (such as miners) or by co-signers in a
multisig spend. This solves all known cases of unwanted transaction
malleability, which is a problem that makes programming Bitcoin wallet
software more difficult and which seriously complicates the design of smart
contracts for Bitcoin.
• Capacity increase: Segwit transactions contain new fields that are not
part of the data currently used to calculate the size of a block, which
allows a block containing segwit transactions to hold more data than allowed
by the current maximum block size. Estimates based on the transactions
currently found in blocks indicate that if all wallets switch to using
segwit, the network will be able to support about 70% more transactions. The
network will also be able to support more of the advanced-style payments
(such as multisig) than it can support now because of the different weighting
given to different parts of a transaction after segwit activates (see the
following section for details).
• Weighting data based on how it affects node performance: Some parts of
each Bitcoin block need to be stored by nodes in order to validate future
blocks; other parts of a block can be immediately forgotten (pruned) or used
only for helping other nodes sync their copy of the block chain. One large
part of the immediately prunable data are transaction signatures (witnesses),
and segwit makes it possible to give a different "weight" to segregated
witnesses to correspond with the lower demands they place on node resources.
Specifically, each byte of a segregated witness is given a weight of 1, each
other byte in a block is given a weight of 4, and the maximum allowed weight
of a block is 4 million. Weighting the data this way better aligns the most
profitable strategy for creating blocks with the long-term costs of block
validation.
• Signature covers value: A simple improvement in the way signatures are
generated in segwit simplifies the design of secure signature generators
(such as hardware wallets), reduces the amount of data the signature
more quickly. This is made possible by having the generator sign the amount
of bitcoins they think they are spending, and by having full nodes refuse to
accept those signatures unless the amount of bitcoins being spent is exactly
the same as was signed. For non-segwit transactions, wallets instead had to
they made, which could be a slow operation on hardware wallets and in other
situations where bandwidth or computation speed was constrained.
• Linear scaling of sighash operations: In 2015 a block was produced that
required about 25 seconds to validate on modern hardware because of the way
transaction signature hashes are performed. Other similar blocks, or blocks
that could take even longer to validate, can still be produced today. The
problem that caused this can't be fixed in a soft fork without unwanted
side-effects, but transactions that opt-in to using segwit will now use a
different signature method that doesn't suffer from this problem and doesn't
have any unwanted side-effects.
bits of security---which is beyond what cryptographers believe can be broken
today. But because P2SH is more flexible, only about 80 bits of security is
provided per address. Although 80 bits is very strong security, it is within
the realm of possibility that it can be broken by a powerful adversary.
which provides about 128 bits of security (that is 281 trillion times as
much security as 80 bits and is equivalent to the maximum bits of security
believed to be provided by Bitcoin's choice of parameters for its Elliptic
Curve Digital Security Algorithm [ECDSA].)
• More efficient almost-full-node security Satoshi Nakamoto's original
Bitcoin paper describes a method for allowing newly-started full nodes to
protected by large amounts of proof of work. Unfortunately, Nakamoto's
method can't guarantee that a newly-started node using this method will
produce an accurate copy of Bitcoin's current ledger (called the UTXO set),
making the node vulnerable to falling out of consensus with other nodes.
Although the problems with Nakamoto's method can't be fixed in a soft fork,
Segwit accomplishes something similar to his original proposal: it makes it
(specifically, the segregated witnesses) while still ensuring that the node
can build an accurate copy of the UTXO set for the block chain with the most
proof of work. Segwit enables this capability at the consensus layer, but
note that Bitcoin Core does not provide an option to use this capability as
of this 0.13.1 release.
• Script versioning: Segwit makes it easy for future soft forks to allow
Bitcoin users to individually opt-in to almost any change in the Bitcoin
Script language when those users receive new transactions. Features
currently being researched by Bitcoin Core contributors that may use this
capability include support for Schnorr signatures, which can improve the
privacy and efficiency of multisig transactions (or transactions with
multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can
improve the privacy and efficiency of scripts with two or more conditions.
Other Bitcoin community members are studying several other improvements
that can be made using script versioning.
Activation for the segwit soft fork is being managed using BIP9
versionbits. Segwit's version bit is bit 1, and nodes will begin
tracking which blocks signal support for segwit at the beginning of the
first retarget period after segwit's start date of 15 November 2016. If
95% of blocks within a 2,016-block retarget period (about two weeks)
signal support for segwit, the soft fork will be locked in. After
another 2,016 blocks, segwit will activate.
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Octobe013265.html

##### Raspberry Pi Node woes- moving blockchains copies between Windows and Linux

My Pi 2 was being slow to sync. So I plugged its USB drive into a Windows 8 laptop and ran bitcoin-qt for a few days until everything was synced. I tried to plug the USB drive back in the Raspberry Pi, but the bitcoin-qt won't recognize the data, even though I can see it browsing the RPI. I tried all sorts of -rescan and -detachdb commands on both units, but no dice. The Pi is resyncing the blockchain, but adding to the USB drive instead of replacing the files.
• Any way I can force bitcoin-qt to rescan the drive or do anything to recognize the already existent blocks when running on the Pi? The Pi can browse what appears to be a complete blockchain through its file explorer.
• If I can't save the old blocks, which files at least can I delete? The files are at 50 GB already and will push at least another 30 GB downloading the rest of the second blockchain. However, looking at the file structure it's not clear which blocks are new or no longer important.