Get Started


Aeon (AEON) is a private, secure, untraceable currency. You are your bank, you control your funds, and nobody can trace your transfers.

Could not connect to Bitcoin Core using JSON-RPC error message when launching Eclair

Hi! I am new to the Lightning Network and I am seeking to install a Lighting Network full node on my PC.

I already have Bitcoin Core installed and my full bitcoin node working (version 0.17.1).

I went through some steps to install the LN full node on a video on YouTube, following instructions from a Medium post: "How to run a Lightning Network node on Windows" (

I installed Eclair (v0.2-beta9) from their Github page.

But when I try to launch Eclair (with my Bitcoin Core node up and running), an error message pops us, saying:
Could not connect to Bitcoin Core using JSON-RPC.
Make sure that Bitcoin Core is up and running and RPC parameters are correct.

Here is what I have in my Bitcoin Core .conf file:


And in my eclair.conf file:


By the way, I went through an old thread on the same topic (, but the solutions proposed did not work for me.

Your help would be greatly appreciated :-) Thanks!
submitted by swisscrypto77 to lightningnetwork [link] [comments]

I got bored last night, so I made a mobile RPC wallet for Bitcoin Cash. Connect to your full node wallet, and use it whenever, wherever.

I got bored last night, so I made a mobile RPC wallet for Bitcoin Cash. Connect to your full node wallet, and use it whenever, wherever. submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

"could not connect to bitcoin core using json-rpc" Eclair Wallet Windows

Hello @ all,
could you please help me and tell me what i did wrong?
Many thanks in advance
submitted by Lebowski36 to lightningnetwork [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]

Can anyone run RPC commands on my full node if I run bitcoind or bitcoin-qt connected to the internet?

Is RPC completely disabled if I don't include bitcoin.conf in my bitcoin directory, and if it's there, does bitcoind open ports automatically that allow anyone to RPC on my node?
submitted by sonkeypop to Bitcoin [link] [comments]

Did remove their public rpc api? I can't seem to connect anymore? /r/Bitcoin

Did remove their public rpc api? I can't seem to connect anymore? /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Can anyone run RPC commands on my full node if I run bitcoind or bitcoin-qt connected to the internet? /r/Bitcoin

Can anyone run RPC commands on my full node if I run bitcoind or bitcoin-qt connected to the internet? /Bitcoin submitted by HiIAMCaptainObvious to BitcoinAll [link] [comments]

Connection string for RPC when there's no user_name and password /r/Bitcoin

Connection string for RPC when there's no user_name and password /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

RPC over internet -- how to secure/encrypt the connection? /r/Bitcoin

RPC over internet -- how to secure/encrypt the connection? /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Are there any Bitcoin clients that can RPC connect to a Bitcoind server?

I'm running the original Bitcoin wallet on my server, and I wanted a graphical client that I can run on my desktop that can rpc connect to my server, but I can't seem to find any.
The Bitcoin-qt doesn't support rpcconnect ( which is very strange! it should support it :().
Does anyone know of any client that does support it?
submitted by intahnetmonster to BitcoinBeginners [link] [comments]

Cannot connect to Bitcoin RPC

I'd really appreciate some help, I'm running amd64 debian squeeze and I've downloaded the bitcoin client, poclbm, and phoenix. I'm trying to pool mine at and I've used "./ -u -p --host= --port=8337 -d 0" which returns "Problems communicating with bitcoin RPC". I also tried "./ -u DEVICE=0" and that returns [16/06/2011 17:43:44] Phoenix r101 starting... [16/06/2011 17:43:44] Failed to connect, retrying..." Obviously I've added in my user and password.
Here are the two devices I can use:
[0] AMD Phenom(tm) II X4 955 Processor [1] ATI RV730
And here is my lspci -v:
01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon >HD 4670] (prog-if 00 [VGA controller]) Subsystem: Hightech Information System Ltd. Device 2009 Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at fe9e0000 (64-bit, non-prefetchable) [size=64K] I/O ports at c000 [size=256] Expansion ROM at fe9c0000 [disabled] [size=128K] Capabilities: Kernel driver in use: fglrx_pci
If anyone can shine some light on the subject or just guide me in the right direction that would be great, thanks.
submitted by hexabyte to BitcoinMining [link] [comments]

Bitcoin HD wallet with RPC connection C# library

Hey guys, I'm building site where i would like to use HD addresses to separate generating and watching addresses for customer and controling those addresses. Currently im using bitcoind, which has nice library BitcoinLib available through NuGet. However as far as i know it doesnt support HD addresses. Does any other combination of C# library + wallet support HD addresses? thanks
submitted by GereG to Bitcoin [link] [comments]

Bitcoin HD wallet with RPC connection C# library /r/Bitcoin

Bitcoin HD wallet with RPC connection C# library /Bitcoin submitted by coincrazyy to BitcoinAll [link] [comments]

Algorithm for starting to accept payments in BTC?

I'm a developer and run a full node of Bitcoin.
I have several shops where I plan to start accepting bitcoin payments. The volume I invision in the beginning would be rather small.
(1) What'd be a simple algorithm for how to get started with it?
Would I have to generate (N of shops * 100) addresses first? And then map each of 100 to a shop? And then at checkout give a user one of those addresses and then watch when the 1st confirmation arrives, by doing poll requests from my shop to my full node server, remotely, via RPC?

(2) Also, how would I actually properly create a wallet for this? I'll need that wallet to be watch-only.
(3) Would I be able to somehow connect my Electrum client-wallet to that bitcoin watch-only wallet so that I could see how much of bitcoins there're in it, from my laptop in a more convenient manner?

I don't consider third-party solutions such as BTC server or Electrum server. I use Electrum as a wallet only, on desktop.
submitted by artjuna_0900 to btc [link] [comments]

Gridcoin "Fern" Release
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.



Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.


Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.


The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog



Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.







As a reminder:









Detailed Changelog

[] 2020-09-03, mandatory, "Fern"





submitted by jamescowens to gridcoin [link] [comments]

Are there any public nodes available for test payment?

Hi. Sorry if this is off-topic, failed to find any response at /cryptodevs.Started exploring cryptodev few days ago. It was not long before i faced the problem of hosting Bitcoin Core node - my current workstation fails to meet both network bandwidth and storage capacity requirements. I think need to find some adequate hosting to continue my experiments. Nevertheless, I expect this task will take some time, while I'd be pleased to start testing my software ASAP. Are there any "public" nodes that I can connect to (using RPC) for a single test payment? If not, what hosting can you advice to use for Core node?
Predicting your voices - yes, i do know about testnet, and i use it quite a lot, but now i need to test my soft in real world conditions. Thanks.
submitted by n0d1fference2me to Bitcoin [link] [comments]

How to Convert Reddit MOONS to Dai (and then Ethereum, Bitcoin, fiat etc)

There are already good resources out there such as:,Click%20%E2%80%9CSEND%20MOONS%E2%80%9D
Hopefully, the guide below can help fill in any blanks or give you an alternate route. Please note this is a long and fairly complex process and runs the risk of loosing MOONs and small amounts of Ethereum and Dai which are used in the transfer process. I take no responsibility for individuals using this guide and it is up to you to research other resources and do your due diligence.

  1. Post engaging content, comments or memes...
  2. Hope that you get upvotes
  3. The more upvotes you get, the more MOONS (a cryptocurrency token) at the end of the month you get
  4. These MOONS are tokens on the Rinkeby Test Network, not the main Ethereum blockchain
  5. Now time to convert these MOONS to Ethereum, Bitcoin, fiat etc
  6. Please note that I am not responsible for any loss of funds beyond this point to proceed with caution!!!
  7. You will want to link your reddit MOONS account to a Metamask account
  8. Download Metamask if you haven't already (it's a Chrome app)
  9. Find out the seed phrase for your Reddit Moons Wallet (don't share this with anyone and keep it safe!). Do this by opening the reddit app and clicking on 'Vault' on the left hand menu
  10. Then click the three little dots next to Vault (at the top)
  11. Now click Recovery Phrase
  12. Write this down with pen and paper
  13. Now open Metamask and import your seed phrase to link the account (Note that your MOONS will probably not appear yet, will get to that later)
  14. Next up we are going to want to go to the exchange where we can swap our MOON tokens for Eth (although it is not as straightforward a process as you might think)
  16. You will see that this exchange has three sections. The first allows us to exchange MOONS (on the Rinkeby blockchain) to XMOONS (on the XDai blockchain, where Gas fees are paid in XDai rather than Eth). The second section allows us to exchange XMOONS for XDai. The third section allows us to exchange XDai for good old fashioned Ethereum (on the actual Ethereum blockchain).
  17. Before we get started with any exchanging, we need to configure metamask a bit.
  18. First up we are going to make Metamask show the MOONS that we have. To do this, change the network from 'Main Ethereum Network' to 'Rinkeby Test Network' at the top dropdown menu. Now click 'Add Token' and custom token. Now input the following:
  19. Token contract address: 0xDF82c9014F127243CE1305DFE54151647d74B27A
  20. Click next once
  21. Now click back (weird I know)
  22. In the decimals of precision enter 18
  23. You should now be able to see the correct number of MOONS and this should match the amount you saw on your vault in Reddit
  24. In preparation for later we are also going to want to add the xDai network to our metamask
  25. To do this click on that drop down at the top of top of metamask again and click Custom RPC
  26. Now enter exactly what is shown here
  27. Still with me? Now we are going to get to exchanging
  28. Switch metamask back to Rinkeby Test Network and on click 'connect' and follow the instructions shown on metamask
  29. We are also going to need some Rinkeby Ethereum (don't worry it's free since its just a test network, go to to get some (don't need much)
  30. Now click MOON to xMOON and convert the amount you want to!
  31. This process can take quite a while (took me 30 mins) so grab a coffee
  32. To check if you have xMOONs now, change your metamask over to xDai network
  33. They should appear on the site
  34. Next we want to convert these xMoon's into xDai, however, we have to have some xDai in there in the first place to pay for the gas (remember that this xDai blockchain uses xDai to pay for gas not Eth!). To do this, buy some Dai (20 USD should do) in your favourite way (normal exchange, DeFi, etc.) and transfer it to your Metamask account Eth account (ON THE MAIN ETHEREUM BLOCKCHAIN, DON'T USE RINKEBY!). Also transfer around 10 USD worth of Eth to your metamask to cover any gas fees on the Main Ethereum Blockchain side of things.
  35. Great, now while keeping Metamask on the Main Ethereum Blockchain, click DAI to xDAI and convert around10-20 USD.
  36. Once this xDai has shown up (again could take a while), switch metamask back over to xDai blockchain and click xMOON to xDai (this should be fairly quick)
  37. Now click xDai to Dai (might take a while again, don't panic like I did!)
  38. You should now have Dai on the Ethereum blockchain held in your metamask (which you can see once you switch metamask back over to Main Ethereum)
  39. Feel free now to do with the Dai whatever you wish! Send to an exchange and swap to BTC or Eth, keep a hold of in metamask etc etc

Please feel free to offer comments and corrections in the comments :)

Edit 1: Typo fix!
submitted by christophertacon to CryptoCurrency [link] [comments]

RPC Specify wallet for each command?

Hello there. I made a post on bitcoin about a week ago here asking for help with loading wallets in rpc. I got that sorted and now I'm moving onto working with Monero
I am able to connect to bitcoin-wallet-rpc which is connected to my local testnet daemon but if I want to interact with a users wallet I have to unload all the other wallets to make sure I am interacting with the right one because I can't seem to work out how to specify which wallet for each command.
The solution with BTC was to add /wallet/ onto the end of the service_url but there dosn't seem to be anything like that in XMR.
Am I missing something obvious? Any help appreciated!!
submitted by AnAsepticAttack to Monero [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]

How to run two bitcoind processes in isolation (Windows)

I have a synced node, and I would like to create a pruned copy of that node without destroying all blocks and chainstate I already have. My thought would be to run two copies of bitcoin {BitcoinA.exe, BitcoinB.exe}, while offline and bound to Both A and B point to each other through a connect or addnode config setting. My thought would be that now the "blank" bitcoin node (BitcoinB) would download and prune all the block data from BitcoinA via localhost.
I can imagine that I'd need separate data, block and chainstate dirs. I'll need separate rpc-cookies and separate ports.
Obviously I could just do the 300 GB file copy then do a rescan, but I figured I'd get faster IO on localhost<->localhost than disk<->disk.
Surely this is a fairly common way to clone block data. Has anyone done this before? Thoughts or advice?
submitted by brianddk to Bitcoin [link] [comments]

Is there a python (or other) library to send raw bitcoin protocol commands to a peer?

From the protocol docs, there are some interesting low level commands that aren't really surfaced in the client RPC API. Is there a python, ruby or nodejs library that will allow you to connect to peers and send protocol commands?
Something like:
python start python connect python send_command getheaders python stop
submitted by brianddk to Bitcoin [link] [comments]

Raspibolt troubles: bitcoind shutting down, out of space?

Hey y'all. Had my node running for some 19-20 months now. Following the Stadicus guide. on a raspberry pi 3. Bitcoin v0.19.0.1
the other day I just checked up on it and noticed it was in a failed state and didn't have the HDD mounted. The log seems to indicate it just stopped, the last entry is
2020-08-21T17:35:41Z socket recv error Connection reset by peer (104) 
I did the troubleshooting guide (no stranger to this) figuring there had been a power outage possibly. I ran fsck and it took a LONG while to find and clean up a lot of errors. The drive works fine, i can connect to it via my pc (using linux file systems paragon) transfer files.. etc. I ran fsck another time or two to be sure and no errors found. It's got 57% free space.
I got the raspberry pi to mount the HDD again, started up bitcoind and it started to sync slowly. I'd check with getblockchain info and figured it would take around 60+ hours to finish and left it overnight.
Today I come back to find it was no longer syncing. Now no matter what I do, starting bitcoind manually, or having it automatically boot getblockchain info gives me an error
error: Could not connect to the server Make sure the bitcoind server is running and that you are connecting to the correct RPC port. 
So bitcoind seems to shutdown instantly after starting it. AND checking the log, the last message from the 21st (above) is all that's there, no new information in the log.
I tried to re-install bitcoin v0.19.0.1 and got a suspect. When extracting the package into the tmp folder, it fails due to out of space errors. So this possibly means something is going on with the SD card? or something filled it up? Not sure what to check, or how really.
curiously the startup script for the raspibolt displays this for the SSD. Not sure how to interpret that. 36M free?
 SSD 36M (240%) 
here i'm stuck, what can I try next? I believe I have backups of the important information. I'd like to avoid a total reformatting if at all possible.
submitted by mabezard to lightningnetwork [link] [comments]

How to Hack bitcoin server mining app - YouTube Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors Unencrypted RPC & Multiparty ECDSA ~ Bitcoin op Tech #18 A breif introduction to the Chain Query Bitcoin RPC API Bitcoin JSON-RPC Tutorial 5 - Your First Calls - YouTube

JSON-RPC. Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a HTTP JSON-RPC server, but Basic access authentication must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use ... bitcoin-rpc-client. This is a lightweight java bitcoind JSON-RPC client binding. It does not require any external dependencies. Maven. The package is published in the wf.bitcoin group and you can add it to you pom.xml adding a section like this: After doing changes in bitcoin config file, I just reduce the range of records to be inserted. RPC server cannot handle loads of data at one time. Otherwise, server down problem occurs and connection failed. Max 100 records get inserted at a time or less than that. And one more thing, keep restarting bitcoind RPC server by stop and start commands given below: The second method uses JSON-RPC. This is a common interface that allows you to connect to bitcoind and execute commands from any language - and possibly even from another computer. The Bitcoin Wiki has a page with a detailed description of some ways to make a JSON-RPC call in various programming languages. For brevity, only two are listed. In ... Individuals, businesses, developers: learn from our simple Bitcoin guides. How Bitcoin works, what is Bitcoin, what is blockchain, how to buy Bitcoin, what is Bitcoin mining and more.

[index] [10333] [37024] [1361] [10551] [47860] [19856] [25310] [16953] [27976] [3853]

How to Hack bitcoin server mining app - YouTube

This video is unavailable. Watch Queue Queue. Watch Queue Queue Do subscribe and share Bitcoin JSON-RPC tutorial. Making your first bitcoin JSON-RPC calls in PHP. My Book: The Bitcoin Operations Technology Group (Optech) works to bring the best open source technologies and techniques to Bitcoin-using businesses in order to lower costs and improve customer ... Bitcoin JSON-RPC tutorial. Handling JSON, entering parameters and receiving error messages. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U.