API reference (JSON-RPC) - Bitcoin Wiki

Are all these JSON-RPC commands supported by a pruned node? /r/Bitcoin

Are all these JSON-RPC commands supported by a pruned node? /Bitcoin submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

Hey, r/Bitcoin and Node.js developers, I created an open-source Express middleware plugin that easily maps JSON-RPC commands to any url for rapid development.

Hey, Bitcoin and Node.js developers, I created an open-source Express middleware plugin that easily maps JSON-RPC commands to any url for rapid development. submitted by NielDLR to Bitcoin [link] [comments]

Power of the Command Line (bitcoin-cli, hwi, electrum, trezorctl)

I think some of the console tools available with HW wallets today are greatly under utilized. Here's a quick write-up on how to create and sign a TXN very similar to 43d27...1fc06 found on the SLIP-14 wallet. I'll be using TrezorCTL, Electrum, and HWI for the signing. I won't go much into the setup or install, but feel free to ask if you have questions about it. Note, you don't have to use all three of these. Any one will produce a valid signed TXN for broadcast. I just showed how to do it three ways. Whats more some of the Electrum and HWI steps are interchangeable.
ColdCard also has a utility called ckcc that will do the sign operation instead of HWI, but in many ways they are interchangeable. KeepKey and Ledger both have libraries for scripted signing but no one-shot, one-line console apps that I know of. But HWI and Electrum of course work on all four.

TrezorCTL

This is the what most would think of to use to craft and sign TXNs, and is definitely very simple. The signing uses a script called build_tx.py to create a JSON file that is then used by the btc sign-tx command. The whole process is basically:
  1. tools/build_tx.py | trezorctl btc sign-tx -
This just means, take the output of build_tx and sign it. To copy 43d27...1fc06, I wrote a small script to feed build_tx, so my process looks like:
  1. ~/input.sh | tools/build_tx.py | trezorctl btc sign-tx -
But it's all very simple. Note... I used TrezorCTL v0.12.2 but build_tx.py version 0.13.0 1.

input.sh

```

!/bin/bash

secho() { sleep 1; echo $*}
secho "Testnet" # coin name secho "tbtc1.trezor.io" # blockbook server and outpoint (below) secho "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00:0" secho "m/84'/1'/0'/0/0" # prev_out derivation to signing key secho "4294967293" # Sequence for RBF; hex(-3) secho "segwit" # Signature type on prev_out to use secho "" # NACK to progress to outs secho "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" # out[0].addr secho "10000000" # out[1].amt secho "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu" # out[1].addr secho "20000000" # out[1].amt secho "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x" # out[2].addr secho "99999694" # out[2].amt secho "" # NACK to progress to change secho "" # NACK to skip change secho "2" # txn.version secho "0" # txn.locktime ```

Electrum

Electrum is one of the better GUI wallets available, but it also has a pretty good console interface. Like before you need your Trezor with the SLIP-14 wallet loaded and paired to Electrum. I'll assume Electrum is up and running with the Trezor wallet loaded to make things simple.
Like with TrezorCTL, Electrum feeds on a JSON file, but unlike TrezorCTL it needs that JSON squished into the command line. This is a simple sed command, but I won't bore you with the details, but just assume that's done. So the process in Electrum (v4.0.3) looks like:
  1. electrum serialize (create psbt to sign)
  2. electrum --wallet signtransaction (sign said psbt)
Still pretty simple right! Below is the JSON I smushed for #1

txn.json

{ "inputs": [{ "prevout_hash":"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "prevout_n": 0, "value_sats": 129999867 }], "outputs": [{ "address": "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3", "value_sats": 10000000 },{ "address": "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu", "value_sats": 20000000 },{ "address": "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x", "value_sats": 99999694 }]}

HWI

HWI is an unsung hero in my book. It's a very small clean and simple interface between HW wallets and Bitcoin Core. It currently supports a good range of HW wallets. It keeps itself narrowly focused on TXN signing and offloads most everything else to Bitcoin Core. Again, I'll assume you've imported your Trezor keypool into Core and done the requisite IBD and rescan. And if you don't have the RPC enabled, you can always clone these commands into the QT-console.
To sign our TXN in HWI (v1.1.2), we will first need to craft (and finalize) it in Bitcoin Core (0.21.1). Like in Electrum, we will have to use simple sed to smush some JSON into command arguments, but I'll assume you have that covered. It will take an inputs.json and an outputs.json named separately.
  1. bitcoin-cli createpsbt (create psbt)
  2. bitcoin-cli -rpcwallet= walletprocesspsbt (process psbt)
  3. hwi -f signtx (sign psbt)
  4. bitcoin-cli -rpcwallet= finalizepsbt (get a signed TXN from psbt)
A little more involved, but still nothing too bad. Plus this gives you the full power of Bitcoin Core including integrations with LND (lightning).

inputs.json

[{ "txid": "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "vout": 0 }]

outputs.json

[{ "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3": 0.10000000 },{ "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu": 0.20000000 },{ "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x": 0.99999694 }]

Conclusion

This may all seem like very low level coding, but is surprisingly simple once you get a knack for it. Whats more, all these platforms support testnet which allows you to practice with valueless coins until you get the hang of it. And, like many things in bitcoin, this is all (mostly) python, which is one of the easier languages to learn.
Enjoy
Footnotes
1 - https://github.com/trezotrezor-firmware/issues/1296
submitted by brianddk to Bitcoin [link] [comments]

BCH JSON RPC Calls List?

Hi all, trying to find documentation for the list of JSON RPC calls for Bitcoin Cash. This is as close as I can get, and it says it's outdated.
submitted by jeffthedunker to Bitcoincash [link] [comments]

Power of the Command Line (bitcoin-cli, hwi, electrum, trezorctl)

I think some of the console tools available with HW wallets today are greatly under utilized. Here's a quick write-up on how to create and sign a TXN very similar to 43d27...1fc06 found on the SLIP-14 wallet. I'll be using TrezorCTL, Electrum, and HWI for the signing. I won't go much into the setup or install, but feel free to ask if you have questions about it. Note, you don't have to use all three of these. Any one will produce a valid signed TXN for broadcast. I just showed how to do it three ways. Whats more some of the Electrum and HWI steps are interchangeable.

TrezorCTL

This is the what most would think of to use to craft and sign TXNs, and is definitely very simple. The signing uses a script called build_tx.py to create a JSON file that is then used by the btc sign-tx command. The whole process is basically:
  1. tools/build_tx.py | trezorctl btc sign-tx -
This just means, take the output of build_tx and sign it. To copy 43d27...1fc06, I wrote a small script to feed build_tx, so my process looks like:
  1. ~/input.sh | tools/build_tx.py | trezorctl btc sign-tx -
But it's all very simple. Note... I used TrezorCTL v0.12.2 but build_tx.py version 0.13.0 1.

input.sh

```

!/bin/bash

secho() { sleep 1; echo $*}
secho "Testnet" # coin name secho "tbtc1.trezor.io" # blockbook server and outpoint (below) secho "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00:0" secho "m/84'/1'/0'/0/0" # prev_out derivation to signing key secho "4294967293" # Sequence for RBF; hex(-3) secho "segwit" # Signature type on prev_out to use secho "" # NACK to progress to outs secho "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" # out[0].addr secho "10000000" # out[1].amt secho "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu" # out[1].addr secho "20000000" # out[1].amt secho "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x" # out[2].addr secho "99999694" # out[2].amt secho "" # NACK to progress to change secho "" # NACK to skip change secho "2" # txn.version secho "0" # txn.locktime ```

Electrum

Electrum is one of the better GUI wallets available, but it also has a pretty good console interface. Like before you need your Trezor with the SLIP-14 wallet loaded and paired to Electrum. I'll assume Electrum is up and running with the Trezor wallet loaded to make things simple.
Like with TrezorCTL, Electrum feeds on a JSON file, but unlike TrezorCTL it needs that JSON squished into the command line. This is a simple sed command, but I won't bore you with the details, but just assume that's done. So the process in Electrum (v4.0.3) looks like:
  1. electrum serialize (create psbt to sign)
  2. electrum --wallet signtransaction (sign said psbt)
Still pretty simple right! Below is the JSON I smushed for #1

txn.json

{ "inputs": [{ "prevout_hash":"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "prevout_n": 0, "value_sats": 129999867 }], "outputs": [{ "address": "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3", "value_sats": 10000000 },{ "address": "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu", "value_sats": 20000000 },{ "address": "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x", "value_sats": 99999694 }]}

HWI

HWI is an unsung hero in my book. It's a very small clean and simple interface between HW wallets and Bitcoin Core. It currently supports a good range of HW wallets. It keeps itself narrowly focused on TXN signing and offloads most everything else to Bitcoin Core. Again, I'll assume you've imported your Trezor keypool into Core and done the requisite IBD and rescan. And if you don't have the RPC enabled, you can always clone these commands into the QT-console.
To sign our TXN in HWI (v1.1.2), we will first need to craft (and finalize) it in Bitcoin Core (0.21.1). Like in Electrum, we will have to use simple sed to smush some JSON into command arguments, but I'll assume you have that covered. It will take an inputs.json and an outputs.json named separately.
  1. bitcoin-cli createpsbt (create psbt)
  2. bitcoin-cli -rpcwallet= walletprocesspsbt (process psbt)
  3. hwi -f signtx (sign psbt)
  4. bitcoin-cli -rpcwallet= finalizepsbt (get a signed TXN from psbt)
A little more involved, but still nothing too bad. Plus this gives you the full power of Bitcoin Core including integrations with LND (lightning).

inputs.json

[{ "txid": "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "vout": 0 }]

outputs.json

[{ "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3": 0.10000000 },{ "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu": 0.20000000 },{ "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x": 0.99999694 }]

Conclusion

This may all seem like very low level coding, but is surprisingly simple once you get a knack for it. Whats more, all these platforms support testnet which allows you to practice with valueless coins until you get the hang of it. And, like many things in bitcoin, this is all (mostly) python, which is one of the easier languages to learn.
Enjoy
Footnotes
1 - https://github.com/trezotrezor-firmware/issues/1296
submitted by brianddk to TREZOR [link] [comments]

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]

What is the fastest and most accurate way to get the live network hashrate for all of ZCash?

What is the fastest and most accurate way to get the live network hashrate for all of ZCash? I've been using various APIs but I feel like they're a little too slow. Thanks!
submitted by CastrosBallsack to zec [link] [comments]

Bitcoin - scripting / command line interface (access balance, send)

I did a lot of searching before asking here... no "recent" results, everything is (many) years old...
I want to script some simple tasks:
Check my address's balance, and send bitcoin to another address.
I am looking of for a wallet application/library that offers a scripting API or a command line interface.
Windows (batch, powershell) or Linux is fine.
Bitcoind has deprecated that feature, and Electrum is.... weird and not really documented.
Would you recommend Electrum anyway? Does it make sense to use Python in the Electrum console for scripts, or use the CLI commands in an "external" scripts?
Thanks for your input!
submitted by callosciurini to Bitcoin [link] [comments]

txunami: a transaction generator for scalability testing

Txunami (https://github.com/gandrewstone/txunami ) is a transaction generator that I created to solve the problem of loading the network. It is capable of ~50000 transactions per second (TPS) using 10 threads (tested to a local bitcoind). It submits transactions directly to bitcoind nodes via the P2P protocol rather than using the RPC protocol. This makes for a better test since most real transactions are submitted and relayed via this channel.
Txunami has a JSON based configuration file that allows the tester to configure different phases of operation, where a phase is basically a time interval, a set of nodes to send traffic to, and the desired TPS load. This allows the tester to characterize operation at different loads rather than only producing a maximal number. The configuration file also contains UTXO descriptions that provide Txunami with initial coins. It uses the format produced by the bitcoin-cli's "listunspent" and "dumpprivkey" RPC commands, making it quite easy to supply Txunami with initial coins.
submitted by gandrewstone to bitcoin_unlimited [link] [comments]

I gathered a bunch of data from my node and made a site to display it

I gathered a bunch of data from my node and made a site to display it
https://www.nodeupdate.com/ (updated regularly)
https://preview.redd.it/fy4hlq7dsik31.png?width=1361&format=png&auto=webp&s=cf363d941ef5df1c55fafff636baeb718aa867d9
I was surprised by how much useful information you can get from querying a node. I built this site using basic Bitcoin Core RPC commands like these: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC))
I am still working on the page, and hoping to have charts soon.
submitted by FunOptimizer42 to Bitcoin [link] [comments]

Gridcoin Leisure Update 3.7.14.0 Released

Today we have a new leisure update for you. This version includes a lot of "under the hood" changes, but there are some improvements for the average user as well.
 
Notably this release includes a better time to stake calculation method, thanks to @jamescowens. Also the Neural Network runs much smoother thanks to many optimizations by @ifoggz.
 
Download the update from GitHub here.
The Windows MSI can be downloaded here.
 
Full Release Notes:
Added
 
Changed
 
Fixed
 
Removed
 
Thank you to all the developers who contributed to this release. I will update this post when the Windows MSI has been uploaded to the website.
submitted by barton26 to gridcoin [link] [comments]

Soo after almost 3 months of setting up I have my own LN full node running on RP3

Soo after almost 3 months of setting up I have my own LN full node running on RP3
I have been eager to try LN mainnet since the very beginning of it. I've found out about lnd, eclair, zap and other wallets but every scenario I tried to use it failed because of critical issues:
  • eclair does not really constitute a wallet, it's more like a credit card - you can send money but not receive it
  • lnd is okay, but requires a server and tons of resources for maintaining a full node, can't be used securely, efficiently and mobily at the same time
  • zap offers some cloud wallet (in testnet!) by default, this is a serious misunderstanding of my cryptoanarchy needs
  • web wallets - ah, forget it
So I've decided to use my Raspberry Pi with a very old laptop HDD attached (200GB so the pruning function has to be used) to create a backend wallet service and zap desktop (temporarily!) as my frontend control panel.
https://preview.redd.it/0vcq147887q11.png?width=1024&format=png&auto=webp&s=7bb6eccdd4110a857e5af0400acc2d7e1ee7ee85
Setting up Pi is easy, lots of tutorials over the internet, not gonna discuss it here. Then I had to obtain bitcoind (current rel: bitcoin-0.17.0-arm-linux-gnueabihf.tar.gz) and lnd (lnd-linux-armv7-v0.5-beta.tar.gz), create a bitcoin technical user, deploy the tools, configure and install new systemd services and go through the configs. This is a tricky part, so let's share:
# Generated by https://jlopp.github.io/bitcoin-core-config-generato # This config should be placed in following path: # ~/.bitcoin/bitcoin.conf # [core] # Set database cache size in megabytes; machines sync faster with a larger cache. Recommend setting as high as possible based upon machine's available RAM. dbcache=100 # Keep at most  unconnectable transactions in memory. maxorphantx=10 # Keep the transaction memory pool below  megabytes. maxmempool=50 # Reduce storage requirements by only storing most recent N MiB of block. This mode is incompatible with -txindex and -rescan. WARNING: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, greater than 550 = automatically prune blocks to stay under target size in MiB). prune=153600 # [network] # Maintain at most N connections to peers. maxconnections=40 # Use UPnP to map the listening port. upnp=1 # Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit. maxuploadtarget=5000 # [debug] # Log IP Addresses in debug output. logips=1 # [rpc] # Accept public REST requests. rest=1 # [wallet] # Do not load the wallet and disable wallet RPC calls. disablewallet=1 # [zeromq] # Enable publishing of raw block hex to 
. zmqpubrawblock=tcp://127.0.0.1:28332 # Enable publishing of raw transaction hex to
. zmqpubrawtx=tcp://127.0.0.1:28333 # [rpc] # Accept command line and JSON-RPC commands. server=1 # Username and hashed password for JSON-RPC connections. The field comes in the format: :$. RPC clients connect using rpcuser=/rpcpassword= arguments. You can generate this value with the ./share/rpcauth/rpcauth.py script in the Bitcoin Core repository. This option can be specified multiple times. rpcauth=xxx:yyy$zzz
Whooaa, this online config generator is really helpful, but I still had to manually correct a few things. The last line is obviously generated by rpcauth.py, I disabled the wallet functionality as lnd is going to take care of my funds. ZMQ is not available to the network so only my LND can use it, RPC usage I still have to think through a little, in general I would like to have my own block explorer some day but also be safe from any hacking attempts (thus I would need at least 2 RPC ports/user accounts - one for lnd, one for block explorer frontend). No ports open on firewall at this time, only UPnP is active and gently opens 8333 for block/tx transfers.
Now, synchronizing the blockchain took me time from mid-July to early September... The hard drive is really slow, also my external HDD drive has some trouble with its A/C adapter so Pi was getting undervoltage alerts all the time. Luckily, it is just downclocking when it happens and slowly but steadily synchronized the whole history. After all, I'm not paying even $5 monthly for a VPS, it is by design the cheapest hardware I could use to set up my LN wallet.
When bitcoind was ready (I've heard some stories about btcd but I don't trust this software yet, sorry), it's time to configure lnd.conf:
[Application Options] debuglevel=trace rpclisten=0.0.0.0:10009 externalip=X.X.X.X:9735 listen=0.0.0.0:9735 alias=X color=#XXXXXX [Bitcoin] bitcoin.active=1 bitcoin.mainnet=1 bitcoin.node=bitcoind [Bitcoind] bitcoind.rpchost=127.0.0.1 bitcoind.rpcuser=X bitcoind.rpcpass=X bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 
Here I've had to XXX a little more fields, as not only the bitcoind RPC credentials are stored here, but also my node's public information (it should be illegal to run nodes without specifically selected color and alias!). It is public (and I had to open port 9735 on my firewall), but not necessarily connected to my reddit account for most of the adversaries, so let's keep it this way. In fact, I also see a security vulnerability here: my whole node's stability depends on the IP being static. I could swap it for a .tk domain but who can tell if the bad guys won't actively fight DNS system in order to prevent global economic revolution? As such, I would rather see node identification in LN based on a public key only with possible *hints* of last-known-ip-address but the whole discovery should be performed by the nodes themself in a p2p manner, obviously preventing malicious actors from poisoning the network in some way. For now, I consider the IP stability a weak link and will probably have to pay extra Bitcoin TX fees when something happens to it (not much of a cost luckily!).

https://preview.redd.it/hjd1nooo77q11.png?width=741&format=png&auto=webp&s=14214fc36e3edf139faade930f4069fc31a3e883
Okay then, lnd is up and running, had to create a wallet and give it a night for getting up to speed. I don't know really what took it so long, I'm not using Windows nor 'localhost' in the config so the issues like #1027 are not the case. But there are others like #1545 still open so I'm not going to ponder much on this. I haven't really got any idea how to automatically unlock the wallet after Pi restart (could happen any time!), especially since I only tried to unlock it locally with lncli (why would I enter the password anywhere outside that host?), but let's say that my wallet will only be as stable as my cheap hardware. That's okay for the beta phase.
Finally, zap-desktop required me to copy tls.cert and admin.macaroon files to my desktop. If my understanding of macaroon (it's like an authentication cookie, that can later be revoked) is correct then it's not an issue, however it would be nice to have a "$50 daily limit" macaroon file in the future too, just to avoid any big issues when my client machine gets stolen. Thanks to this, I can ignore the silly cloud-based modes and have fully-secure environment of my home network being the only link from me to my money.
https://preview.redd.it/11bw3dgw47q11.png?width=836&format=png&auto=webp&s=b7fa7c88d14f22441cbbfc0db036cddfd7ea8424
Aaand there it is. The IP took some time to advertise, I use 1ml.com to see if my node is there. The zap interface (ZapDesktop-linux-amd64-v0.2.2-beta.deb) lacks lots of useful information so I keep learning lncli syntax to get more data about my new peers or the routes offered. The transactions indeed run fast and are ridiculously cheap. I would really love to run Eclair with the same settings but it doesn't seem to support custom lnd (why?). In fact, since all I need is really a lncli wrapper, maybe it will be easy to write my own (seen some web gui which weighs 700MB after downloading all dependencies with npm - SICK!). Zap for iOS alpha test registration is DOWN so I couldn't try it (and I'm not sure if it allows custom lnd selection), Zap for Android doesn't even exist yet... I made a few demo transactions and now I will explore all those fancy t-shirt stores as long as the prices are still in "early investor" mode - I remember times when one could get 0.001 BTC from a faucet...
https://preview.redd.it/42sdyoce57q11.png?width=836&format=png&auto=webp&s=7ec8917eaf8f3329d51ce3e30e455254027de0ee
If you find any of the facts presented by me false, I am happy to find out more in the discussion. However what I did I did mostly for fun, without paying much attention to the source code, documentation and endless issue lists on github. By no means I claim this tutorial will work for you but I do think I shared the key points and effort estimations to help others decide if they want a full-node LN client too. I'm also interested in some ideas on what to do with it next (rather unlikely that I will share my lnd admin.macaroon with anyone!) especially if it gives me free money. For example, I can open 1000 channels and start earning money from fees, although I no longer have more Bitcoins than the LN capacity yields... I will probably keep updating the software on my Pi until it leaves beta phases and only then will pour more money inside. I'm also keen on improving the general security of my rig and those comments I will answer more seriously.
submitted by pabou to Bitcoin [link] [comments]

Question for API

Hi, I have made a little game for two persons. I want them to be able to play it for dogecoins. Against eachother. So I wonder what kind of system is used in sites, lets say dogedice. They don't have wallets for each user (?) is there an internal database on the site with a key to show how many doge out of a gigantic wallet each user is entitled to?
Is there an API for something like this?! Thank you
submitted by shitshit1337 to dogecoindev [link] [comments]

I Am Creating A New Bitcoin Core GUI Header

Hey folks,
I have begun work to create a new Bitcoin GUI header. I am doing this for several reasons:
What will CBitcoin (the new GUI header) be?
CBitcoin will be a new GUI header as mentioned above. Among some things, it will support SegWit, it'll combine a GUI and command prompt into one single program and once LN is more developed, it'll integrate that as well.
You can find the project on my website: http://cowlite.nl/cbitcoin.php
and on Github: https://github.com/WJongkind/CBitcoin
During the development of CBitcoin, a strong and easy-to-use framework will be written in Java for interaction with the Bitcoin Network, based on the Bitcoin Core's bitcoind and it's JSON RPC API. Eventually it might be decided that this framework will become a entire project on it's own, but we are not that far yet.
You can read more details about the project on my website: http://cowlite.nl/cbitcoin.php. The entire project is open-source and will remain that way for obvious reasons: the software will be trusted, people can contribute to the code and people can borrow code for their own projects.
Looking for contributors
Currently, I am the only developer of the software. I do this in my spare time as a hobby and I do not earn any form of payment for it (however, people do have the option to donate). I am sure I could write the software entirely myself, though that would probably take a significant amount of time. Therefore I am asking any programming enthusiasts out there that have spare time to lend a hand. On the GitHub page & on my website there are instructions on how you can become part of the project. Donations will be split up amongst all contributors.
submitted by ImJustACowLol to Bitcoin [link] [comments]

Ravencoin Open Developer Meeting - 1/4/2019

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

submitted by Chatturga to Ravencoin [link] [comments]

What has Dash ever copied from others besides the original BTC codebase?

In the spirit of not biting the hand that feeds us, I'm starting this thread to raise awareness of how much Dash copies from Bitcoin Core.
It's disappointing to see even some Dash Mods don't understand how much Dash benefits from all the hard work of BTC Core, so let's look at precisely what Dash 12.3 has copied from Bitcoin.
What has Dash ever copied from others besides the original BTC codebase?
Dash copies ("backports") 1000s of BTC Core commits on every major release.
Do you know how to use github? If you do, the scale of what Dash has copied from BTC is perfectly clear from looking at https://github.com/dashpay/dash/graphs/contributors
You can see most so-called Dash commits were written by Bitcoin devs, and only one Dash dev (UdjinM6) with a significant number of original (IE non-backported) commits.
Here are the specifics on all the latest things in Dash 12.3 copied from BTC as well as a statement of Dash's intention to continue copying from BTC for the foreseeable future:
We backported many performance improvements and refactoring from Bitcoin Core and aligned most of our codebase with version 0.14.
+Most notable ones besides various performance and stability improvements probably are
+Compact Block support (BIP 152),
+Mining transaction selection ("Child Pays For Parent"),
+Null dummy soft fork (BIP 147, without SegWit), +Nested RPC Commands in Debug Console and
+Support for JSON-RPC Named Arguments.
+You can read more about all changes in Bitcoin Core 0.13 and 0.14 in following documents: +- release-notes-0.13.0.md; +- release-notes-0.13.1.md; +- release-notes-0.13.2.md; +- release-notes-0.14.0.md; +- release-notes-0.14.1.md; +- release-notes-0.14.2.md.
+Note that some features were already backported earlier (per-UTXO fix, -assumevalid, GUI overlay etc.) and some were not backported at all +(SegWit and feefilter, you can read more about why we did so here and here). +The alert system was also kept in place for now.

We are going to continue backporting the most notable fixes and improvements from Bitcoin Core versions 0.15 and 0.16 in future releases.

Source: https://github.com/dashpay/dash/pull/2045/files
Here is a tiny part of the list of the latest things Dash has copied from BTC Core
I'd post the entire list but Reddit says "(THIS IS TOO LONG (MAX: 10000)" LOL!
https://github.com/UdjinM6/dash/blob/369414a04258cd4ed9f520f87fa2a9889f17785d/doc/release-notes/dash/release-notes-0.12.3-backports.md

12.3 backports and related fixes:

bc45a2f87 Backport compact blocks functionality from bitcoin (#1966)
8b4c419ed Revert "Merge #7542: Implement "feefilter" P2P message" (#2025)
a4b313fd3 Fix std in DBG macro
6a6e4cdc1 Remove remaining using namespace std
08b5c69ef Merge #9643: [refactor] Remove using namespace from wallet/ & util*
ccca7af09 Merge #9476: [refactor] Remove using namespace from rpc/ & script/ sources
4ac4e96e8 Merge #9765: Harden against mistakes handling invalid blocks
662ec024a Make peer id logging consistent ("peer=%d" instead of "peer %d")
592d8f073 Use a temp pindex to avoid a const_cast in ProcessNewBlockHeaders
15a8fcf99 Add a CValidationInterface::NewPoWValidBlock callback
d28172f57 Call AcceptBlock with the block's shared_ptr instead of CBlock&
c99dd9733 [qa] Avoid race in preciousblock test.
807ae74c2 Make CBlockIndex*es in net_processing const
1d1c31052 Fix cmd args handling for -bip9params
64817fe1d [qa] Fix race condition in sendheaders.py
b2bc78099 Fix argument to wait_until
026f2e2a8 Merge #8446: [Trivial] BIP9 parameters on regtest cleanup
e326bda69 Tests: refactor compact size serialization in mininode
2c810d2c3 Allow changing BIP9 parameters on regtest
45151bd13 Move context-required checks from CheckBlockHeader to Contextual...
cef919f18 Merge #9486: Make peer=%d log prints consistent
55ef4d0a9 [wallet] Add include_unsafe argument to listunspent RPC
e1e03f42c [wallet] Add IsAllFromMe: true if all inputs are from wallet
611b31ece Merge #9650: Better handle invalid parameters to signrawtransaction
ff335e47f [qa] test_framework: Add wrapper for stop_node
64e1bfacd Add BIP32 to bips.md
4bb2af8d1 Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8
61af31531 Merge #8976: libconsensus: Add input validation of flags (#1891)
00a0bc710 Remove "TODO: fix off-by-one"
625252fb4 Allow to pass redirect_stderr=True to initialize_chain and use in wallet-dump.py
d56ac5a74 Fix import-rescan.py and add workaround for pruning mode
submitted by Dash_2_The_Future to dashpay [link] [comments]

The great Blockchain search

Alright now that we have fairly conclusive evidence that Julian is inside the Embassy I think it's time to discuss what we have found in our search of the blockchain. As many of you may know I spearheaded the search and contributed to enhanced versions of the jean.py scripts that work directly on the local blockchain but still retained https://blockchain.info/ calls for those who did not want to download the full blockchain. First I will post our github repo https://github.com/WikiLeaksFreedomForce and I will discuss the different code used and some of the things we've found through our testing and learning of the blockchain technology.
 
First off I started working with the original Jean.py scripts. They didn't work for me originally and I had to modify them a bit to get them to work. Once I did that I set out to make it much easier to use. On the chans there was talk of using a program called trid which is used to determine a file type of an unknown set of data. It's fairly advanced and has an ever growing database of known file types so it would often give false positives. We figured we could just get a list of known file headers to search for inside the data and limit the scope to fewer false positives. So within my first week of starting we already had code that worked pretty well at finding things. The main goal at first was to be able to successfully download the cablegate archive that Wikileaks uploaded themselves to the blockchain which was relatively simple with the full list of transactions that they themselves uploaded right after.
 
Moving forward from Jean.py I needed a faster way of communicating with the data from the blockchain and I found the JSON RPC commands built into the bitcoin client. The first couple weeks I had some issues with the fact the latest versions of bitcoin core don't keep a database of transaction ID's stored by default. Fortunately on my second attempt to getting it I enabled txindex=1 inside the bitcoin conf file. This had to rebuild the full index of each transaction and took several days.
 
Shortly after I did this work the first "great blockchain" post was made here and we gained a lot of support from other programmers willing to help out. We had one user build a Go program that does the same thing and avoids the issue of txindex=1, we had another user help us build a framework for parsing the blocks directly in c#, and we had another user more experienced in Python to help out with the original script. With the new help we were able to prototype new techniques for searching relatively quickly as well as improve readability and usage of the code. There are still plans to continue improving the code and make it easier to use but desire to keep working on it has come to a halt since most people are confident that Julian is safe in the Embassy and his Dead Man Switch was not released.
 
The blockchain is rather interesting as it's a ledger of information. Each transaction has a series of data that it uses to transmit and store information. I'm not fully aware of every aspect but I have learned a lot in the great search. We've found that most information stored as human readable content is inside the scripts. Each transaction has an input and output script. These are stored as binary data inside the blockchain .dat files and displayed as hex data through RPC and on https://blockchain.info/. The hex data tends to make it easier to see the data whereas often times unicode translations will make it look like gibberish.
 
Our code was designed around the principals of the original Satoshi Upload script as well as the download script. This used a unique line of code that ensured the correct data was uploaded and can be downloaded. This line encoded the length and a checksum of the data for the transaction inside each transaction. So when applying the Satoshi Downloader you can search for the first 8 bytes of data for a length value and checksum for data that follows that length after the first 8 bytes. Websites like http://www.cryptograffiti.info/ do not use this length and checksum. Right now our code can download everything inside a transaction that we know about. There are ways of improving speed by only flagging a transaction that contains significant information such as known file headers or follows the length and checksum from Satoshi. This has lead to a few interesting finds. Including but not limited to Peter Todd's lucifer linux burn in utility. I still plan to add a plaintext search at some point but there are websites devoted to finding those.
 
One thing that I couldn't get to work right was finding Wikileaks file hashes inside the blockchain. The information on how they do it is limited and I was only able to find the one cabelgate hash stored following the same idea as OpenTimeStamps. Searching for hashes takes a long time though and I have a simple python parser made that takes a dictionary of all the hashes and searches for them. The dictionaries I have as well as the python script are all on the girhub repo.
 
Some things we have found include: Cablegate, This is dog meme, unknown gpg acceptable files, plaintext messages, and a 7z with a message from Julian Assange(Don't get too excited I uploaded it myself to prove a point that we can't verify who sends a transaction). We haven't found anything really that hasn't already been documented or is available on other sites.
 
I would like to thank everyone who was involved on the Discord server working with me on this search it was great working with everyone and learning as a group!
 
Please feel free to comment and ask questions and I will try to answer them as best I can.
 
Edit: I am also free to discuss some of the stories and strange things that have occurred during the search. I tried to keep the main article about what we did do not what we were told to do or how.
submitted by TrustyJAID to WhereIsAssange [link] [comments]

Gridcoin Developer Update May 7th, 2018

Hello everyone and welcome to another Developer Update from the Gridcoin team. I'd like to remind everyone that these posts will be created every two weeks unless a wallet update is pending that week.
 
The last two weeks have largely been spent preparing for the next leisure release. The release would have come sooner, but some last minute additions to the staging branch were pulled in since the previous update post. Some of these pull requests have included:
 
Testnet has been working with PR #1060 which was mentioned in the last Developer Update post. I can now happily report that two superblocks have been successfully staked on testnet by Linux clients using contract forwarding. These results are extremely promising and will be a welcome addition for improved superblock stability on mainnet.
In the coming days I expect a new staging build to be ready for testnet deployment so testing will refocus soon on the PRs mentioned in this post.
 
While not entirely wallet related, I did want to point out some behind the scenes improvements for the https://gridcoin.us website. The site now properly redirects to HTTPS and supports TLS 1.2. Our site is now rated "A+" by SSL Labs. Thanks to our founder Rob for making these changes!
 
Thanks for reading this edition of the Developer Update. Expect to see another update two weeks from today (5/21), unless there is a wallet update released between now and then. If you have any comments or questions for the Gridcoin development team feel free to ask in the comments below. If I am not able to answer your question directly, I can certainly forward it to someone who can!
submitted by barton26 to gridcoin [link] [comments]

RPC tests; what are they, why do we care, can you help?

Some of you may have seen me tweeting about the RPC tests earlier today (which ended with https://twitter.com/dogecoin_devs/status/957634677380132865 ). This post is a bit to talk about the development process, a bit to update everyone, and a bit to track status for the other developers.
One of the issues we had with early Dogecoin releases was how to efficiently test compatibility of new releases with software such as mining pools. The RPC ( https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) ) interface is extensive and the commands interact with each other, making it time consuming to test effectively. Bitcoin Core solved this by introducing a set of tests which emulate services using the RPC interface.
These are important because Bitcoin isn't designed to support restructuring it, as we do (although more recent releases are vastly easier to update), so some of the changes we make can interact in unexpected ways with the base code. Issues such as the memory usage of 1.10 were indicated by the RPC tests, although at the time we missed the connection between the test problems and memory.
Max has updated the majority of the tests, reducing numbers of blocks mined to match Dogecoin maturity numbers, increasing transaction amounts to compensate for differences in fee schemes, etc. However, we have a small number of tests which fail due to unclear reasons, plus others which fail intermittently. My current concern is https://github.com/dogecoin/dogecoin/blob/1.14-dev/qa/rpc-tests/p2p-fullblocktest.py , which fails when testing that coinbase (mining reward) payments cannot be spent too early. I've checked and re-checked the numbers and the logs and it looks correct, and have had to take a break for now.
If you want to dig into these, the tests are run by:
  1. Build 1.14-dev (note it creates bitcoind because it's not rebranded yet)
  2. Run qa/pull-testerpc-tests.py p2p-fullblocktest to run just the full block tests, or qa/pull-testerpc-tests.py to run the full standard test suite (this will highlight other failing tests to tackle later).
  3. Wait for ages for the first run (it's a bit faster on later runs), like seriously think about getting some food while this works.
  4. It will fail and report the error.
When the test fails, it will leave behind the generated node configurations, logs and wallets (the path is displayed at the start of the tests running). You can also get more detail by running the tests with the option --tracerpc.
The other major failing test I'm struggling with is fundrawtransaction, which seems to be highlighting some sort of issue with watch only addresses. On line 617 ( https://github.com/dogecoin/dogecoin/blob/1.14-dev/qa/rpc-tests/fundrawtransaction.py#L617 ) it fails while trying to spend funds that node 3 should have access to because node 0 sent them to an address node 3 is watching, however for whatever reason node 3 seems unaware of those funds. Checking the generated wallet seems to suggest the address is watched correctly, but it doesn't realise the transaction is relevant.
We're working on these, but if anyone wants to dig in, please do go for it :)
submitted by rnicoll to dogecoindev [link] [comments]

QuarkChain Testnet 2.0 Mining.

QuarkChain Testnet 1.0 was built based on standardized blockchain system requirements, which included network, wallet, browser, and virtual machine functionalities. Other than the fact that the token was a test currency, the environment was completely compatible with the main network. By enhancing the communication efficiency and security of the network, Testnet 2.0 further improves the openness of the network. In addition, Testnet 2.0 will allow community members (other than citizens or residents of the United States) to contribute directly to the network, i.e. running a full node and mining, and receive testnet tokens as rewards.
QuarkChain Testnet 2.0 will support multiple mining algorithms, including two typical algorithms: Ethash and Double SHA256, as well as QuarkChain’s unique algorithm called Qkchash – a customized ASIC-resistant, CPU mining algorithm, exclusively developed by QuarkChain. Mining is available both on the root chain and on shards due to QuarkChain’s two-layered blockchain structure. Miners can flexibly choose to mine on the root chain with higher computing power requirements or on shards based on their own computing power levels. Our Goal By allowing community members to participate in mining on Testnet 2.0, our goal is to enhance QuarkChain’s community consensus, encourage community members to participate in testing and building the QuarkChain network, and gain first-hand experience of QuarkChain’s high flexibility and usability. During this time, we hope that the community can develop a better understanding about our mining algorithms, sharding technologies, and governance structures, etc. Furthermore, this will be a more thorough challenge to QuarkChain’s design before the launch of mainnet! Thus, we sincerely invite you to join the Testnet 2.0 mining event and build QuarkChain’s infrastructure together!
Today, we’re pleased to announce that we are officially providing the CPU mining demo to the public (other than citizens and residents of the United States)! Everyone can participate in our mining event, and earn tQKC, which can be exchanged to real rewards by non-U.S. persons after the launch of our mainnet. Also, we expect to upgrade our testnet over time, and expect to allow GPU mining for Ethash, and ASIC mining for Double SHA256 in the future. In addition, in the near future, a mining pool that is compatible with all mining algorithms of QuarkChain is also expected to be supported.
We hope all the community members can join in with us, and work together to complete this milestone! 2 Introduction to Mining Algorithms 2.1 What is mining? Mining is the process of generating the new blocks, in which the records of current transactions are added to the record of past transactions. Miners use software that contribute their mining power to participate in the maintenance of a blockchain. In return, they obtain a certain amount of QKC per block, which is called coinbase reward. Like many other blockchain technologies, QuarkChain adopts the most widely used Proof of Work (PoW) consensus algorithm to secure the network.
A cryptographically-secure PoW is a costly and time-consuming process which is difficult to solve due to computation-intensity or memory intensity but easy for others to verify. For a block to be valid it must satisfy certain requirements and hash to a value less than the current target threshold. Reverting a block requires recreating all successor blocks and redoing the work they contain, which is costly.
By running a cluster, everyone can become a miner and participate in the mining process. The mining rewards are proportional to the number of blocks mined by each individual.
2.2 Introduction to QuarkChain Algorithms and Mining setup According to QuarkChain’s two-layered blockchain structure and Boson consensus, different shards can apply different consensus and mining algorithms. As part of the Boson consensus, each shard can adjust the difficulty dynamically to increase or decrease the hash power of each shard chain.
In order to fully test QuarkChain testnet 2.0, we adopt three different types of mining algorithms” Ethash, Double SHA256, and Qkchash, which is ASIC resistant and exclusively developed by QuarkChain founder Qi Zhou. These first two hash algorithms correspond to the mining algorithms dominantly conducted on the graphics processing unit (GPU) and application-specific integrated circuits (ASIC), respectively.
I. Ethash Ethash is the PoW mining algorithm for Ethereum. It is the latest version of earlier Dagger-Hashimoto. Ethash is memory intensive, which makes it require large amounts of memory space in the process of mining. The efficiency of mining is basically independent of the CPU, but directly related to memory size and bandwidth. Therefore, by design, building Ethash ASIC is relatively difficult. Currently, the Ethash mining is dominantly conducted on the GPU machines. Read more about Ethash: https://github.com/ethereum/wiki/wiki/Ethash
II. Double SHA256 Double SHA256 is the PoW mining algorithms for Bitcoin. It is computational intensive hash algorithm, which uses two SHA256 iterations for the block header. If the hash result is less than the specific target, the mining is successful. ASIC machine has been developed by Bitmain to find more hashes with less electrical power usage. Read more about Double SHA256: https://en.bitcoin.it/wiki/Block_hashing_algorithm
III. Qkchash Originally, Bitcoin mining was conducted on the CPU of individual computers, with more cores and greater speed resulting in more profitability. After that, the mining process became dominated by GPU machines, then field-programmable gate arrays (FPGA) and finally ASIC, in a race to achieve more hash rates with less electrical power usage. Due to this arms race, it has become increasingly harder for prospective new miners to join. This raises centralization concerns because the manufacturers of the high-performance ASIC are concentrated in a small few.
To solve this, after extensive research and development, QuarkChain founder Dr. Qi Zhou has developed mining algorithm — Qkchash, that is expected to be ASIC-resistant. The idea is motivated by the famous date structure orders-statistic tree. Based on this data structure, Qkchash requires to perform multiple search, insert, and delete operations in the tree, which tries to break the ASIC pipeline and makes the code execution path to be data-dependent and unpredictable besides random memory-access patterns. Thus, the mining efficiency is closely related to the CPU, which ensures the security of Boston consensus and encourges the mining decentralization.
Please refer to Dr. Qi’s paper for more details: https://medium.com/quarkchain-official/order-statistics-based-hash-algorithm-e40f108563c4
2.3 Testnet 2.0 mining configuration Numbers of Shards: 8 Cluster: According to the real-time online mining node The corresponding mining algorithm is Read more about Ethash with Guardian: https://github.com/QuarkChain/pyquarkchain/wiki/Ethash-with-Guardian)
We will provide cluster software and the demo implementation of CPU mining to the public. Miners are able to arbitrarily select one shard or multiple shards to mine according to the mining difficulty and rewards of different shards. GPU / ASIC mining is allowed if the public manages to get it working with the current testnet. With the upgrade of our testnet, we will further provide the corresponding GPU / ASIC software.
QuarkChain’s two-layered blockchain structure, new P2P mode, and Boson consensus algorithm are expected tobe fully tested and verified in the QuarkChain testnet 2.0. 3 Mining Guidance In order to encourage all community members to participate in QuarkChain Testnet 2.0 mining event, we have prepared three mining guidances for community members of different backgrounds.
Today we are releasing the Docker Mining Tutorial first. This tutorial provides a command line configuration guide for developers and a docker image for multiple platforms, including a concise introduction of nodes and mining settings. Follow the instructions here: Quick Start with QuarkChain Mining.
Next we will continue to release: A tutorial for community members who don’t have programming background. In this tutorial, we will teach how to create private QuarkChain nodes using AWS, and how to mine QKC step by step. This tutorial is expected to be released in the next few days. Programs and APIs integrated with GPU / ASIC mining. This is expected to allow existing miners to switch to QKC mining more seamlessly. Frequently Asked Questions: 1. Can I use my laptop or personal computer to mine? Yes, we will provide cluster software and the demo implementation of CPU mining to the public. Miners will be able to arbitrarily select one shard or multiple shards to mine according to the work difficulty and rewards of different shards. 2. What is the minimum requirements for my laptop or personal computer to mine? Please prepare a Linux or MacOs machine with public IP address or port forwarding set up. 3. Can I mine with my GPU or an ASIC machine? For now, we will only be providing the demo implementation of CPU mining as our first step. Interested miners/developers can rewrite the corresponding GPU / ASIC mining program, according to the JSON RPC API we provided. With the upgrade of our testnet, we expect to provide the corresponding GPU / ASIC interface at a later date. 4. What is the difference among the different mining algorithms? Which one should I choose? Double SHA256 is a computational intensive algorithm, but Ethash and Qkchash are memory intensive algorithms, which have certain requirements on the computer’s memory. Since currently we only support CPU mining, the mining efficiency entirely depends on the cores and speed of CPU. 5. For testnet mining, what else should I know? First, the mining process will occupy a computer’s memory. Thus, it is recommended to use an idle computer for mining. In Testnet 2.0 settings, the target block time of root chain is 60 seconds, and the target block time of shard chain is 10 seconds. The mining is a completely random process, which will take some time and consume a certain amount of electricity. 6. What are the risks of testnet mining? Currently our testnet is still under the development stage and may not be 100% stable. Thus, there would be some risks for QuarkChain main chain forks in testnet, software upgrades and system reboots. These may cause your tQKC or block record to be lost despite our best efforts to ensure the stability and security of the testnet.
For more technical questions, welcome to join our developer community on Discard: https://discord.me/quarkchain. 4 Reward Mechanism Testnet 2.0 and all rewards described herein, including mining, are not being offered and will not be available to any citizens or residents of the United States and certain other jurisdictions. All rewards will only be payable following the mainnet launch of QuarkChain. In order to claim or receive any of the following rewards after mainnet launch, you will be required to provide certain identifying documentation and information about yourself. Failure to provide such information or demonstrate compliance with the restrictions herein may result in forfeiture of all rewards, prohibition from participating in future QuarkChain programs, and other sanctions.
NO U.S. PERSONS MAY PARTICIPATE IN TESTNET 2.0 AND QUARKCHAIN WILL STRICTLY ENFORCE THIS VIA OUR KYC PROCEDURES. IF YOU ARE A CITIZEN OR RESIDENT OF THE UNITED STATES, DO NOT PARTICIPATE IN TESTNET 2.0. YOU WILL NOT RECEIVE ANY REWARDS FOR YOUR PARTICIPATION.
4.1 Mining Rewards
  1. Prize Pool A total of 5 million QKC prize pool have been reserved to motivate all miners to participate in the testnet 2.0 mining event. According to the different mining algorithms, the prize pool is allocated as follows:
Total Prize Pool: 5,000,000 QKC Prize Pool for Ethash Algorithm: 2,000,000 QKC Prize Pool for Double SHA256 Algorithm: 1,000,000 QKC Prize Pool for Qkchash Algorithm: 2,000,000 QKC
The number of QKC each miner is eligible to receive upon mainnet launch will be calculated on a pro rata basis for each mining algorithm set forth above, based on the ratio of sharded block mined by each miner to the total number of sharded block mined by all miners employing such mining algorithm in Testnet 2.0.
  1. Early-bird Rewards To encourage more people to participate early, we will provide early bird rewards. Miners who participate in the first month (December 2018, PST) will enjoy double points. This additional point reward will be ended on December 31, 2018, 11:59pm (PST).
4.2 Bonus for Bug Submission: If you find any bugs for QuarkChain testnet, please feel free to create an issue on our Github page: https://github.com/QuarkChain/pyquarkchain/issues, or send us an email to [email protected]. We may provide related rewards based on the importance and difficulty of the bugs.
4.3 Reward Rules: QuarkChain reserves the right to review the qualifications of the participants in this event. If any cheating behaviors were to be found, the participant will be immediately disqualified from any rewards. QuarkChain further reserves the right to update the rules of the event, to stop the event/network, or to restart the event/network in its sole discretion, including the right to interpret any rules, terms or conditions. For the latest information, please visit our official website or follow us on Telegram/Twitter. About QuarkChain QuarkChain is a flexible, scalable, and user-oriented blockchain infrastructure by applying blockchain sharding technology. It is one of the first public chains that successfully implemented state sharding technology for blockchain in the world. QuarkChain aims to deliver 100,000+ on-chain TPS. Currently, 14,000+ peak TPS has already been achieved by an early stage testnet. QuarkChain already has over 50 partners in its ecosystem. With flexibility, scalability, and usability, QuarkChain is enabling EVERYONE to enjoy blockchain technology at ANYTIME and ANYWHERE.
Testnet 2.0 and all rewards described herein are not being and will not be offered in the United States or to any U.S. persons (as defined in Regulation S promulgated under the U.S. Securities Act of 1933, as amended) or any citizens or residents of countries subject to sanctions including the Balkans, Belarus, Burma, Cote D’Ivoire, Cuba, Democratic Republic of Congo, Iran, Iraq, Liberia, North Korea, Sudan, Syria, Zimbabwe, Central African Republic, Crimea, Lebanon, Libya, Somalia, South Suda, Venezuela and Yemen. QuarkChain reserves the right to terminate, suspend or prohibit participation of any user in Testnet 2.0 at any time.
In order to claim or receive any rewards, including mining rewards, you will be required to provide certain identifying documentation and information. Failure to provide such information or demonstrate compliance with the restrictions herein may result in termination of your participation, forfeiture of all rewards, prohibition from participating in future QuarkChain programs, and other actions.
This announcement is provided for informational purposes only and does not guarantee anyone a right to participate in or receive any rewards in connection with Testnet 2.0.
Note: The use of Testnet 2.0 is subject to our terms and conditions available at: https://quarkchain.io/testnet-2-0-terms-and-conditions/
more about qurakchain: Website: https://quarkchain.io/cn/ Facebook: https://www.facebook.com/quarkchainofficial/ Twitter: https://twitter.com/Quark_Chain Telegram: https://t.me/quarkchainio
submitted by Rahadsr to u/Rahadsr [link] [comments]

Moving Cloud Chain-Technical Demonstration

Moving Cloud Chain-Technical Demonstration

Overview Moving Cloud Chain Platform

As the leading public chain, Moving Cloud Chain is developed under MIT License Agreement with all code and technical data open-sourced. This is initially designed to create a stable and user-friendly developing platform for developers in intelligent industry. In this ecosystem with series of SDK and api connected, it helps developers construct side-chain decentralized application including customerizing side chain, smart contract and application development management. In this case, MCC works as “raw materials” for other coins or DApp projects and the Moving Cloud Coin is a native incentive token for community contributors. Security is maintained on the platform by the use of super network nodes. These network nodes can be controlled by organizations or individual users that are directly taking part in the ecosystem.

Moving Cloud Chain Blockchain Technology

Technical Advantages of Moving Cloud Chain Platform

1. Technical Architecture
Moving Cloud Chain is developed totally under Node.js, an open-sourced and cross-platform JavaScript runt-time environment that executes JavaScript code outside a browser. The back end uses Express.js and front end uses Angular.js with application client structured under Electron framework and Database under SQLite. Applications in both front end and back end are programmed by using Javascript language and the interface programmed HTML5 and CSS3.Node.js. This architecture provides Moving Cloud Chain the advantages in asynchronous processing mechanism and the best suit for digital asset applications interaction in real time. And of course it finally enables Moving Cloud Chain platform the technical guarantee for instant messaging of high-performance.
2. Sidechain Technology
Since the bitcoin network system is limited to only several standard transaction due to the scalability problem, Moving Cloud Chain uses side chain under Ethereum system that supports not only transfer, but also some other smart contract application like in multi-signature, underlying security and lottery.
By using sidechain mechanism, all chains have separate distributed network nodes and independent users, investors and developers. This solves the problems of blocking among chains and also provides a separate set of hedger with customized consensus mechanism, blockchain parameters as well as transaction types.
Besides the separate chain network nodes, developers can also customize a decentralized DApp under Moving Cloud Chain platform. The sidechain can be entrusted under node cluster and forms a sharding mechanism which alleviate chain jam and blocking. All chains would have respective DApp under sidechain whose code logic uses Node.js with back end & front end using Json rpc protocol to communicate.
3. Account
Under bitcoin and other derivative system network, there is no any account for users to storage balance which is achieved via transaction status alteration within network. Moving Cloud Chain is not merely a currency system but also an application platform for varies DApps. And account is comparably a better choice for quicker and lower cost of transaction. All accounts in Moving Cloud Coin consist of a command, public and private key and an address where users can set secondary password. For better mnemonic processing, we provide 128 bit entropy with 12 words. Users themselves keep the commands which cannot found once lost.
4. Relational Database
Currently most blockchain system use some relatively simple irrational database like berkey db, leveldb for data storage which provides some simple data structure such as btree, hashtable, and queue. Although these structures can be processed for digital currency system, it’s far from enough for application platforms especially in fields of finance, banking and e-commerce. There are some advantages on relational database that Moving Cloud Chain is using:
  • Transaction processing
  • Low cost to updating database
  • Support some complex join query
Moving Cloud Chain choose sqlite, a lightweight embedded relational databases with 2T capacity. Within these database, all data information file can be freely shared among nodes that provides great convenience to DApp development.
5. Consensus Mechanism
Moving Cloud Chain use DPOS (Delegated Proof of Stake) consensus algorithm and client election system. Under Moving Cloud System, an effective and practical Byzantine fault-tolerant algorithm greatly reducing the possibility of network branching. No danger of double spending will come out if the total number of evil nodes for hard fork is under one third.
6. Sandbox mechanism
Moving Cloud Chain use VM module under Node.js environment to ensure sandbox mechanism. The VM module is the encapsulation of V8 engine that can process javascript code directly.
However since VM module alone doesn’t support systematic api from nodes like system file and network transmission, it’s really difficult to import data from third party without Require function and even impossible for modularization development. To solve this problem, browerify technology is required so as to pack all frequently-used third-party data in a js file and run DApp project under Moving Cloud Chain system smoothly. As for some system level api needing update, Moving Cloud Chain provides sidechain for interprocess communication to ensure security and function.

Case: Moving Cloud Chain Application

The Moving Cloud Chain is also an application in sports and intelligent fields under Moving Cloud Chain platform. In this application system, the service includes index & verify sports data and wallet service. POE consensus is proof of effort that collects and verifies data based on the sports & exercise from each user. The more participants exercise, the more contributions they make. Our native token asset-Moving Cloud Coin Token (MCC) functions as an incentive mechanism based on POE Mining consensus for network node contributors who facilitate our ecosystem operation. In this case, every single person who uses Moving Cloud products and DApp is doing POE Mining.

Moving Cloud Chain Case Application

Contact Us

【Website】https://www.mcsports.cn/
【Whitepaper】https://www.mcsports.cn/mcblock/
【facebook】https://www.facebook.com/Moving-Cloud-Chain-1973623086244715/
【twitter】https://twitter.com/McsportsM
【LinkedIn】https://www.linkedin.com/company/moving-cloud-chain-mcc/
【Medium】https://medium.com/@McsportsM
【Telegram】https://t.me/movingcloudtech
【Github】https://github.com/MovingCloudChain
submitted by McsportsM to MovingCloudChain_MCC [link] [comments]

Arionum Roadmap Update

Development of the Arionum platform is alive and well. The Arionum developers are hard at work making this PHP blockchain platform the best possible solution for those looking for a easily implementable and stable, reliable blockchain ecosystem written entirely from scratch in PHP.
With that said I would like to address the current state of Arionum with an end of March Roadmap Update. You can find copies of the Roadmap on the official Arionum Discord and the Bitcointalk ANN post (links below). Let's take a look at where we stand today:
  1. Creation of the Blockchain Explorer - COMPLETE
The Arionum Blockchain Explorer provides the ability to view the current status of the Blockchain, difficulty, current block, transactions, wallet balances, and other Blockchain statistics.
It is operational and can be found here
  1. Launch of an Arionum Mining pool -COMPLETE
A mining pool allows for a group of individual miners to combine their efforts and spread the block reward amongst the group.
There are currently 2 official Arionum pools; the original Arionum mining pool, aropool.com, and aro.cool the pool dedicated to optimising the block reward for small miners.
The code for the Arionum mining pool has also been released. There are two active community built pools, aro.hashe.rs, and arionum.rocks
  1. Creation of a Windows PHP bundle - COMPLETE
This bundle was created to bundle a command line wallet and functional PHP Miner into a package that could be easily installed on a Windows machine. It can be downloaded here
  1. Windows GUI Wallet - COMPLETE
The GUI wallet allows for the storage and transfer of ARO coins utilizing an easy to use graphical interface. It can be downloaded here
The GUI wallet has been continuously updated and even includes a no hassle, integrated mining client that can be launched in seconds.
  1. Release of full API - COMPLETE
The API allows for easy integration of Arionum blockchain information into other applications or tools
The API documentation can be found here
  1. Blockchain based Raffle -COMPLETE
This is a trustless raffle built on the Arionum blockchain. Users can enter the raffle by sending ARO to the raffle address. Once a week three winners are randomly chosen by the application to receive ARO based on the number of entries. You can enter here
  1. Development of Bitcoin-like JSON-RPC API - IN PROGRESS
This API will allow Arionum to be more easily implemented on exchanges in the future. The Arionum Devs are currently hard at work developing this API to improve the process to be listed on a Cryptocurrency exchange.
  1. Linux GUI Wallet - FUTURE TASK
This will be a GUI wallet similar to the Windows version.
  1. Mac OS GUI Wallet - FUTURE TASK
This will be a GUI wallet similar to the Windows version.
  1. Android Wallet - FUTURE TASK
An Arionum wallet build for the Android mobile OS.
  1. iOS Wallet - FUTURE TASK
An Arionum wallet built for the Apple iOS mobile OS.
  1. Assets System - FUTURE TASK
The Arionum Assets System will allow developers to utilize the Arionum blockchain in their own applications without the necessity of coding smart contracts or creating a new blockchain.
  1. Alias System - FUTURE TASK
The Alias System will allow individuals to assign a name or alias to their wallet address. For example a user could name their wallet “ArionumRules” and use that alias instead of the wallet address.
  1. Payment Processor - FUTURE TASK
The Arionum Payment Processor will allow for the Arionum to be easily accepted by merchants as a form of payment.
  1. Add to Exchanges - FUTURE TASK
The listing of Arionum on exchanges will allow for greater accessibility of ARO coins and create more awareness of Arionum.
The Devs are currently in contact with exchanges discussing the possibility of listing.
  1. Directory of Sites Accepting ARO - FUTURE TASK
This will be a continually updated list of all merchants accepting ARO as a form of payment.
Stay tuned for more info!
submitted by clshipp91 to Arionum [link] [comments]

Bitcoin JSON-RPC Tutorial 5 - Your First Calls - YouTube How to give your bitcoin node commands using a web server Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - YouTube Bitcoin JSON-RPC Tutorial 2 - VPS Setup 9. bitcoind

Bitcoin Cash Node documentation JSON-RPC commands list Initializing search GitLab Bitcoin Cash Node documentation GitLab Home Setup instructions Release notes Release notes Release Notes for Bitcoin Cash Node version 22.1.0 Release Notes for Bitcoin Cash Node version 22.0.0 Release notes 0.21.2 ... JSON-RPC. Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a HTTP JSON-RPC server, but Basic access authentication must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you ... # JSON-RPC options (for controlling a running Bitcoin/bitcoind process) # server=1 tells Bitcoin-QT to accept JSON-RPC commands. server=1. Also, when in doubt run bitcoind in one cmd window and bring up a second one. Recurse in to the directory containing bitcoind (inside that second cmd window). Then try to run a simple command (try bitcoind ... Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a HTTP JSON-RPC server, but Basic access authentication must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use 'jsonrpc'. JSON RPC API Bitcoind compatible RPC api. My Wallet users can interact with their wallet using our JSON RPC api. It is intended to be fully compatible with the original Bitcoind RPC protocol however some method calls are not supported. No Blockchain Download - Save on bandwidth and disk space. No Need to run Bitcoind - Some VPS and shared hosting plans do not allow you to run custom processes ...

[index] [51207] [35468] [42390] [15616] [6851] [42687] [21252] [9457] [14121] [27115]

Bitcoin JSON-RPC Tutorial 5 - Your First Calls - YouTube

Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - Duration: 8:10. ... Bitcoin from the Command Line - Sending Bitcoin Transactions Programmatically with Javascript - Duration: 17:07. Decypher Media ... In this video I revisit an old topic where several things have changed since 2015 in regards to using the JSON-RPC to communicate with your node with an apache server with PHP. https://www.amazon ... Bitcoin JSON-RPC tutorial. Making your first bitcoin JSON-RPC calls in PHP. My Book: https://www.amazon.com/Building-Bitcoin-Websites-Beginners-Development/d... Bitcoin JSON-RPC tutorial. How to set up bitcoind on a VPS. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U Bitcoin JSON-RPC Tutorial 2 - VPS Setup - Duration: 6:28. m1xolyd1an 14,440 views. 6:28. Steve Jobs introduces iPhone in 2007 - Duration: 10:20. John Schroter Recommended for you. 10:20 . The ...

#