Python request module for bitcoin json rpc Edureka Community

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]

1mb Fork Txn

Enclosed find a signed 1mb txn (999,957 bytes), that if mined will fork the network. TxnID: bbb67fc3320d1e9a58c7cd0bb5ead2cff87b243e089e4a21dad669ba28703f32
The outputs of this transaction have the following function, designated by their prefix:
The 1mb signed txn: https://anonfile.com/N2T4Aeb0bb/1mbtxn.txt
Once a client is available that will support relay of this txn, the console interface will likely not support it. To push this txn you'll have to use the RPC interface with a script https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpc_user="Your_User"
rpc_password="Your_Pass"
rpc_connection = AuthServiceProxy("http://%s:%[email protected]:8332"%(rpc_user, rpc_password))
txn = []
f = open('1mbtxn.txt', 'r') #This is the above linked txt file containing the txn
txn = f.read()
f.close()
print(rpc_connection.sendrawtransaction(txn))
if you get this error, your client does not support this txn
64: tx-size
submitted by 1MBforKTR1gAqRLkNbQg to btc [link] [comments]

QuarkChain Testnet 2.0 Mining.

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

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]

Transcript from Ravencoin Open Developer Meeting - Nov. 16, 2018

Tron at 2:03 PM

Topics: Messaging (next phase) UI 2.2 - Build from develop - still working out a few kinks Mobile - Send/Rcv/View Assets - In progress Raven Dev Kit -Status

RavencoinDev at 2:04 PM

Hey Everybody! Let's get started!Thanks Tron for posting the topics.Tron is going talk about Messaging Plans.Let's start there.

Chatturga at 2:06 PM

It looks like this channel is not connected to the IRC. One moment

RavencoinDev at 2:07 PM

Well, we going to move forward as the tech guys fix the IRC connections.

Tron at 2:07 PM

I wanted to have a doc describing the messaging, but it isn't quite ready.I understand this isn't going to IRC yet, but I'm starting anyway.

RavencoinDev at 2:08 PM

Look for it soon on a Medium near you.

Tron at 2:08 PM

Summary version: Every transaction can have an IPFS hash attached.

Vincent at 2:09 PM

any plans for a 'create IPFS' button?

RavencoinDev at 2:09 PM

Yes

Vincent at 2:09 PM

on asset creatin window also?

RavencoinDev at 2:09 PM

Yes

Vincent at 2:09 PM

sweet

Tron at 2:09 PM

IPFS attachments for transactions that send ownership token or channel token back to the same address will be considered broadcast messages for that token.The client will show the message.Some anti-spam measures will be introduced.If a token is in a new address, then messages will be on by default.The second token in an address, the channel will be available, but muted by default.

RavencoinDev at 2:11 PM

That way I can't spam out 21b tokens and then start sending messages to everybody.

Tron at 2:11 PM

We'd like to have messaging in a reference client on all six platforms.

corby at 2:11 PM

Hi!

Tron at 2:11 PM

Photos will not be shown. Messages will be "linkified"

RavencoinDev at 2:12 PM

and plain text.We'll start with the QT wallet support

Tron at 2:12 PM

Any other client is free to show any IPFS message they choose.The messaging is fully transparent.

Rikki RATTOE at 2:13 PM

ok, so messaging isn't private

Tron at 2:13 PM

Anyone could read the chain and see the messages.

RavencoinDev at 2:13 PM

No, never was planned to be private

MSFTserver-mine more @ MinerMore at 2:13 PM

irc link should be fixed

Tron at 2:13 PM

It is possible to put encrypted content in the IPFS, but then you'd have to distribute the key somehow.

RavencoinDev at 2:13 PM

Thanks MSFT!

Chatturga at 2:13 PM

Negative

Tron at 2:14 PM

Core protocol changes Extend the OP_RVN_ASSET to include for any transfer: RVNT <0xHH><0x12><0x20><32 bytes encoding 256 bit IPFS hash> 0xHH - File type 0x00 - NO data, 0x01 - IPFS hash, 0x02 through 0xFF RESERVED 0x12 - IPFS Spec - Using SHA256 hash 0x20 - IPFS Spec - 0x20 in hex specifying a 32 byte hash. …. (32 byte hash in binary)

corby at 2:14 PM

By it's nature nothing on chain is private per se. Just like with wallets you'd need to use crypto to secure messaging between parties.

Tron at 2:14 PM

Advantages: This messaging protocol has the advantage of not filling up the blockchain. The message information is public so IPFS works as a great distributed store. If the messages are important enough, then the message sender can run nodes that "PIN" the message to keep a more durable version. The message system cannot be spoofed because any change in the message will result in a different hash, and therefore the message location will be different. Only the unique token holder can sign the transaction that adds the message. This prevents spam. Message clients (wallets), can opt-in or opt-out of messages by channel. Meta-message websites can allow viewing of all messages, or all messages for a token. A simple single channel system is supported by the protocol, but a channel could be sub-divided by a client to have as many sub-channels as desired. There are no limits on the number of channels per token, but each channel requires the 5 RVN fee to create the channel.

RavencoinDev at 2:14 PM

So, somebody could create their own client and encrypt the data on the blockchain if they wished.

corby at 2:15 PM

Wow Tron types fast

Rikki RATTOE at 2:15 PM

yeah there was some confusion in the community whether messaging would be private and off chain

Tron at 2:15 PM

Anti-Spam Strategy One difficulty we have is that tokens can be sent to any Ravencoin asset holder unsolicited. This happens on other asset platforms like Counterparty. In many cases, this is good, and is a way for asset issuers to get their token known. It is essentially an airdrop. However, combined with the messaging capabilities of Ravencoin, this can, and likely will become a spam strategy. Someone who wants to send messages (probably scams) to Ravencoin asset holders, which they know are crypto-savvy people, will create a token with billions of units, send it to every address, and then message with the talking stick for that token. Unless we preemptively address this problem, Ravencoin messaging will become a useless spam channel. Anyone can stop the messages for an asset by burning the asset, or by turning off the channel. A simple solution is to automatically mute the channel (by default) for the 2nd asset sent to an address. The reason this works is because the assets that you acquire through your actions will be to a newly generated address. The normal workflow would be to purchase an asset on an exchange, or through a ICO/STO sale. For an exchange, you'll provide a withdrawal address, and best practice says you request a new address from the client with File->'Receiving addresses…'->New. To provide an address to the ICO/STO issuer, you would do the same. It is only the case where someone is sending assets unsolicited to you where an address would be re-used for asset tokens. This is not 100% the case, and there may be rare edge-cases, but would allow us to set the channels to listen or silent by default. Assets sent to addresses that were already 'on-chain' can be quarantined. The user can burn them or take them out of quarantine.

RavencoinDev at 2:18 PM

Okay, let me know when/if you guys read through all that. 📷📷2

corby at 2:18 PM

To be clear this is a client-side issue -- anyone will be able to send anything (including messages) to any address on chain..

RavencoinDev at 2:18 PM

It'll be in the Medium post later.

Tron at 2:19 PM

@corby The reference client will only show messages signed by the issuer or designated channels.Who is ready for another wall of text? 📷

corby at 2:19 PM

I hear that's the plan 📷 just pointing out that it is on the client in these cases..

Tron at 2:20 PM

Yes, any client can show anything gleaned from the chain.Goal: A simple message format without photos. URL links are allowed and most clients will automatically "linkify" the message for valid URLs. For display, message file must be a valid json file. { "subject":"This is the optional subject", "message": "This is required.", "expires": 1578034800 } Only "message" is required {"message":"Hello world"}

bhorn at 2:21 PM

expires?

Vincent at 2:21 PM

discount coupon?

Tron at 2:21 PM

If you have a message that worthless (say after a vote), just don't show the message.

bhorn at 2:21 PM

i see - more client side operation

corby at 2:21 PM

/expires

Tron at 2:22 PM

Yep. And the expiration could be used by IPFS pinners to stop worrying about the message. Optional

RavencoinDev at 2:22 PM

If the client sees a message that is expired it just won't display it.

Vincent at 2:23 PM

will that me messaged otherwise may cause confusion?"expired'

RavencoinDev at 2:23 PM

YesWe'll do our best to make it intuitive.

Tron at 2:24 PM

Client handling of messages Pop-up messages or notifications when running live. Show messages for any assets sent to a new address - by default Mute messages for assets sent to an address that was already on-network. Have a setting to not show messages older than X IPFSHash (or 8 bytes of it) =

Rikki RATTOE at 2:25 PM

will there be a file size limit for IPFS creation in the wallet?

RavencoinDev at 2:25 PM

We'll also provide updated documentation.

Tron at 2:26 PM

Excellent question Rikki. Here are some guidelinesGuidelines: Clients are free to show or not show poorly formed messages. Reference clients will limit message display to properly formed messages. If subject is missing, the first line of the message will be used (up to 80 chars). Standard JSON encoding for newlines, tabs, etc. https://www.freeformatter.com/json-escape.html Expiration is optional, but desired. Will stop showing the message after X date, where X is specified as Unix Epoch. Good for invites, voting requests, and other time sensitive messages that have no value after a specific date. By default clients will not show a message after X blocks (default 1 year) Amount of subject shown will be client dependent - Reference client may cut off at 80 chars. Messages longer than 15,000 (about 8 pages) will not be pinned to IPFS by some scanners. Messages longer than 15,000 characters may be rejected altogether by the client. Images will not be shown in reference clients. Other clients may show any IPFS content at their discretion. IPFSHash is only a "published" message if the Admin/Owner or Channel token is sent from/to the same address. This allows for standard transfers with metadata that don't "publish".Free Online JSON Escape / Unescape Tool - FreeFormatter.comA free online tool to escape or unescape JSON strings

RavencoinDev at 2:26 PM

We're hoping to add preferences that will allow the user to customize their messaging experience.

Tron at 2:27 PM

Also, happy to receive feedback from everyone.

corby at 2:27 PM

In theory though if you maintain your own IPFS nodes you should be able to reference files of whatever size right?

Steelers at 2:27 PM

How about a simple Stop light approach - Green (ball) New Message, Yellow (Ball) Expiring Messages, Red (Ball) Expired Messages

RavencoinDev at 2:27 PM

Yes please! That's the point of sharing it here

Chatturga at 2:27 PM

Fixt

push | ravenland.org at 2:28 PM

Thanks @Tron can you provide any details of the coming 'tooling' at the end of november, and what that might enable (apologies as I am a bit late to meeting if this has been asked already)

VeronicaBOT at 2:28 PM

sup guys

Tron at 2:28 PM

Sure, that's coming.

RavencoinDev at 2:28 PM

That's the Raven WebDev Kit topic coming up in a few mins.

push | ravenland.org at 2:29 PM

oki 📷 cheers

RavencoinDev at 2:29 PM

Questions on messaging?

Jeroz at 2:30 PM

Not sure if I missed it, but how fast could you send multiple messages in succession?

BruceFenton at 2:30 PM

Some kind of sweep feature or block feature for both tokens and messages could be useful Certain messages will be illegal to possess in certain jurisdictions If someone sends a picture of Tiennneman tank man in China or a message calling for the overthrow of a ruler it could be illegal for someone to have There’s no way for that jurisdiction to censor the chain So some users might want the option to purge messages or not receive them client side / on the wallet

Tron at 2:30 PM

Messages are a transaction.

RavencoinDev at 2:30 PM

So it'll cost you to spam messages.They can only send a hash to that picture and the client won't display anything not JSON

corby at 2:31 PM

purge/block is the age old email spam

Tron at 2:31 PM

The Reference client - other clients / web sites, etc can show anything they wish.

RavencoinDev at 2:31 PM

You can also burn a token if you never want to receive messages from that token owner.

UserJonPizza|MinePool.com|Mom at 2:32 PM

Can't they just resend the token?

Tron at 2:33 PM

Yes, but it would default to mute.📷2

RavencoinDev at 2:33 PM

meaning it would show up in a spam foldetab

bhorn at 2:33 PM

is muting available for the initial asset as well?

RavencoinDev at 2:33 PM

Something easy to ignore if muted.

Tron at 2:33 PM

@bhorn Yes

BruceFenton at 2:33 PM

Can users nite some assets and not others?

Tron at 2:33 PM

@bhorn It just isn't the default.

BruceFenton at 2:33 PM

Mute

RavencoinDev at 2:33 PM

YesYou can mute per token.

BruceFenton at 2:34 PM

Great

Tron at 2:34 PM

And per token per channel.

Jeroz at 2:34 PM

channels are the subtokens?

BruceFenton at 2:34 PM

What’s per token per channel mean ?

Tron at 2:34 PM

The issuer sends to the "Primary" channel.Token owner can create channels like "Alert", "Emergency", etc.These "talking sticks" are similar to unique assets.📷1ASSET~Channel

RavencoinDev at 2:37 PM

Okay, we have a few more topics to cover today.Tron will post more details on Medium and we can continue discussions there.

Jeroz at 2:38 PM

Ah, I missed channel creation bit for each token with the 5 RVN / channel cost. It makes more sense to me now.

RavencoinDev at 2:38 PM

The developers are working towards posting a new version 2.2 that has the updated UI shown on twitter.

Vincent at 2:39 PM

twit link?

RavencoinDev at 2:39 PM

The consuming of large birds (not ravens) might slow the release a bit.So likely the week after Thanksgiving.

[Dev] Blondfrogs at 2:39 PM

The new UI will contain: - New menu layout - New icons - Dark mode - Added RVN colors

Dan1666 at 2:39 PM

+1 Dark mode

RavencoinDev at 2:39 PM

DARK MODE!

Dan1666 at 2:40 PM

so pleased about that

RavencoinDev at 2:40 PM

I can honestly say it'll be the nicest crypto wallet out there.

[Dev] Blondfrogs at 2:40 PM

A little sneak peak, but this is not the final project📷📷6📷3

!S1LVA | MINEPOOL at 2:40 PM

Outstanding

Dan1666 at 2:41 PM

reminds me of Sub7 ui for those that might remember

UserJonPizza|MinePool.com|Mom at 2:41 PM

Can we have an asset count at the top?

[Dev] Blondfrogs at 2:41 PM

Icons will be changing

Vincent at 2:41 PM

does the 'transfer assets' have a this for that component?

Tron at 2:41 PM

Build from develop to see the sneak preview in action.There may be small glitches depending on OS. These are being worked on.

Rikki RATTOE at 2:41 PM

No plans for the mobile wallet to show an IPFS image I'm assuming? Would be a nice feature if say a retail store could send a QR coupon code to their token holders and they could scan the coupon using their wallet in store

[Dev] Blondfrogs at 2:42 PM

@Vincent That will probably be a different section added later📷1

RavencoinDev at 2:42 PM

Yes, Rikki we do want to support messaging.Looking into how that would work with Apple and Google push.

push | ravenland.org at 2:42 PM

sub7📷1hahaoldschoolit so is similar aswell

[Master] Roshii at 2:43 PM

Messages are transactions no need for any push

Tron at 2:43 PM

@Rikki RATTOE There's a danger in showing graphics where anyone can post anything without accountability for their actions. A client that only shows tokens for a specific asset could do this📷1

RavencoinDev at 2:43 PM

True, unless you want to see the messages even if you haven't opened your wallet in a week.

Rikki RATTOE at 2:44 PM

the only thing I was thinking was if you simply linked the image, somebody could just copy the link and text it off to everyone and the coupon isn't all that exclusive

UserJonPizza|MinePool.com|Mom at 2:44 PM

Maybe a mobile link-up for a easy way to see messages by just importing pubkey(edited)

RavencoinDev at 2:45 PM

Speaking of mobileWe are also getting close to a release of mobile that includes the ability to show assets held, and transfer them.Roshii has been hard at work.📷6📷1

Vincent at 2:46 PM

can be hidden also?

RavencoinDev at 2:47 PM

We're still finalizing the UI design but that is on the list of todos📷1

Under at 2:47 PM

Could we do zerofee mempool messaging that basically gets destroyed after it expires out of the mempool for real-time stealth mode messaging

corby at 2:48 PM

That's interesting!

RavencoinDev at 2:49 PM

There are other solutions available for stealth messaging, that's not what the devs had intended to build. It does sound cool though @Under

Under at 2:50 PM

📷 we’ll keep up the good work. Looking forward to the db upgrades. Will test this weekend

RavencoinDev at 2:50 PM

Thanks!That leaves us with 10 minutes for the Dev Kit!Corby has been working on expanding some of the awesome work that @Under has been doing.

corby at 2:52 PM

Yes -- all of the -addressindex rpc calls are being updated to work with assets

RavencoinDev at 2:52 PM

Hopefully we'll be able to post the source soon once the initial use cases are all working.

corby at 2:52 PM

so assets are being tied into transaction history, utxos, etc

RavencoinDev at 2:52 PM

The devs want to provide a set of API's that make it easy for web developers to build solutions on top of Ravencoin.VinX is investigating the possibility of using Ravencoin to power their solution.

corby at 2:53 PM

will be exposed via insight-api which we've forked from @Under

[Master] Roshii at 2:53 PM

Something worth bringing up is that you will be able to get specific asset daba from full nodes with specific message protocols.

corby at 2:54 PM

also working on js lib for client side construction of asset transactions

Tron at 2:55 PM

Dev Kit will be an ongoing project so others can contribute and extend the APIs and capabilities of the 2nd layer.📷3📷3

RavencoinDev at 2:55 PM

Will be posted soon to the RavenProject GitHub.

corby at 2:55 PM

separate thing but yes Roshii that is worth mentioning -- network layer for getting asset data

RavencoinDev at 2:55 PM

Again want to give thanks to @Under for getting a great start on the project

push | ravenland.org at 2:56 PM

Yes looking forward to seeing more on the extensive api and capabilities, is there a wiki on this anywhere tron?(as to prevent other people replicating eachothers work?)

RavencoinDev at 2:56 PM

The wiki will be in the project on GitHub

push | ravenland.org at 2:56 PM

im guessing when the kit is released, something will appear, okok cool

RavencoinDevat 2:57 PM

Any questions about the Web DevKit?

push | ravenland.orgToday at 2:57 PM

well, what kind of support will it give us, that would be nice, is this written anywhereI'm still relatively new to blockchain<2 yearsso need some hand holding i suppose 📷

bhorn at 2:58 PM

right, what are initial use cases of the devkit?

push | ravenland.org at 2:58 PM

i mean im guessing metamask like capabilitysome kind of smart contract, some automation capabilitiesrpc scriptsstuff like thiseven if proof of concept or examplei guess im wondering if my hopes are realistic 📷

RavencoinDev at 2:59 PM

You can see the awesome work that @Under has already don that we are building on top of.

push | ravenland.org at 2:59 PM

yes @Under is truly a herooki, cool

RavencoinDev at 2:59 PM

https://ravencoin.network/Ravencoin Block ExplorerRavencoin Insight. View detailed information on all ravencoin transactions and blocks.

push | ravenland.org at 2:59 PM

ok, sweet, that is very encouragingthanks @Under for making that code public

corby at 3:00 PM

It will hopefully allow you to write all sorts of clients -- depending on complexity of use case you might just have js lib (wallet functions, ability to post txs to gateway) or a server side project (asset explorer or exchange)..(edited)

Tron at 3:00 PM

Yeah, thanks @Under .

RavencoinDev at 3:00 PM

What's your GitHub URL @Under ?

push | ravenland.org at 3:00 PM

https://github.com/underdarkskies/ i believeGitHub· GitHubunderdarkskies has 31 repositories available. Follow their code on GitHub.📷

RavencoinDev at 3:00 PM

Yup!

push | ravenland.org at 3:00 PM

he is truly a hero(edited)

RavencoinDev at 3:00 PM

LOL

push | ravenland.org at 3:00 PM

damn o'sgo missing everywhere

RavencoinDev at 3:01 PM

teh o's are hard... Just ask @Chatturga

push | ravenland.org at 3:01 PM

📷

Chatturga at 3:01 PM

O's arent the problem...

push | ravenland.org at 3:01 PM

📷📷

RavencoinDev at 3:02 PM

Alright we're at time and the devs are super busy. Thanks everybody for joining us.

push | ravenland.org at 3:02 PM

thanks guys

RavencoinDev at 3:02 PM

Thank you all for supporting the Raven community.📷6

corby at 3:02 PM

thanks all!

push | ravenland.org at 3:02 PM

keep up the awesome work, whilst bitcoin sv and bitcoin abc fight, another bitcoin fork raven, raven thru the night📷5

Vincent at 3:02 PM

piece!!

RavencoinDev at 3:03 PM

We're amazingly blessed to have you on this ride with us.📷5📷9📷5

Dan1666 at 3:03 PM

gg

BruceFenton at 3:03 PM

📷📷12📷4

UserJonPizza|MinePool.com|Mom at 3:55 PM

Good meeting! Excited for the new QT!!
submitted by Chatturga to u/Chatturga [link] [comments]

One dev's opinion: Enabling mining pool policy experimentation

A new Bitcoin Core (aka bitcoind) feature enables miner policy experimentation: https://github.com/bitcoin/bitcoin/pull/1583 The pull request was opened in July 2012 and merged in the past 24 hours.
This feature enables the local mining policy to artificially prefer (or avoid) certain transactions. Primarily, this will be used by the miner to ensure that a local transaction is mined, regardless of attached fees.
(warning: personal opinion ahead; speaking for myself, not my employer or other devs)
It has always seemed likely to me that a mature mining market would feature contractual agreements with outside, non-mining entities to mine certain types of transactions. This is a natural outgrowth of free market competition between miners (aka mining pools), for services that benefit the bitcoin community.
Many bitcoin mining pools supplement their income via merged mining. Some pools are forming agreements with enterprise-scale miners, or chip makers. As many different bitcoin applications come online, miners will likely compete for transaction-related services as well. This feature, JSON-RPC API call "prioritisetransaction", enables competition on a per-transaction granularity.
submitted by jgarzik 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]

Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015

Wladimir on Feb 16 2015:
Bitcoin Core version 0.10.0 is now available from:
https://bitcoin.org/bin/0.10.0/
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
The whole distribution is also available as torrent:
https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent
magnet:?xt=urn:btih:170c61fe09dafecfbb97cb4dccd32173383f4e68&dn;=0.10.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrading warning
Because release 0.10.0 makes use of headers-first synchronization and parallel
block download (see further), the block files and databases are not
backwards-compatible with older versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.
Notable changes

Faster synchronization
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
validate those. In a second stage, when the headers have been discovered, we
download the blocks. However, as we already know about the whole chain in
advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On
recent hardware with a decent network link, it can be as little as 3 hours
for an initial full synchronization. You may notice a slower progress in the
very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
  • getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
  • getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we
have requested from peers (but haven't received yet) are also listed as
'inflight'.
  • A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
settings will create transactions that confirm quickly; see the new
'txconfirmtarget' setting to control the tradeoff between fees and
confirmation times. Fees are added by default unless the 'sendfreetransactions'
setting is enabled.
Prior releases used hard-coded fees (and priorities), and would
sometimes create transactions that took a very long time to confirm.
Statistics used to estimate fees and priorities are saved in the
data directory in the fee_estimates.dat file just before
program shutdown, and are read in at startup.
New command line options for transaction fee changes:
  • -txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
  • -sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0)
New RPC commands for fee estimation:
  • estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
  • estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
estimate.
RPC access control changes
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
For the user this means that -rpcallowip takes a subnet specification, which can be
  • a single IP address (e.g. 1.2.3.4 or fe80::0012:3456:789a:bcde)
  • a network/CIDR (e.g. 1.2.3.0/24 or fe80::0000/64)
  • a network/netmask (e.g. 1.2.3.4/255.255.255.0 or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address
matches one of them.
For example:
| 0.9.x and before | 0.10.x |
|--------------------------------------------|---------------------------------------|
| -rpcallowip=192.168.1.1 | -rpcallowip=192.168.1.1 (unchanged) |
| -rpcallowip=192.168.1.* | -rpcallowip=192.168.1.0/24 |
| -rpcallowip=192.168.* | -rpcallowip=192.168.0.0/16 |
| -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) |
Using wildcards will result in the rule being rejected with the following error in debug.log:
 Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). 
REST interface
A new HTTP API is exposed when running with the -rest flag, which allows
unauthenticated access to public node data.
It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded
binary) or json.
For more details, see the doc/REST-interface.md document in the repository.
RPC Server "Warm-Up" Mode
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
immediately after starting the process. However, until all initialisations
are done, it always returns an immediate error with code -28 to all calls.
This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
For 0.10 the security of signing against unusual attacks has been
improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1
instead of OpenSSL. Libsecp256k1 is a cryptographic library
optimized for the curve Bitcoin uses which was created by Bitcoin
Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an
attacker on shared virtual machine hardware could extract a private
key if they could cause a target to sign using the same key hundreds
of times. While using shared hosts and reusing keys are inadvisable
for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization
and reduction in timing leaks that we've eagerly wanted to use for a
long time, but this functionality has still not made its
way into a released version of OpenSSL. Libsecp256k1 achieves
significantly stronger protection: As far as we're aware this is
the only deployed implementation of constant time signing for
the curve Bitcoin uses and we have reason to believe that
libsecp256k1 is better tested and more thoroughly reviewed
than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
Watch-only wallet support
The wallet can now track transactions to and from wallets for which you know
all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a
possibly vulnerable system. In addition, it can help for (manual) construction
of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to
importprivkey, but instead takes an address or script (in hexadecimal) as
argument. After using it, outputs credited to this address or script are
considered to be received, and transactions consuming these outputs will be
considered to be sent.
The following RPCs have optional support for watch-only:
getbalance, listreceivedbyaddress, listreceivedbyaccount,
listtransactions, listaccounts, listsinceblock, gettransaction. See the
RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require
-txindex, scales better, integrates better with the wallet, and is compatible
with future block chain pruning functionality. It does mean that all relevant
addresses need to added to the wallet before the payment, though.
Consensus library
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
The purpose of this library is to make the verification functionality that is
critical to Bitcoin's consensus available to other applications, e.g. to language
bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or
alternative node implementations.
This library is called libbitcoinconsensus.so (or, .dll for Windows).
Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h).
In its initial version the API includes two functions:
  • bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
  • bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
for existing methods should remain stable.
Standard script rules relaxed for P2SH addresses
The IsStandard() rules have been almost completely removed for P2SH
redemption scripts, allowing applications to make use of any valid
script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
While the Bitcoin protocol has always supported these types of script,
actually using them on mainnet has been previously inconvenient as
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
most miners include them in blocks they mined.
bitcoin-tx
It has been observed that many of the RPC functions offered by bitcoind are
"pure functions", and operate independently of the bitcoind wallet. This
included many of the RPC "raw transaction" API functions, such as
createrawtransaction.
bitcoin-tx is a newly introduced command line utility designed to enable easy
manipulation of bitcoin transactions. A summary of its operation may be
obtained via "bitcoin-tx --help" Transactions may be created or signed in a
manner similar to the RPC raw tx API. Transactions may be updated, deleting
inputs or outputs, or appending new inputs and outputs. Custom scripts may be
easily composed using a simple text notation, borrowed from the bitcoin test
suite.
This tool may be used for experimenting with new transaction types, signing
multi-party transactions, and many other uses. Long term, the goal is to
deprecate and remove "pure function" RPC API calls, as those do not require a
server round-trip to execute.
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
key and script operations easily accessible via command line.
Mining and relay policy enhancements
Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its getblocktemplate must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.
The prioritisetransaction RPC method has been added to enable miners to
manipulate the priority of transactions on an individual basis.
Bitcoin Core now supports BIP 22 long polling, so mining software can be
notified immediately of new templates rather than having to poll periodically.
Support for BIP 23 block proposals is now available in Bitcoin Core's
getblocktemplate method. This enables miners to check the basic validity of
their next block before expending work on it, reducing risks of accidental
hardforks or mining invalid blocks.
Two new options to control mining policy:
  • -datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
  • -datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs.
The relay policy has changed to more properly implement the desired behavior of not
relaying free (or very low fee) transactions unless they have a priority above the
AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
BIP 66: strict DER encoding for signatures
Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
consensus rule, which prohibits non-DER signatures. Such transactions have been
non-standard since Bitcoin v0.8.0 (released in February 2013), but were
technically still permitted inside blocks.
This change breaks the dependency on OpenSSL's signature parsing, and is
required if implementations would want to remove all of OpenSSL from the
consensus code.
The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
sequence of 1001 blocks have version number 3 or higher, the new consensus
rule becomes active for those blocks. When 951 out of a sequence of 1001
blocks have version number 3 or higher, it becomes mandatory for all blocks.
Backward compatibility with current mining software is NOT provided, thus miners
should read the first paragraph of "Mining and relay policy enhancements" above.
0.10.0 Change log

Detailed release notes follow. This overview includes changes that affect external
behavior, not code moves, refactors or string updates.
RPC:
  • f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
  • b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
  • 171ca77 estimatefee / estimatepriority RPC methods
  • b750cf1 Remove cli functionality from bitcoind
  • f6984e8 Add "chain" to getmininginfo, improve help in getblockchaininfo
  • 99ddc6c Add nLocalServices info to RPC getinfo
  • cf0c47b Remove getwork() RPC call
  • 2a72d45 prioritisetransaction
  • e44fea5 Add an option -datacarrier to allow users to disable relaying/mining data carrier transactions
  • 2ec5a3d Prevent easy RPC memory exhaustion attack
  • d4640d7 Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
  • 83f3543 Added argument to listaccounts to include watchonly addresses
  • 952877e Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
  • d7d5d23 Added argument to listtransactions and listsinceblock to include watchonly addresses
  • f87ba3d added includeWatchonly argument to 'gettransaction' because it affects balance calculation
  • 0fa2f88 added includedWatchonly argument to listreceivedbyaddress/...account
  • 6c37f7f getrawchangeaddress: fail when keypool exhausted and wallet locked
  • ff6a7af getblocktemplate: longpolling support
  • c4a321f Add peerid to getpeerinfo to allow correlation with the logs
  • 1b4568c Add vout to ListTransactions output
  • b33bd7a Implement "getchaintips" RPC command to monitor blockchain forks
  • 733177e Remove size limit in RPC client, keep it in server
  • 6b5b7cb Categorize rpc help overview
  • 6f2c26a Closely track mempool byte total. Add "getmempoolinfo" RPC
  • aa82795 Add detailed network info to getnetworkinfo RPC
  • 01094bd Don't reveal whether password is <20 or >20 characters in RPC
  • 57153d4 rpc: Compute number of confirmations of a block from block height
  • ff36cbe getnetworkinfo: export local node's client sub-version string
  • d14d7de SanitizeString: allow '(' and ')'
  • 31d6390 Fixed setaccount accepting foreign address
  • b5ec5fe update getnetworkinfo help with subversion
  • ad6e601 RPC additions after headers-first
  • 33dfbf5 rpc: Fix leveldb iterator leak, and flush before gettxoutsetinfo
  • 2aa6329 Enable customising node policy for datacarrier data size with a -datacarriersize option
  • f877aaa submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
  • e69a587 submitblock: Support for returning specific rejection reasons
  • af82884 Add "warmup mode" for RPC server
  • e2655e0 Add unauthenticated HTTP REST interface to public blockchain data
  • 683dc40 Disable SSLv3 (in favor of TLS) for the RPC client and server
  • 44b4c0d signrawtransaction: validate private key
  • 9765a50 Implement BIP 23 Block Proposal
  • f9de17e Add warning comment to getinfo
Command-line options:
  • ee21912 Use netmasks instead of wildcards for IP address matching
  • deb3572 Add -rpcbind option to allow binding RPC port on a specific interface
  • 96b733e Add -version option to get just the version
  • 1569353 Add -stopafterblockimport option
  • 77cbd46 Let -zapwallettxes recover transaction meta data
  • 1c750db remove -tor compatibility code (only allow -onion)
  • 4aaa017 rework help messages for fee-related options
  • 4278b1d Clarify error message when invalid -rpcallowip
  • 6b407e4 -datadir is now allowed in config files
  • bdd5b58 Add option -sysperms to disable 077 umask (create new files with system default umask)
  • cbe39a3 Add "bitcoin-tx" command line utility and supporting modules
  • dbca89b Trigger -alertnotify if network is upgrading without you
  • ad96e7c Make -reindex cope with out-of-order blocks
  • 16d5194 Skip reindexed blocks individually
  • ec01243 --tracerpc option for regression tests
  • f654f00 Change -genproclimit default to 1
  • 3c77714 Make -proxy set all network types, avoiding a connect leak
  • 57be955 Remove -printblock, -printblocktree, and -printblockindex
  • ad3d208 remove -maxorphanblocks config parameter since it is no longer functional
Block and transaction handling:
  • 7a0e84d ProcessGetData(): abort if a block file is missing from disk
  • 8c93bf4 LoadBlockIndexDB(): Require block db reindex if any blk*.dat files are missing
  • 77339e5 Get rid of the static chainMostWork (optimization)
  • 4e0eed8 Allow ActivateBestChain to release its lock on cs_main
  • 18e7216 Push cs_mains down in ProcessBlock
  • fa126ef Avoid undefined behavior using CFlatData in CScript serialization
  • 7f3b4e9 Relax IsStandard rules for pay-to-script-hash transactions
  • c9a0918 Add a skiplist to the CBlockIndex structure
  • bc42503 Use unordered_map for CCoinsViewCache with salted hash (optimization)
  • d4d3fbd Do not flush the cache after every block outside of IBD (optimization)
  • ad08d0b Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
  • 5734d4d Only remove actualy failed blocks from setBlockIndexValid
  • d70bc52 Rework block processing benchmark code
  • 714a3e6 Only keep setBlockIndexValid entries that are possible improvements
  • ea100c7 Reduce maximum coinscache size during verification (reduce memory usage)
  • 4fad8e6 Reject transactions with excessive numbers of sigops
  • b0875eb Allow BatchWrite to destroy its input, reducing copying (optimization)
  • 92bb6f2 Bypass reloading blocks from disk (optimization)
  • 2e28031 Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
  • ab15b2e Avoid copying undo data (optimization)
  • 341735e Headers-first synchronization
  • afc32c5 Fix rebuild-chainstate feature and improve its performance
  • e11b2ce Fix large reorgs
  • ed6d1a2 Keep information about all block files in memory
  • a48f2d6 Abstract context-dependent block checking from acceptance
  • 7e615f5 Fixed mempool sync after sending a transaction
  • 51ce901 Improve chainstate/blockindex disk writing policy
  • a206950 Introduce separate flushing modes
  • 9ec75c5 Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
  • 868d041 Remove coinbase-dependant transactions during reorg
  • 723d12c Remove txn which are invalidated by coinbase maturity during reorg
  • 0cb8763 Check against MANDATORY flags prior to accepting to mempool
  • 8446262 Reject headers that build on an invalid parent
  • 008138c Bugfix: only track UTXO modification after lookup
P2P protocol and network code:
  • f80cffa Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
  • c30329a Add testnet DNS seed of Alex Kotenko
  • 45a4baf Add testnet DNS seed of Andreas Schildbach
  • f1920e8 Ping automatically every 2 minutes (unconditionally)
  • 806fd19 Allocate receive buffers in on the fly
  • 6ecf3ed Display unknown commands received
  • aa81564 Track peers' available blocks
  • caf6150 Use async name resolving to improve net thread responsiveness
  • 9f4da19 Use pong receive time rather than processing time
  • 0127a9b remove SOCKS4 support from core and GUI, use SOCKS5
  • 40f5cb8 Send rejects and apply DoS scoring for errors in direct block validation
  • dc942e6 Introduce whitelisted peers
  • c994d2e prevent SOCKET leak in BindListenPort()
  • a60120e Add built-in seeds for .onion
  • 60dc8e4 Allow -onlynet=onion to be used
  • 3a56de7 addrman: Do not propagate obviously poor addresses onto the network
  • 6050ab6 netbase: Make SOCKS5 negotiation interruptible
  • 604ee2a Remove tx from AlreadyAskedFor list once we receive it, not when we process it
  • efad808 Avoid reject message feedback loops
  • 71697f9 Separate protocol versioning from clientversion
  • 20a5f61 Don't relay alerts to peers before version negotiation
  • b4ee0bd Introduce preferred download peers
  • 845c86d Do not use third party services for IP detection
  • 12a49ca Limit the number of new addressses to accumulate
  • 35e408f Regard connection failures as attempt for addrman
  • a3a7317 Introduce 10 minute block download timeout
  • 3022e7d Require sufficent priority for relay of free transactions
  • 58fda4d Update seed IPs, based on bitcoin.sipa.be crawler data
  • 18021d0 Remove bitnodes.io from dnsseeds.
Validation:
  • 6fd7ef2 Also switch the (unused) verification code to low-s instead of even-s
  • 584a358 Do merkle root and txid duplicates check simultaneously
  • 217a5c9 When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
  • f74fc9b Print input index when signature validation fails, to aid debugging
  • 6fd59ee script.h: set_vch() should shift a >32 bit value
  • d752ba8 Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
  • 698c6ab Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
  • ab9edbd script: create sane error return codes for script validation and remove logging
  • 219a147 script: check ScriptError values in script tests
  • 0391423 Discourage NOPs reserved for soft-fork upgrades
  • 98b135f Make STRICTENC invalid pubkeys fail the script rather than the opcode
  • 307f7d4 Report script evaluation failures in log and reject messages
  • ace39db consensus: guard against openssl's new strict DER checks
  • 12b7c44 Improve robustness of DER recoding code
  • 76ce5c8 fail immediately on an empty signature
Build system:
  • f25e3ad Fix build in OS X 10.9
  • 65e8ba4 build: Switch to non-recursive make
  • 460b32d build: fix broken boost chrono check on some platforms
  • 9ce0774 build: Fix windows configure when using --with-qt-libdir
  • ea96475 build: Add mention of --disable-wallet to bdb48 error messages
  • 1dec09b depends: add shared dependency builder
  • c101c76 build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
  • e432a5f build: add option for reducing exports (v2)
  • 6134b43 Fixing condition 'sabotaging' MSVC build
  • af0bd5e osx: fix signing to make Gatekeeper happy (again)
  • a7d1f03 build: fix dynamic boost check when --with-boost= is used
  • d5fd094 build: fix qt test build when libprotobuf is in a non-standard path
  • 2cf5f16 Add libbitcoinconsensus library
  • 914868a build: add a deterministic dmg signer
  • 2d375fe depends: bump openssl to 1.0.1k
  • b7a4ecc Build: Only check for boost when building code that requires it
Wallet:
  • b33d1f5 Use fee/priority estimates in wallet CreateTransaction
  • 4b7b1bb Sanity checks for estimates
  • c898846 Add support for watch-only addresses
  • d5087d1 Use script matching rather than destination matching for watch-only
  • d88af56 Fee fixes
  • a35b55b Dont run full check every time we decrypt wallet
  • 3a7c348 Fix make_change to not create half-satoshis
  • f606bb9 fix a possible memory leak in CWalletDB::Recover
  • 870da77 fix possible memory leaks in CWallet::EncryptWallet
  • ccca27a Watch-only fixes
  • 9b1627d [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
  • a53fd41 Deterministic signing
  • 15ad0b5 Apply AreSane() checks to the fees from the network
  • 11855c1 Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
GUI:
  • c21c74b osx: Fix missing dock menu with qt5
  • b90711c Fix Transaction details shows wrong To:
  • 516053c Make links in 'About Bitcoin Core' clickable
  • bdc83e8 Ensure payment request network matches client network
  • 65f78a1 Add GUI view of peer information
  • 06a91d9 VerifyDB progress reporting
  • fe6bff2 Add BerkeleyDB version info to RPCConsole
  • b917555 PeerTableModel: Fix potential deadlock. #4296
  • dff0e3b Improve rpc console history behavior
  • 95a9383 Remove CENT-fee-rule from coin control completely
  • 56b07d2 Allow setting listen via GUI
  • d95ba75 Log messages with type>QtDebugMsg as non-debug
  • 8969828 New status bar Unit Display Control and related changes
  • 674c070 seed OpenSSL PNRG with Windows event data
  • 509f926 Payment request parsing on startup now only changes network if a valid network name is specified
  • acd432b Prevent balloon-spam after rescan
  • 7007402 Implement SI-style (thin space) thoudands separator
  • 91cce17 Use fixed-point arithmetic in amount spinbox
  • bdba2dd Remove an obscure option no-one cares about
  • bd0aa10 Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
  • 94e1b9e Re-work overviewpage UI
  • 8bfdc9a Better looking trayicon
  • b197bf3 disable tray interactions when client model set to 0
  • 1c5f0af Add column Watch-only to transactions list
  • 21f139b Fix tablet crash. closes #4854
  • e84843c Broken addresses on command line no longer trigger testnet
  • a49f11d Change splash screen to normal window
  • 1f9be98 Disable App Nap on OSX 10.9+
  • 27c3e91 Add proxy to options overridden if necessary
  • 4bd1185 Allow "emergency" shutdown during startup
  • d52f072 Don't show wallet options in the preferences menu when running with -disablewallet
  • 6093aa1 Qt: QProgressBar CPU-Issue workaround
  • 0ed9675 [Wallet] Add global boolean whether to send free transactions (default=true)
  • ed3e5e4 [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
  • e7876b2 [Wallet] Prevent user from paying a non-sense fee
  • c1c9d5b Add Smartfee to GUI
  • e0a25c5 Make askpassphrase dialog behave more sanely
  • 94b362d On close of splashscreen interrupt verifyDB
  • b790d13 English translation update
  • 8543b0d Correct tooltip on address book page
Tests:
  • b41e594 Fix script test handling of empty scripts
  • d3a33fc Test CHECKMULTISIG with m == 0 and n == 0
  • 29c1749 Let tx (in)valid tests use any SCRIPT_VERIFY flag
  • 6380180 Add rejection of non-null CHECKMULTISIG dummy values
  • 21bf3d2 Add tests for BoostAsioToCNetAddr
  • b5ad5e7 Add Python test for -rpcbind and -rpcallowip
  • 9ec0306 Add CODESEPARATOFindAndDelete() tests
  • 75ebced Added many rpc wallet tests
  • 0193fb8 Allow multiple regression tests to run at once
  • 92a6220 Hook up sanity checks
  • 3820e01 Extend and move all crypto tests to crypto_tests.cpp
  • 3f9a019 added list/get received by address/ account tests
  • a90689f Remove timing-based signature cache unit test
  • 236982c Add skiplist unit tests
  • f4b00be Add CChain::GetLocator() unit test
  • b45a6e8 Add test for getblocktemplate longpolling
  • cdf305e Set -discover=0 in regtest framework
  • ed02282 additional test for OP_SIZE in script_valid.json
  • 0072d98 script tests: BOOLAND, BOOLOR decode to integer
  • 833ff16 script tests: values that overflow to 0 are true
  • 4cac5db script tests: value with trailing 0x00 is true
  • 89101c6 script test: test case for 5-byte bools
  • d2d9dc0 script tests: add tests for CHECKMULTISIG limits
  • d789386 Add "it works" test for bitcoin-tx
  • df4d61e Add bitcoin-tx tests
  • aa41ac2 Test IsPushOnly() with invalid push
  • 6022b5d Make script_{valid,invalid}.json validation flags configurable
  • 8138cbe Add automatic script test generation, and actual checksig tests
  • ed27e53 Add coins_tests with a large randomized CCoinViewCache test
  • 9df9cf5 Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
  • dcb9846 Extend getchaintips RPC test
  • 554147a Ensure MINIMALDATA invalid tests can only fail one way
  • dfeec18 Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
  • 2b62e17 Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
  • 16d78bd Add valid invert of invalid every numeric opcode tests
  • f635269 tests: enable alertnotify test for Windows
  • 7a41614 tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
  • 5122ea7 tests: fix forknotify.py on windows
  • fa7f8cd tests: remove old pull-tester scripts
  • 7667850 tests: replace the old (unused since Travis) tests with new rpc test scripts
  • f4e0aef Do signature-s negation inside the tests
  • 1837987 Optimize -regtest setgenerate block generation
  • 2db4c8a Fix node ranges in the test framework
  • a8b2ce5 regression test only setmocktime RPC call
  • daf03e7 RPC tests: create initial chain with specific timestamps
  • 8656dbb Port/fix txnmall.sh regression test
  • ca81587 Test the exact order of CHECKMULTISIG sig/pubkey evaluation
  • 7357893 Prioritize and display -testsafemode status in UI
  • f321d6b Add key generation/verification to ECC sanity check
  • 132ea9b miner_tests: Disable checkpoints so they don't fail the subsidy-change test
  • bc6cb41 QA RPC tests: Add tests block block proposals
  • f67a9ce Use deterministically generated script tests
  • 11d7a7d [RPC] add rpc-test for http keep-alive (persistent connections)
  • 34318d7 RPC-test based on invalidateblock for mempool coinbase spends
  • 76ec867 Use actually valid transactions for script tests
  • c8589bf Add actual signature tests
  • e2677d7 Fix smartfees test for change to relay policy
  • 263b65e tests: run sanity checks in tests too
Miscellaneous:
  • 122549f Fix incorrect checkpoint data for testnet3
  • 5bd02cf Log used config file to debug.log on startup
  • 68ba85f Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
  • e5ee8f0 Remove -beta suffix
  • 38405ac Add comment regarding experimental-use service bits
  • be873f6 Issue warning if collecting RandSeed data failed
  • 8ae973c Allocate more space if necessary in RandSeedAddPerfMon
  • 675bcd5 Correct comment for 15-of-15 p2sh script size
  • fda3fed libsecp256k1 integration
  • 2e36866 Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
  • cd01a5e Enable paranoid corruption checks in LevelDB >= 1.16
  • 9365937 Add comment about never updating nTimeOffset past 199 samples
  • 403c1bf contrib: remove getwork-based pyminer (as getwork API call has been removed)
  • 0c3e101 contrib: Added systemd .service file in order to help distributions integrate bitcoind
  • 0a0878d doc: Add new DNSseed policy
  • 2887bff Update coding style and add .clang-format
  • 5cbda4f Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
  • b4a72a7 contrib/linearize: split output files based on new-timestamp-year or max-file-size
  • e982b57 Use explicit fflush() instead of setvbuf()
  • 234bfbf contrib: Add init scripts and docs for Upstart and OpenRC
  • 01c2807 Add warning about the merkle-tree algorithm duplicate txid flaw
  • d6712db Also create pid file in non-daemon mode
  • 772ab0e contrib: use batched JSON-RPC in linarize-hashes (optimization)
  • 7ab4358 Update bash-completion for v0.10
  • 6e6a36c contrib: show pull # in prompt for github-merge script
  • 5b9f842 Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
  • 4e7c219 Catch UTXO set read errors and shutdown
  • 867c600 Catch LevelDB errors during flush
  • 06ca065 Fix CScriptID(const CScript& in) in empty script case
Credits

Thanks to everyone who contributed to this release:
  • 21E14
  • Adam Weiss
  • Aitor Pazos
  • Alexander Jeng
  • Alex Morcos
  • Alon Muroch
  • Andreas Schildbach
  • Andrew Poelstra
  • Andy Alness
  • Ashley Holman
  • Benedict Chan
  • Ben Holden-Crowther
  • Bryan Bishop
  • BtcDrak
  • Christian von Roques
  • Clinton Christian
  • Cory Fields
  • Cozz Lovan
  • daniel
  • Daniel Kraft
  • David Hill
  • Derek701
  • dexX7
  • dllud
  • Dominyk Tiller
  • Doug
  • elichai
  • elkingtowa
  • ENikS
  • Eric Shaw
  • Federico Bond
  • Francis GASCHET
  • Gavin Andresen
  • Giuseppe Mazzotta
  • Glenn Willen
  • Gregory Maxwell
  • gubatron
  • HarryWu
  • himynameismartin
  • Huang Le
  • Ian Carroll
  • imharrywu
  • Jameson Lopp
  • Janusz Lenar
  • JaSK
  • Jeff Garzik
  • JL2035
  • Johnathan Corgan
  • Jonas Schnelli
  • jtimon
  • Julian Haight
  • Kamil Domanski
  • kazcw
  • kevin
  • kiwigb
  • Kosta Zertsekel
  • LongShao007
  • Luke Dashjr
  • Mark Friedenbach
  • Mathy Vanvoorden
  • Matt Corallo
  • Matthew Bogosian
  • Micha
  • Michael Ford
  • Mike Hearn
  • mrbandrews
  • mruddy
  • ntrgn
  • Otto Allmendinger
  • paveljanik
  • Pavel Vasin
  • Peter Todd
  • phantomcircuit
  • Philip Kaufmann
  • Pieter Wuille
  • pryds
  • randy-waterhouse
  • R E Broadley
  • Rose Toomey
  • Ross Nicoll
  • Roy Badami
  • Ruben Dario Ponticelli
  • Rune K. Svendsen
  • Ryan X. Charles
  • Saivann
  • sandakersmann
  • SergioDemianLerner
  • shshshsh
  • sinetek
  • Stuart Cardall
  • Suhas Daftuar
  • Tawanda Kembo
  • Teran McKinney
  • tm314159
  • Tom Harding
  • Trevin Hofmann
  • Whit J
  • Wladimir J. van der Laan
  • Yoichi Hirai
  • Zak Wilcox
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Also lots of thanks to the bitcoin.org website team David A. Harding and Saivann Carignan.
Wladimir
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Dev++ 01-08-EN  Remote Procedure Calls (RPC) - Anditto Heristyo Bitcoin JSON-RPC Tutorial 2 - VPS Setup Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - YouTube Programming Bitcoin-qt using the RPC api (1 of 6) Bitcoin JSON-RPC Tutorial 1

JSON-RPC. A light weight remote procedure call protocol. It is designed to be simple! Site by Matt Morley of MPCM Technologies LLC, a manager of the JSON-RPC google group. ... This is what i am doing RPC_USER = username RPC_PASS = pasword rpc_id = ID ... : local variable 'response' referenced before assignment 17302/python-request-module-for-bitcoin-json-rpc Toggle navigation I recently received an ASIC miner, and I use the popular cgminer, an ASIC miner (written in C) for Bitcoin (and Litecoin).. Cgminer provides an RPC API that let you retrieve stats about your device(s), and I'm buidling an open source monitoring dashboard, RigsMonitoring writen in Python, accessing the API with Python is easy using sockets. Enable cgminer API If Bitcoin-SE is the incorrect place to post it, I apologize in advance; I'm new to SE and this was my best guess. I'm attempting, in order to better understand how Bitcoin mining works, to code a simple Bitcoin CPU miner in Java, which I have some but not much experience with. All the online resources on JSON-RPC implementation in Java I have ... RSK adds value and expand functionality to the Bitcoin ecosystem by providing smart contracts and greater scalability. The Stack ... JSON RPC methods; Management API methods; RPC PUB SUB methods; Note: request headers must contain the specification of "Content-Type:application/json" JSON RPC methods. Method Supported Comments; web3_clientVersion: YES web3_sha3: YES net_version: YES: Mainnet ...

[index] [32871] [9027] [47202] [36600] [43343] [12661] [41790] [1168] [10843] [1187]

Dev++ 01-08-EN Remote Procedure Calls (RPC) - Anditto Heristyo

An introduction to the Bitcoin JSON-RPC tutorial series. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U Bitcoin JSON-RPC tutorial. How to set up bitcoind on a VPS. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors ... REST API concepts and examples - Duration: 8:53. WebConcepts 4,225,052 views. 8:53. Edward Snowden: How Your Cell Phone Spies on You ... In this video I revisit an old topic where several things have changed since 2015 in regards to using the JSON-RPC to communicate with your node with an apache server with PHP. https://www.amazon ... Bitcoin JSON-RPC tutorial. How to set up and use bitcoind wallet notify feature. My Book: ... REST API concepts and examples - Duration: 8:53. WebConcepts 4,232,865 views. 8:53. Creating a ...

#