How to Import, Export, Store and Manage Private Keys in

Groestlcoin 6th Anniversary Release


Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.

Other Linux


Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here


ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.





ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).





ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).




Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.


Remastered Improvements



ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.



Linux :
 pip3 install -r requirements.txt python3 bip39\ 


ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.



Linux / OSX (Instructions)


UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

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:
Aimed-for Setup:
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!)
Go to, select Armory..
It leads to a Download from Git:
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 \ --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
add/change the following line:
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:
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.

--If anyone can offer a solution to this, I'd be very grateful--

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 -
Inside the script, it has the line:
python --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 --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) - Unsupported language specified. Defaulting to English (en) (ERROR) - Failed to start Armory database: cannot concatenate 'str' and 'int' objects Traceback (most recent call last): File "", line 1808, in startArmoryDBIfNecessary TheSDM.spawnDB(str(ARMORY_HOME_DIR), TheBDM.armoryDBDir) File "/BitcoinArmory/", 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
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) - 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 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: ./
(which uses command line:)
python --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
So, this is the command which it reports that it starts with:
(WARNING) - 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..
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,
Broadcast the signed tx.

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"!)
submitted by fartinator to Bitcoin [link] [comments]

Blockchain online training

Blockchain online training

Blockchain originally blockchain, is a growing list of called blocks, which are linked using Each block contains a cryptographic hash of the previous block, and transaction data (generally represented as a Merkle tree root hash).

a blockchain is resistant to modification of the data. It is “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way”. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. for best blockchain training visit follow link

For more information about blockchain visit following site:

blockchain training

For more information about blockchain please contact following mobile number VLR TRAINING 9985269518

#blockchain online training


#Bitcoin & Blockchain


#Blockchain tutorial

#blockchain wallet

For free blockchain class please visit following links :

blockchain demo classes

blockchain classes1

blockchain classes2

Blockchain course content:

Decentralized Money
· Transformation in trading units
· Cryptography and Crypto-currency
· Anonymity and Pseudonymity in cryptocurrencies
· Digital Signatures
· Cryptocurrency Hash codes
· Distributed networks
Exploring Blockchain
· Introduction to Blockchain.
· Why Blockchain is crucial?
· Key vocabulary while discussing Blockchain
· Distinction between databases and blockchain
· Explaining Distributed Ledger
· Blockchain ecosystem
· Blockchain structure
· Working of blockchain technology
· Permission and permission-less blockchain
Bitcoin & Blockchain
· Bitcoin and its History
· Why use Bitcoins?
· Where and how to buy bitcoins
· How to store bitcoins?
· How and where to spend bitcoins?
· Selling bitcoins
· Bitcoin transactions
· How bitcoin transactions work
· What happens in case of invalid transactions
· Parameters that invalidate the transactions
· Scripting language in bitcoin
· Applications of bitcoin script
· Nodes and a network of bitcoin
· Various roles you can play in the Bitcoin Ecosystem
What is Ethereum?
· What is Ether?
· How to use Ethereum?
· The Ethereum ecosystem, DApps, and DAOs
· How Ethereum mining works
· Learning Solidity
· Contract classes, Functions, and conditionals
· Inheritance & abstract contracts
· Libraries
· Types & Optimization
· Global Variables
· Debugging
· Future of Ethereum
Ethereum Private Blockchain and Smart contracts
· Private and public blockchain
· Various blockchain setup platforms
· Using Ethereum to set up private blockchain
· Steps to build a blockchain solution.
· Smart contract on Ethereum
· Compile, deploy and instantiate contracts
· Configuring, running and working with the go-Ethereum client
· Account management and mining
· Understand the different stages of a contract deployment
· How to interact with a contract once deployed?
Solidity basics
· Introduction to Solidity
· Learning Solidity
· Basics (version pragma and comments)
· Structure of a contract
· Keywords
· Data Structures (Arrays, Mapping, Structs)
· Data Types (signed and unsigned int, strings, boolean, address)
· Looping and Conditional Statements
· Inheritance
· Polymorphism
Advance Solidity
· Imports and libraries
· Extended String Functionality and Bytes
· Custom Modifiers and Error Handling
· Creating and deploying your own tokens
· Event logging, handling
· Parameter Mapping and Returning multiple variables
· State Modifiers (Pure/View/Constant/Payable)
· Transferring Ether between contracts (ERC20 and ERC223)
· Deployment
· Contract ABI
· Introduction to the Truffle Framework
· Communicating between smart contracts and HTML pages using web3.js and Metamask
· Setting up event-driven Interfaces
· Client-side signing and remotes nodes for Dapps
Deploying DAPP using Truffle and Web3J
· Creating a project structure on Truffle
· Writing the smart contract
· Compiling and migrating the smart contract
· Publishing the DApp
· How web3.js and truffle work with ReactJS
· Deploying smart contract services on the test blockchain network
· Running the DApp on the Ethereum node using Metamask
submitted by nandhani4321 to u/nandhani4321 [link] [comments]

Homelab collective ressources post!

Hey guys!
I'm fairly new to this sub and to having a home lab in general and I found this community to be so kind and helping, I wanted to give back what I've learned. I'm seeing a lot of questions asked around on improvements and on what to do with x extra hardware so I thought it would be nice to have a thread to regroup that.
I'll put here some stuff I gathered and the most common questions I've seen, feel free to contribute and i'll update the post along.
Latest Additions
Homelab Dashboard
Posts about dashboards have been growing lately and here are some of the best that were kind enough to provide us with their sources.
User Screenshot Source
yours truly
NiknakSi TBA
yourofl10 TBA
mescon & SyNiK4L
Or build yours from scratch: PRTG API, ELK, Grafana, freeboard, JumpSquares
Some other resources: Custom Monitoring Scripts by 0110010001100010
Credits to apt64 for his original post
= Pi specific =
= Download Automation =
= Virtualization =
= Monitoring =
= Media Center =
= Remote access =
= VOIP =
= Networking =
= File Servers/Storage/RAID =
= Cameras =
= Documentation =
= Dynamic DNS =
= Backup =
= Creating network diagrams =
= Guides =
= Misc =
That's all I could come up with on top of my head + some research, passing over to you guys so we can get a nice complete list!
Let's try and stick with free(or mostly) softwares, let me know if you guys feel otherwise.
submitted by Gabisonfire to homelab [link] [comments]

Useful Beginner's Guide to Syscoin

What is Syscoin?

Some have described Syscoin (SYS) as the Shopify, Amazon and Ebay of the blockchain world. Syscoin is a revolutionary cryptocurrency that offers near zero cost financial transactions, incredible speed and provides businesses the infrastructure to trade goods, assets, digital certificates and data securely. Syscoin isn’t just about money and trading, it has the ability to attract various business types thanks to its native set of features geared towards business on the blockchain. From eBay traders and High Street shops to Medical applications, Insurance and Gaming, Syscoin’s decentralized network benefits everyone!   Syscoin is developed by Blockchain Foundry (BF). BF provides blockchain technology based services, projects and products for a wide variety of use cases with the stated aim of disrupting markets by leveraging the potential of blockchain technology. Syscoin is mainly known to be the first cryptocurrency to offer a fully decentralized marketplace based on blockchain. What is lesser known is that this is only a part of what Syscoin offers.   With the introduction of Masternodes in February or March 2018 SYS will be transformed from just a ’marketplace coin’ to a completely ‘utilitarian coin’. The Masternode infrastructure allows the addition of decentralized databases and file storage, increased transaction speed to surpass POS/Visa/Mastercard capabilities, true Turing complete smart contract capabilities for unlimited business logic, sidechains, application layers and an identity layer. This will all be accessible through an API, rather than a new language, enabling nearly any developer to create any blockchain application they can conceive. This will usher in the next generation of blockchain applications - made for new or existing businesses - by conveniently offering everything available from the blockchain space today. In simple terms think Dash + Ethereum/Lisk + Monero + Nano + Storj + Particl capabilities all in one coin!    

SYS Origin

The blockchain as conceptualized by Satoshi Nakamoto back in 2008 envisioned a peer-to-peer electronic cash network that would prevent double-spending. A year later, the blockchain became an integral part of bitcoin, serving as the latter's public ledger of transactions. Although Nakamoto's reference client mentioned a decentralized marketplace service, the subsequent implementation did not incorporate this due to a lack of resources.   Syscoin was initially described in a 2014 draft whitepaper that envisioned Decentralized Marketplace Creation, Decentralized Smart Contracts and Documents, Decentralized Certificate Issuance and Transfer, and Decentralized Data Storage and Retrieval, as among the services that it would offer upon its release.   Syscoin aimed to bring Nakamoto's vision of a decentralized marketplace back into the blockchain, among the other commercial-grade services it aims to deliver to clients. Other services that Syscoin plans to provide include secure data storage and transfer, and unique user aliases that link their owners to the services controlled by the alias.   The early Syscoin wallet was superseded by the release of Blockmarket Desktop 1.0 on September 12, 2017, marking the culmination of Syscoin's vision of a fully decentralized marketplace with a desktop GUI based on the blockchain.   The planned release of Blockmarket Web, a fully web-based version, and Blockmarket Professional in 2018 takes that vision one step further, as more advanced seller stores become a reality.    

The Team

The Team that NEVER quits! Before the launch of Syscoin (Q3 2014), there was a presale ICO by Moolah (as a partner), which turned out to be detrimental for Syscoin. The project raised around 1,000BTC for development but the Syscoin Team only managed to access 250BTC which were used for price support. Moolah (Ryan Kennedy) absconded with the bulk of the ICO funds and the Syscoin team were left with ~30million Syscoin at a price around 400 satoshi. Even after this tragic event, the devs didn’t quit and continued to work on the project without stopping. The case against Moolah is still on-going. See the article from CoinDesk here:   What is this detail telling us about the dev team? While some crypto projects are just scams and bring little to no innovation, they’ve proven that they are in it for the long term - ably demonstrated by the fact that they continued to work despite their funds being stolen. And now that hard work is beginning to pay off with the entire team going full-time for the first time in January 2018 and new developers being hired following VC funding for BF.
View Team Page.    

Blockchain Foundry Products

BF Products    

What is Blockmarket Desktop?

Building on the World's First Decentralized Marketplace, Blockmarket is the newest generation of Syscoin's Desktop wallet with a complete, state-of-the-art marketplace built-in where you can securely and reliably buy and sell any items you wish. Entire stores can be created directly through the marketplace where you can sell your own products or re-sell others’ products for commission. Use of blockchain technology eliminates middlemen, credit card fees, maintenance fees, downtime and political interference. Persons are literally able to buy or sell anything to anyone, anytime, anywhere on Earth! Blockmarket Desktop was launched on September 12, 2017. Download Blockmarket Desktop 1.2    

Key Blockmarket Features

- Decentralized Marketplace

The marketplace platform provides a decentralized and high redundant channel for selling goods and services. Features include: • Price Pegging to currencies such as USD, EUR, GBP, CAD, CNY and BTC • Bitcoin and Zcash as payment options • Arbitrated Escrow • Encrypted Messaging • KYC/AML Compliance • Images • Unlimited Inventory Items  

- Name Aliases

Wallet addresses for cryptocurrencies generally consist of a unique string of between 27-34 alphanumeric characters. Such an address isn’t easy to memorize. Although the addresses can be added to an address book within the wallet, Syscoin has taken the user's convenience one step further, allowing you to create a unique Alias for your wallet address, such as a name, title, or characters specific to a username. These can be used to send SYS from home, to a mobile wallet, to work, to friends, to common suppliers or to repeat customers easily, without requiring any memorizing, writing it down, copy & pasting or emailing yourself the address.  

- Digital Certificates

Using the cryptography of the blockchain persons can issue, authorize, and exchange digital certificates of any kind. With Syscoin anyone can issue provably-unique certificates with text or ASCII content to one or multiple parties on the Syscoin blockchain. These certificates can be authenticated by anyone via Syscoin’s cryptographic proof of work. This allows for the creation and free exchange of any kind of digital asset such as ownership certificates, warranties, receipts, tickets, certifications, diplomas, software licenses and more.  

- Integrated Exchanges

Integrated Crypto exchanges - Flypme and Changelly will facilitate exchanging 30+ cryptos for SYS, directly within the Blockmarket wallet.  

- Security Audit Verified

Blockmarket was successfully and independently security audited by Digital Boundary Group and was deemed low risk. View Audit Results.    

Blockmarket Desktop – Quickstart Tutorials (16 short vids)

BM Desktop – Quickstart Tutorials    

Blockmarket Web – (The Key to Mass Adoption)

BM web will bring SYS’s existing decentralized marketplace and all its features into a web-based version, enabling ease of use with a simple email and password login (grandma friendly) without any need for downloading a wallet or waiting for sync. Blockmarket web will be launched in Q1 2018.   This launch will be accompanied by a marketing campaign roll-out that seeks to build brand recognition with audiences within the existing crypto ecosystem and more significantly with the broader, global, non-crypto audience. For this reason Ballistic Arts, a full-service marketing agency was retained by BF. BF Engages Marketing Agency    

Primary Target Market + Value Potential

The primary target market for BF’s Syscoin/Blockmarket web flagship is the retail e-commerce industry. This sets up their decentralized marketplace to rival such commercial giants as Amazon ($648B market cap), Alibaba ($453B market cap) and eBay ($43B market cap). According to eMarketer’s Worldwide Retail and Ecommerce Sales report, global retail e-commerce sales for 2017 were $2.3 Trillion. This is expected to reach an estimated $4 Trillion by 2020 reflecting the rapid growth within this sector.   To perform a very simple assessment of the Syscoin/Blockmarket web’s potential let’s assume that a 1% portion of the forecasted $4 trillion market is captured, which represents $40 billion in revenue. Assuming a sales to market cap ratio of 1:1 for simplicity, the circulating supply of 531 million SYS, with a $40 billion market cap yields a price of roughly $75 per coin. However, with masternodes that limit the circulating supply and token utility that extends beyond retail e-commerce, the SYS price could likely reach much higher. Please note that these are just very simple assumptions and projections for this exercise, however the real world driven potential that this project has is clearly evident.    

Key Syscoin Developments

- Z-DAG: Zero Confirmation Transactions with Double Spend Protection (WORLD’S FIRST)

View Developer’s Twitter post View Syscoin’s Twitter post  

- Masternodes

Ability for world-class transactions-per-second performance to scale-out with added nodes (theoretically 100k TPS per 1000 Masternodes, 300k TPS/3k masternodes, etc). In later releases, masternodes will also process smart contracts and facilitate sharded+encrypted offchain file-storage (with onchain anchors), among other touted functionality. They should also result in steadying the price movements - less volatility as holding will be incentivized.  

- Masternode Rewards + Min. Hardware Specs

Masternode Rewards + Min. Hardware Specs Masternode ROI Calculator  

- Smart Contracts

Scalable Ethereum Virtual Machine: Allows Turin complete smart contracts to be executed following the ethereum protocol at a much faster speed and at a fraction of the ethereum gas price.  

- Assets & Token Issuance

With its token issuance service, Syscoin allows anyone to create a custom asset token which can then be sent directly to anyone else on the network. This facilitates a variety of use cases including ICO token issuance, supply chain management, reward points, and loyalty programs.  

- Anonymous Transactions

Anonymous transactions: via mixing/shuffling at user-specified denomination. Afterwards, additional tech will be added in the near future which will further compound the degree of anonymity provided -Add ValueShuffle running on top of the masternode layer and you have the world's most advanced privacy tech in any coin. This brings true money fungibility to Syscoin and the missing link for true economic sovereignty. View Developer’s Twitter post.  

- Instant Send

Transactions can be sent and received instantly. This represents a similar sending capability as Dash, but is a step beyond- A type of backend node locking will allow an instantly received sum to be sent immediately, without delay, and without network risk of double-spend.    

Why Invest in Syscoin?



Merchant Pilot Program    


Development Updates

White Paper

White Paper.pdf Note: It is anticipated that the whitepaper will be updated by the team in the near future due to recent developments    


Roadmap 2017-2018.png    

Blockchain Application Development Architecture

Blockchain Application Development Architecture.png    

Feature List 2017 & 2018

Feature List 2017 & 2018.jpg    

Where to Buy



• Block Market Wallet 1.2 – Windows and Mac. Download from • QT Wallet for Developers: Download from – Syscoin MultiCoin Wallet (only supports send/receive)HolyTransaction – Syscoin Multicoin Web Wallet (desktop & android)    

Need Help or Want to Contribute?

If you need help for an important wallet issue or if you want to know how you can contribute in promoting Syscoin Join the Slack channel where the SYS team and community members are active, helpful and responsive.    

Credit To

Other Sources    

Last Updated

This post was last updated on Feb 10 2018.    


This post was created particularly to aid those who are new to Syscoin. Please note that the content provided within this post is for information purposes only and is not to be construed as investment advice.
submitted by idbrews to SysCoin [link] [comments]

Run a 0.14 Full-Node on RaspberryPi3 Pruned(less than 16GB SD needed)

Happy if this guide helps you.
Tip if you want: 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
UPDATE 04/06/17
Add 'uacomment=UASF-SegWit-BIP148' into your bitcoin.conf if you want to signal UASF.
UPDATE 03/13/17
ADDED a tl;dr; Version at the end of this Post.
UPDATE 03/12/17:
Just to test it - I reinstalled all on 8GB SD and it works as well. But maybe you should use at least 16GB for the beginning.
Using a 128GB card for the first version was a little bit stupid - so I reinstalled everything on a 8GB SD card. Including Linux and a pruned blockchain - and it works.
I used prune=550 and Jessie Lite (headless / command line) - without wallet and gui.
The SD is almost full, but it works so far
I also updated the whole manual a bit to make things more clear. Thank you for all your feedback!
Just started my Bitcoin Node today and wanted to share the way I did it with people who are interested in running their own full node. It took some time to write everything down - hopefully correct so far.
I am sure, many people around bitcoin are way more informed and educated as I am - I am the noob. So I wrote this manual to help users like me - noobs, to get started with a cheap, simple bitcoin node on raspberry pi.
Have fun!
I wanted to get my Raspberry Pi 3 working as a node to support the network. Actually the process of installing and running the node was more or less easy - but for Noobs (like I am) it might be a bit tricky to start the whole thing, because there are different ways.
Did you - like me - think you would need +120GB on the raspi, external USB HDD to be a full node? You won't!
If you have a Raspberry and you know what Bitcoin is, I guess, you are a little bit aware of linux, networks and of course bitcoin - so I won't go into detail too much.
This guide is just a little helper to get a full node running on your raspberry pi. Thanks to the help of the nice people in this sub and of course the documentation by the developers, I got it working - and of course also special thanks to - as I followed their tutorial to start - I went some other ways here and there - so please read carefully.
For the Part 2 I would suggest to have open and read through my manual.
I split the tutorial in 2 Parts - PART ONE is about installing the client on your PC and downloading the Blockchain.
PART TWO is about the setup of the raspberryPi and transferring the pruned blockchain to the pi and run it as a full node!
The first thing to be aware of is: You actually need to download the whole blockchain to get this working - if you already have your bitcoin client synced on the PC / MAC great you can reuse it!
Now you might think "but you said less than 16GB in the title!"
Yes, but the good thing is you won't need to download it on your Raspberry, neither you need to sync it completely on your raspberry which took ages (weeks!) before. When you finished this Guide, you will just have a max. 4GB Blockchain on your Raspberry Pi - but it still is a full node! The magic word is Pruning.
Maybe even a 8GB SD Card works just fine including Linux (jessie lite)!
So, if you already have a full node on your PC - Great you can almost skip PART ONE - BUT have at how to Prune in PART ONE if you don't know about it.
For PART TWO you'll need a Raspberry Pi 2 or 3 (I used 3) min. 8GB (works also) or better 16GB SD Card. (I used a 128GB for the first version of this manual - which is way too big)


This is the manual how to get started on you PC / MAC / Linux (I did it on Win7)
Go to: and download the core Client for your Machine (I used win64).
Install it and configure it to save the Blockchaindata to the directory of your choice - so instead getting 120GB on your C drive, I would suggest to download it to another place like a USB drive.
You can set this up during the install. Standard folder for the blockchain folder is "%APPDATA%\Bitcoin" on Windows.
or you can do it after the install by creating a bitcoin.conf file inside your installation folder / or %APPDATA%\Bitcoin and add
to the file. Line by line.
By the way here you could also just add dbcache - to use more memory to speed up the process a bit:
if you don't want to use the settings inside the program. (you can also set this inside the program under settings! If you have this inside the bitcoin.conf you will see the amount you set there from inside the program - it overrides the values)
You can check inside the windows client under settings, if you can see a manual dbcache is set by having a look at the left footer area. When your dbcache value shows up, everything is fine.
So the Blockchain download process will take time - maybe a few days! Depending on your machine, internet connection and HDD.
The Blockchain is huge as it contains every single transaction of the past until today. You won't need to keep your PC running all the time, you can turn it off and on and it will resync automatically when you start bitcoin-qt.exe!
Make sure to close the client always via "quit" - ctrl+q.
After you have your bitcoin core installed, the blockchain downloaded and synced - you are ready to PRUNE!
First - close the Client and let it close smoothly. After it is really closed you can follow these steps:
By pruning, your blockchain will dramatically shrink. From 120GB to just a few GB.
Be aware, that you will lose your Downloaded Blockchain as pruning will erase a big chunk of it! If you have enough space, you could of course keep the full blockchain saved somewhere on another HDD.
You can prune by editing your bitcoin.conf file by adding:
I used prune=1024 - not sure where the differences are right now (min. prune=550). (for my 8GB version I used 550! I suggest to use this.)
Save the bitcoind.conf file and restart your windows client.
It will now clean up the Blockchain. So just the latest blocks are saved. The client should start without any problems. Maybe it takes some time to prune the blockchain data.
Check if everything works normally (the client opens as usual, you can see an empty wallet) than close the client.
Inside the Bitcoin Folder, you'll find two folders called:
blocks chainstate
those are the interesting folders containing the important data (now pruned) - and we will transfer those two to the raspberry later!
Now you are good to start the raspi transfer explained in the next part.


Here is what I did:
1) I installed Raspian Pixel ( using a 128 GB SD - which is not needed because of "Pruning" - I think a 16GB card might work, too! (You can also install Raspian Jessie Lite - which saves you even more space, as it runs headless - only command line) (Updated: It is better to use Jessie Lite to save a lot of space - when you are fine with only command line)
2) I followed partly this tutorial to get everything running and setup:
Please have a look at it - I have copied the Headlines in capitals to let you know what I did, and what I skipped.
Set You RasPi up including "EDITING FILES" to save your Layout at the tutorial page and come back here.
I skipped the CONFIGURE USB AND SET AUTOMOUNT process, as we are going to use PRUNING to reduce the 120GB to a tiny filesize - so USB Devices are not needed here!
It was necessary to ENLARGE SWAP FILE to install bitcoin core - otherwise it didn't went through which ended in a frozen raspi.
So have a close look by following the raspnode tutorial at: ENLARGE SWAP FILE.
I have my raspi running via cable to router - but you can also WiFi setup everything described under NETWORKING ON THE RASPBERRY PI.
Now comes the interesting part: Follow the steps at DOWNLOADING BITCOIN CORE DEPENDENCIES - they work fine for 0.14.0 too. Git should be on Board already when you installed Pixel - otherwise you would need to install it.
sudo apt-get install git -y (only jessy lite)
I skipped the next command lines - as I don't use bitcoin-qt wallet. If you want to use it as wallet - do the step.
mkdir ~/bin cd ~bin
Now you are in the folder you want your bitcoin core data be downloaded to via git. I didn't Downloaded the Berkeley Database source code - so I also skipped the whole next command lines
[email protected]~/bin$ wget [email protected]~/bin$ tar -xzvf db-4.8.30.NC.tar.gz [email protected]~/bin$ cd db-4.8.30.NC/build_unix/ [email protected]~/bin/db-4.8.30.NC/build_unix$ ../dist/configure --enable-cxx [email protected]~/bin/db-4.8.30.NC/build_unix$ make -j4
and went on with "INSTALLING BITCOIN"!
I followed the first part but instead downloading 0.13 I took of course the latest version:0.14
git clone -b 0.14 cd bitcoin ./
this might take some time to start.
If you have trouble with hanging RESOLVING DELTAS - just restart the Raspberry Pi and remove the bitcoin folder inside /~bin using
rm -rf bitcoin
this command will delete the folder and you can reuse
git clone -b 0.14

For some reason RESOLVING DELTAS is a common problem with different downloads - so just retry it and at least after 3 times it should work!

as I didn't use the GUI/ Wallet, I ran
./configure --enable-upnp-default --disable-wallet
as I don't need the wallet functionality.
I didn't need to use "MAKE" which saves you maybe up to 2.5 hours.
instead you can just go ahead with:
sudo make install
(If I am wrong in doing so - please let me know)
The install takes some time - and just a heads up: when it gets stuck somewhere - just redo the installation process - it took three times to went through - stuck at some processing.
After the installation took place you can finally get your Raspberry Pi Node running in no time!
To test if the the installation went through - you can just start bitcoind using:
bitcoind &
than check if everything is working so far:
bitcoin-cli getinfo
after a few seconds you should see version: etc...
if not, something went wrong. Try to redo the steps in the raspnode tutorial.
(don't give up if it failed - retry! Ask your questions here)
IMPORTANT: you need to stop bitcoin on your raspberry now!
bitcoin-cli stop
If you don't need an external USB Drive - what I hope - as we are going to use pruning just go ahead and skip the USB part and create a file inside (or follow the raspnode tutorial on how to setup the USB drive):
cd .bitcoin
sudo nano bitcoin.conf
and enter the exact same pruning size you have used on your Desktop Machine to prune. I used 1024 but the minimum is 550. (used 550 for the 8GB SD card on PC and Raspberry)
That's it for the raspi.
update: To signal UASF enter in a new line:


Now you have to transfer the two folders CHAINSTATE and BLOCKS from your PC bitcoind directory to your raspberry.
I am using a program called "WINSCP" - it is free and easy to use:
We need this to transfer the files to the Raspberry pi. Pretty sure you can also do it via SSH - but I am the noob. So let's keep it simple.
Open Winscp and put in the IP Address of your Raspberry Pi, User and Password (same as in SSH)
You should now see the directories on your Raspberry Pi. There is a folder called
enter it and you will see the two folders
blocks & chainstate
you can delete them on the raspberry as they have some data from your previous test inside.
Make sure you can also see the bitcoin.conf file in that directory, which needs to contain the exact same prune line, like the one on your desktop machine. If not, make sure to edit it via SSH. The line "datadir=l:\yourfolder" is obviously not needed in the Raspberry bitcoin.conf file.
Now grab the two folders CHAINSTATE and BLOCKS from your PC and copy them to your .bitcoind folder.
I also copied banlist.dat, fee_estimation.dat, mempool.dat and peers.dat to the folder - not really knowing if needed! Not needed.
The whole copy process might take some minutes (against some weeks in the old way).
After copying is finished, you can now start bitcoind on the Raspberry.
bitcoind &
the & symbol let you still use the command line while the process is running btw.
The process - if succesfull - will take some time to finish.
bitcoin-cli getinfo
Will give you some informations what is going on right now. When you can see, that it is checking the blocks, this is good!
If you get an error - double check - if you have the correct prune size (same as on desktop machine) - in bitcoin.conf and that this file is inside .bitcoin on RaspberryPi. It took me some time, to find my mistakes.
Congrats! You are almost a part of the network!
To make your node now a fullnode, you will need to go to your router (often and enable portforwarding for your raspberry pi - and open ports 8333 - that's it!
You can now go to:
scroll down to "JOIN THE NETWORK" and check check if your node IP is connected!
It will show up as soon as the blocks are checked and the raspi is running.
Well done!
Now you are running a full node, with a small Blockchain and got it working in Minutes, not weeks!
I really hope, my little tutorial worked for you and your are part of the Node network now.
If you have problems or I made a mistake in this helper tut, just let me know and I will try to make it better.
Have fun and NODL!
the noob
tl;dr; (if you are a real noob start with the non-tl;dr version!)
tl;dr; PART ONE
1) Download & install / setup bitcoincore @
2) change dbcache to something smaller than your memory and download the whole Blockchain (120GB).
3) create a file called bitcoin.conf put the line prune=550 (or higher) in to activate pruning on win inside %appData%/bitcoin
4) Open ports 8333 on your Router to make this a full node with a smaller Blockchain.
You are running a full node on your PC.
tl;dr; PART TWO
1) Install jessie lite and the needed dependencies on your SDCard - Raspberry
( >git clone -b 0.14 )
  • see tutorial for more info.
2) create a file called bitcoin.conf inside .bitcoin and add the same prune=Number you had on your PC.
3) transfer the pruned folders BLOCKS and CHAINSTATE to the Raspberry Folder .bitcoin
4)Start "bitcoind &"
5) let everything sync
6) Make sure you have port 8333 opened on your router.
You are running a full node on your Raspberry with a super small Blockchain (I put all on a 8GB SDcard)
Tip if you want : 19656Uwdwko5RjtnuwQENpjBwE3ChzD59v
updated 03/12 - will update more, soon.
updated 03/12.2 - I updated the whole process a bit and also added some improvements.
updated 03/14/ Added a tl;dr version at the end.
submitted by I-am-the-noob to Bitcoin [link] [comments]

I found two wallet.dat files from june 2011 - please help recovering them

Hey guys, so finally i have been able to rescue my two old harddrives from my parents with two different wallet.dat files on them. Both from june 2011. I can remember i did some experiments with mining, but i think i didnt get i to work with a pool, tryed solo mining but probably never found a block. But the hell its worth a check! Ofcourse i made several backups. They are both windows wallets. Im trying to check them on mac but not sure if im doing it right. So in tried installing Electrum and import the wallets, shows zero balance, but not sure if it works like that. Also i tried installing bitcoin-qt for mac, replacing the newly created wallet.dat with the 2011 one. This is where im at now, sadly i have only 5% of the blockchain database downloaded and will never be able to finish because i dont have enough harddrive space, at the current state this shows also btc balance 0.0 - but i dont realy trust it. I tried to click on "Receiving adresses" on bitcoin qt and checked this adress with blockexplorer, but its also empty, but im also skeptic about this because the given adress is the same for both different wallet.dats.. so maybe its just a new one.
Any bulletproof way of checking their balance on MacOSX? I mean there is a good possibility that there is just nothing on them, but im kind of confused.
Happy to tip someone for helping if i find something
submitted by g4merboy to Bitcoin [link] [comments]

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

How to Upgrade

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.


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

Where can I import my wallet.dat?

I am fairly new to Bitcoin, but one year ago, I made a Bitcoin address on Bitcoin-Qt, but I stopped using it, because the whole database downloading took so much space on my disk.
I have my wallet.dat file, but I don't know, where can I use it. I tried Electrum, but it seems that the wallet.dat import doesn't work there.
Can you recommend me any other wallets, where I can import that file?
Thank you.
submitted by Amic58 to Bitcoin [link] [comments]

Bitcoin Core 0.10.1 Released

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

Upgrading and downgrading

How to Upgrade

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

Downgrade warning

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

Notable changes

This is a minor release and hence there are no notable changes. For the notable changes in 0.10, refer to the release notes for the 0.10.0 release at

0.10.1 Change log

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


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

Bitcoin client comparison? Ease of use, functionality, security etc..

Hey everyone,
I've recently started using bitcoins, and been trying to figure out the best way to store them.. There are a bunch of desktop clients available, each with it's ups and downs, supporting different features, and using different amount of resources..
I wanted to find a nice overview of them all, but so far I'm not finding anything that I wanted to know.. So I think we should have some kind of wiki page, that describes them in more details. Explains how to start using each of them, and how to ensure it's safe.
For example, to try and secure my wallet files, I'm storing them in a TrueCrypt volume, that's archived to the cloud. This way they are backed up to multiple locations, incase my machine dies, and are also encrypted, in case one of the machines is compromised! I'm not sure if that's overkill or not :)
I thought I'd start with a short write-up of my opinions on some of the clients and my impressions of them. It's by no means a comprehensive review (that would take a lot more space than a single reddit post). All of this is just a subjective view on each of the clients.. I hope more people will add to it, maybe even compoling a nice and informative comparison of all the popular clients!
  1. Bitcoin-QT: The official client. Somewhat basic in functionality, advanced functions (like backing up the private key) available through the "debug" window., but works well for a lot of people.. You can backup the wallet.dat file in the TrueCrypt volume to secure the coins, but the client will store the main working copy of the wallet file in %APPDATA% in Windows - leaving it potentially compromised, unless you encrypt the wallet file (part of the client's functionality). There's no obvious way to change the storage location.
    The downside (upside for some?) of the client is that it stores the whole blockchain.. (almost 15GB atm) Initial synchronisation takes a lot of time.. If you don't use it for some time, you'll have to synchronise again, which takes time (and CPU resources btw)..
    At the end of the day, the wallet is as secure as your machine is. No support for paper wallets / watch-only wallets / offline storage, transactions.. But for basic use - it works perfectly fine.
  2. Bitcoin Armory: A popular powerful client, runs "on top" of Bitcoin-QT, which means the blockchain is also stored on the local drive.. On top of that, the Armory client will also build a local database to manage it, which means it needs more storage on it's own.. (at the moment, that's an extra 16GB on top of the blockchain!). Also, the synchronisation status is not very helpful, just saying the % synchronised.. At least Bitcoin-QT states how many weeks/days you are behind, so you can somewhat estimate how soon the sync will work.
    The Armory client supports multiple wallets, compared to the official client, which can be stored separately. The wallets use (correct me if I'm wrong?) a deterministic key to generate the private keys, which means if you backup your wallet in cold storage - you can restore it at any point, and restore all the new addresses generated after the backup - a very useful feature. The Armory client has more advanced functionality like paper backups (described above), offline wallets and offline transactions, and a lot more.. Some features are missing, like importing watch-only addresses. You can though create a watch-only backup of a wallet, and import that on a different machine, but if you only have an address - not supported atm.
    The client seems rather powerful, but also feels a bit clunky and hard to use.. Some functionality is missing, and just strange (not all private key formats are supported.. even if most other clients have no problems with them)
  3. MultiBit: A lite bitcoin client, that doesn't store the whole blockchain locally. This makes it a lot easier to start using, even on a new machine. It will only synchronise a part of the blockchain that is relevant for a specific address, which means you save on both time and storage when using it, but it can be (potentially, but quite unlikely) compromised, if the only nodes it can see are rogue.
    It also supports multiple wallets, you can select where to store the wallet files, and they can be password protected as well. You can store them on a TrueCrypt volume, to secure it even more. The app is still relatively simple to use, while providing more functionality than just the basics.
    Compared to Armory and Bitcoin-QT, you can also create a portable installation, which can be stored on a USB key / True Crypt volume along with the key files.
  4. Electrum: This is one of the clients I've hardly used so far.. It has a full and a portable version! With the portable version I can store they keys where I want, and keep them secure as I see fit. As MultiBit, it doesn't store the full chain, but instead will use a server to keep and manage the blockchain. But nothing is stopping you from running your own electrum server and connecting to it, if you're worried.
    The client seems rather simple, but powerful at the same time. Same as Armory - it will create a seed that will be used to generate addresses. The nice thing is that it will generate multiple receiving addresses, and will also maintain change addresses, which (if I'm right) means that each transaction will not reuse the same address twice, unless you force it to. My only gripe so far with it is that it's the only client so far where you can't send to multiple addresses in one transaction, forcing only a single recipient per transaction.. I hope that'll change in the future :(
submitted by artiomchi to Bitcoin [link] [comments]

HELP! Bitcoin qt client crashed on my computer with a database error! Lost all my bitcoins?!

hey guys,
The bitcoin qt client was catching up with the blockchain (5 days worth), when after maybe 15 minutes, it comes up with an error, "database corrupted" or something along the lines of that. I looked it up and users said to delete everthing in my %appdata/roaming/bitcoin% directy except the wallet.dat file.
So I did that, and downloaded the latest bitcoin qt client, but as it's got 252 weeks to catch up on, it shows 0 btc, is this normal? Will it show my bitcoins whilst it's done updating?
It should show it at the end, right? Once it's seen the transactions on the blockchain? Sorry, I'm just ultra panicky atm from not seeing my bitcoins :S
EDIT: GOT MY BITCOINS. For anyone that has this problem in the future, it's 99.99% likely it's a RAM problem. Took my dodgy ram stick out and used a rescan tag & it was all good to go! You can also import the boostrap.dat file.
submitted by TheNewHero to Bitcoin [link] [comments]

Qtum - Quantum Chain Design Document

Serialization: Qtum Foundation Design Document

In this series of articles, the Qtum Quantum Chain Foundation will make public its early design documents for the first time, hoping to help the community understand the design intent of Qtum and the implementation details of key technologies. The article will be based on the original design draft in order to restore the designer's original ideas. Follow-up Qtum project team will be further collation and interpretation, to help readers understand more technical details, so stay tuned.
The topics that may be included in this series include
* Qtum account abstraction layer AAL
* Qtum distributed autonomous protocol DGP
* Qtum wallet (qt, mobile wallet, etc.) and browser
* Add RPC call
* Mutual interest consensus mechanism MPoS
* Add opcode
* Integration of EVM and Qtum blockchain
* Qtum x86 virtual machine
* Others...
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch.
Qtum original design document summary -- Qtum new OPCODE
As we all know, Qtum uses the same UTXO model as Bitcoin. The original UTXO script was not compatible with the EVM account model, so Qtum added three OP_CREATE, OP_CALL, and OP_SPEND opcodes to the UTXO transaction script for the purpose of providing operational support for conversions between UTXO and EVM account models. The original names of the three opcodes are OP_EXEC(OP_CREATE), OP_EXEC_ASSIGN(OP_CALL) and OP_TXHASH(OP_SPEND), respectively.
The following is an excerpt of representative original documents for interested readers.
OP_CREATE (or OP_EXEC) is used to create a smart contract. The original design files (with Chinese translation) related to this opcode by the Qtum development team are as follows (ps: QTUM <#> or QTUMCORE<#> in the document numbering internal design documents. ):
QTUMCORE-3:Add EVM and OP_CREATE for contract execution Description:After this story, the EVM should be integrated and a very basic contract should be capable of being executed. There will be a new opcode, OP_CREATE (formerly OP_EXEC), which takes 4 arguments, in push order: 1. VM version (currently 1 is EVM) 2. Gas price (not yet used, anything is valid) 3. Gas limit (not yet used, assume very high limit) 4. bytecodeFor now it is OK that this script format be forced and mandatory for OP_CREATE transactions on the blockchain. (ie, only "standard" allowed on the blockchain) When OP_CREATE is encountered, it should execute the EVM and persist the contract to a database (triedb) Note: Make sure to follow policy for external code (commit vanilla unmodified code first, and then change it as needed) Make the EVM test suite functional as well (someone else can setup continuous integration changes for it though) 
The above document describes the functions required by OP_CREATE and the parameters used.


OP_CALL is used for contract execution and is one of the most commonly used opcodes. There are many descriptions in the original design document.
QTUM6: Implement calling environment info in EVM for OP_EXEC_ASSIGN 
Description: Solidity expects certain information to be pushed onto the stack as part of it's ABI. So, when data is sent into the contract using OP_EXEC_ASSIGN we need to make sure to provide this data. This data includes the Solidity "function selector" as well as ensuring the opcodes CALLER and ORIGIN function properly. This looks to be fairly easy, it should just be transferring some data from the Bitcoin stack to the EVM stack, and setting some fields for the origin info. However, this story should be split into multiple tasks and re-evaluated if it isn't easy. See also: For populating the CALLER and ORIGIN value, the following should be done: OP_EXEC_ASSIGN should take 2 extra arguments, SENDER and SENDER_SIGNATURE. Sender should be a public key. Sender Signature is the signature of all the vins for the current transaction, signed of course using the SENDER value.On the EVM side, CALLER's value will be a public key hash, ie, a hash of the SENDER public key. This public key hash should be compatible with Bitcoin's public key hash for it's standard version 1 addresses. IF the given SENDER_SIGNATURE does not match successfully, then the transaction should be considered invalid. If the SENDER public key is 0, then SENDER_SIGNATURE must also be 0, and the given CALLER opcode etc should just return 0.
The above document describes the OP_EXEC_ASSIGN calling environment information that needs to be implemented in the EVM.
QTUM8: Implement OP_EXEC_ASSIGN for sending money to contracts 
Description: A new opcode should be added, OP_EXEC_ASSIGN. This opcode should take these arguments in push order: # version number (VM version to use, currently just 1)

gas price (can be ignored for now)

gas refund script (can be ignored for now)

data (The data to hand to the smart contract. This will include things like the Solidity ABI Function Selector and other data that will later be available using the CALLERDATA EVM opcode) # smart contract address (txid + vout number)

It should return two values right now, 0 and 0. These are for spendable and out of gas, respectively. Making them spendable and dealing with out of gas will be in a future storyFor this story, the EVM contract does not actually need to be executed. This opcode should only be a placeholder so that the accounting system can determine how much money a contract has control of
The above document describes the OP_EXEC_ASSIGN implementation details.
QTUM15: Execute the relevant contract during OP_EXEC_ASSIGN 
Description: After this story is complete, when OP_EXEC_ASSIGN is reached, it should actually execute the contract whose address was given to it, passing the relevant data from the bitcoin script stack with it. Other data such as the caller and sender can be left for a later story. Making the CALLER, ORIGIN etc opcodes work properly will be fixed with a later story
The above document describes OP_EXEC_ASSIGN how the script runs the relevant contract code.
QTUM40: Allow contracts to send money to pubkeyhash addresses Description: We need to allow contracts to send money back to pubkeyhash addresses, so that people can withdraw their coins from contracts when allowed, etc. This should work similar to how version 0 contract sends work. Instead of using an OP_EXEC_ASSIGN vout though, we need to instead use a standard pubkeyhash script. So, upon spending to a pubkeyhash, the following transaction should be placed on the blockchain: vin: [standard contract OP_EXEC_ASSIGN inputs] ... vout: OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG change output - version 0 OP_EXEC_ASSIGN back to spending contract These outputs should be directly spendable in the wallet with no changes to the wallet code itself 
The above document describes how to allow contracts to send QTUM to pubkeyhash addresses.
QTUMCORE-10:Add ability for contracts to call other deployed contracts Description:Contracts should be capable of calling other contracts using a new opcode, OP_CALL. Arguments in push order:version (32 bit integer) gas price (64 bit integer) gas limit (64 bit integer) contract address (160 bits) data (any length) OP_CALL should ways return false for now. OP_CALL only results in contract execution when used in a vout; Similar to OP_CREATE, it uses the special rule to process the script during vout processing (rather than when spent as is normal in Bitcoin). Contract execution should only be triggered when the transaction script is in this standard format and has no extra opcodes. If OP_CALL is created that uses an invalid contract address, then no contract execution should take place. The transaction should still be valid in the blockchain however. If money was sent with OP_CALL, then that money (minus the gas fees) should result in a refund transaction to send the funds back to vin[0]'s vout script. The "sender" exposed to EVM should be the pubkeyhash spent by vin[0]. If the vout spent by vin[0] is not a pubkeyhash, then the sender should be 0.Funds can be sent to the contract using an OP_CALL vout. These funds will be handled by the account abstraciton layer in a different story, to expose this to the EVM. Multiple OP_CALLS can be used in a single transaction. However, before contract execution, the gas price and gas limit of each OP_CALL vout should be checked to ensure that the transaction provides enough transaction fees to cover the gas. Additionally, this should be verified even when the contract is not executed, such as when it is accepted in the mempool. 
The above document describes how the contract calls other contracts via OP_CALL.


OP_SPEND is used for the cost of the contract balance. Because the contract address is a special address, in order to ensure consensus, the UTXO needs to be specially processed. Therefore, there are more descriptions of the OP_SPEND operation code in the original design document.
QTUM20: Create OP_EXEC_SPEND transaction when a contract spends money 
Description: When a CALL opcode or similar to used from an EVM contract to send another contract money, this should be shown on the blockchain as a new transaction. When a money transfer is done in the contract, the miner should add a new transaction exactly after the currently processing transaction in the block. This transaction should spend an input owned by the contract by using EXEC_SPEND in it's redeemScript. For the purposes of this story, assume change is not something to be worried about and consume as many inputs are needed. Properly picking effecient coins and sending back money to the originating contract will come in a later story. Edge cases to watch for: The transaction for sending money to the contract must come directly after the executing transaction. The outputs should use a version-0 OP_EXEC_ASSIGN vout, so that if the transaction were received out of context, it would still mean to not execute the contract.
The above document describes the timing of creating a OP_SPEND transaction.
QTUM21: Create consensus-critical change and coin-picking algorithm for OP_EXEC_SPEND transactions Description: Building on #20, now a consensus-critical algorithm must be made that picks the most optimal outputs belonging to the contract, and spends them, and also makes a change output that returns the "change" from the transaction back to the contract. All outputs in this case should be using a version-0 OP_EXEC_ASSIGN, to avoid running into the limitation that prevents more than one (version 1) OP_EXEC_ASSIGN transaction from being in a single transaction. The transaction should have as many vins as needed, and exactly 2 vouts. The first vout to go to the target contract, and the second vout to send change back to the source contract. 
QTUM22: Disallow more than one EVM execution per transaction
Description: In order to avoid significant edge cases, for now, disallow more than one EVM execution to take place in a single transaction. This includes both deployment and fund assignment vouts. Instead, such things should be split into multiple transactions If two EVM executions are encountered, the transaction should be treated as completely invalid and not suitable for broadcast nor putting into a block
QTUM23: Add "version 0" OP_EXEC_ASSIGN, which does not execute EVM Description: To counteract problems from #22, we should allow OP_EXEC_ASSIGN to be used to fund a contract without the contract actually being executed. This will be used later for "change" outputs to (multiple) contracts. If the version number passed in for OP_EXEC_ASSIGN is 0, then the contract is not executed. Also, this is only valid if the data provided to OP_EXEC_ASSIGN is just a single byte "0". Multiple version-0 OP_EXEC_ASSIGN vouts should be valid in a transaction, or 1 non-version-0 OP_EXEC_ASSIGN (or an OP_EXEC deployment) and multiple version-0 OP_EXEC_ASSIGN vouts. This will be used for all money spending that is sent from a contract to another contract
The above three documents describe that if the consensus-associated coin-picking algorithm guarantees that the OP_SPEND opcode does not cause a consensus error, the correctness of the change is ensured. At the same time, it describes the situation where the contract does not need to be run and how it is handled.
QTUM34: Disallow OP_EXEC and OP_EXEC_ASSIGN from coinbase transactions Description: Because of problems with coinbase maturity and potential side effects from ordering of gas-refund scripts, it should not be legal for coinbase outputs to be anything which results in EVM execution or directly changing EVM account balances. This includes version 0 OP_EXEC_ASSIGN outputs. 
The above document stipulates that coinbase transactions should not include contract-related scripts.

Other related documents

In addition, there are some documents describing the infrastructure needed for the new operation code.
QTUMCORE-51:Formalize the version field for OP_CREATE and OP_CALL Description:In order to sustain future extensions to the protocol, we need to set some rules for how we will later upgrade and add new VMs by changing the "version" argument to OP_CREATE and OP_CALL. We need a definitive VM version format beyond our current "just increment when doing upgrades". This would allow us to more easily plan upgrades and soft-forks. Proposed fields: 
  1. VM Format (can be increased from 0 to extend this format in the future): 2 bits2. Root VM - The actual VM to use, such as EVM, Lua, JVM, etc: 6 bits
  2. VM Version - The version of the Root VM to use (for upgrading the root VM with backwards compatibility) - 8 bits
  3. Flag options - For flags to the VM execution and AAL: 16 bits Total: 32 bits (4 bytes). Size is important since it will be in every EXEC transaction Flag option bits that control contract creation: (only apply to OP_CREATE) • 0 (reserve) Fixed gas schedule - if true, then this contract chooses to opt-out of allowing different gas schedules. Using OP_CALL with a gas schedule other than the one specified in it's creation will result in an immediate exception and result in an out of gas refund condition • 1 (reserve) Enable contract admin interface (reserve only, this will be implemented later. Will allow contracts to control for themselves what VM versions and such they allow, and allows the values to be changed over the lifecycle of the contract) • 2 (reserve) Disallow version 0 funding - If true, this contract is not capable of receiving money through version 0 OP_CALL, other than as required for the account abstraction layer. • bits 3-15 available for future extensions Flag options that control contract calls: (only apply to OP_CALL) • (none yet) Flag options that control both contract calls and creation: • (none yet) These flags will be implemented in a later story Note that the version field now MUST be a 4 byte push. A standard EVM contract would now use the version number (in hex) "01 00 00 00" Consensus behavior: VM Format must be 0 to be valid in a block Root VM can be any value. 1 is EVM, 0 is no-exec. All other values result in no-exec (allowed, but the no execution, for easier soft-forks later) VM Version can be any value (soft-fork compatibility). If a new version is used than 0 (0 is initial release version), then it will execute using version 0 and ignore the value Flag options can be any value (soft-fork compatibility). (inactive flag fields are ignored) Standard mempool behavior: VM Format must be 0Root VM must be 0 or 1VM Version must be 0Flag options - all valid fields can be set. All fields that are not assigned must be set to 0Defaults for EVM: VM Format: 0Root VM: 1VM Version: 0Flags: 0
The above documents formally identified OP_CREATE and OP_CALL needed version information, paving the way for subsequent multi-virtual machine support for Qtum.
QTUMCORE-52:Contract Admin Interface Description:(note, this isn't a goal for mainnet, though it would be a nice feature to include) It should be possible to manage the lifecycle of a contract internally within the contract itself. Such variables and configuration values that might need to be changed over the course of a contract's lifecycle: • Allowable gas schedules 
• Allowable VM versions (ie, if a future VM version breaks this contract, don't allow it to be used, as well as deprecating past VM versions from being used to interact with this contract) • Creation flags (the version flags in OP_CREATE) All of these variables must be able to be controlled within the contract itself, using decentralized code. For instance, in a DAO scenario, it might be something that participants can vote on within the contract, and then the contract triggers the code that changes these parameters. In addition, a contract should be capable of detecting it's own settings throughout it's execution as well as when it is initially created. I propose implementing this interface as a special pre-compiled contract. For a contract ot interact with it, it would call it using the Solidity ABI like any other contract. Proposed ABI for the contract: • bytes[2048] GasSchedule(int n) • int GasScheduleCount() • int AddGasSchedule(bytes[2048] • bytes[32] AllowedVMVersions() • void SetAllowedVMVersions(bytes[32]) Alternative implementations: There could be a specific Solidity function which is called in order to validate that the contract should allow itself to be called in a particular manner: pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; } } In this way a contract is responsible for managing it's own state. The basic way it would work is that when a you use OP_CALL to call a contract, it would first execute these two functions (and their execution would be included in gas costs). If either function returns false, then it immediately triggers an out of gas condition and cancels execution. It's slightly complicated to manage the "ValidateVMVersion" callback however, because we must decide which VM version to use. A bad one could cause this function itself to misbeha`ve.```````
pragma solidity 0.4.0; contract BlockHashTest {function BlockHashTest() { }function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454") { return true; //allow contract to run }return false; //do not allow contract to run}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10) { return true; //allow to run on versions 2-9. Say for example 1 had a vulnerability in it, and 10 broke the contract }return false; }
The above document describes the management interface of the contract, and yes the contract can manage its own status.
QTUMCORE-53:Add opt-out flags to contracts for version 0 sends Description:Some contracts may wish to opt-out of certain features in Qtum that are not present in Ethereum. This way more Ethereum contracts can be ported to Qtum without worrying about new features in the Qtum blockchain Two flag options should be added to the Version field, which only have an effect in OP_CREATE for creating the contract: 2. (1st bit) Disallow "version 0" OP_CALLs to this contract outside of the AAL. (DisallowVersion0)  If this is enabled, then an OP_CALL using "root VM 0" (which causes no execution) is not allowed to be sent to this contract. If money is attempted to be sent to this contract using "version 0" OP_CALL, then it will result in an out of gas exception and the funds should be refunded. Version 0 payments made internally within the Account Abstraction Layer should not be affected by this flag. Along with these new consensus rules, there should also be some standard mempool checks: 
  1. If an OP_CALL tx uses a different gas schedule than the contract creation, and the disallow dynamic gas flag is set, then the transaction should be rejected from the mempool as a non-standard transaction (version 0 payments should not be allowed as standard transactions in the mempool anyway)
The above document describes how to get better EVM compatibility by ignoring certain Qtum specific features in order to port Ethereum contract code. This makes smart contracts in the Ethereum ecosystem more easily compatible with Qtum.


The Qtum original design document presented above describes Qtu's increased opcode associated with the contract run, laying the groundwork for subsequent Qtum's EVM VMs that are compatible with the account model on top of the UTXO model, and also making the account abstraction layer AAL possible. The subsequent Qtum project team will further interpret the key documents. If you have any questions, readers can post comments in the comments area or contact the Qtum project team .
The Qtum quantum chain public number will be updated from time to time around the above topics to restore the history of the Qtum project and key technologies from scratch .
Please note that based on Patrick Dai's translation request, the content in this material is translated to English and published on Reddit.
OP's Qtum Address: QMmYAMEFgvPJGwK9nrwqYw1DHhBkiuEi78
submitted by szhman to Qtum [link] [comments]

Bitcoin Wallet Recovery Install, Backup And Restore A Bitcoin Wallet. Or, Almost Any CryptoCoin Wallet (Windows) Bitcoin-QT wallet review How To Import Private Key into Bitcoin Daimond Wallet  Import Bitcoin Import non spendable bitcoin with private key

A progress or busy indicator would be useful when Bitcoin is performing an operation, even if started via RPC, so users don't shut down Bitcoin-Qt while it is performing some database operation. There is an option that allows you to disable the automatic rescan, if for example you have many keys to import before you wish the rescan to happen. The binary files for Windows, Mac and Ubuntu differs. But Yes, the wallet backup file, database file and other core files such as: wallet.dat, wallet.keys, lmdb (data.mdb, lock.mdb), blk*.dat, .ldb files are compatible across platforms. So you can basically move your wallet to Raspberry Pi or another computer or different operating system without having to download the entire blockchain again. Bitcoin-Qt version 0.7.0 is now available for download at: Core bitcoin handling and blockchain database. Reduced CPU usage, by eliminating some redundant hash calculations; Add 2 labels to the overviewpage that display Wallet and Transaction status (obsolete or current) Extend the optionsdialog (e.g. language selection) and re-work it I had Bitcoin-Qt on my computer with several bitcoins in my wallet, using Vista. Then my computer crashed. Finally I was able to get my computer fixed and download a new version of Bitcoin-Qt. Now I would like to import my original wallet.dat from the old client which was encrypted into an new version of Bitcoin-Qt. How do I do that? Select Import wallet. Choose the File/Text tab at the top. Paste the backup into the text field, then enter the password for this wallet. Press Import Wallet. If you pasted the backup code correctly and entered the correct password your bitcoin wallet will be imported.

[index] [22514] [19479] [937] [25469] [14674] [10169] [19178] [13764] [24892] [18254]

Bitcoin Wallet Recovery

How To Import Private Key into Bitcoin Daimond Wallet. How To Import Private key in core Wallet. In this video you will learn how to import Private key into Bitcoin daimond Core wallets but this ... - Bitcoin wallet & multi crypto wallet! Send, receive, store and track your e-money/stable coins & digital assets. - Trust Wallet’s server-free infrastructure ensures only you can access your e ... download PASSWORD: bitcoin..... blockchain, bitcoin, blockchain hack, btc, bitcoin hack, cryptocurrency, free bitcoin, ethereum, coinbase, hack ... Here is a tutorial how to import your old bitcoin wallet into a new wallet in easy steps. I was able to import 1.7 old forgotten bitcoin from 2013. Bitcoin How to import your old wallet into new one tutorial works 100% Recovered 1.7 BTC - Duration: ... How To Backup and Restore Your DogeCoin Wallet Safely and Securely (Or any QT Client ...

Flag Counter