php - JSON-RPC call to bitcoind error, 403 failed to open ...

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]

How can I get this script to work for Litecoin 0.8.7.5?

What would I need to do to get this script to work for Litecoin 0.8.7.5? https://github.com/litecoin-project/litecoin/releases/tag/v0.8.7.5
 class Bitcoin { // Configuration options private $username; private $password; private $proto; private $host; private $port; private $url; private $CACertificate; // Information and debugging public $status; public $error; public $raw_response; public $response; private $id = 0; /** * @param string $username * @param string $password * @param string $host * @param int $port * @param string $proto * @param string $url */ function __construct($username, $password, $host = 'localhost', $port = 8332, $url = null) { $this->username = $username; $this->password = $password; $this->host = $host; $this->port = $port; $this->url = $url; // Set some defaults $this->proto = $host == 'localhost' ? 'http':'https'; $this->CACertificate = null; } /** * @param string|null $certificate */ function setSSL($certificate = null) { $this->proto = 'https'; // force HTTPS $this->CACertificate = $certificate; } function __call($method, $params) { $this->status = null; $this->error = null; $this->raw_response = null; $this->response = null; // If no parameters are passed, this will be an empty array $params = array_values($params); // The ID should be unique for each call $this->id++; // Build the request, it's ok that params might have any empty array $request = json_encode(array( 'method' => $method, 'params' => $params, 'id' => $this->id )); // Build the cURL session $curl = curl_init("{$this->proto}://{$this->username}:{$this->password}@{$this->host}:{$this->port}/{$this->url}"); $options = array( CURLOPT_RETURNTRANSFER => TRUE, CURLOPT_FOLLOWLOCATION => TRUE, CURLOPT_MAXREDIRS => 10, CURLOPT_HTTPHEADER => array('Content-type: application/json'), CURLOPT_POST => TRUE, CURLOPT_POSTFIELDS => $request ); if ($this->proto == 'https') { // If the CA Certificate was specified we change CURL to look for it if ($this->CACertificate != null) { $options[CURLOPT_CAINFO] = $this->CACertificate; $options[CURLOPT_CAPATH] = DIRNAME($this->CACertificate); } else { // If not we need to assume the SSL cannot be verified so we set this flag to FALSE to allow the connection $options[CURLOPT_SSL_VERIFYPEER] = FALSE; } } curl_setopt_array($curl, $options); // Execute the request and decode to an array $this->raw_response = curl_exec($curl); $this->response = json_decode($this->raw_response, TRUE); //error_log('this->response: '. print_r($this->response,true)); // If the status is not 200, something is wrong $this->status = curl_getinfo($curl, CURLINFO_HTTP_CODE); // If there was no error, this will be an empty string $curl_error = curl_error($curl); curl_close($curl); if (!empty($curl_error)) { $this->error = $curl_error; } if ($this->response['error']) { // If bitcoind returned an error, put that in $this->error $this->error = $this->response['error']['message']; } elseif ($this->status != 200) { // If bitcoind didn't return a nice error message, we need to make our own switch ($this->status) { case 400: $this->error = 'HTTP_BAD_REQUEST'; break; case 401: $this->error = 'HTTP_UNAUTHORIZED'; break; case 403: $this->error = 'HTTP_FORBIDDEN'; break; case 404: $this->error = 'HTTP_NOT_FOUND'; break; } } if ($this->error) { return FALSE; } return $this->response['result']; } } /* Address History Interface Class */ class AddressHistory { public $address = null; public $n_tx = 0; public $total_sent = 0; public $total_received = 0; public $balance = 0; public $final_balance = 0; public $txns = array(); public function __construct($txn=null) { if(! is_array($txn)) return null; if(array_key_exists('address', $txn)) $this->address = $txn['address']; if(array_key_exists('n_tx', $txn)) $this->n_tx = $txn['n_tx']; if(array_key_exists('total_sent', $txn)) $this->total_sent = $txn['total_sent']; if(array_key_exists('total_received', $txn))$this->total_received = $txn['total_received']; if(array_key_exists('balance', $txn)) $this->balance = $txn['balance']; if(array_key_exists('final_balance', $txn)) $this->final_balance = $txn['final_balance']; if(is_array($txn['txns'])) { foreach($txn['txns'] as $key => $this_txn) { $new_txn = array( 'hash' => $this_txn['hash'], 'block_height' => $this_txn['block_height'], 'value' => $this_txn['value'], 'spent' => $this_txn['spent'], 'spent_by' => $this_txn['spent_by'], 'confirmations'=> $this_txn['confirmations'] ); $this->txns[$key] = new TransRef($new_txn); } } else { $this->txns = null; } return $this; } } /* Transaction Reference Interface Class */ class TransRef { public $hash; public $block_height; public $value; public $spent; public $spent_by; public $confirmations; public function __construct($txnref=null) { if(! is_array($txnref)) return null; if(array_key_exists('hash', $txnref)) $this->hash = $txnref['hash']; if(array_key_exists('block_height', $txnref)) $this->block_height = $txnref['block_height']; if(array_key_exists('value', $txnref)) $this->value = $txnref['value']; if(array_key_exists('spent', $txnref)) $this->spent = $txnref['spent']; if(array_key_exists('spent_by', $txnref)) $this->spent_by = $txnref['spent_by']; if(array_key_exists('confirmations', $txnref)) $this->confirmations = $txnref['confirmations']; return $this; } } /* CoindRPC - JsonRPC Class to talk to bitcoind */ class CoindRPC extends Bitcoin { public function __construct() { return parent::__construct(WN_RPC_USER, WN_RPC_PASS, WN_RPC_HOST, WN_RPC_PORT); } public function __call($method, $params) { return parent::__call($method, $params); } public function get_address_balance($address, $confirmations=0) { try { $address_info = $this->validateaddress($address); if($address_info['isvalid'] == 1 && $address_info['ismine'] == 1) { $balance = $this->getreceivedbyaddress($address, $confirmations); } if($balance != '') { return floatval($balance); } else { return 0; } } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } public function get_address_history($address) { try { $address_info = $this->validateaddress($address); if($address_info['isvalid'] == 1 && $address_info['ismine'] == 1) { //- if only listening to one BTC account //$history = $this->listtransactions(WN_RPC_ACCT); $history = $this->listtransactions(); $txns = array(); $final_balance = $balance = 0; foreach($history as $txn) { if($txn['address'] != $address) continue; $n_tx = $total_received = $total_sent = 0; $n_tx = intval($addr_hist['n_tx']) + 1; switch($txn['category']) { case('receive'): $total_received = $addr_hist['total_received'] += $txn['amount']; $balance = $balance + $txn['amount']; //- can we trust final balance here? do we need more history $final_balance = $final_balance + $txn['amount']; break; case('send'): $total_sent = $addr_hist['total_sent'] += $txn['amount']; $balance = $balance + $txn['amount']; //- can we trust final balance here? do we need more history $final_balance = $final_balance + $txn['amount']; break; } $txns[] = array( 'hash' => $txn['txid'], 'value' => $txn['amount'], 'spent' => $txn['spent'], 'spent_by' => $txn['spent_by'], 'confirmations' => $txn['confirmations'], ); } $addr_hist = array( 'address' => $address, 'n_tx' => $n_tx, 'total_sent' => $total_sent, 'total_received' => $total_received, 'balance' => $balance, 'final_balance' => $final_balance, 'txns' => $txns ); $addr_hist = new AddressHistory($addr_hist); } else { $addr_hist = false; error_log('Address invalid: '.$address); error_log('['.__LINE__.'] : '.__FILE__); } return $addr_hist; } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } public function get_transaction($hash) { try { return $this->gettransaction($hash); } catch (Exception $e) { error_log('error: '. print_r($e->getMessage(),true)); error_log('['.__LINE__.'] : '.__FILE__); } } } /* Helper class */ class Helper { public static $api = null; public static $db = null; public function __construct($db, $api) { Helper::$api = $api; Helper::$db = $db; } public static function walletnotify_email($txnhead) { //- bitcoind calls walletnotify on 0 confirmations and 1. //- We only want email to go out on the first call. Otherwise //- if we want only one 1 confrime, change this to //- confirmations == 0) return; if($txnhead['confirmations'] > 0) return; $tmpl = file_get_contents('email.notify.tmpl.html'); foreach($txnhead as $key => $val) { $map['{'.$key.'}'] = $val; } $map['{timestamp}'] = date('Y-m-d H:i:s', WN_GLOBAL_TIMESTAMP); $map['{hostname}'] = php_uname('n'); $html = str_replace(array_keys($map), array_values($map), $tmpl); $txid_short = substr($txnhead['txid'], 0, 4).' .. '.substr($txnhead['txid'], -4); $msg = "=WNotify=". "\ntxid: ".$txid_short. "\nAmt : ".$txnhead['amount']. "\nCmnt: ".$txnhead['comment']. "\nAcct: ".$txnhead['account']. "\nConf: ".$txnhead['confirmations']. "\nCat : ".$txnhead['category']. "\nAddr: ".$txnhead['address']. ""; //- send to carrier's email to SMS gateway if configured if(defined('WN_SMS_ADMIN') && filter_var(WN_SMS_ADMIN, FILTER_VALIDATE_EMAIL)) { Helper::send_email_sms($msg, WN_SMS_ADMIN); } return Helper::send_email($html, 'WN:WalletNotify', WN_EMAIL_ADMIN);; } public static function send_email($msg, $subj, $to) { $headers = 'From: '.WN_EMAIL_FROM."\r\n"; $headers .= "MIME-Version: 1.0\r\n"; $headers .= "Content-Type: text/html; charset=ISO-8859-1\r\n"; if(trim($msg) == '') return false; return mail($to, $subj, $msg, $headers); } public static function send_email_sms($msg, $to) { if(trim($msg) == '') return false; if($to == '') return false; $headers = 'From: '.WN_EMAIL_FROM."\r\n"; return mail($to, null, $msg."\n.", $headers); } } 
submitted by Mjjjokes to cryptodevs [link] [comments]

Looking for a bitcoin core RPC wallet GUI/manager

So I installed bitcoin core running on an ububtu server and got it caught up, and would like to connect to it and send/receive coin from its wallet. I understand that I could manage it with bitcoin-cli, but I am lazy and like to point and click.
Ideally: its a multi-os program that accepts RPC connection info and then manages features of the bitcoin core (bitcoind).
Bonus points: its a php scripts I can setup since I love web admin interfaces.
Side question: can I set up bitcoin-qt to manage a bitcoind instance over the network by RPC? This would also solve my original question.
Thanks
submitted by zmach1n3 to Bitcoin [link] [comments]

How can I sign a message with a Litecoin address using PHP?

I am looking for something similar to https://github.com/BitcoinPHP/BitcoinECDSA.php/blob/mastesrc/BitcoinPHP/BitcoinECDSA/BitcoinECDSA.php, i.e. doing it independently on a PHP server without any need to make a JSON-RPC call.
submitted by ramboKick to litecoin [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]

Blocknet FAQ

Community-Produced FAQ document
What Is Blocknet?
The Blocknet is a general-purpose infrastructure for inter-blockchain services. It is designed to enable the emerging “token ecosystem.” The first product build on this infrastructure is a decentralized exchange.
What Does It Do?
The Blocknet enables inter-blockchain services, like decentralized exchange, monetised API consumption, and p2p digital service delivery. These are core enabling features of inter-chain dapps.
How Does It Work?
To support inter-blockchain services, the Blocknet has three core components, which work together to provide three core services.
The core components are:
The core services are:
What Is a Decentralized Exchange?
A decentralized exchange is a service enabling counterparties (which may be people or machines) to exchange one currency or token for another, without the involvement of any third party as an intermediary.
The term “decentralized” denotes matters of control rather than the distribution of processing; the ideal of a decentralized solution is for the parties to a given interaction to be self-sovereign actors, in the sense that no third party is required to act on their behalf in order for the interaction to take place.
How Does a Decentralized Exchange Work?
Exchanges have four core functions:
Hence, in order to be a decentralized exchange, each of these core functions must be decentralized.
The Blocknet decentralizes them in the following ways:
Why Is a Decentralized Exchange a Key Enabler Of the Token Ecosystem?
Decentralized exchange makes blockchain services intrinsically monetizable, removing the friction and high costs of traditional payment networks that have prevented the monetisation of the bulk of the API ecosystem.
Due to the decentralized exchange, consumers of a service may pay in their native token even if the service consumes a different token. In a world in which (a) there are already thousands of blockchains, and (b) blockchains bloat inexorably, and so it is advisable not to support many services per blockchain, monetising inter-chain services is both an operational necessity and an ecosystem-enabling service.
What Coins Does the Decentralized Exchange Support?
The Blocknet was designed to maximise interoperability, and so most blockchain tokens may be integrated with no coding required.
The current integration requirements are:
As a result, the Blocknet supports the majority of cryptocurrencies in existence, and no permission from anyone is required for these to be traded on the exchange.
The current list is:
BAY BTC BLK BLOCK DASH DGB DOGE DYN PIVX LTC MUE NMC SYS VTC VIA BRK BRX ETH NLG QTUM DCR POT PPC XVG MONA FAIR NAV
How Fast Is the Decentralized Exchange?
Instant.
However, note that once you have completed a trade and received coins, you will be dependent on their blockchain’s accepted confirmation time before your coins will be spendable again.
Note: A future enhancement to the decentralized exchange may include a filter on the order book to enable traders to trade coins with less than the number of confirmations conventionally agreed upon as “safe.” This incurs a degree of risk for the benefit of supporting trading styles that require rapidly entering and exiting a position, such as scalping.
How Private Is the Decentralized Exchanged?
Because decentralized exchanges do not require traders to submit KYC information or divulge anything else about themselves to a third party, traders enjoy a naturally high degree of privacy.
However, for most wallets, aspects of transactions are linkable to IP addresses, so in order to obfuscate that, one might use TOR or I2P. The Blocknet’s DHT network overlay does not use IP addresses, however.
Combined with any privacy-centric coin, a decentralized exchange run over IP-obfuscating tech is a near-perfect mixing solution. For example, one may trade some coins for Zcash, sends them to a different address, and then trade back again.
What Are the Possible Applications Of the xBridge Protocol Other Than a Decentralized Exchange?
The Blocknet is designed as infrastructure for the emerging token ecosystem. Any service or orchestrated sequence of microservices provided by dapps may be delivered over the Blocknet's infrastructure.
Using decentralized exchange, these services are intrinsically monetizable, removing the friction and high costs of traditional payment networks - friction which has prevented the monetisation of the bulk of the API ecosystem.
Due to the decentralized exchange, consumers of a service may pay in their native token even if the service consumes a different token.
What Are the Benefits Of Running a Node? How Many Blocks Do I Need To Run One?
There are two types of node: a "service node" and a “trader node”. Service nodes do not handle or control any trader's coins. Their function is to collect and distribute trade fees. Typically a service node operator will run multiple full node wallets of whichever coins (s)he wants to support, in order to garner as many trade fees as possible. Trader nodes enable one to trade on the decentralized exchange.The amount of BLOCK currently needed to run a service node is 5,000 BLOCK. To use the exchange you will not need any BLOCK.
Will There Be Fees For Buying/Trading On the Blocknet Exchange?
Yes, there are fees, though they are significantly lower that centralised exchanges.
The fee structure is as follows:
Will A User Need BLOCK To Participate On An Exchange?
No, to use the exchange you will NOT need any BLOCK. Only the service node operators will need BLOCK in order to collect and distribute trade fees. Additionally, the service nodes do not handle or control and trader’s coins. The sole purpose of the service node is to only collect and distribute trade fees.
Staking
Staking and fees on the Blocknet are bundled together in a 70/30 split between nodes and stakers. This is a combination of POS staking and network trading fees. Staking is estimated to be between 9% - 14% in the first year. Nodes will receive 70% and stakers will receive 30%. This means that if you do not have enough Block to run a node, you will STILL get part of the node fees, and if you run a node, you will also get part of the stakes as well. Your wallet must be unlocked to actively stake and receive rewards. There will be 525,600 new blocks created annually (at 1 block per minute) with decreasing inflation each subsequent year.
Block Specs
Core Team
Set up guides
Links
submitted by Blocknet to theblocknet [link] [comments]

Echoes of the Past: Recovering Blockchain Metrics From Merged Mining

Cryptology ePrint Archive: Report 2018/1134
Date: 2018-11-22
Author(s): Nicholas Stifter, Philipp Schindler, Aljosha Judmayer, Alexei Zamyatin, Andreas Kern, Edgar Weippl

Link to Paper


Abstract
So far, the topic of merged mining has mainly been considered in a security context, covering issues such as mining power centralization or crosschain attack scenarios. In this work we show that key information for determining blockchain metrics such as the fork rate can be recovered through data extracted from merge mined cryptocurrencies. Specifically, we reconstruct a long-ranging view of forks and stale blocks in Bitcoin from its merge mined child chains, and compare our results to previous findings that were derived from live measurements. Thereby, we show that live monitoring alone is not sufficient to capture a large majority of these events, as we are able to identify a non-negligible portion of stale blocks that were previously unaccounted for. Their authenticity is ensured by cryptographic evidence regarding both, their position in the respective blockchain, as well as the Proof-of-Work difficulty.
Furthermore, by applying this new technique to Litecoin and its child cryptocur rencies, we are able to provide the first extensive view and lower bound on the stale block and fork rate in the Litecoin network. Finally, we outline that a recovery of other important metrics and blockchain characteristics through merged mining may also be possible.

References
  1. C. Decker and R. Wattenhofer, “Information propagation in the bitcoin network,” in Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on. IEEE, 2013, pp. 1–10. [Online]. Available: http://diyhpl.us/∼bryan/papers2/bitcoin/Information% 20propagation%20in%20the%20Bitcoin%20network.pdf
  2. A. Gervais, G. O. Karame, K. Wust, V. Glykantzis, H. Ritzdo rf, and S. Capkun, “On the ¨ security and performance of proof of work blockchains,” in Proceedings of the 2016 ACM SIGSAC. ACM, 2016, pp. 3–16.
  3. A. E. Gencer, S. Basu, I. Eyal, R. van Renesse, and E. G. Sirer, “Decentralization in bitcoin and ethereum networks,” in Proceedings of the 22nd International Conference on Financial Cryptography and Data Security (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/preproceedings/75.pdf
  4. I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is vulnerable,” in Financial Cryptography and Data Security. Springer, 2014, pp. 436–454. [Online]. Available: http://arxiv.org/pdf/1311.0243
  5. K. Nayak, S. Kumar, A. Miller, and E. Shi, “Stubborn mining: Generalizing selfish mining and combining with an eclipse attack,” in 1st IEEE European Symposium on Security and Privacy, 2016. IEEE, 2016. [Online]. Available: http://eprint.iacr.org/2015/796.pdf
  6. A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish mining strategies in bitcoin,” http://arxiv.org/pdf/1507.06183.pdf, 2015, accessed: 2016-08-22. [Online]. Available: http://arxiv.org/pdf/1507.06183.pdf
  7. J. Bonneau, “Why buy when you can rent? bribery attacks on bitcoin consensus,” in BITCOIN ’16: Proceedings of the 3rd Workshop on Bitcoin and Blockchain Research, February 2016. [Online]. Available: http://fc16.ifca.ai/bitcoin/papers/Bon16b.pdf
  8. K. Liao and J. Katz, “Incentivizing blockchain forks via whale transactions,” in International Conference on Financial Cryptography and Data Security. Springer, 2017, pp. 264–279. [Online]. Available: http://www.cs.umd.edu/∼jkatz/papers/whale-txs.pdf
  9. P. McCorry, A. Hicks, and S. Meiklejohn, “Smart contracts for bribing miners,” in 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final14.pdf
  10. A. Zamyatin, N. Stifter, A. Judmayer, P. Schindler, E. Weippl, and W. J. Knottebelt, “(Short Paper) A Wild Velvet Fork Appears! Inclusive Blockchain Protocol Changes in Practice,” in 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018. [Online]. Available: https://eprint.iacr.org/2018/087.pdf
  11. Blockchain.com, “Blockchain.com orphaned blocks,” https://www.blockchain.com/btc/orphaned-blocks, Blockchain.com, accessed: 2018-09-25.
  12. BitcoinChain.com, “Bitcoinchain bitcoin block explorer,” https://bitcoinchain.com/blockexplorer, BitcoinChain.com, accessed: 2018-09-25.
  13. ChainQuery.com, “A web based interface to the bitcoin api json-rpc,” http://chainquery.com/bitcoin-api, ChainQuery.com, accessed: 2018-09-25.
  14. L. Project, “Litecoin,” https://litecoin.org/, accessed: 2016-03-29.
  15. Y. Sompolinsky and A. Zohar, “Accelerating bitcoin’s transaction processing. fast money grows on trees, not chains,” p. 881, 2013. [Online]. Available: http://eprint.iacr.org/2013/881.pdf
  16. A. Miller and L. JJ, “Anonymous byzantine consensus from moderately-hard puzzles: A model for bitcoin,” https://socrates1024.s3.amazonaws.com/consensus.pdf, 2014, accessed: 2016-03-09. [Online]. Available: https://socrates1024.s3.amazonaws.com/consensus.pdf
  17. J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone protocol: Analysis and applications,” in Advances in Cryptology-EUROCRYPT 2015. Springer, 2015, pp. 281–310. [Online]. Available: http://courses.cs.washington.edu/courses/cse454/15wi/papers/bitcoin765.pdf
  18. R. Pass and E. Shi, “Fruitchains: A fair blockchain,” http://eprint.iacr.org/2016/916.pdf, 2016, accessed: 2016-11-08. [Online]. Available: http://eprint.iacr.org/2016/916.pdf
  19. R. Pass, L. Seeman, and a. shelat, “Analysis of the blockchain protocol in asynchronous networks,” http://eprint.iacr.org/2016/454.pdf, 2016, accessed: 2016-08-01. [Online]. Available: http://eprint.iacr.org/2016/454.pdf
  20. K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, and E. Gun, “On scaling decentralized blockchains,” in ¨ 3rd Workshop on Bitcoin and Blockchain Research, Financial Cryptography 16, 2016. [Online]. Available: http://www.tik.ee.ethz.ch/file/74bc987e6ab4a8478c04950616612f69/main.pdf
  21. A. Kiayias and G. Panagiotakos, “On trees, chains and fast transactions in the blockchain.” http://eprint.iacr.org/2016/545.pdf, 2016, accessed: 2017-02-06. [Online]. Available: http://eprint.iacr.org/2016/545.pdf
  22. Y. Sompolinsky, Y. Lewenberg, and A. Zohar, “Spectre: A fast and scalable cryptocurrency protocol,” Cryptology ePrint Archive, Report 2016/1159, 2016, accessed: 2017-02-20. [Online]. Available: http://eprint.iacr.org/2016/1159.pdf
  23. Y. Sompolinsky and A. Zohar, “Phantom: A scalable blockdag protocol,” Cryptology ePrint Archive, Report 2018/104, 2018, accessed:2018-01-31. [Online]. Available: https://eprint.iacr.org/2018/104.pdf
  24. Bitcoin community, “Bitcoin-core source code,” https://github.com/bitcoin/bitcoin, accessed: 2018-09-25.
  25. A. Miller, J. Litton, A. Pachulski, N. Gupta, D. Levin, N. Spring, and B. Bhattacharjee, “Discovering bitcoin’s public topology and influential nodes,” http://cs.umd.edu/projects/coinscope/coinscope.pdf, May 2015, accsessed: 2016-03-09. [Online]. Available: http://cs.umd.edu/projects/coinscope/coinscope.pdf
  26. chainz.cryptoid.info/, “Chainz blockchain explorers,” chainz.cryptoid.info/, chainz.cryptoid.info/, accessed: 2018-09-25.
  27. Narayanan, Arvind and Bonneau, Joseph and Felten, Edward and Miller, Andrew and Goldfeder, Steven, “Bitcoin and cryptocurrency technologies,” http://bitcoinbook.cs.princeton.edu/, 2016, accessed: 2016-03-29. [Online]. Available: https://d28rh4a8wq0iu5.cloudfront.net/bitcointech/readings/princeton bitcoin book.pdf
  28. A. Judmayer, A. Zamyatin, N. Stifter, A. G. Voyiatzis, and E. Weippl, “Merged mining: Curse or cure?” in CBT’17: Proceedings of the International Workshop on Cryptocurrencies and Blockchain Technology, Sep 2017. [Online]. Available: https://eprint.iacr.org/2017/791.pdf
  29. M. Jakobsson and A. Juels, “Proofs of work and bread pudding protocols,” in Secure Information Networks. Springer, 1999, pp. 258–272. [Online]. Available: https://link.springer.com/content/pdf/10.1007/978-0-387-35568-9 18.pdf
  30. A. Judmayer, N. Stifter, K. Krombholz, and E. Weippl, “Blocks and chains: Introduction to bitcoin, cryptocurrencies, and their consensus mechanisms,” Synthesis Lectures on Information Security, Privacy, and Trust, 2017.
  31. A. Kiayias, A. Miller, and D. Zindros, “Non-interactive proofs of proof-of-work,” Cryptology ePrint Archive, Report 2017/963, 2017, accessed:2017-10-03. [Online]. Available: https://eprint.iacr.org/2017/963.pdf
  32. Namecoin community, “Namecoin source code - chainparams.cpp,” https://github.com/namecoin/namecoin-core/blob/fdfb20fc263a72acc2a3c460b56b64245c1bedcb/src/chainparams.cpp#L123, accessed: 2018-09-25.
  33. ——, “Namecoin source code - auxpow.cpp,” https://github.com/namecoin/namecoincore/blob/fdfb20fc263a72acc2a3c460b56b64245c1bedcb/src/auxpow.cpp#L177-L200, accessed: 2018-09-25.
  34. I0Coin community, “I0coin source code,” https://github.com/domob1812/i0coin, accessed: 2018-09-25.
  35. S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https://bitcoin.org/bitcoin.pdf, Dec 2008, accessed: 2015-07-01. [Online]. Available: https://bitcoin.org/bitcoin.pdf
  36. N. T. Courtois and L. Bahack, “On subversive miner strategies and block withholding attack in bitcoin digital currency,” arXiv preprint arXiv:1402.1718, 2014, accessed: 2016-07-04. [Online]. Available: https://arxiv.org/pdf/1402.1718.pdf
  37. J. Gobel, P. Keeler, A. E. Krzesinski, and P. G. Taylor, “Bitcoin blockchain dynamics: the ¨ selfish-mine strategy in the presence of propagation delay,” http://arxiv.org/pdf/1505.05343.pdf, 2015, accessed: 2015-03-01. [Online]. Available: http://arxiv.org/pdf/1505.05343.pdf
  38. N. Developers, “Neo4j,” 2012.
  39. Gavin Andresen, “Bitcoin improvement proposal 34 (bip34): Block v2, height in coinbase,” https://github.com/bitcoin/bips/blob/mastebip-0034.mediawiki, accessed: 2018-09-25. [Online]. Available: https://github.com/bitcoin/bips/blob/mastebip-0034.mediawiki
  40. Matt Corello, “Fast internet bitcoin relay engine,” http://bitcoinfibre.org/, accessed: 2018-09-25. [Online]. Available: http://bitcoinfibre.org/
  41. Suhas Daftuar, “sendheaders message,” https://github.com/bitcoin/bips/wiki/Comments:BIP-0130, accessed: 2018-09-25. [Online]. Available: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130
  42. R. Bowden, H. P. Keeler, A. E. Krzesinski, and P. G. Taylor, “Block arrivals in the bitcoin blockchain,” 2018. [Online]. Available: https://arxiv.org/pdf/1801.07447.pdf
  43. GeistGeld community, “Geistgeld source code,” https://github.com/Lolcust/GeistGeld, accessed: 2018-09-25.
  44. A. P. Ozisik, G. Bissias, and B. Levine, “Estimation of miner hash rates and consensus on blockchains,” arXiv preprint arXiv:1707.00082, 2017, accessed:2017-09-25. [Online]. Available: https://arxiv.org/pdf/1707.00082.pdf
  45. E. Duffield and D. Diaz, “Dash: A payments-focused cryptocurrency,” https://github.com/dashpay/dash/wiki/Whitepaper, Aug 2013, accessed: 2018-09-25. [Online]. Available: https://github.com/dashpay/dash/wiki/Whitepaper
  46. N. Van Saberhagen, “Cryptonote v 2.0,” https://cryptonote.org/whitepaper.pdf, Oct 2013. [Online]. Available: https://cryptonote.org/whitepaper.pdf
  47. G. Hall, “Guide: Merge mining 6 scrypt coins at full hashpower, simultaneously,” https://www.ccn.com/guide-simultaneously-mining-5-scrypt-coins-full-hashpowe, Apr 2014, accessed: 2018-09-25. [Online]. Available: https://www.ccn.com/guide-simultaneouslymining-5-scrypt-coins-full-hashpowe
  48. united-scrypt coin, “[ann][usc] first merged minable scryptcoin unitedscryptcoin,” https://bitcointalk.org/index.php?topic=353688.0, Nov 2013, accessed: 2018-09-25. [Online]. Available: https://bitcointalk.org/index.php?topic=353688.0
  49. J. A. D. Donet, C. Perez-Sola, and J. Herrera-Joancomart ´ ´ı, “The bitcoin p2p network,” in Financial Cryptography and Data Security. Springer, 2014, pp. 87–102. [Online]. Available: http://fc14.ifca.ai/bitcoin/papers/bitcoin14 submission 3.pdf
  50. M. Bartoletti and L. Pompianu, “An analysis of bitcoin op return metadata,” https://arxiv.org/pdf/1702.01024.pdf, 2017, accessed: 2017-03-09. [Online]. Available: https://arxiv.org/pdf/1702.01024.pdf
  51. R. Matzutt, J. Hiller, M. Henze, J. H. Ziegeldorf, D. Mullmann, O. Hohlfeld, and K. Wehrle, ¨ “A quantitative analysis of the impact of arbitrary blockchain content on bitcoin,” in Proceedings of the 22nd International Conference on Financial Cryptography and Data Security (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/preproceedings/6.pdf
  52. M. Grundmann, T. Neudecker, and H. Hartenstein, “Exploiting transaction accumulation and double spends for topology inference in bitcoin,” in 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final10.pdf
  53. A. Judmayer, N. Stifter, P. Schindler, and E. Weippl, “Pitchforks in cryptocurrencies: Enforcing rule changes through offensive forking- and consensus techniques (short paper),” in CBT’18: Proceedings of the International Workshop on Cryptocurrencies and Blockchain Technology, Sep 2018. [Online]. Available: https://www.sba-research.org/wpcontent/uploads/2018/09/judmayer2018pitchfork 2018-09-05.pdf
submitted by dj-gutz to myrXiv [link] [comments]

How Ulbricht paid ฿100 to learn about `bitcoind -rescan`

I was revisiting Gwern and my research into the Silk Road / Mt. Gox connection, found something very interesting on the '1MR6pXD' address. Oh Ulbricht...
xpost from this post:
Long-time readers may recall that among Ulbricht's problems with developing & running Silk Road, he had problems with theft from his MtGox account: "Silk Goxed: How DPR used Mtgox for hedging & lost big". We identified his accounts and deposits as part of that investigation.
Based on our findings, imposter has found a previously unknown Ross Ulbricht account on the Bitcoin Talk forums, used for tech support with SR1 problems: the user account "kohlanta" (posts), registered 19 August 2012. The name is a reference to a tourist destination in Thailand; Ulbricht was living in Australia around this time and traveled some places, apparently including Ko Lanta. This account must be Ulbricht because (1) who has ฿40,000 in a single address in August 2015? (2) the amount matches up exactly with the big transactions noted in 'Silk Goxed', and kohlanta's address 1MR..Y is the one involved in the Ulbricht withdrawals/deposits. (When he told me about this, I felt dumb - why hadn't I bothered to google 1MR..Y during our 'Silk Goxed' work to see if it had appeared anywhere else online?)
kohlanta's first question concerns the inability to move ฿40,000; this problem was solved by bitcoind -rescan, as pointed out by BT user fcmatt. (You can see he did indeed pay the ฿100 by noting that the amounts shrink by exactly that much.)
We can also see the trial testimony independently confirmed by kohlanta's further questions: questions about using curl, json-rpc, and versioning issues with the wallet.
There's nothing really important here that I can see, but it's interesting to see him panicking over the 1MR..Y, and it's definitely a reminder that Bitcoin addresses are only pseudonymous; once pseudonymity has been broken or damaged, you can continue to follow transactions & addresses to see what you can find.
submitted by impost_r to Bitcoin [link] [comments]

BitWhite Photon

As you have been already heard, we are preparing important changes in the existing network architecture. Currently, the active work is under way to create a new update “BitWhite Photon”, you can follow the progress on Github: https://github.com/BTWhite/go-btw-photon
BitWhite Photon Throughout the development of the platform, we have encountered many difficulties related to JavaScript and the insufficiently good architecture embedded in the core of logic. We see a significant decrease in the speed of the network because of this, it does not suit us and we have to think more and more about how to improve the current situation.
BitWhite Photon as a revolutionary step to a truly bright future promises us a new protocol (Photon), which will combine dpos, pos, pow and dag. Photon does not talk only about the census of the current code in a new language, it talks about writing a new protocol. We want to create an infrastructure in which the processing of transactions will be handled only by those who really need it, thereby relieving delegates to a minimum. Despite all, we want to act honestly, so that delegates still pretend to be the managers of the network, we do not want to take away their reward and honor from them. In addition, delegates are the guarantee of decentralization of the project.
Why GO? It is difficult to find a language that would be both fast and simple enough for DAPP developers. Golang is the best option, because it runs tens of times faster than JavaScript and was developed by Google for its not very experienced programmers. Go is good not only with a rich set of built-in libraries, but also by imposing a single style and recommendations for good code, just read about gofmt.
Database In addition to slow JavaScript, we faced with the problem of SQLite (the database that is currently used). Despite the power of your server, this database still specializes in small sites or client bases with a small information flow. In our situation, even the update of information about the feasts of our delegates becomes a problem, and during a closed investigation we found that SQLite updated about 10 records per second during the network operation. It’s too slow, because sometimes we need to do it much faster. Therefore, we are looking towards a hybrid with two databases, one of them must be superfast, for example RocksDB or LevelDB, these low-level NoSQL databases run hundreds of times faster.
In any case, all this will allow creating an efficient and high-speed ecosystem in which a large number of programs can simultaneously work, a platform with which it will be comfortable for both developers and users.
Alpha release First alpha release of Photon Protocol has been already appeared on Github. This version is intended for developers, internal testing, but if you want you can download the archive and try the Protocol on your hardware.
Now it’s just a demonstration of the performance of the future system, the ability to send JSON-RPC requests and get the expected answers. However, this is a demonstration that Photon is already in working version.
The types of queries are described and examples of responses are provided as well, seehttps://github.com/BTWhite/go-btw-photon/blob/mastedocs/RPC-METHODS.md
If you find any issues, please describe them here:https://github.com/BTWhite/go-btw-photon/issues
t.me/WhiteBitcoin https://bitwhite.org/ #BitWhite #BTW
submitted by BitWhite to u/BitWhite [link] [comments]

ShapeShift and Changelly are scamming developers

They scam developers with their affiliate programs, ShapeShift - mostly just by their wild bureaucracy, Changelly was caught not paying their customers Affiliate Program. Well maybe ShapeShift too, because they can.
You take many days to study their API to write an app that probably could be useful for their own ecosystem.
The tiny thing they give in return - as a motivation - 0.25% reward.
But they look for every opportunity to not pay you.
My process of signing up with ShapeShift: (5 days between each customer support response, because their customer support is broken)
15 days ago - 1st wrote them. Filled the form to receive API key, API key was granted immediately, but they redirected to their portal to write their technical support to approve
10 days ago - they required to fill another form
5 days ago - they required to translate my app into English. What? My application is focused on a local market.
My experience with Changelly:
They find any reason to not pay you. For example - reason could be anything your application "is using different servers to access API", or "you have more web-site than 1"
Their API is very ugly and using JSON RPC 2.0 which is restricting PHP developers from intuitive coding. (Very inconvenient choice). Yes there are better security with JSON RPC, because you have to sign every request with JSON RPC - but its again - odd bureaucracy. HTTPS is strong enough for securing data between servers.
Okay, even if I spend hundreds of dollars on integrating JSON RPC into PHP. Main thing - Changelly isn't doing for security of their customers - Third Parties that develop apps with them - can't get Order ID: Which means that everyone who want can use their API to build customer base without providing a proof that their customers deal with Changelly - then replace Bitcoin-addresses - since customer will get used that no proof needed that you're dealing with their service (Usually I give my customers link where they can check if their Order ID was created with Changelly)
Moral of the story: Build your own independent services to compete with ShapeShift and Changelly - because these are big washing machines and pirates. Not legitimate companies at all.
submitted by blksz to Bitcoin [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]

Making a proof-of-concept blockchain explorer but I'm wondering how best to access the VPS-hosted node via JSON-RPC...

Hi, as the title pretty much says, I've spun up a VPS-hosted full node and have configured it for JSON-RPC access on localhost. I understand that I can ssh tunnel into that VPS instance and issue calls to it through that, but is that the best way to go about it?
The block explorer will be running on Ruby or PHP and hosted on a separate webhost... I should be able ssh into the node with either Ruby or PHP, but that just feels... dirty... Would it be most convenient to host the blockchain explorer website from the same machine, ie. just initiate the calls from localhost?
UPDATE: as per u/Indy997's suggestion, I've added my webhost's public IP to bitcoin.conf and we'll see if that's enough to get this ball rolling.
submitted by AltF to btc [link] [comments]

[ANN][Pre-ICO is LIVE] Bitcoin Crown - Cryptocurrency for online gaming.

BTCC INTRODUCTION
Bitcoin Crown is the digital trading token that will give game developers, content creators and gaming communities the required crypto-backed value and tools for implementing and managing virtual goods.
Token Sale Details
Token Name : BitCoin Crown Symbol : BTCC Soft Cap : $2,500,000 USD Hard Cap : $10,000,000 USD Price : 0.25 USD Accepted currency : ETH
Pre-ICO Stage #1
Start : 15/04/2018 End : 30/04/2018 For Sale : 6,300,000 BTCC Bonus : 40% Target : $1,575,000 USD
Pre-ICO Stage #2
Start : 01/05/2018 End : 14/05/2018 For Sale : 6,300,000 BTCC Bonus : 25% Target : $1,575,000 USD
ICO Crowdsale
Start : 15/05/2018 End : 31/05/2018 For Sale : 12,600,000 BTCC Bonus : 15% Target : $3,150,000 USD
Token Distribution
Total Supply : 70,000,000 BTCC
Only 70 Million BTCC tokens will ever be created. Among them 20 Million will be spend on Bounty Campaign.
The BTCC tokens are intended to be allocated as follows:
60% (30,000,000) to be sold by BTCC to Private Sale, Pre-ICO & Crowdsale purchasers.
20% (10,000,000) reserved by the Company to incentivize community, beta testers, marketing and strategic partners.
20% (10,000,000) to be distributed by the Company to the BTCC Coin Team and Advisors.
Funds Allocation
50% Development : This refers to the development and operational costs of all technology described in this whitepaper, including smart contracts, wallets, SDKs, APIs, game plugins, third party plugins, and any other BTCC Coin related updates. This will also cover hiring additional full-time developers and consultants to accelerate development so that we meet or exceed the roadmap goals and expansion goals.
30% Marketing & Growth : The marketing budget allows for a constant and relentless promotion of BTCC Coin to gamers in multiple target countries and gaming segments. This will be used for video and in-game advertising, promotional events & tournaments, sponsorships, mobile & social media ads, and liasoning with studios.
5% Security : We are taking the necessary steps to ensure that optimal security standards are followed in every release. This includes professional code audits and penetration testing on all APIs, smart contracts, Mobile and PC wallets, plugins and SDKs.
5% Legal : BTCC will obtain the appropriate legal advice to always ensure that we operate in accordance with the laws and regulations of each jurisdiction that we do business in. Funds will be held in reserve for any future issues or challenges that may arise in any region.
5% Hosting & Infrastructure : This will cover a minimum of 5 years of increased costs required for expansion of the web servers, firewalls, load balancers, DDOS protection and network for anticipated increases in Traffic to the web platform and public JSON-RPC API.
5% Contingency : This amount will be set aside for unforeseen costs.
Official links :
Website => http://www.bitcoincrowncoin.com/ White Paper => http://www.bitcoincrowncoin.com/legal/white%20paper.pdf Bounty => https://bitcointalk.org/index.php?topic=3321329 Twitter => https://twitter.com/BtcCrown Telegram => https://t.me/bitcoincrown Facebook => https://www.facebook.com/BitCoinCrownofficial Reddit => https://www.reddit.com/useBTCcrown/ Medium => https://medium.com/@BitcoinCrown Youtube => https://youtu.be/bSEcoMo9-90
submitted by BTCcrown to u/BTCcrown [link] [comments]

How Ulbricht paid ฿100 to learn about `bitcoind -rescan`

Long-time readers may recall that among Ulbricht's problems with developing & running Silk Road, he had problems with theft from his MtGox account: "Silk Goxed: How DPR used Mtgox for hedging & lost big". We identified his accounts and deposits as part of that investigation.
Based on our findings, impost_imposter has found a previously unknown Ross Ulbricht account on the Bitcoin Talk forums, used for tech support with SR1 problems: the user account "kohlanta" (posts), registered 19 August 2012. The name is a reference to a tourist destination in Thailand; Ulbricht was living in Australia around this time and traveled some places, apparently including Ko Lanta. This account must be Ulbricht because (1) who has ฿40,000 in a single address in August 2012? (2) the amount matches up exactly with the big transactions noted in 'Silk Goxed', and kohlanta's address 1MR..Y is the one involved in the Ulbricht withdrawals/deposits. (When he told me about this, I felt dumb - why hadn't I bothered to google 1MR..Y during our 'Silk Goxed' work to see if it had appeared anywhere else online?)
kohlanta's first question concerns the inability to move ฿40,000; this problem was solved by bitcoind -rescan, as pointed out by BT user fcmatt. (You can see he did indeed pay the ฿100 by noting that the amounts shrink by exactly that much.)
We can also see the trial testimony independently confirmed by kohlanta's further questions: questions about using curl, json-rpc, and versioning issues with the wallet.
There's nothing really important here that I can see, but it's interesting to see him panicking over the 1MR..Y, and it's definitely a reminder that Bitcoin addresses are only pseudonymous; once pseudonymity has been broken or damaged, you can continue to follow transactions & addresses to see what you can find.
submitted by gwern to SilkRoad [link] [comments]

[uncensored-r/Bitcoin] I Am Creating A New Bitcoin Core GUI Header

The following post by ImJustACowLol is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ Bitcoin/comments/7om6if
The original post's content was as follows:
Hey folks,
I have begun work to create a new Bitcoin GUI header. I am doing this for several reasons:
  • Bitcoin-qt doesn't support SegWit
  • Bitcoin-qt frequently freezes on some systems
  • I have written a Java framework for interaction with the Bitcoin network (through bitcoind and JSON RPC). This framework allows for very rapid development.
  • Conventional full-node clients often take a long time to process updates; CBitcoin is aimed at rapidly pushing through updates while remaining safe to use.
  • Why not? It's fun!
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 censorship_notifier to noncensored_bitcoin [link] [comments]

Guides for running a validating node?

Are there any good guides around for setting up a fully-validating node? I'm not interested in having a hot wallet with any actual funds in it; I just need to listen to the network to check if payments have been made, including zero-conf. Any pre-written software (preferably PHP) that would be relevant?
Without anyone else's input, my course of action would be to get something like a digital ocean account with the 40GB-SSD plan and install bitcoin core on it, and use the JSON-RPC functions in PHP to read from it. But I'm wondering if this is just 2011-esque thinking and there might be a better way these days.
submitted by xbtdev to Bitcoin [link] [comments]

CUDAMiner Optimization Basics

I've posted this information a lot recently to new miners with NVIDIA cards. This subreddit seemed like the right home for it, and hopefully this is will serve as a helpful starting place to clarify the very basics and get people started.
As always, watch your GPU core temperatures closely. Lower hash rates correlate to lower operating temperatures. Play with these features to adjust your hash rate according to the load your GPU can handle. For example, one of my cards has better cooling than the other, so I run them at different hash rates to keep them both in the temperature range that I'm comfortable with.
Getting Started (Windows Environment):
  1. Download and install the latest NVIDIA Drivers.
  2. Download and extract the latest version of cudaMiner (SEE BITCOINTALK - CUDAMINER LINK BELOW) .
  3. Create a new text file in the same directory as cudaminer.exe (x32 or x64, depending on your system).
  4. Open text file and enter your configuration into the new batch file (See below for samples. Change settings to match your specific set-up):
  5. Change text file extension to .bat
  6. Execute batch file (not the executable).
  7. ???
  8. To exit, CTRL+C to break, wait, then Y to exit OR press the "Red X"; If the the command window closes immediately, add "pause" to the end of the batch script to view the error.
  9. If running x64 version, try x32 version and compare results.
  10. !!!
  11. Profit
Common Errors
Error Possible Cause
Command prompt window flashes and closes. Usually indicates bad syntax or attempting to launch executable. Review batch script settings. Add "pause" to end of batch script to view error.
Stratum Authentication Failed / "HTTP Request failed; No Error" Indicates connection issue. Review server address & user credentials.
Memory error / Result doesn't validate on CPU / Error 30 (Indicates launch configuration is invalid/not optimal. Change launch configuration flags. Update drivers.
"json_rpc_call failed" You are launching the executable; you cannot do this. Create and launch using batch script instead.
:::Sample Configurations (EDIT TO MATCH YOUR SPECIFIC CREDENTIALS & GPU SETTINGS) :::Single GPU ::SingleGPU.bat cudaminer.exe -i 1 -C 1 -m 1 -H 1 -l auto -o stratum+tcp://YOUR.POOL.ADDRESS:#### -O USER.WORKER:WORKERPW :::Multi GPU, Multi Command Prompt ::GPU0.bat (Address/Login for Standard Pool Mining, 1st GPU) cudaminer.exe -d 0 -i 1 -C 1 -m 1 -H 1 -l auto -o stratum+tcp://YOUR.POOL.ADDRESS:#### -O USER.WORKER:WORKERPW ::GPU1.bat (Address/Login for P2Pool Mining, 2nd GPU) cudaminer.exe -d 1 -i 1 -C 1 -m 1 -H 1 -l K4x32 -o stratum+http://YOUR.P2POOL.ADDRESS:#### -O WALLETADDRESS:ANYPW :::Multi GPU, Single Command Prompt ::DoubleGPU.bat cudaminer.exe -d 0,1 -H 1,1 -i 1,1 -l K3x9,K4x32 -C 1,1 -o stratum+tcp://YOUR.POOL.ADDRESS:#### -O USER.WORKER:WORKERPW 
Fundamental Flags:
  • FLAGS ARE CASE SENSITIVE
Setting -flag (Options) Description
cudaminer.exe N/A Call to execute cudaMiner
Specify Device -d (Any, counts from 0) Only for multi-GPU configurations: create multiple .bat files or use comma separated values.
Interactive Mode -i (0/1) When enabled, it reduces GPU utilization and hash rate to allow for computer use during mining
Enable Texture Cache -C (0/1/2) (Disabled, 1-D Caching, 2-D Caching) may increase or reduce hash rate, available according to your compute capability - check WIKI CUDA LINK BELOW
Memory Batching -m (0/1) Consolidates hash work into a single memory block and can lead to lower memory usage. Is implicitly enabled with Texture Caching.
Hash Parallel -H (0/1/2) (CPU Only, CPU Assist, GPU Only) determines how much work will be shared by the CPU. Defaults to GPU Only (2) if not specified.
Launch Configuration^ -l (auto/G/GBxW) Autotune, autotune for card generation, or specify particular setting. Defaults to autotune if not specified.
Server URL -o Address:Port Full URL of the mining server you wish to connect to.
Device Credentials -O User:Pass Username (or Username.Workername for pools) & password pair for the mining server for your device.
Debug-Benchmark Mode& -D --benchmark Verbose output to view block/warp chart and test a configuration.
  • NOTE ^ : This option is they key to tuning your hash rate and resulting GPU temperature. Choosing "auto" will enable autotuning, allowing cudaMiner to choose the best config. Choosing just "G," card generation code, will autotune for that specific card generation. "GBxW" is the specific setting you choose for the card where "BLOCK" is the row #, "WARP" is the Column number in autotune chart. Your BLOCKxWARP value should not exceed your maximum core configuration (WIKI GPU LIST BELOW), otherwise cudaMiner will crash/return error. For best results, the BLOCKxWARP value should be an exact multiple of your core config.
-For example NVIDIA GT 750M, Kepler card, row 4, column 32 is K4x32 (4x32=128). This is exactly 1/3 of and does not exceed the max core config of 384). 
  • NOTE & : Autotuning reported hashrates are not always accurate, but you can use the results in the benchmark table to choose the ballpark hash rate you desire. If you define a setting or allow it to complete the autotuning, it will then begin the benchmark and show you the average hashrate once you end the sesion (CTRL+C). Before closing the command prompt, you can scroll back up and save a screenshot of the block table. Type "Y" after ending to close the program. Remember to turn OFF the flag -D --benchmark after you are done. This is benchmark mode; cudaMiner will not connect to the pool until you remove this flag
Sources & Additional References:
BitcoinTalk - cudaMiner Downloads & Latest News
Netcode Pool - cudaMiner Guide
/dogemining - NVIDIA Tuning Guide
Hardware Specifications/Comparisons
Wikipedia - Comparison of NVIDIA GPUs
Wikipedia - CUDA
cudaMiner Devs - cudaMiner scrypt Hashrate list
Litecoin WIKI - Hardware Comparison List
Litecoin WIKI - Hardware Comparison List (Raw Data)
Last Updated Mar 1, 2014
NyanCoins: KKvQjafJ3QckoCNQtdLkDfieBqUpuAVM4y
DogeCoins: DD4TcmjNE9RhVBaSadZDkqZtTQfyUstsFL
Or tips! Contributions greatly appreciated!
submitted by FwuffyKittens to nyanmining [link] [comments]

My findings into Mike Hearn being Satoshi Nakamoto

Is Satoshi Nakamoto Mike Hearn?

There are many coincidences involving a Mike Hearn and Satoshi Nakamoto connection.

Besides Mike being British and Satoshi using British English my first inclination to even consider Mike Hearn as being Satoshi Nakamoto was that Mike’s bitcointalk.org profile was created 1 day after Satoshi last logged in to the forum.
Satoshi’s profile: https://bitcointalk.org/index.php?action=profile;u=3 Mike’s profile: https://bitcointalk.org/index.php?action=profile;u=2700

Mike’s bitcointalk presence began 1 day 53 minutes and 13 seconds after Satoshi’s bitcointalk presence ended. Almost exactly 1 day separating their profiles seemed odd to me especially considering the impact Mike had in development later on.

Why would Satoshi Nakamoto hide his real identity?
The people who created the precursors to Bitcoin were not anonymous. Satoshi even referenced multiple influences by name in his whitepaper like Wei Dai, Ralph Merkle, and Adam Back. So why did the person behind Satoshi feel the need to remain anonymous? There doesn’t seem to be any precedent in the small niche of people who attempted to make digital/electronic cash. A lot of people are constantly regurgitating the idea that Satoshi knew how big Bitcoin would become and that Governments or nefarious people would want to hunt him down for his bitcoin holdings or for simply inventing bitcoin. In reality, Satoshi didn’t even know if his invention would gain traction. Satoshi didn’t know he would be one of a handful of users running bitcoin in the first year which would allow him to mine as many blocks as he did. Satoshi didn’t know how much bitcoin would actually be worth.
So why would Mike Hearn hide is identity?
Mike Hearn in mid August 2006 was hired on by Google as a Site Reliability Engineer (http://web.archive.org/web/20090514053312/http://mikehearn.wordpress.com:80/2006/08/)
Why would an employee of Google secretly develop something? Well, Google themselves sum it up pretty nicely here: “As part of your employment agreement, Google most likely owns intellectual property (IP) you create while at the company. Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.“ (https://opensource.google.com/docs/iarc/ )
Here Mike was indeed fully aware of Google’s policy when he released bitcoinj as a Google copyrighted project under the Apache 2 license: https://bitcointalk.org/index.php?topic=4236.msg61438#msg61438 https://bitcointalk.org/index.php?topic=4236.msg61658#msg61658
Then here he is emailing Satoshi (himself :) a few hours after the bitcointalk announcement: “From: Mike Hearn [email protected] Date: Mon, Mar 7, 2011 at 2:13 PM To: Satoshi Nakamoto [email protected]
Hi Satoshi,
I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: …. “ https://pastebin.com/JF3USKFT
I wonder what Google would have done with Bitcoin had Hearn/Satoshi not been anonymous?

Mike claiming he supposedly “coined the term SPV”. Or, did he? Here is Peter Todd https://twitter.com/petertoddbtc/status/649413412158599168 and her is the reddit thread to go along with it: https://www.reddit.com/Bitcoin/comments/3n1ydp/peter_todd_on_twitter_mike_hearn_claiming_he/

The term “SPV” does not appear in the whitepaper but its meaning does. Simplified Payment Verification is section 8 of the whitepaper. Did Mike slip and just inadvertently hint to him being the real Satoshi? Upon further investigation Mike had claimed months earlier that he coined the term “SPV wallet”. https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e So he could have meant to say SPV wallet when Peter Todd was calling him out or maybe he did mean to say just “SPV”. Still not the smoking gun but interesting that he would throw that around knowing full well that Simplified Payment Verification was in the Whitepaper.

[After writing this up, Mike just released all his private Satoshi Emails through a user named CipherionX. Mike did show up in a reddit thread to confirm that they came from him and are indeed not fake. Bitcointalk link: https://bitcointalk.org/index.php?topic=2080206.0 Reddit link to Mike’s post: https://www.reddit.com/btc/comments/6t2ci2/never_before_seen_mike_hearn_satoshi_nakamoto/dliizv6/ ] It is very plausible that in order to remain separate from the creator of Bitcoin that someone would in fact have email conversations between himself and alias as “proof” that the pseudonymous Bitcoin creator and Mike Hearn are completely different independent people. Of course this would only make sense if the emails were made public at some point. Well, Mike just made them public. Mike also attempted to divulge them to Charles Hoskinson in 2013 who did not release them to the public.
If the dates can be trusted, Mike’s email leak serves as proof that he was there early on even if he was corresponding with himself ;) Besides the new email dump the only known public involvement was here on the sourceforge forum in October 2009: https://sourceforge.net/p/bitcoin/mailman/bitcoin-list/thread/f4cd80640910240804m64ba45f1g216905fc9db16a2%40mail.gmail.com/#msg23827020 . Later on Mike did produce an email he sent to Satoshi In April of 2009 here in this thread: https://bitcoinfoundation.org/forum/index.php?/topic/54-my-first-message-to-satoshi/ which does correspond with the email dump.
Why did Mike not use Sourceforge as he posted openly so frequently in other project lists or forums? My best guess is that Mike figured he could be traced using multiple aliases on Sourceforge if an employee was so inclined to investigate so he switched it up and decided to have the fabricated conversations with himself through a more controlled environment.?????

What is odd about Mike’s involvement early on is that it doesn’t really parallel with his natural demeanor. He is very vocal and has an involved online presence yet he just really isn’t himself during the early stages of Bitcoin. Even his personal blog posts came to a halt in early 2009. https://web.archive.org/web/20111130084418/http://mikehearn.wordpress.com:80/ For someone who was generally very active online before Bitcoin and then after Satoshi’s disappearence, I find it odd that there is a dead silence period from Mike Hearn while Satoshi existed online.

Hal Finney was also involved at the start only to leave and eventually return. He came back a month before Satoshi departed though. Hal was the recipient of bitcoins first transaction and helped Satoshi troubleshoot early problems http://online.wsj.com/public/resources/documents/finneynakamotoemails.pdf

So it appears that Satoshi may have had either a rapport or at the least some familiarity with Hal. This lead me to Google Mike Hearn and Hal Finney together which turned up a nice find. Here, https://sourceforge.net/p/tboot/mailman/tboot-devel/?style=threaded&viewmonth=200807 Mike and Hal are talking about Trusted Computing back in July 2008, just months before the bitcoin whitepaper surfaced. Unfortunately I don’t quite fully understand Trusted Computing and the reason Mike Hearn was inquiring about it or how it would relate to early Bitcoin. However, I did also find this thread from Mike Hearn that Hal Finney later resurrected about TC: https://bitcointalk.org/index.php?topic=67508.0 And even more interesting, Hal Finney later wrote in his brief memoir of bitcoin, “Bitcoin and Me”, posted on the bitcointalk forum (https://bitcointalk.org/index.php?topic=155054.0) that he was currently “working on something Mike Hearn suggested, using the security features of modern processors, designed to support "Trusted Computing", to harden Bitcoin wallets.” Was Mike Hearn originally researching a use for trusted computing in Bitcoin but never implemented it only to later pass it on to Hal FInney as a “suggestion”? Mike on Google+ posted a link to Hal’s TC project when he learned Hal passed away and linked to Hal’s post on BTCtalk (https://plus.google.com/+MikeHearn ; https://bitcointalk.org/index.php?topic=154290.0 )

In searching for clues about Satoshi I came across a colloquial/slang term that he used. “Hack on” was used by Satoshi in the context of “work on”. https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206 I found multiple instances where Mike Hearn used the same exact term in the same context: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007779.html http://bitcoin-development.narkive.com/hczWIAby/bitcoin-development-cartographer https://web.archive.org/web/20170628004052/http://www.advogato.org/person/mikehearn/ https://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00031.html

I do admit the “hack on” arguement is the weakest evidence as it is somewhat common term. However not everyone used it in that context (such as Hal Finney) and it does add to a list of coincidences.

Another weak coincidence is Mike Hearns birthday. MIke’s birthday is April 17th, 1984. Satoshi’s birthday was chosen as April 5th, 1975. I don’t know about you, but a lot of times when I have to enter a birthday in a service where I don’t want them knowing the truth, I usually always use my real birth month with fake day and year.

Mike went Facebook silent from July 23, 2007 to March 8, 2011 which also coincides with Satoshi’s existence and pre-release development of Bitcoin. https://www.facebook.com/i.am.the.real.mike?lst=662933243%3A61203304%3A1502324015

Here is Satoshi stating he started working on bitcoin in 2007 https://bitcointalk.org/index.php?topic=195.msg1617#msg1617,

According to Mike Hearn, Satoshi “communicated with a few of the core developers before leaving. He told myself and Gavin that he had moved on to other things and that the project was in good hands.“ https://bitcointalk.org/index.php?topic=145850.msg1558053#msg1558053 This is also backed up by the new email release here: https://pastebin.com/syrmi3ET Mike- “I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?” Satoshi- “I've moved on to other things. It's in good hands with Gavin and everyone.” The above communication is supposedly the last time anyone heard from Satoshi and none other than Mike Hearn was the recipient.
** Calendar of Mike travelling vs Satoshi post history. It would make sense that Satoshi would post less or not at all when he traveled.
Thoughts on the new email dump….draft notes…
https://pastebin.com/wA9Jn100
December 27, Mike decides to email Satoshi. This is 2 weeks after Satoshi went silent on the forums and Mike joined the forum. He has been back into Bitcoin for less than a month and he is already working on a “Java implementation of the simplified payment verification, with an eye to building a client that runs on Android phones.“ Mike said he was working on a client on December 22 a week after joining the community
By march 7 Mike had the Google “lawyers happy enough” about the bitcoinj release. Seems that within under 3 months Mike developed and released bitcoinj while also dealing with Google’s IP lawyers and copyright/licensing.
Satoshi mentioned the e-bay marketplace feature twice: I started implementing a marketplace feature earlier that facilitates offering things for sale and taking orders, it's only half done though. A bit like e-bay but without auctions, just "buy now". Among other things, it would make it easy for anyone to offer currency exchange.
https://pastebin.com/Na5FwkQ4
I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it. https://pastebin.com/JF3USKFT
Satoshi sought guidance about EC-DSA and RSA key length
April 18th 2009 Mike told Satoshi he works at Google, April 18th 2009 Mike Said they use protocol buffers “here at google” Jan 7 2011 Satoshi asked Mike if the client-only implementation would be Google proprietary. Jan 12th, 2011 Mike announced on bitcointalk that he worked for Google https://bitcointalk.org/index.php?topic=2745.msg37471#msg37471
Other searchables. Email addresses: [email protected] [email protected] Freenode IRC “TD” Brother David WIlliam Hearn,
submitted by SkyScraper_Farms to MikeHearnIsSatoshi [link] [comments]

Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - YouTube Bitcoin JSON-RPC Tutorial 5 - Your First Calls - YouTube Bitcoin JSON-RPC Tutorial 2 - VPS Setup Bitcoin JSON-RPC Tutorial 4 - Command Line Interface - YouTube Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors

Simple Bitcoin JSON-RPC client based on GuzzleHttp. Installation. Run php composer.phar require denpa/php-bitcoinrpc in your project directory or add following lines to composer.json Json-RPC, PHP curl, and Bitcoin getblocktemplate request. Ask Question Asked 6 years, 8 months ago. Active 6 years, 8 months ago. Viewed 3k times 1. Thanks for stopping in :) I break things, fiddle around, and then try to put them back together. It is how I seem to learn best. (One of) My recent obsession(s) has been with crypto-currency. Since I have a little bit of knowledge working with API ... Bitcoin-JSON-RPC-Client is a lightweight Java bitcoin JSON-RPC client binding. It does not require any external dependencies. Code Example Then, you set up a bitcoin.conf file (location depends on your OS) where you have the lines: rpcuser=someusernamehere rpcpassword=somepasswordhere rpcport=8332 rpcport defaults to 8332 so you can leave it out. 本文转自:https://laravel-china.org/index.php/articles/8919/bitcoin-requests-node-data-through-rpc 文章来自本人

[index] [4248] [13211] [8855] [49010] [41753] [7037] [42588] [33809] [34043] [13326]

Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - YouTube

Bitcoin JSON-RPC tutorial. How to set up bitcoind on a VPS. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U Bitcoin JSON-RPC tutorial. How to set up and use bitcoind wallet notify feature. How to set up and use bitcoind wallet notify feature. My Book: Building Bitcoin Websites - https://www.amazon.com ... Bitcoin JSON-RPC tutorial. Set up your bitcoin.conf file and create custom settings with bitcoind. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U Bitcoin JSON-RPC tutorial. Getting started with the bitcoin command line interface. My Book: https://www.amazon.com/Building-Bitcoin-Websites-Beginners-Devel... 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 ...

#