Bitcoind – Commands, RPC Protocol, Install Server

Peter McCormack makes his first Bitcoin RPC call...

(ring ring)
Woman: RPC Legal, how may I help you?
Peter: Hi, it's Peter McCormack can I speak to...
Woman (interrupts Peter): Ah hello Peter. Yes, we've all been expecting your call.
(woman laughs and some faint laughter of others is heard in the background)
Woman: I'll put you through to your solicitor.
(pause)
Solicitor: Peter. Good morning.
Peter: Hi I had a message to call you.
Solicitor: Yes. Not good news I'm afriad.
Peter: Oh?
Solicitor: Yes. I'm going to have to drop your case I'm afraid. Sorry, I can't represent you.
Peter: Huh? Why? What's happened?
Solicitor: Let me be blunt. Excuse the language. Are you a fucking idiot? What the heck were you doing on Twitter? Did you not think for one minute to actually go and investigate this Craig Wright yourself before slandering him?
Peter: Uh. Uh. But. But. What do you mean?
Solicitor: I can't represent you. Sorry.
Peter: What about the £100,000 I sent you? I want my money back.
Solicitor: Did you read the legal contract? I presume you didn't cause I did not Tweet it to you.
Peter: No. I want my money back.
Solicitor: Well if you read it you'll see that at this stage after our initial investigations of your case - or to be more honest what you seemed to think was a case, well you have to forefit 75% I'm afraid. It's in the contract.
Peter: That's not fair.
Solicitor: Life's not fair Peter. You did sign the contract. If you don't like it feel free to slander us here at RPC about it on Twitter and we'll collect a lot more from you.
Peter: So how much do I get back?
Solicitor: Well I can return £25,000 to you which is the 25%
Peter: Can you send me a cheque?
Solicitor: Hmmm. Well I didn't want to be sitting on the money so I invested it all. Is £25,000 worth of Bitcoin OK?
Peter: I guess so, as long as you pay the $5 transaction fee.
Solicitor: $5 transaction fee? What are you talking about? BSV transaction fee is less than a penny.
Peter: Whaaaaatttttt. You bought Bitcoin SV?
Solicitor: No I bought Bitcoin. Why do you call it Bitcoin SV? As far as I can see it is Bitcoin. I soon realised just how bad your case was Peter. But I kept reading and studying and I felt compelled to buy some.
Peter: What made you do that?
Solicitor: It's What Bitcoin Did Peter, it's What Bitcoin Did. Bye.
(click)
submitted by jim-btc to bitcoincashSV [link] [comments]

Peter McCormack makes his first Bitcoin RPC call...

(ring ring)
Woman: RPC Legal, how may I help you?
Peter: Hi, it's Peter McCormack can I speak to...
Woman (interrupts Peter): Ah hello Peter. Yes, we've all been expecting your call.
(woman laughs and some faint laughter of others is heard in the background)
Woman: I'll put you through to your solicitor.
(pause)
Solicitor: Peter. Good morning.
Peter: Hi I had a message to call you.
Solicitor: Yes. Not good news I'm afriad.
Peter: Oh?
Solicitor: Yes. I'm going to have to drop your case I'm afraid. Sorry, I can't represent you.
Peter: Huh? Why? What's happened?
Solicitor: Let me be blunt. Excuse the language. Are you a fucking idiot? What the heck were you doing on Twitter? Did you not think for one minute to actually go and investigate this Craig Wright yourself before slandering him?
Peter: Uh. Uh. But. But. What do you mean?
Solicitor: I can't represent you. Sorry.
Peter: What about the £100,000 I sent you? I want my money back.
Solicitor: Did you read the legal contract? I presume you didn't cause I did not Tweet it to you.
Peter: No. I want my money back.
Solicitor: Well if you read it you'll see that at this stage after our initial investigations of your case - or to be more honest what you seemed to think was a case, well you have to forefit 75% I'm afraid. It's in the contract.
Peter: That's not fair.
Solicitor: Life's not fair Peter. You did sign the contract. If you don't like it feel free to slander us here at RPC about it on Twitter and we'll collect a lot more from you.
Peter: So how much do I get back?
Solicitor: Well I can return £25,000 to you which is the 25%
Peter: Can you send me a cheque?
Solicitor: Hmmm. Well I didn't want to be sitting on the money so I invested it all. Is £25,000 worth of Bitcoin OK?
Peter: I guess so, as long as you pay the $5 transaction fee.
Solicitor: $5 transaction fee? What are you talking about? BSV transaction fee is less than a penny.
Peter: Whaaaaatttttt. You bought Bitcoin SV?
Solicitor: No I bought Bitcoin. Why do you call it Bitcoin SV? As far as I can see it is Bitcoin. I soon realised just how bad your case was Peter. But I kept reading and studying and I felt compelled to buy some.
Peter: What made you do that?
Solicitor: It's What Bitcoin Did Peter, it's What Bitcoin Did. Bye.
(click)
submitted by jim-btc to bitcoinsv [link] [comments]

"Bitcoin ABC 0.21.7 has been released. This release includes post-upgrade stability changes and 25% performance improvements for JSON RPC calls. Download it here: download.bitcoinabc.org/0.21.7/ "

submitted by Mr-Zwets to btc [link] [comments]

"Bitcoin ABC 0.21.7 has been released. This release includes post-upgrade stability changes and 25% performance improvements for JSON RPC calls. Download it here: download.bitcoinabc.org/0.21.7/ "

submitted by Mr-Zwets to Bitcoincash [link] [comments]

My Bitcoin tip-bot is currently undergoing testing for Segwit. Please donate some time to test it.

My reddit bitcoin tip-bot, TipBit is currently utilizing web APIs to check balances, complete transactions, etc... and that is not ideal. Because none of the web APIs had Segwit support, my bot couldn't handle withdrawal to a Segwit wallet, and nothing was done using Segwit internally either.
This didn't seem right... especially with me being a huge advocate for Segwit implementations... it's only right that I learn Bitcoin Node RPC calls and implement them into my own work.
So I updated my bot...
I have finally completed a version of the bot that uses Bitcoin RPC calls to handle everything, including giving all users a Segwit address and a legacy address, and handling all internal storage of funds in a Segwit wallet, and allowing for Segwit wallet withdrawals on top of the legacy withdrawals. Nothing is done with a web API, and the only one I'll be adding back in is the Web API check of the bitcoin price.
I'd like to thoroughly test this new version of the bot before I move it from Testnet to Mainnet, and I need testers for that purpose. I would appreciate it if anyone here could donate a bit of their time to go to the thread about the new bot and utilize the bot in any way you can think of, to make sure it works.
It follows the same rules as the original bot, so you should be able to register, do a sweep deposit, do a normal deposit, check balance, and tip your coins around. If you need free testnet coins to try out the bot, either go to this testnet faucet or just PM me and I'll deposit some into your test bot account once you're registered.
I can answer any questions below.
submitted by TipBitDev to Bitcoin [link] [comments]

My Bitcoin tip-bot is currently undergoing testing for Segwit. Please donate some time to test it.

My reddit bitcoin tip-bot, TipBit is currently utilizing web APIs to check balances, complete transactions, etc... and that is not ideal. Because none of the web APIs had Segwit support, my bot couldn't handle withdrawal to a Segwit wallet, and nothing was done using Segwit internally either.
This didn't seem right... especially with me being a huge advocate for Segwit implementations... it's only right that I learn Bitcoin Node RPC calls and implement them into my own work.
So I updated my bot...
I have finally completed a version of the bot that uses Bitcoin RPC calls to handle everything, including giving all users a Segwit address and a legacy address, and handling all internal storage of funds in a Segwit wallet, and allowing for Segwit wallet withdrawals on top of the legacy withdrawals. Nothing is done with a web API, and the only one I'll be adding back in is the Web API check of the bitcoin price.
I'd like to thoroughly test this new version of the bot before I move it from Testnet to Mainnet, and I need testers for that purpose. I would appreciate it if anyone here could donate a bit of their time to go to the thread about the new bot and utilize the bot in any way you can think of, to make sure it works.
It follows the same rules as the original bot, so you should be able to register, do a sweep deposit, do a normal deposit, check balance, and tip your coins around. If you need free testnet coins to try out the bot, either go to this testnet faucet or just PM me and I'll deposit some into your test bot account once you're registered.
I can answer any questions below.
submitted by TipBitDev to Bitcoin [link] [comments]

My Bitcoin tip-bot is currently undergoing testing for Segwit. Please donate some time to test it.

My reddit bitcoin tip-bot, TipBit is currently utilizing web APIs to check balances, complete transactions, etc... and that is not ideal. Because none of the web APIs had Segwit support, my bot couldn't handle withdrawal to a Segwit wallet, and nothing was done using Segwit internally either.
This didn't seem right... especially with me being a huge advocate for Segwit implementations... it's only right that I learn Bitcoin Node RPC calls and implement them into my own work.
So I updated my bot...
I have finally completed a version of the bot that uses Bitcoin RPC calls to handle everything, including giving all users a Segwit address and a legacy address, and handling all internal storage of funds in a Segwit wallet, and allowing for Segwit wallet withdrawals on top of the legacy withdrawals. Nothing is done with a web API, and the only one I'll be adding back in is the Web API check of the bitcoin price.
I'd like to thoroughly test this new version of the bot before I move it from Testnet to Mainnet, and I need testers for that purpose. If anyone here could donate a bit of their time to go to the thread about the new bot and utilize the bot in any way you can think of, to make sure it works.
It follows the same rules as the original bot, so you should be able to register, do a sweep deposit, do a normal deposit, check balance, and tip your coins around. If you need free testnet coins to try out the bot, either go to this testnet faucet or just PM me and I'll deposit some into your test bot account once you're registered.
I can answer any questions below.
submitted by TipBitDev to Bitcoin [link] [comments]

Are there bitcoin-cash full nodes open to issue RPC calls to without running my own?

Title!
submitted by wisequote to btc [link] [comments]

Configuring bitcoin full node for faster RPC calls

I have been working with a bitcoin full node and attempting to parse the blockchain data, whilst storing it in an external database.
The script I am using iterates through each block using getblock[hash;2] which populates multiple tables. However in order to get the current blocks input values we have to perform an expensive getRawTransaction each previous txid.
We have singled this out as the bottleneck in the code for most time taken, rendering the script very slow. We have also tried using RPC batching but this also takes considerable amount of time, potentially more with a memory overhead.
I am wondering if there is a best configuration of the daemon to improve RPC call speed? i.e. using rpcthread/queue, increasing dbcache etc.
Another option would be to implement blocks only mode, by reducing the bandwidth could this improve RPC commands?
Bitcoin Core Daemon version v0.16.0.0-g4b4d7eb255
Server Details OS-Ubuntu 16.04 32 GB ram
submitted by dandan4561 to Bitcoin [link] [comments]

Create wallet for bitcoin cash through Remote Procedure Call (rpc)

Currently I am developing an mobile app for coin exchange (Bitcoin, Ethereum, Bitcoin, Wowbit). I am using Bitcoin Unlimited as the platform for creating bitcoin cash wallet. Right now, only one wallet existed in bitcoin unlimited. I search command for creating bitcoin cash wallet, but found nothing. How I can create a wallet for bitcoin cash? Thank you.
submitted by polosemit to Bitcoincash [link] [comments]

Configuring bitcoin full node for faster RPC calls /r/Bitcoin

Configuring bitcoin full node for faster RPC calls /Bitcoin submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

Configuring bitcoin full node for faster RPC calls /r/Bitcoin

Configuring bitcoin full node for faster RPC calls /Bitcoin submitted by cryptoallbot to cryptoall [link] [comments]

Setting up a local bitcoin core server for json-rpc calls (testnet)?

Setting up a local bitcoin core server for json-rpc calls (testnet)? submitted by arcral to AlternativeCoin [link] [comments]

Setting up a local bitcoin core server for json-rpc calls (testnet)? /r/Bitcoin

Setting up a local bitcoin core server for json-rpc calls (testnet)? /Bitcoin submitted by HiIAMCaptainObvious to BitcoinAll [link] [comments]

Samourai Wallet connects to your node using the standard Bitcoin Remote Procedure Call (RPC) interface.

Samourai Wallet connects to your node using the standard Bitcoin Remote Procedure Call (RPC) interface. submitted by a56fg4bjgm345 to ledgerwallet [link] [comments]

Saw a few posts today about reddcoin ecommerce. osCommerce has a Bitcoin module. Since Reddcoin uses the same RPC calls, it should work for reddcoin...

Saw a few posts today about reddcoin ecommerce. osCommerce has a Bitcoin module. Since Reddcoin uses the same RPC calls, it should work for reddcoin... submitted by TheSciNerd to reddCoin [link] [comments]

Developers: Super-simple jQuery code for making JSON-RPC calls to Bitcoin Client

In working on some proof-of-concept stuff, I ran in to a bunch of issues communicating with the Bitcoin Client server. Though there are a number of existing libraries for both JSON-RPC in general, and communicating with the Bitcoin Client, they're all a bit heavier than I wanted. So, I dug through the source code and came up with the smallest, easiest way to connect to the server using nothing but some Javascript and jQuery:
$.ajax({ url: 'http://RPC_USERNAME:[email protected]:RPC_PORT', dataType: 'json', type: 'POST', contentType: 'application/json', data: '{"method": "API_METHOD"}', // For parameters: //data: '{"method": "API_METHOD", "params": ["PARAMETERS"]}', timeout: 15000, success: function(data) { // Response lives in data.result (data.result.version, etc) }, error: function(oops) { // oops.statusText returns error } }); 
Running this code will access a wallet on the same machine. I haven't done much testing of different calls or error handling, but this should be enough to get you started. Replace RPC_USERNAME, RPC_PASSWORD, and RPC_PORT (usually 8332) with the data set in your bitcoin.conf file, and reference the API calls list to see what you can do. With a properly-configured server, I imagine you could change 127.0.0.1 to a URL or IP and access a web-based client.
This code is 100% open and free for anyone to do whatever they want with it, obviously. No credit necessary. Consider it under a WTFPL License. I will kindly take Bitcoin donations, of course: 1KSEKy3XTRxJd7CqKciSsnx752VRaibBWr. Enjoy!
submitted by 54mf to Bitcoin [link] [comments]

Technical: The Path to Taproot Activation

Taproot! Everybody wants to have it, somebody wants to make it, nobody knows how to get it!
(If you are asking why everybody wants it, see: Technical: Taproot: Why Activate?)
(Pedants: I mostly elide over lockin times)
Briefly, Taproot is that neat new thing that gets us:
So yes, let's activate taproot!

The SegWit Wars

The biggest problem with activating Taproot is PTSD from the previous softfork, SegWit. Pieter Wuille, one of the authors of the current Taproot proposal, has consistently held the position that he will not discuss activation, and will accept whatever activation process is imposed on Taproot. Other developers have expressed similar opinions.
So what happened with SegWit activation that was so traumatic? SegWit used the BIP9 activation method. Let's dive into BIP9!

BIP9 Miner-Activated Soft Fork

Basically, BIP9 has a bunch of parameters:
Now there are other parameters (name, starttime) but they are not anywhere near as important as the above two.
A number that is not a parameter, is 95%. Basically, activation of a BIP9 softfork is considered as actually succeeding if at least 95% of blocks in the last 2 weeks had the specified bit in the nVersion set. If less than 95% had this bit set before the timeout, then the upgrade fails and never goes into the network. This is not a parameter: it is a constant defined by BIP9, and developers using BIP9 activation cannot change this.
So, first some simple questions and their answers:

The Great Battles of the SegWit Wars

SegWit not only fixed transaction malleability, it also created a practical softforkable blocksize increase that also rebalanced weights so that the cost of spending a UTXO is about the same as the cost of creating UTXOs (and spending UTXOs is "better" since it limits the size of the UTXO set that every fullnode has to maintain).
So SegWit was written, the activation was decided to be BIP9, and then.... miner signalling stalled at below 75%.
Thus were the Great SegWit Wars started.

BIP9 Feature Hostage

If you are a miner with at least 5% global hashpower, you can hold a BIP9-activated softfork hostage.
You might even secretly want the softfork to actually push through. But you might want to extract concession from the users and the developers. Like removing the halvening. Or raising or even removing the block size caps (which helps larger miners more than smaller miners, making it easier to become a bigger fish that eats all the smaller fishes). Or whatever.
With BIP9, you can hold the softfork hostage. You just hold out and refuse to signal. You tell everyone you will signal, if and only if certain concessions are given to you.
This ability by miners to hold a feature hostage was enabled because of the miner-exit allowed by the timeout on BIP9. Prior to that, miners were considered little more than expendable security guards, paid for the risk they take to secure the network, but not special in the grand scheme of Bitcoin.

Covert ASICBoost

ASICBoost was a novel way of optimizing SHA256 mining, by taking advantage of the structure of the 80-byte header that is hashed in order to perform proof-of-work. The details of ASICBoost are out-of-scope here but you can read about it elsewhere
Here is a short summary of the two types of ASICBoost, relevant to the activation discussion.
Now, "overt" means "obvious", while "covert" means hidden. Overt ASICBoost is obvious because nVersion bits that are not currently in use for BIP9 activations are usually 0 by default, so setting those bits to 1 makes it obvious that you are doing something weird (namely, Overt ASICBoost). Covert ASICBoost is non-obvious because the order of transactions in a block are up to the miner anyway, so the miner rearranging the transactions in order to get lower power consumption is not going to be detected.
Unfortunately, while Overt ASICBoost was compatible with SegWit, Covert ASICBoost was not. This is because, pre-SegWit, only the block header Merkle tree committed to the transaction ordering. However, with SegWit, another Merkle tree exists, which commits to transaction ordering as well. Covert ASICBoost would require more computation to manipulate two Merkle trees, obviating the power benefits of Covert ASICBoost anyway.
Now, miners want to use ASICBoost (indeed, about 60->70% of current miners probably use the Overt ASICBoost nowadays; if you have a Bitcoin fullnode running you will see the logs with lots of "60 of last 100 blocks had unexpected versions" which is exactly what you would see with the nVersion manipulation that Overt ASICBoost does). But remember: ASICBoost was, at around the time, a novel improvement. Not all miners had ASICBoost hardware. Those who did, did not want it known that they had ASICBoost hardware, and wanted to do Covert ASICBoost!
But Covert ASICBoost is incompatible with SegWit, because SegWit actually has two Merkle trees of transaction data, and Covert ASICBoost works by fudging around with transaction ordering in a block, and recomputing two Merkle Trees is more expensive than recomputing just one (and loses the ASICBoost advantage).
Of course, those miners that wanted Covert ASICBoost did not want to openly admit that they had ASICBoost hardware, they wanted to keep their advantage secret because miners are strongly competitive in a very tight market. And doing ASICBoost Covertly was just the ticket, but they could not work post-SegWit.
Fortunately, due to the BIP9 activation process, they could hold SegWit hostage while covertly taking advantage of Covert ASICBoost!

UASF: BIP148 and BIP8

When the incompatibility between Covert ASICBoost and SegWit was realized, still, activation of SegWit stalled, and miners were still not openly claiming that ASICBoost was related to non-activation of SegWit.
Eventually, a new proposal was created: BIP148. With this rule, 3 months before the end of the SegWit timeout, nodes would reject blocks that did not signal SegWit. Thus, 3 months before SegWit timeout, BIP148 would force activation of SegWit.
This proposal was not accepted by Bitcoin Core, due to the shortening of the timeout (it effectively times out 3 months before the initial SegWit timeout). Instead, a fork of Bitcoin Core was created which added the patch to comply with BIP148. This was claimed as a User Activated Soft Fork, UASF, since users could freely download the alternate fork rather than sticking with the developers of Bitcoin Core.
Now, BIP148 effectively is just a BIP9 activation, except at its (earlier) timeout, the new rules would be activated anyway (instead of the BIP9-mandated behavior that the upgrade is cancelled at the end of the timeout).
BIP148 was actually inspired by the BIP8 proposal (the link here is a historical version; BIP8 has been updated recently, precisely in preparation for Taproot activation). BIP8 is basically BIP9, but at the end of timeout, the softfork is activated anyway rather than cancelled.
This removed the ability of miners to hold the softfork hostage. At best, they can delay the activation, but not stop it entirely by holding out as in BIP9.
Of course, this implies risk that not all miners have upgraded before activation, leading to possible losses for SPV users, as well as again re-pressuring miners to signal activation, possibly without the miners actually upgrading their software to properly impose the new softfork rules.

BIP91, SegWit2X, and The Aftermath

BIP148 inspired countermeasures, possibly from the Covert ASiCBoost miners, possibly from concerned users who wanted to offer concessions to miners. To this day, the common name for BIP148 - UASF - remains an emotionally-charged rallying cry for parts of the Bitcoin community.
One of these was SegWit2X. This was brokered in a deal between some Bitcoin personalities at a conference in New York, and thus part of the so-called "New York Agreement" or NYA, another emotionally-charged acronym.
The text of the NYA was basically:
  1. Set up a new activation threshold at 80% signalled at bit 4 (vs bit 1 for SegWit).
    • When this 80% signalling was reached, miners would require that bit 1 for SegWit be signalled to achive the 95% activation needed for SegWit.
  2. If the bit 4 signalling reached 80%, increase the block weight limit from the SegWit 4000000 to the SegWit2X 8000000, 6 months after bit 1 activation.
The first item above was coded in BIP91.
Unfortunately, if you read the BIP91, independently of NYA, you might come to the conclusion that BIP91 was only about lowering the threshold to 80%. In particular, BIP91 never mentions anything about the second point above, it never mentions that bit 4 80% threshold would also signal for a later hardfork increase in weight limit.
Because of this, even though there are claims that NYA (SegWit2X) reached 80% dominance, a close reading of BIP91 shows that the 80% dominance was only for SegWit activation, without necessarily a later 2x capacity hardfork (SegWit2X).
This ambiguity of bit 4 (NYA says it includes a 2x capacity hardfork, BIP91 says it does not) has continued to be a thorn in blocksize debates later. Economically speaking, Bitcoin futures between SegWit and SegWit2X showed strong economic dominance in favor of SegWit (SegWit2X futures were traded at a fraction in value of SegWit futures: I personally made a tidy but small amount of money betting against SegWit2X in the futures market), so suggesting that NYA achieved 80% dominance even in mining is laughable, but the NYA text that ties bit 4 to SegWit2X still exists.
Historically, BIP91 triggered which caused SegWit to activate before the BIP148 shorter timeout. BIP148 proponents continue to hold this day that it was the BIP148 shorter timeout and no-compromises-activate-on-August-1 that made miners flock to BIP91 as a face-saving tactic that actually removed the second clause of NYA. NYA supporters keep pointing to the bit 4 text in the NYA and the historical activation of BIP91 as a failed promise by Bitcoin developers.

Taproot Activation Proposals

There are two primary proposals I can see for Taproot activation:
  1. BIP8.
  2. Modern Softfork Activation.
We have discussed BIP8: roughly, it has bit and timeout, if 95% of miners signal bit it activates, at the end of timeout it activates. (EDIT: BIP8 has had recent updates: at the end of timeout it can now activate or fail. For the most part, in the below text "BIP8", means BIP8-and-activate-at-timeout, and "BIP9" means BIP8-and-fail-at-timeout)
So let's take a look at Modern Softfork Activation!

Modern Softfork Activation

This is a more complex activation method, composed of BIP9 and BIP8 as supcomponents.
  1. First have a 12-month BIP9 (fail at timeout).
  2. If the above fails to activate, have a 6-month discussion period during which users and developers and miners discuss whether to continue to step 3.
  3. Have a 24-month BIP8 (activate at timeout).
The total above is 42 months, if you are counting: 3.5 years worst-case activation.
The logic here is that if there are no problems, BIP9 will work just fine anyway. And if there are problems, the 6-month period should weed it out. Finally, miners cannot hold the feature hostage since the 24-month BIP8 period will exist anyway.

PSA: Being Resilient to Upgrades

Software is very birttle.
Anyone who has been using software for a long time has experienced something like this:
  1. You hear a new version of your favorite software has a nice new feature.
  2. Excited, you install the new version.
  3. You find that the new version has subtle incompatibilities with your current workflow.
  4. You are sad and downgrade to the older version.
  5. You find out that the new version has changed your files in incompatible ways that the old version cannot work with anymore.
  6. You tearfully reinstall the newer version and figure out how to get your lost productivity now that you have to adapt to a new workflow
If you are a technically-competent user, you might codify your workflow into a bunch of programs. And then you upgrade one of the external pieces of software you are using, and find that it has a subtle incompatibility with your current workflow which is based on a bunch of simple programs you wrote yourself. And if those simple programs are used as the basis of some important production system, you hve just screwed up because you upgraded software on an important production system.
And well, one of the issues with new softfork activation is that if not enough people (users and miners) upgrade to the newest Bitcoin software, the security of the new softfork rules are at risk.
Upgrading software of any kind is always a risk, and the more software you build on top of the software-being-upgraded, the greater you risk your tower of software collapsing while you change its foundations.
So if you have some complex Bitcoin-manipulating system with Bitcoin somewhere at the foundations, consider running two Bitcoin nodes:
  1. One is a "stable-version" Bitcoin node. Once it has synced, set it up to connect=x.x.x.x to the second node below (so that your ISP bandwidth is only spent on the second node). Use this node to run all your software: it's a stable version that you don't change for long periods of time. Enable txiindex, disable pruning, whatever your software needs.
  2. The other is an "always-up-to-date" Bitcoin Node. Keep its stoarge down with pruning (initially sync it off the "stable-version" node). You can't use blocksonly if your "stable-version" node needs to send transactions, but otherwise this "always-up-to-date" Bitcoin node can be kept as a low-resource node, so you can run both nodes in the same machine.
When a new Bitcoin version comes up, you just upgrade the "always-up-to-date" Bitcoin node. This protects you if a future softfork activates, you will only receive valid Bitcoin blocks and transactions. Since this node has nothing running on top of it, it is just a special peer of the "stable-version" node, any software incompatibilities with your system software do not exist.
Your "stable-version" Bitcoin node remains the same version until you are ready to actually upgrade this node and are prepared to rewrite most of the software you have running on top of it due to version compatibility problems.
When upgrading the "always-up-to-date", you can bring it down safely and then start it later. Your "stable-version" wil keep running, disconnected from the network, but otherwise still available for whatever queries. You do need some system to stop the "always-up-to-date" node if for any reason the "stable-version" goes down (otherwisee if the "always-up-to-date" advances its pruning window past what your "stable-version" has, the "stable-version" cannot sync afterwards), but if you are technically competent enough that you need to do this, you are technically competent enough to write such a trivial monitor program (EDIT: gmax notes you can adjust the pruning window by RPC commands to help with this as well).
This recommendation is from gmaxwell on IRC, by the way.
submitted by almkglor to Bitcoin [link] [comments]

BCH JSON RPC Calls List?

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

Upcoming Major Riecoin 0.20 Upgrade

Upcoming Major Riecoin 0.20 Upgrade
A new major Riecoin upgrade is planned, and includes a hard fork. Below is a summary of the changes so far and the hard fork improvements. More details can be found on BitcoinTalk. Feel free to ask Pttn there or on Discord if you have questions regarding the update.
The first step of this upgrade was to update the base code to Bitcoin’s 0.20, which is done. You can find the experimental code at the Github repository. Experimental binaries can also be downloaded here. Despite their prerelease status, they should work fine, though please backup your wallets if you plan to use 0.20, just in case.
Pool operators and other advanced Riecoin users should start looking into the changes and update their software accordingly, as well as closely follow the Riecoin Core development.
Here is a list of notable changes from 0.16.3.1.
The next step will be the hard fork, in order to improve Riecoin in multiple ways. Here is the list of planned changes.
Once the development is advanced enough, a date will be chosen for the hard fork. Testnet will be hardforked first to ensure the well functioning of the implementation. Stay tuned!
submitted by PttnMe to RieCoin [link] [comments]

PYRK Tokens and future plans for their development

PYRK Tokens and future plans for their development
Hello. 👋🏻 In this post, we will tell you about PYRK Tokens and future plans for their development.
💡 Crypto coins halving is an event when the reward for mining new blocks is halved. When this happens, miners begin to receive 50% less for transaction processing. Usually, halving occurs approximately once every 200,000 blocks, for Bitcoin it is approximately every four years. It is planned to carry out halving until the maximum volume is reached.
❗️ The PYRK system uses quite a different approach to limiting mining inflation. So-called halving will occur every 200,000 units, and supply will be reduced by 20%.
❗️ Other cryptocurrencies usually implement a 50% halving. We, however, decided to reduce it to 20% to reduce the initial shock impact of a halving event.
✅ Total supply of PYRK coins becomes logarithmic due to the halving nature. And, thus, a maximum total supply will be approximately 100 Million Pyrk. According to our calculations, approximately 50% of the maximum supply will be mined in the first 3 years.
✅ The PYRK team also plans an improvement - Simple Tokens. The idea is something similar to the SLP (Simple Ledger Protocol) used by Bitcoin Cash and ERC Tokens used by Ethererum. Our protocol is easier to create and use than both.
✅ One of the issues with using the Bitcoin Cash system is that the functionality of Tokens are not built into the core client, therefore to use or integrate tokens requires additional programming libraries. Second, while the BCH chain is strong, is it also slow, with a block average of 10 minutes. This is fine for large transactions, but if you want to send transactions quickly this becomes an issue. The Pyrk blockchain has an average block time of 90 seconds. Last, the transaction fees on the BCH network will be higher in USD value than a similar transaction on the Pyrk blockchain.
✅ Ethereum ERC-20 tokens are also a popular choice, however these tokens require programming a contract using the Solidity language of Ethereum. If you don’t program your contract correctly, you could end up having big problems later on. Pyrk has taken out all the guess work in creating tokens and offers two of the most popular token types. Fungible tokens, which are tokens that are replaceable with each other and have equal value. These are the same as ERC-20. The other type is Non-Fungible tokens, in which each token is unique. Each of these token types has their own use case depending on the users needs.
✅ The Pyrk token system will be built into the core RPC functionality of the Pyrk software client. Anybody who has the Pyrk wallet can create, send, and receive tokens in seconds. This makes integration with exchanges easier as well.
Read more about PYRK Token ar https://www.pyrk.org/Pyrk-Whitepaper.pdf
And check our website for more information: https://www.pyrk.org
https://preview.redd.it/vxvj2qphqq151.png?width=1200&format=png&auto=webp&s=e000f611b48fb522c38abed2be8c7f25301819be
submitted by VS_community to pyrk [link] [comments]

Technical details of the Earthcoin network 2019

Technical details of the Earthcoin network 2019
Blockchain parameters
crypt hashing algorithm
Proof of Work (POW) mining
60 seconds block target
Difficulty retarget after each block (+167%, -91%)
Total coins will be 13.5 billion coins (infinite by a theory, because the minimal block reward is 1 EAC, but in the practice 13.5*109 will not be exceeded within the next 2000 years)
50 confirmations per minted block
5 confirmations per transaction
Supports transaction messages
Initial block reward on average 10,000 EAC, varies seasonly ( currently 625 EAC) Block payout is halved every year, minimum payout of 1 EAC per block Superblocks every 14 and 31 day The default ports are 35677 (P2P-network) and 15678 (RPC-calls, optional)
Transaction speed
The mechanism behind Earthcoin which is based on peer-to-peer, allows transactions to happen very quickly. This means that once you pay or get payed with Earthcoin, the time taken to see the money transferred is equal or sometimes faster than the avarege debit card. Earthcoin promotes transaction times of approximatly 30 seconds where it is actually closer to 10-15 seconds which is nowadays regarded as being instant. The true strength behind this speed is the abillity to use it in any store in the near future with the same feel of speed as the currency you hold today.
Security
The Earthcoin network had been attacked by a 51% attack and controlled by a group of hackers for several months in the middle of 2017. Thanks to the unwavering efforts of the community, the attack was thrown back and EarthCoin was returned to all users. The source code was then fixed, secured against similar attacks in the future and a unique protection against time travel attack was implemented. The EarthCoin code is now much more secure than most of other cryptocurrencies. In the first half of 2019, a major upgrade of the Earthcoin network was done and security features according to the current blockchain protocol of Bitcoin and Litecoin networks were implemented.
From:http://deveac.com/technical.html
submitted by zongyongge to Earthcoin [link] [comments]

Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors Bitcoin JSON-RPC Tutorial 5 - Your First Calls Bitcoin JSON-RPC Tutorial 1 Bitcoin JSON-RPC Tutorial 4 - Command Line Interface Bitcoin Tarot Crypto Calls - YouTube

Accounts explained • API calls list • API reference (JSON-RPC) • Block chain download • Dump format • getblocktemplate • List of address prefixes • Protocol documentation • Script • Technical background of version 1 Bitcoin addresses • Testnet • Transaction Malleability • Wallet import format $ ./bitcoind -daemon bitcoin server starting $ ./bitcoin-cli -rpcwait help # shows the help text A list of RPC calls will be shown. $ ./bitcoin-cli getbalance 2000.00000 If you are learning the API, it is a very good idea to use the test network (run bitcoind -testnet and bitcoin-cli -testnet). JSON-RPC Commands sent over the JSON-RPC interface and through the bitcoin-cli binary can now use named arguments. This follows the JSON-RPC specification for passing parameters by-name with an object. The RPC calls are deprecated and will either return -1 or 1e24 appropriately. Making RPC calls with bitcoin-cli. You can use the same bitcoind executable to make RPC calls (just by adding an RPC method at the end of command line), but this is depreciated, and you're now supposed to use bitcoin-cli for this purpose. How to Do RPC Calls with C++ Bitcoind . bitcoin deamon = core value of the software (bitcoind -printtoconsole -debug=1) Bitcoind provide the RPC "interface" in which user can query with bitcoin-cli (or a library in c++). You must run bitcoind before using bitcoin-cli.

[index] [23961] [11389] [11694] [19427] [11294] [3626] [27108] [319] [5238] [18703]

Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors

An introduction to the Bitcoin JSON-RPC tutorial series. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U. Bitcoin JSON-RPC Tutorial 5 - Your First Calls ... Bitcoin JSON-RPC Tutorial 5 - Your First Calls - Duration: 10:06. m1xolyd1an 12,264 views. 10:06. IN-SHADOW - A Modern Odyssey ... Gold will be explosive, unlike anything we’ve seen says Canada’s billionaire Frank Giustra - Duration: 20:47. Kitco NEWS Recommended for you Programming Interview: Remote Procedure Call in Operating System - Duration: 10:44. ... Bitcoin JSON-RPC Tutorial 5 - Your First Calls - Duration: 10:06. m1xolyd1an 11,838 views. Bitcoin JSON-RPC tutorial. Getting started with the bitcoin command line interface. ... Bitcoin JSON-RPC Tutorial 5 - Your First Calls - Duration: 10:06. m1xolyd1an 11,288 views.

Flag Counter