Any human way to compile qt wallet for win64? · Issue #640

Groestlcoin 6th Anniversary Release

Introduction

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?

Windows
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.
OSX
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.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

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

Source

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.

Features

Download

iOS
Android

Source

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.

Features

Download

Main Release (Main Net)
Testnet Release

Source

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.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

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

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

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

Features

Download

Source

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.

Features

Remastered Improvements

Download

Source

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.

Features

Download

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

Source

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.

Features

Download

Windows
Linux / OSX (Instructions)

Source

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.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

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.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Reddcoin on Raspberry Pi

A lot of user asked lately, how to run Reddcoin on the popular Raspberry Pi platform. Raspberry Pi is a cheap ARM computer (using junk leftover chips with 10 year lag in technology) but it has enough RAM and consumes around 5 watts, so its ideal to use it for Reddcoin Staking.
This tutorial is not from me, i take NO RESPONSIBILITY about these binaries or the accuracy. This tutorial is created by cryptoBUZE, a fellow member of the Reddcoin community.
Before attempting to follow this tutorial, do a sudo apt-get update
The following commands must be run to install dependencies:
sudo apt-get install libboost-thread-dev
sudo apt-get install libboost-program-options-dev
sudo apt-get install libboost-filesystem-dev
sudo apt-get install libboost-system-dev
Download and install older libssl version - bitcoin clones are using this glorious and fantastic communist product of openssl so it naturally does not works. Its getting totally incompatible after each relase even with itself. Therefore, you must install this, which is the compatible one with the wallet software (no, you cant even compile the code with the newer one) :
wget http://apt.screenlyapp.com/raspbian/pool/main/o/openssl/libssl1.0.0_1.0.1t-1%2Bdeb8u6_armhf.deb
wget http://apt.screenlyapp.com/raspbian/pool/main/o/openssl/libssl-dev_1.0.1t-1%2Bdeb8u6_armhf.deb
sudo dpkg -i libssl1.0.0_1.0.1t-1+deb8u6_armhf.deb
sudo dpkg -i libssl-dev_1.0.1t-1+deb8u6_armhf.deb
Download the wallet software itself:
wget https://github.com/cryptoBUZE/reddcoin/releases/download/raspberrypi/reddcoind
wget https://github.com/cryptoBUZE/reddcoin/releases/download/raspberrypi/reddcoin-cli
wget https://github.com/cryptoBUZE/reddcoin/releases/download/raspberrypi/reddcoin-qt
chmod +x reddcoin\*
When speaking about compatibility, ARM is similar to x86 if you are running user mode applications. You know that every arm based chip needs a different kernel due to the lack of an unified IO system thankfully for the glorious clueless egoistic communist developers at ARM, who succesfully bankrupted the corporation after 25 or so years, and the company got acquired by the japanese softbank. But in user mode, its sort of backward compatible if you have all the proper libraries installed. This means that this will run on any other newer ARM based machine as well (not just raspberry pi-s, on every other arm stuff, chromebooks, or android phones hacked to work with linux).
submitted by GeriGeriGeri to reddCoin [link] [comments]

Discord Log from Ravencoin Open Developer Meeting - Oct 5, 2018

joey at 1:57 PM

What kind of transaction types are possible with RVN assets? Is it possible to create an asset that has a set lifetime or self-destruct time?

Tron at 2:00 PM

Not for assets/sub-assets/unique. We might be able to do that with voting tokens.

RavencoinDev at 2:01 PM

Hello Everybody!📷1

SpyderDev at 2:01 PM

Hi boss📷1

[Dev] Blondfrogs at 2:01 PM

SUP📷1

Chatturga at 2:01 PM

^📷1

BruceFenton at 2:01 PM

Probably lots of ways to do a self destruct on second layer as well if desired

russ at 2:01 PM

suuuuuupso what is todays topic?

RavencoinDev at 2:02 PM

Thanks for joining us today. We would like to discuss the current status of the 2.1 release.As well as doing an open Q&A at the end.First though I want to thank everybody that helped get the word out on upgrading to the 2.0.4.1 release!Without that fix being in place and exchanges and pools upgrading we would be having a different conversation today.This community is amazing.

russ at 2:04 PM

we would have ended up like pigeoncoinnot a good look📷2

watsure at 2:05 PM

Hello Mr. God

RavencoinDev at 2:05 PM

Exactly

russ at 2:05 PM

i gave pigeoncoin the pullrequest but they ignored meglad we have competent devs

[Dev] Blondfrogs at 2:05 PM

Everyone, So we are planning on getting out build 2.1 as soon as possible. We are still doing bug fixes, and getting the code hardened for release. There is currently one bug is the asset layer that we are fixing right now, and once that is done we should have a couple days of testing. It would be lovely if the community helped with testing, and we appreciate all of the testing that the community has already done. Once, we have a basic build that is tested, we are going to make a public release and notify the miners and pools.

RavencoinDev at 2:06 PM

Once that bug is addressed a release branch will be created.

russ at 2:06 PM

that duplicate ownership asset bug is nasty

RavencoinDev at 2:06 PM

You should all be able to build that and jump on testnet.

[Dev] Blondfrogs at 2:07 PM

@russ Yeah, didn't see that one. BUt I have a fix right now that seems to be working on my local machine

RavencoinDev at 2:07 PM

We need as much testing help from our devs as possible.

[Dev] Blondfrogs at 2:07 PM

so, I will have that pushed up with the day.

russ at 2:07 PM

nice

[Dev] Blondfrogs at 2:08 PM

Just a reminder, that when the new wallet is published, if you don't update your wallet by the time assets are voting in by the blocks you will fork. So, we are going to try and get the wallet out there as soon as we can so users have weeks to upgrade.

Skan at 2:09 PM

Hey everyone

RavencoinDev at 2:10 PM

Any questions comments about the 2.1 release?

Skan at 2:10 PM

Mojave support?

SpyderDev at 2:10 PM

Yes and no

RavencoinDev at 2:10 PM

Good question SkanRight now that's also an issue with Bitcoin.

SpyderDev at 2:12 PM

The short version for Mojave is that the released binaries will work fine.

Skan at 2:12 PM

Interesting, so is it likely going to be a future upgrade that brings stability?

SpyderDev at 2:12 PM

However, developers should hold off.

RavencoinDev at 2:12 PM

We are currently building on High Sierra

Skan at 2:12 PM

Ok good to know for those who ask

SpyderDev at 2:13 PM

There is an incompatibility with Berkeley db version 4 that causes a segfault on init.

RavencoinDev at 2:13 PM

Or using the build scripts that Under created to build on Linux. Thjanks @Under

[Master] Roshii at 2:13 PM

Looks I'm late to the event

[Dev] Blondfrogs at 2:13 PM

THE MASTER!

RavencoinDev at 2:13 PM

Sorry it's late for you @[Master] Roshii

Skan at 2:14 PM

master roshi is never late, he is simply the turtle hermit

SpyderDev at 2:14 PM

One can upgrade Berkeley-db to the latest version and compile with the --incompatible-bdb and things will run, but there are some unknowns as far as wallet compatibility is concerned.

RavencoinDev at 2:15 PM

Raven will likely follow Bitcoin on Mojave support.

SpyderDev at 2:15 PM

The release binaries are compiled on Linux which we have tested on Mojave, so as long as you aren't compiling binaries go ahead and update to Mojave

RavencoinDev at 2:15 PM

It's a problem they have to solve as well, so...

SpyderDev at 2:15 PM

There is supposed to be a patch to bdb, but so far it isn't working

[Master] Roshii at 2:15 PM

@RavencoinDev it's never late for me.

Skan at 2:15 PM

Ok, and for the devs interested just point them to the berkeley upgrade with some warnings or to Under's scripts?

RavencoinDev at 2:16 PM

Right, the wallet runs just fine on Mojave. It's just a developer issue.

[Master] Roshii at 2:16 PM

If I can say anything it will be : don't update to Mojave

SpyderDev at 2:16 PM

There is a warning note in the docs section for OSX building

RavencoinDev at 2:16 PM

Mojave slowed down @[Master] Roshii and the iOS wallet.

Skan at 2:16 PM

YikesOk good to know, just want to be able to help / point people in the right direction

RavencoinDev at 2:17 PM

Thanks @Skan

SpyderDev at 2:17 PM

There is also an issue with Mojave dark mode and the QT wallet that makes things difficult to read (white on white text). We have a workaround which is to disable dark mode for QT in the plist file.

Skan at 2:17 PM

Ok so this is going to be pretty soon then, right ? Next week, likely?

RavencoinDev at 2:18 PM

Any further Mojave questions?Which @Skan ?

Skan at 2:18 PM

I think that covers it for me2.1 releaseIn order to have weeks to upgrade before main net

RavencoinDev at 2:18 PM

Yes, it is looking like we can work through this last issue with asset re-org very soon.Likely early next week.

Skan at 2:20 PM

Is 2.1 going to have any UI updates ?

RavencoinDev at 2:20 PM

Yes, frogs has more details.

[Dev] Blondfrogs at 2:20 PM

The UI is done. It is currently in the develop2. So if you have built the develop2 branch, you would be looking at the new UI for now.

RavencoinDev at 2:21 PM

There have been other QT designs kicked around and we would love to see more from the community.

[Dev] Blondfrogs at 2:21 PM

Future upgrades to come though. but those won't be mandatory upgrades. Just visual upgrades.

SpyderDev at 2:21 PM

The UI tweaks are subtle, but they make a big difference.

Skan at 2:22 PM

Very cool, I will check out dev2 branch

russ at 2:22 PM

new asset creation UI is awesome

Skan at 2:22 PM

I saw that, I like it. And the longer asset holdings list

RavencoinDev at 2:22 PM

@russ Don't make @[Dev] Blondfrogs head any larger...

russ at 2:23 PM

lol

RavencoinDev at 2:23 PM

Other 2.1 release questions/comments?

Skan at 2:23 PM

Cant think of anything else at the momentThanks!

Hans_Schmidt at 2:23 PM

Is dividend support officially part of 2.1 release? It wasn't intuitive to me how that works.

RavencoinDev at 2:24 PM

No it will be in the next release. However, you could write a script that would provide the same functionality with what will be released in 2.1.

Skan at 2:25 PM

I heard something about Phase 4 being complete already, is that true, and is that in 2.1?

RavencoinDev at 2:25 PM

List all addresses with an asset, loop through sending X raven to each.

Skan at 2:25 PM

Unique assets>

RavencoinDev at 2:25 PM

Yes, Unique assets are complete.(edited)

Tron at 2:25 PM

Dividend support can be done without modifying the protocol. We can add it to a version of the software that can be used by the payer, without requiring others to upgrade.So we did phase 1, 2, 4

Skan at 2:26 PM

Oh wowGreat job everyone!

RavencoinDev at 2:26 PM

Yeah, we're super excited about the use cases that assets and unique assets provide to our develoepers(edited)

Skan at 2:27 PM

Can you tell us anything else about this separate software client? Will it be geared more towards enterprise use in general or will it just be that feature?

RavencoinDev at 2:27 PM

Speaking of, do any of you have a dev project in the works with assets?

russ at 2:27 PM

well its not a separate software client, its a backwards compatible release @Skan(edited)kind of like a softfork if you know what that is

Skan at 2:28 PM

Yeah unique assets will be awesome, actually there's a korean community member planning on issuing them along with silver ravencoinsIf im not mistaken

RavencoinDev at 2:28 PM

That's awesome!

russ at 2:28 PM

@RavencoinDev @Scotty is working on an asset explorerhttp://ravencoin.asset-explorer.net/

RavencoinDev at 2:29 PM

Yes, we've been watching that.

Skan at 2:29 PM

I am working with him on a Korean translation of the whitepaper, x16r whitepaper, and an introduction article so that we can take advantage of our availability in that market📷1

RavencoinDev at 2:29 PM

Super excited to see that mature.

Skan at 2:29 PM

@russ ah ok that makes senseWill there be anything else to that release?

RavencoinDev at 2:30 PM

Thanks @Skan. We want Raven to span the globe.Okay, Open Q&A time.What other questions do you guys have?

Skan at 2:31 PM

This release with rewards capability, will there be anything else added/changed for that version?

Tron at 2:31 PM

It might be released as phase 3, 5, 6.Although it could be released separately, without impacting anything.

Skan at 2:32 PM

Ah ok, so all of these features can be opted-into by someone who wants to take advantage, without cluttering the experience for a basic user

Tron at 2:32 PM

Phase 5 and 6 will be together as it requires a hard-fork.

RavencoinDev at 2:33 PM

Yes, we want to focus on user experience so it's super simple to do what you want to do.

Skan at 2:33 PM

Awesome

russ at 2:33 PM

so is anyone working on RSK yet

[Dev] Blondfrogs at 2:34 PM

We aren't yet.

russ at 2:34 PM

yea im gonna have a look at the code soon

[Master] Roshii at 2:34 PM

Who said ravencoin needs RSK

RavencoinDev at 2:34 PM

It'd be great to have that done by the community.

russ at 2:34 PM

i think some people would like smart contracts @[Master] Roshii

Skan at 2:35 PM

RSK would be great for token distributions

russ at 2:35 PM

the real trick would be getting RSK to recognize assets

Tron at 2:35 PM

RSK, Segwit, Lightning are all on the table, but lower priority than phases 3, 5, 6.

[Master] Roshii at 2:35 PM

This is just like saying let's do what ravencoin does in the old fassion!

russ at 2:35 PM

well not really, smart contracts can do other things

[Master] Roshii at 2:36 PM

What's the RBF status @Tron

Skan at 2:36 PM

Keep us posted russ I think that would be amazingWhen you write smart contracts in RSK what language is it in?

russ at 2:36 PM

solidity i thinlthink

RavencoinDev at 2:36 PM

yes

russ at 2:36 PM

eth contracts also work on RSKso thats a plus

Skan at 2:37 PM

Ok great so we dont even have to work on templates or anything

RavencoinDev at 2:37 PM

Having solidity contracts that interact with Raven assets would open up a lot of possibilities.

Skan at 2:37 PM

I think so too, especially for stuff like tokens in gaming use case📷1

russ at 2:37 PM

i guess it would also help with cross chain atomic swaps too

Skan at 2:37 PM

Yep

RavencoinDev at 2:37 PM

Yes!

russ at 2:38 PM

BTC directly for an asset

Skan at 2:38 PM

sounds like a good product

russ at 2:38 PM

making ICOs easier

Tron at 2:38 PM

Yes, cross-chain atomic swaps would be amazing with user issued assets.

RavencoinDev at 2:39 PM

Other questions?

Skan at 2:40 PM

Smart contract atomic swap erc20token 1:1 for their new RVN counterpart

Hans_Schmidt at 2:40 PM

I believe that every cross-chain atomic swap implementation I have seen requires a trusted federation. That's even true for RSK.

Tron at 2:40 PM

@Skan I like it!

Skan at 2:42 PM

No more questions from me

RavencoinDev at 2:42 PM

Okay, seems that we're winding down on the Q&A.Thank you all for joining us today. I've really liked how this discussion has worked out on Discord.Did anybody miss IRC today?

russ at 2:43 PM

hell no

Hans_Schmidt at 2:43 PM

Like a toothache

russ at 2:43 PM

this was waaay better

RavencoinDev at 2:44 PM

📷

Hans_Schmidtat 2:44 PM

Missed the mems tho

RavencoinDevToday at 2:44 PM

I agree. I was even able to fix my typos.That's right, we had some epic memes last time.Where are you @Pathfinder

Chatturga at 2:45 PM

@Pathfinder Do you have an epic meme for us today?

Skan at 2:45 PM

Meme please

[Master] Roshii at 2:46 PM

Can somebody give @Pathfinder a Master Memer role and color

Chatturga at 2:46 PM

https://i.imgflip.com/2jgpgw.jpg📷📷1📷1

Pathfinder at 2:46 PM

heyayeah, that was my meme for today 📷 ty Chatturga

BruceFenton at 2:46 PM

Good stuff

RavencoinDev at 2:47 PM

Thanks everybody!

[Dev] Blondfrogs at 2:47 PM

peace out

Skan at 2:47 PM

Later!

RavencoinDev at 2:47 PM

Have a great weekend. NH Raven Meetup next week!!!!

Jeroz at 2:47 PM

📷

SpyderDev at 2:47 PM

Thanks guys!

RavencoinDev at 2:47 PM

See you there!

Pathfinder at 2:47 PM

I'll be there! looking forward to seeing folks 📷

Hans_Schmidt at 2:47 PM

See ya in NH

Tron at 2:48 PM

See ya there!

Jeroz at 2:48 PM

Cant make it, but have fun! 📷

RavencoinDev at 2:48 PM

^ did you have a question about tron's Comment?

Jeroz at 2:49 PM

No I was super excited about it

RavencoinDev at 2:49 PM

Ah, me too!

russ at 2:49 PM

mtarget is streaming the meetup, right?

RavencoinDev at 2:50 PM

Not sure, we have really appreciated his work in the past but haven't heard.

Chatturga at 2:52 PM

Yes, he is planning on doing a stream📷1

RavencoinDev at 2:53 PM

Thanks again everybody.
submitted by Chatturga to Ravencoin [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 Bitcoin.org, select Armory..
It leads to a Download from Git:
https://github.com/goatpig/BitcoinArmory/releases
Followed the procedure for Linux Debian verify code, compile, install, all straight-forward..
Began by running bitcoind, and telling Armory where to find it. This is the command I used, obviously it was all on one line and didn't include the arrows/explanations!:
python ArmoryQt.py \ --satoshi-datadir=/BlockChain/chain20180414/blocks \ # <-----(where my bitcoind blocks live) --datadir=/ArmoryDataDi \ # <-----(this is instead of ~/.armory) --dbdir=/ArmoryDataDidatabases # <-------(again, non std. place used for Armory's databases.. my choice.) 
So, on the Desktop, after the initial "build databases"
(NB the initial "Build Databases" took about 1.5h and my two CPUs were maxed the whole time, Temps up to 62C. Not ideal; Im not in a rush!)
I then wanted to import a watch-only wallet.
Before I did this, I took a full backup of the Armory data dir:
/ArmoryDataDi
(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:
CONF_SWAPSIZE=400 
Then, REBOOT the Pi:
sudo shutdown -h -P now 
Once the compilation was done on the Pi, put the swap back, rebooted and created an Armory wallet.
I added manual entropy and upped the encryption 'time' from 250ms to 2500ms - since the Pi is slow, but I'll be happy to wait for more iterations in the Key Derivation Function.
Once the wallet was created, it obviously prompts you for backup.
I want to add a private key of my own (i.e. import), so don't do the backup until this is over.
I import my Private Key, and Armory checks that this corresponds to a Public Key, which I check is correct.
This is the point now where the Pi storage medium (e.g an SD card) has to be properly destroyed if you ever get rid of it.
I had thought that now would be a good time to decide if your new wallet will generate Segwit receiving addresses, and also addresses used to receive 'change' after a transaction..
But it seems Armory WON'T let you switch to P2SH-P2WPKH unless your Armory is connected to a node offering "WITNESS" service.
Obviously, my Pi is offline and will never connect to a node, so the following will not work on the Pi:
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 - StartArm.sh)
Inside the script StartArm.sh, it has the line:
python ArmoryQt.py --ram-usage=4 --satoshi-datadir=/BlockChain/chain20180414/blocks --datadir=/ArmoryDataDi --dbdir=/ArmoryDataDidatabases 
I know from bitter experience that doing a scan over the blockchain for a new wallet takes a looong time and a lot of CPU, and I'd like it to play nicely; not gobble all the memory and swap and run my 2xCPUs both at 100% for four hours...
So... I aim to run with --ram-usage=X and --thread-count=X
(For me in the end, X=1 but I began with X=4)
I began with --ram-usage=4 (<--- = 4x128Mb)
The result is below...
TypeError: cannot concatenate 'str' and 'int' objects 
It didn't recognise the ram-usage and carried on, crippling my Debian desktop PC.
This is where it gets dangerous; Armory can gobble so much memory and CPU that the windowing environment can cease up, and it can take over 30 minutes just to exit nicely from bitcoind and ArmoryDB.
So, I ssh to the machine from another computer, and keep an eye on it with the command
"free -h" 
I'd also be able to do a "sudo reboot now" if needed from here.

Section 5

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

Section 6

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

Section 7

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

Is there any way to make an ABC node sync faster? Anything really?

This has been so painful to use that I'm likely killing it altogether. It has been for days on and off and I already had blockchain data from bitcoin core Qt stored up to mid 2017.
Now it is stuck syncing with the network in jan 2016 with an ETA of 11 days.
Anything to make this faster? Do -rescan -reindex do anything useful at all?
EDIT: I'm not a really "upgrade" guy so I never upgrade unless I need to, so I was still using windows 8.0 with a lot of "capped" stuff to improve security and speed. It so happens that one of the problems there was that windows 8.0 was NOT ending properly the client when closing it and I needed to manually kill it (also RAM handling was poorer). After some research I decided to upgrade to windows 10 (still possible to get for free even if you had a windows 8.0 license like mine for when it comes installed in your machine already - send a msg here if you want to know the best procedure).
Windows 10 properly handles ending the process, cleaning up RAM, and calling it back. Also, it seems to consume less resources to run ABC client. Just some hints here: windows 10 now uses PowerShell, not the old command shell, but PowShell does not accept commands such as -rescan -reindex as a default, so if you need to run a batch or start the client (or anything else like compiling c/c++ libraries, etc, etc) call cmd.exe instead, not worth the pain to read power shell documentation to execute pedestrian commands.
submitted by rdar1999 to btc [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 http://imgur.com/a/GhCNH https://github.com/Gabisonfire/dashboard-q
lastditchefrt http://i.imgur.com/5zQdao4.png https://github.com/d4rk22/Network-Status-Page
_SleepingBag_ http://i.imgur.com/Ql9ZM4W.png https://github.com/jsank/homelabdash
NiknakSi https://niknak.org/extras/sysinfo TBA
DainBramaged http://imgur.com/jYNlUEQ https://github.com/gordonturneBigBoard
michaelh4u https://i.imgur.com/XkZwMKj.png https://github.com/michaelh4u/homelabfrontpage
spigotx http://imgur.com/a/1zMht https://github.com/spigotx/HomeLab2
SirMaster https://nicko88.com/ https://github.com/dashbad/plex-server-status
yourofl10 http://imgur.com/a/AyROa TBA
TheBobWiley http://imgur.com/a/oU6d3 https://github.com/TheBobWiley/ManageThis-LandingPages
0110010001100010 http://i.imgur.com/iwtQcsL.jpg https://github.com/danodemano/monitoring-scripts
mescon & SyNiK4L https://i.imgur.com/gqdVM6p.jpg https://github.com/mescon/Muximux
ak_rex http://i.imgur.com/a/RJkrT https://github.com/ak-rex/homelab-dashboard
 
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]

Dogecoin on Linux - The Complete Beginner's Guide

I'm writing this because I couldn't find a single condensed guide on compiling the wallet and running mining software on linux, specficially Ubuntu/Linux Mint. I combed Bitcoin and Litecoin forums for similar problems I was running into and eventually got everything nailed down, so here it is in one place, for new Shibes.
If you want to make a Dogecoin directory in your downloads folder to keep things organized, you will need to modify these commands to refelct the change. So instead of going to ~/Downloads/ you will need to go to ~/Downloads/Dogecoin and be sure to put the zipped files there when you download them, but the commands will be the same otherwise.
cwayne18 put in the work to make a PPA for the QT client here.
Ubunutu/Mint/Debian users should be able to install the client with the following commands:
sudo add-apt-repository ppa:cwayne18/doge sudo apt-get update && sudo apt-get install dogecoin-qt 
To update using this method, run
sudo apt-get update && sudo apt-get upgrade dogecoin-qt 
Compiling the Wallet Manually
I suggest using the PPA above, but if you want to compile manually, here you go.
1)Download the newest source from here. If you want to check out the Github page, click here
2)Unzip the package with the native client OR, navigate to your downloads and unzip
cd ~/Downloads unzip dogecoin-master.zip 
3)Now it's time to compile. You will need to install the dependencies, just copy and paste the following code. It will be a fairly large download and could take some time. It is always important to update before installing any new software, so we'll do that first and then install the dependencies.
sudo apt-get update sudo apt-get upgrade sudo apt-get install libssl-dev libdb-dev libdb++-dev libqrencode-dev qt4-qmake libqtgui4 libqt4-dev sudo apt-get install libminiupnpc-dev libminiupnpc8 libboost-all-dev build-essential git libboost1.53-all-dev 
4)Once that is done, go to the doge-coin master directory and compile:
cd ~/Downloads/dogecoin-maste sed -i 's/-mgw46-mt-sd-1_53//g' dogecoin-qt.pro qmake USE_UPNP=- USE_QRCODE=0 USE_IPV6=0 make -j3 
After running the qmake command you will likely see some text similar to
Project MESSAGE: Building without UPNP support Project MESSAGE: Building with UPNP supportRemoved plural forms as the target language has less forms. If this sounds wrong, possibly the target language is not set or recognized. 
It's perfectly normal, so don't worry about that.
Your Dogewallet is ready to go! The executable is in ~/Downloads/dogecoin-maste and called dogecoin-qt. Your wallet information is in ~/.dogecoin. You can run the wallet at any time by opening terminal and typing
cd ~/Downloads/dogecoin-maste ./dogecoin-qt 
Future upgrades to dogewallet are easy. Back up your wallet.dat, and simply follow the same directions above, but you'll be unzipping and building the newer version. You will likely need to rename the old dogecoin-master directory in ~/Downloads before unzipping the newest version and building. Also, it is likely that you will not need to install the dependencies again.
Alternate Method For Installing Dogecoin Wallet from Nicebreakfast
After installing the dependencies listed in step 3, open terminal, then navigate to where you want Dogecoin Wallet stored and run:
git clone https://github.com/dogecoin/dogecoin ./autogen.sh ./configure make 
then when the wallet is updated just run
git pull 
from the dogecoin directory.
GPU Mining
GPU mining requires CGminer. My suggestion is to get the executable already built. The creator of cgminer has removed the built file from his website, but I've uploaded it here
sudo apt-get install pkg-config opencl-dev libcurl4-openssl-dev autoconf libtool automake m4 ncurses-dev cd ~/Downloads tar -xvf cgminer-3.7.2-x86_64-built.tar.bz2 
Don't use anything newer than 3.7.2. The newer versions of CGMiner don't support GPU mining.
That's it! You have cgminer ready to go! You will run cgminer with the following syntax
cd ~/Downloads/cgminer-3.7.2-x86_64-built/ ./cgminer --scrypt -o stratum+tcp://SERVERNAME:PORT -u WORKER.ID -p PASS 
A good guide for fine tuning cgminer can be found here; follow the litecoin example.
EDIT
I had trouble getting cgminer running with a single line command, but running it via an executable .sh file works. This is covered in the cgminer setup guide I posted above but I'll put it here too. In the same directory that has the cgminer executable, you need to make a file called cgminer.sh and make it executable. It should contain the follwing:
export GPU_USE_SYNC_OBJECTS=1 export GPU_MAX_ALLOC_PERCENT=100 export DISPLAY=:0 find *.bin -delete sleep 5 ./cgminer 
Then you can call cgminer in terminal by doing ./cgminer.sh You will need a cgminer.conf file containing all your options. All of this is covered in the guide that is linked above.
A quick note about AMD drivers: They used to be a huge PITA to install and get working, but the newest Catalyst drivers are great. There's a GUI installer, everything works out of the box, and there is a lot of documentation. You can download them here: AMD Catalyst 14.6 Beta Linux
CPU Mining
For CPU mining I use minerd because it doesn't require any work to get running, simply download it and get to work. Download the built file for your machine 32-bit or 64-bit, and then unzip it and you're ready to go!
cd ~/Downloads tar -xvf pooler-cpuminer-2.3.2-linux-x86.tar.gz 
The executable is called minerd and it will be in ~/Downloads but you can move it to wherever you like. To run it, pull up terminal and do
cd ~/Downloads minerd --url=stratum+tcp://SERVER:PORT --userpass=USERNAME.WORKERNAME:WORKERPASSWORD 
You're done! Happy mining!
Common Issues
I ran into this and I've seen others with this problem as well. Everything installs fine but there is a shared library file that isn't where it should be. In fact, it isn't there at all.
 libudev.so.1: cannot open shared object file: No such file or directory 
In terminal, do
sudo updatedb locate libudev.so.0.13.0 
And it will probably return a path /lib/x86_64-linux-gnu. Inside that directory there's a library file called libudev.so.0.13.0. You'll need to make a symlink (aka shortcut) that links libudev.so.1 to libudev.so.0.13.0 So, assuming you're working with libudev.so.0.13.0 do this
cd /lib/x86_64-linux-gnu sudo ln -s libudev.so.0.13.0 libudev.so.1 
Now if you do
ln -l 
You should see
libudev.so.1 -> ./libudev.so.0.13.0 
Meaning you've made the symlink. Also, the text for libudev.so.1 will be blue.
submitted by Boozybrain to dogecoin [link] [comments]

How to Mine BiblePay on Linux

This guide is outdated, please refer to:
https://wiki.biblepay.org/POBH_Setup
https://wiki.biblepay.org/PODC_Setup
 
 
 
 
 
 
 
 
IMPORTANT - Evolution Upgrade:
Quick Start https://wiki.biblepay.org/Quick_Start
Evolution Upgrade Information https://wiki.biblepay.org/Evolution_Upgrade
Getting Started with Evolution https://wiki.biblepay.org/Getting_Started_with_Evolution
Generic Smart Contracts https://wiki.biblepay.org/Generic_Smart_Contracts
What is BiblePay Evolution? https://www.reddit.com/BiblePay/comments/bifvpk/biblepay_evolution_what_is_it/
Recommend 2GB RAM or can get stuck compiling (if 1GB RAM can use Swap File) Use Ubuntu 16.04
INFO
https://github.com/biblepay/biblepay-evolution/blob/masteBuildBiblePay.txt
INSTALL COMMANDS
apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils apt-get install libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler apt-get install git apt-get install curl build-essential libtool autotools-dev automake pkg-config python3 bsdmainutils cmake sudo add-apt-repository ppa:bitcoin/bitcoin sudo apt-get update sudo apt-get install libdb4.8-dev libdb4.8++-dev git clone http://github.com/biblepay/biblepay-evolution prefix=x86_64-pc-linux-gnu cd biblepay-evolution/depends make -j4 # Choose a good -j value, depending on the number of CPU cores available cd .. ./autogen.sh #Note: if echo `pwd` does not return your working directory, replace it with your working directory such as /biblepay-evolution/ ./configure --prefix `pwd`/depends/x86_64-pc-linux-gnu make # See more here: #https://github.com/biblepay/biblepay-evolution/blob/mastedoc/build-unix.md 

SWAP FILE
NOTE: if server is 1GB RAM, before running last command "sudo make", set up a swap file
free #check if swap is 0 dd if=/dev/zero of=/vaswap.img bs=1024k count=1000 mkswap /vaswap.img swapon /vaswap.img free #check if swap is 1024 sudo make 

RUN COMMAND LINE
cd src ./biblepayd -daemon 
OR
RUN GUI
Your GUI program will be located in: /biblepay-evolution/src/qt
./biblepay-qt 
You can also run it in the background (to free up your terminal) if you call it with:
./biblepay-qt & 
To start mining, instructions are the same as for Windows: Go to Tools -> Debug Console
Execute this command (to start mining with 8 threads)
setgenerate true 8 
From there you can use all other commands such as getmininginfo, getwalletinfo, etc. Execute help command to get the list of all available commands.
Note: GUI will be built automatically only if you meet the requirements for qt library, i.e. make sure you ran this line before compiling:
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler 
BIBLEPAY is now Running!

SETUP CONFIG
Stop BiblePay and set up the config file to get starting nodes to sync with and enable mining:
./biblepay-cli stop cd ~/.biblepayevolution/ vi biblepay.conf addnode=node.biblepay.org gen=1 genproclimit=1 
Escape Key + : (Colon Key) + w + q + Enter (saves file and quits)

addnode --- adds a node to the list of nodes to connect to gen=1 --- turns on mining genproclimit --- sets number of threads to use when mining

Run BiblePay again and fully sync with network
cd ../biblepay-evolution/src ./biblepayd -daemon ./biblepay-cli getinfo 

USEFUL COMMANDS
./biblepay-cli help ./biblepay-cli getaccountaddress "" ./biblepay-cli getinfo ./biblepay-cli getmininginfo ./biblepay-cli setgenerate true 8 ./biblepay-cli sendtoaddress "insertAddressHere" 777 "" "" true ./biblepay-cli stop ./biblepayd -daemon top #CPU usage q to quit 

MINING THREADS: To change number of threads to use up for mining
a. Edit home/yourusername/.biblepayevolution/biblepay.conf file:
genproclimit=X 
and restart BiblePay -or- b. Menu >> Tools >> Debug Console >> Type command:
setgenerate true X 
(Replace X with number of threads Use top command to view CPU usage)

POOL
NOTE: To use the pool you must now use the external miner, not the wallet miner https://whitewalr.us/2019/biblepay-nomp-pool-mining.html
  1. Set up an account on pool website: https://pool.biblepay.org/
  2. Create Worker Username(s) - Workers tab >>> Add
  3. Enable pool and add Worker Username in ~/.biblepayevolution/biblepay.conf file, add these lines and save:
    pool=https://pool.biblepay.org workerid=insertWorkerUsernameHere
4. Restart BiblePay
./biblepay-cli stop ./biblepayd -daemon 
Setup Auto-Withdraw Navigate to Account >>> Account Settings >>> Verify your BBP Receiving Address >>> Click Authorize-Auto-Withdraws

UPDATE:

### Turn off/stop BiblePay
cd /home/yourname/biblepay-evolution/src ./biblepay-cli stop 

### Pull down latest Biblepay code and build it
cd /home/yourname/biblepay-evolution git pull origin master sudo make 

### Turn BiblePay back on and check version number
cd src ./biblepayd -daemon ./biblepay-cli getinfo ./biblepay-cli setgenerate true 8 

UPDATE IN ONE COMMAND:
./biblepay-evolution/src/biblepay-cli stop ; cd && cd biblepay-evolution/ && git pull origin master && sudo make && cd src && ./biblepayd -daemon && sleep 90 && ./biblepay-cli getmininginfo 
Note: the ";" says do this after, regardless of the outcome Note: && says do this after only if previous command finished with no errors

SPEED UP COMPILE:
To speed up the compile time, add -j4 or -j8 after make. This way it compiles using 4 or 8 threads instead of just 1.
./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" sudo make -j8 
Reference: http://www.linux-databook.info/?page_id=2319

RSYNC stop biblepay from your nodes compile on your fastest machine then rsync with your machines only src folder is required
rsync -avuz /root/biblepay-evolution/src/ [email protected]:/root/biblepay-evolution/src/ 
https://stackoverflow.com/questions/3299951/how-to-pass-password-for-rsync-ssh-command https://www.thegeekstuff.com/2008/11/3-steps-to-perform-ssh-login-without-password-using-ssh-keygen-ssh-copy-id/
people make cron jobs and rsync automatically

OUTDATED

Unofficial Bash Script
https://gist.github.com/anonymous/d1c1d35e3c8f67f5fb2e204479fa5c6b

Official Ubuntu Package
https://launchpad.net/~biblepay-official

Unofficial Ubuntu Package
https://www.reddit.com/BiblePay/comments/7rwqqs/unofficial_ubuntu_packages_available/

Unofficial Mine in One Line
https://www.reddit.com/BiblePay/comments/7ryuk1/mine_in_one_line/
NOTE: DONT RUN ON A COMPUTER WITH COINS -- THIS IS A CLEAN INSTALL SCRIPT

COMPILE WITHOUT GUI: https://bitcointalk.org/index.php?topic=2042657.msg21878317#msg21878317 https://bitcointalk.org/index.php?topic=2042657.msg21878389#msg21878389
ADVANCED:

DOCKER IMAGES (NOTE: I havent tested these, use at your own risk) https://hub.docker.com/gagaha/biblepay/ https://hub.docker.com/cryptozero/biblepay-opt/
submitted by togoshige to BiblePay [link] [comments]

A guide to sign a super bitcoin (SBTC) transaction offline with patched Electrum for paranoid. Supports any wallets supported by Electrum (including segwit-p2sh and bech32 and all BIP39 seeds). Later BCD will be added.

This is quite advanced. This guide assumes you have some basic experience with the command line, can run Linux and you understand the basics of keys/signing/broadcasting transactions. And that you can compile and run Bitcoin Core and run Electrum. Also, some JSON experience is also nice.
Move you bitcoins to safe addresses first. It is best to use a new seed. Although the procedure in this guide is safe even for hot addresses (containing bitcoins), there is always a risk of a critical mistake. So play it safe.
Why such a guide? I followed these steps because I did not want to expose the keys to any online machine at all. Even if the keys do not have any bitcoins, you can some day have bitcoins sent to these addresses or you have a fork that you have not claimed. All can be stolen if you exposed your key.
This procedure should work with everything that Electrum supports (except maybe F2A that may be not supported on the SBTC chain), so Electrum seed legacy or segwit, LedgeTrezor with legacy or segiwt-p2sh (m/'49) derivation. Similarly, any BIP39 seeds or a single key. are also fine.
  1. Download Electrum. git clone https://github.com/spesmilo/electrum
  2. Apply my patch patch -P0 also this article. The guide assumes that you use patched Electrum from now on.
  3. Run the patched Electrum and catch up with your wallets you want to claim (the wallets can and rather should be watch only, or on ledgetrezor, otherwise your keys are exposed). Now go offline or set localhost as your server that Electrum connects to so no connection is performed. It's required so Electrum will not update the wallet after you edit it.
  4. You can manually create a transaction from the command line but you can use Electrum GUI. You need to locate the wallet file and remove all the transactions from the wallet file except for the one that funds the address you want to claim (the wallet obviously must not be encrypted but for watch-only this is OK). This is tricky. You need to make sure, you gave a proper JSON file, so all the final commas must be dropped. So "addr_history":, "transactions": , "tx_fees":, "txi", "txo", and "verified_tx3": should only contain the funding transaction(s), i.e. the one that you want to spend from.
  5. Run Electrum and check if the wallet is OK. Electrum will show an error if not. You will probably make a few errors so go back to editing the wallet.
  6. Download SBTC bitcoin core clone. git clone https://github.com/superbitcoin/SuperBitcoin
  7. Compile it and let it sync the blockchain (it will take a long time). Run it it with as large -dbcache= as you can. If you have a Bitcoin blockchain you can copy the blocks up to the fork date and issue sbtcd with -reindex. It will just reindex them and it will be faster.
  8. Generate a sbtc address with sbtc-cli getnewaddress. You can skip this step and send directly to an exchange but this intermediate step is safer.
  9. Create a transaction in Electrum to this address. Select all the bitcoins and use as small fee as possible (SBTC blocks are empty so any fee above 1 SBTCsat/byte should be OK).
  10. Save the transaction to a pendrive
  11. Download and install Kubuntu 16.04 (Kubuntu has all the QT libraries for Electrum) on a pen drive.
  12. Copy patched Electrum and the save the transaction to a pen drive (separate from Kubuntu will be more convenient).
  13. Run Kubuntu from the USB without any network access. Run Electrum from the pendrive. Create a wallet from the seed or private keys. The wallets are stored in RAM so after you reboot the computer, they will be gone. Load the transaction, sign it and save it to the pen drive.
  14. Go back to the SBTC Core on the online machine. Display the raw transaction (starts with the hex=). Check in the SBTC Core if it is correct sbtc-cli decoderawtransaction hex
  15. If it looks fine (and your blockchain got synced), broadcast it sbtc-cli sendrawtransaction hex
If there is no error, congratulations, you sent the transaction to the specified address. If it is to your SBTC Core wallet, wait until it confirms and send it further with sbtc-cli setfee feeperkb sbtc-cli sendtoaddress "addr" value "" "" true true
I'm going to update this guide when I figure out the BCD transactions intrinsics. You can download and run the BitcoinDiamond Core clone in the meantime.
SBTC tips: 1KjuY8CTrwMhdLt3uF3hCcSgfkHMyo1ELf
submitted by PVmining to BitcoinAirdrops [link] [comments]

Error compiling bitcoinfaith

Hey,
i can sucesfull compile bitcoin-qt but when i change to bitcoin faith i get error, even though i follow exactly the same steps (and i had no errors with bitcoin diamond for example)
[email protected]:~/bitcoinfaith$ make Making all in src make[1]: Entering directory '/home/chris/bitcoinfaith/src' make[2]: Entering directory '/home/chris/bitcoinfaith/src' CXX btfd-bitcoind.o In file included from ./uint256.h:15:0, from consensus/params.h:9, from chainparams.h:10, from bitcoind.cpp:10: ./crypto/common.h:16:20: fatal error: sodium.h: No such file or directory #include "sodium.h" ^ compilation terminated. Makefile:8105: recipe for target 'btfd-bitcoind.o' failed make[2]: *** [btfd-bitcoind.o] Error 1 make[2]: Leaving directory '/home/chris/bitcoinfaith/src' Makefile:9349: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/chris/bitcoinfaith/src' Makefile:747: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1
Anyone has a guesS?
submitted by adolfaberHitler to BitcoinAirdrops [link] [comments]

Qtum - Quantum Chain Design Document

Serialization: Qtum Foundation Design Document

Foreword
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**)**
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 (or OP_EXEC_ASSIGN)

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: https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI 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 (or OP_TXHASH, OP_EXEC_SPEND)

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.

summary

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]

Trouble with compiling Bitcoin Core on Win10

Attempting to compile Bitcoin Core on a Win10 machine via the Windows Subsystem For Linux method described in the "build-windows.md" file found here on github:
https://github.com/bitcoin/bitcoin
Also, described in this reddit post:
https://www.reddit.com/Bitcoin/comments/6209nx/uasfbitcoin_has_been_updated_if_you_are_running_a/
I've gone through all the steps twice now (restarted completely after the first failure). I get locked up at the step that is supposed to compile the source code via "make".
After a couple hours of running it hits an error:
qt/test/test_main.cpp: In function 'int main(int, char)': qt/test/test)main.cpp:62:43: error: 'setenv' was not declared in this scope setenv("QT_QPA_PLATFORM", "minimal", 0);
what I have tried
I added the following include statement to the cpp file in question: #include this did not work
Next, I changed the setenv function to a putenv function. This function only takes one argument as opposed to setenv which has 3, so I only included the first argument form the setenv function statement.
This actually worked as far as the source code compiling to completion without error.
I am afraid, however, that my changes may have unwanted consequences, and also, upon completion of the compiling, next step is to install the bitcoind executable. This also ran to completion and created a bitcoind.exe file as well as a couple other .exe files.
However, now I don't know what to do. I have a book that I'm following that says to run the executable by simply entering "bitcoind" which then is supposed to request you to create a random password for the configuration file.. however, none of that happens.
So I guess I have 2 major questions. The first, are the changes I made to the cpp file acceptable? And second, how am I supposed to run these executable files within the Windows Subsystem For Linux environment.
Many thanks for any help!
submitted by Ian_Mcstruthers to Bitcoin [link] [comments]

Easy UASF Node in Debian VM tutorial

So if you have a moderately powerful gaming desktop with a Quad-Core CPU like an i5 or better and 8+GB of RAM, you can easily run your own little UASF node in the background. Once it's done syncing with the network, you won't even notice it's there. Here's how.
You will need :
The following assumes you know how to install Linux in a Virtual Machine
Step I. - Installation. Go through expert install and set up a base system with only ssh server enabled. For partitioning, you can do just one big disk and everything in one partition, but if you happen to have a computer that has both SSD's and HDD's, it would be optimal to create two virtual disks and use a small one for the OS on the SSD and a larger one on the HDD in a custom mount point for the blockchain. Reboot and ssh into the server.
Step II. - Build requirements. A few things need to be taken care of. First, you'll want to edit the /etc/network/interfaces file and set up a static IP. Once that's done, stop by your router and make sure that traffic on port 8333 is forwarded to your debian VM. Then, install some packages we need :
apt update apt upgrade apt install build-essential autoconf libssl-dev libboost-dev libboost-chrono-dev libboost-filesystem-dev libboost-program-options-dev libboost-system-dev libboost-test-dev libboost-thread-dev libevent-dev git libtool pkg-config 
The next one is a bit more annoying. We need Berkeley DB 4.8, and it's a little old. It's packages are in the Debian Squeeze archives, so in the /etc/apt/sources.list file, we need to add :
deb http://archive.debian.org/debian/ squeeze main 
Then remember to update again, and install the thing :
apt install libdb4.8++-dev libdb4.8-dev 
If you intend to also throw on xorg and a UI, you will want Qt as well. Otherwise skip this last step.
install libqt4-dev libprotobuf-dev protobuf-compiler libqrencode-dev 
Step III. - Build time
#Starting from /home/yourUser git clone https://github.com/UASF/bitcoin.git -b 0.14-BIP148 cd bitcoin ./autogen.sh ./configure make make install 
That's it! Well, mostly. Start it with
bitcoind -daemon -disablewallet -datadir=/whereveyou/want/youblockchain 
...and wait about thirty hours to sync with the network. You may want to visit the /whereveyou/want/youblockchain directory and create a permanent bitcoin.conf in there. To enable RPC calls to the server and get it to accept bitcoin-cli commands you'll want to use it to create a usepassword and copy that to your user's /.bitcoin/bitcoin.conf.
Minimal bitcoin.conf example
daemon=1 listen=1 disablewallet=1 server=1 rpcuser=bob rpcpassword=bob's password 
Security I recommend you disable password login and use private key authentication only on ssh, and also restrict iptables rules to the bare minimum that must be allowed for this application. You will need this in your iptables script :
# Allows BITCOIN traffic from anywhere -A INPUT -p tcp --dport 8333 -j ACCEPT # Allows RPC calls to the bitcoin server from localhost -A INPUT -p tcp -s 127.0.0.1 --dport 8332 -j ACCEPT 
Useful ressources :
submitted by the_bolshevik to Bitcoin [link] [comments]

Trouble with compiling Bitcoin Core on Win10

Attempting to compile Bitcoin Core on a Win10 machine via the Windows Subsystem For Linux method described in the "build-windows.md" file found here on github:
https://github.com/bitcoin/bitcoin
Also, described in this reddit post:
https://www.reddit.com/Bitcoin/comments/6209nx/uasfbitcoin_has_been_updated_if_you_are_running_a/
I've gone through all the steps twice now (restarted completely after the first failure). I get locked up at the step that is supposed to compile the source code via "make".
After a couple hours of running it hits an error:
qt/test/test_main.cpp: In function 'int main(int, char)':
qt/test/test)main.cpp:62:43: error: 'setenv' was not declared in
this scope setenv("QT_QPA_PLATFORM", "minimal", 0);
what I have tried
I added the following include statement to the cpp file in question: #include ..this did not work
Next, I changed the setenv function to a putenv function. This function only takes one argument as opposed to setenv which has 3, so I only included the first argument form the setenv function statement.
This actually worked as far as the source code compiling to completion without error.
I am afraid, however, that my changes may have unwanted consequences, and also, upon completion of the compiling, next step is to install the bitcoind executable. This also ran to completion and created a bitcoind.exe file as well as a couple other .exe files.
However, now I don't know what to do. I have a book that I'm following that says to run the executable by simply entering "bitcoind" which then is supposed to request you to create a random password for the configuration file.. however, none of that happens.
So I guess I have 2 major questions. The first, are the changes I made to the cpp file acceptable? And second, how am I supposed to run these executable files within the Windows Subsystem For Linux environment.
Many thanks for any help!
submitted by Ian_Mcstruthers to BitcoinTechnology [link] [comments]

Bitcoin Price Predictions with AI GENERATE FREE BITCOINS INTO BITCOIN-QT WALLET (DIRECT DOWNLOAD) How To Earn BITCOIN Only Ads Watch To BTC Crypto Wallet Compiling Windows QT Installing Bitcoin-Qt

compile source code of a coin that is missing files. i.e. you go to compile the wallet and it says yourcoin\src\qt\res\icons bitcoin.ico does not exist You may be trying to compile source code that is missing things - many coins are. This is often seen when a new coin is launched. If it is something simple like an icon use an icon from another Bitcoin Core is both a daemon also a Wallet client. A fully functioning node must have the Bitcoin Core (formerly Bitcoin-Qt) daemon running on a machine instance with the complete block chain downloaded.Note that this speed-up is no longer be needed for Bitcoin Core version 0.10 (click here for Bitcoin Core version history) and above because blockchain syncing is paralleled across multiple If you are building some projects around bitcoin then you might have realized that you have to compile the bitcoin source code to create the bitcoind for your own machine. This is necessary because sometimes the pre-compiled binary do not work as expected and your whole project might become erroneous. the mingw cross-toolchain packages in Ubuntu 16.x have known issues producing viable windows binaries for bitcoin and bitcoin-derived projects. we use Ubuntu 14.04 currently to cross-compile the windows binaries for release, but if that isn't an option for WSL, you can try to instead use Ubuntu 18.04 (though this is not yet tested with PIVX). Instructions for building a Windows Bitcoin sCrypt client v.1.4.0 from source code using a deterministic gitian build. Bitcoin - sCrypt v1.4.0-beta## HOW TO COMPILE GITIAN BUILD OF BITCOIN-SCRYPT QT CLIENT FOR WINDOWSS Amended for Bitcoin-sCrypt by Smokeasy from Gavins Notes to getting gitian bui...

[index] [12526] [6460] [29990] [28334] [19400] [19338] [14217] [19176] [17380] [9588]

Bitcoin Price Predictions with AI