bitcoin core - How to configure rpcallowip with rpcbind ...
Rpcallowip Bitcoin CryptoCoins Info Club
How to resolve issues with feature mempool.space (local on myNode)
At first check that into bitcoin.conf there are the follow lines: rpcbind=0.0.0.0 rpcallowip=127.0.0.1 rpcallowip=10.0.0.0/8 rpcallowip=220.127.116.11/8 rpcallowip=192.0.0.0/8 if reinstalling app from settings - > Reinstall Applications -> Mempool.Space didn't work, try these steps:
check with "docker ps" that mempool docker is present
disable Mempool.Space from GUI
check with "docker ps" that mempool docker isn't present anymore
from CLI: "docker rm mempoolspace"
now from GUI enable again Mempool.Space
check with "docker logs mempoolspace -f" if mempool is fetching blocks and wait until all blocks are fetched. You have to wait a lot of time.. but if logs are going well without errors is ok!
Connecting bitcoin-qt to bitcoind on local network
Hello, I have a bitcoin node running on a headless box (bitcoind) and I would like to connect to it using bitcoin-qt on my desktop. I'm getting a little confused with the process.... does bitcoin-qt need to connect to bitcoind using RPC? Do I store my wallet file on the bitcoind box, or bitcoin-qt box? The bitcoin node is already setup to work with an electrum server, so I already have rpcbind=0.0.0.0, rpcallowip=$ELECTRUX_IP, and rpcuserpcpassword set. I tried adding my desktop IP to rpcallowip, and setting the appropriate username/password in bitcoin-qt's bitcoin.conf, but no luck. I can see in debug.log for bitcoin-qt that the connection is rejected. The node runs over TOR and I have onlynet=onion set in bitcoind's bitcoin.conf, but that doesn't seem to stop electrumx connecting via RPC over clearnet, so this shouldn't be an issue right? Am I missing something here? Help would be much appreciated!
Wassabi modifications to bitcoin.conf makes port 8333 unreachable
I've been trying to track down why my bitcoin node can't be reached through port 8333, even though I have correct port forwarding rules set up on my router, and have allowed traffic on 8333 on my firewall. I checked bitcoin.conf, and noticed a section at the bottom modified by Wasabi: main.listen = 1 main.whitebind = 127.0.0.1:8333 main.rpcbind = 127.0.0.1 main.rpcallowip = 127.0.0.1 main.rpcport = 8332 I can't remember making these changes, but I suppose it's possible. Would these bitcoin.conf changes have been made Wasabi? There was a comment at the bottom of bitcoin.conf saying these changes were made through wassabee. At any rate, commenting them out restored normal bitcoin connectivity. My port can be seen as open at canyouseeme.org. What are the implications to Wasabi of leaving these lines commented out? Edit: spelling Edit 2: Clarification
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.
Builds are now done through Gitian
Calls to getblocktemplate will fail if the segwit rule is not specified. Calling getblocktemplate without segwit specified is almost certainly a misconfiguration since doing so results in lower rewards for the miner. Failed calls will produce an error message describing how to enable the segwit rule.
A warning is printed if an unrecognized section name is used in the configuration file. Recognized sections are [test], [main], and [regtest].
Four new options are available for configuring the maximum number of messages that ZMQ will queue in memory (the "high water mark") before dropping additional messages. The default value is 1,000, the same as was used for previous releases.
The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:1441:1441 (this is an extra :1441 over the normal Docker port specification).
The rpcpassword option now causes a startup error if the password set in the configuration file contains a hash character (#), as it's ambiguous whether the hash character is meant for the password or as a comment.
The whitelistforcerelay option is used to relay transactions from whitelisted peers even when not accepted to the mempool. This option now defaults to being off, so that changes in policy and disconnect/ban behavior will not cause a node that is whitelisting another to be dropped by peers.
A new short about the JSON-RPC interface describes cases where the results of anRPC might contain inconsistencies between data sourced from differentsubsystems, such as wallet state and mempool state.
A new document introduces Groestlcoin Core's BIP174 interface, which is used to allow multiple programs to collaboratively work to create, sign, and broadcast new transactions. This is useful for offline (cold storage) wallets, multisig wallets, coinjoin implementations, and many other cases where two or more programs need to interact to generate a complete transaction.
The output script descriptor (https://github.com/groestlcoin/groestlcoin/blob/mastedoc/descriptors.md) documentation has been updated with information about new features in this still-developing language for describing the output scripts that a wallet or other program wants to receive notifications for, such as which addresses it wants to know received payments. The language is currently used in multiple new and updated RPCs described in these release notes and is expected to be adapted to other RPCs and to the underlying wallet structure.
A new --disable-bip70 option may be passed to ./configure to prevent Groestlcoin-Qt from being built with support for the BIP70 payment protocol or from linking libssl. As the payment protocol has exposed Groestlcoin Core to libssl vulnerabilities in the past, builders who don't need BIP70 support are encouraged to use this option to reduce their exposure to future vulnerabilities.
The minimum required version of Qt (when building the GUI) has been increased from 5.2 to 5.5.1 (the depends system provides 5.9.7)
getnodeaddresses returns peer addresses known to this node. It may be used to find nodes to connect to without using a DNS seeder.
listwalletdir returns a list of wallets in the wallet directory (either the default wallet directory or the directory configured bythe -walletdir parameter).
getrpcinfo returns runtime details of the RPC server. Currently, it returns an array of the currently active commands and how long they've been running.
deriveaddresses returns one or more addresses corresponding to an output descriptor.
getdescriptorinfo accepts a descriptor and returns information aboutit, including its computed checksum.
joinpsbts merges multiple distinct PSBTs into a single PSBT. The multiple PSBTs must have different inputs. The resulting PSBT will contain every input and output from all the PSBTs. Any signatures provided in any of the PSBTs will be dropped.
analyzepsbt examines a PSBT and provides information about what the PSBT contains and the next steps that need to be taken in order to complete the transaction. For each input of a PSBT, analyze psbt provides information about what information is missing for that input, including whether a UTXO needs to be provided, what pubkeys still need to be provided, which scripts need to be provided, and what signatures are still needed. Every input will also list which role is needed to complete that input, and analyzepsbt will also list the next role in general needed to complete the PSBT. analyzepsbt will also provide the estimated fee rate and estimated virtual size of the completed transaction if it has enough information to do so.
utxoupdatepsbt searches the set of Unspent Transaction Outputs (UTXOs) to find the outputs being spent by the partial transaction. PSBTs need to have the UTXOs being spent to be provided because the signing algorithm requires information from the UTXO being spent. For segwit inputs, only the UTXO itself is necessary. For non-segwit outputs, the entire previous transaction is needed so that signers can be sure that they are signing the correct thing. Unfortunately, because the UTXO set only contains UTXOs and not full transactions, utxoupdatepsbt will only add the UTXO for segwit inputs.
getpeerinfo now returns an additional minfeefilter field set to the peer's BIP133 fee filter. You can use this to detect that you have peers that are willing to accept transactions below the default minimum relay fee.
The mempool RPCs, such as getrawmempool with verbose=true, now return an additional "bip125-replaceable" value indicating whether thetransaction (or its unconfirmed ancestors) opts-in to asking nodes and miners to replace it with a higher-feerate transaction spending any of the same inputs.
settxfee previously silently ignored attempts to set the fee below the allowed minimums. It now prints a warning. The special value of"0" may still be used to request the minimum value.
getaddressinfo now provides an ischange field indicating whether the wallet used the address in a change output.
importmulti has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH, and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept an additional witnessscript parameter.
importmulti now returns an additional warnings field for each request with an array of strings explaining when fields are being ignored or are inconsistent, if there are any.
getaddressinfo now returns an additional solvable Boolean field when Groestlcoin Core knows enough about the address's scriptPubKey, optional redeemScript, and optional witnessScript for the wallet to be able to generate an unsigned input spending funds sent to that address.
The getaddressinfo, listunspent, and scantxoutset RPCs now return an additional desc field that contains an output descriptor containing all key paths and signing information for the address (except for the private key). The desc field is only returned for getaddressinfo and listunspent when the address is solvable.
importprivkey will preserve previously-set labels for addresses or public keys corresponding to the private key being imported. For example, if you imported a watch-only address with the label "coldwallet" in earlier releases of Groestlcoin Core, subsequently importing the private key would default to resetting the address's label to the default empty-string label (""). In this release, the previous label of "cold wallet" will be retained. If you optionally specify any label besides the default when calling importprivkey, the new label will be applied to the address.
getmininginfo now omits currentblockweight and currentblocktx when a block was never assembled via RPC on this node.
The getrawtransaction RPC & REST endpoints no longer check the unspent UTXO set for a transaction. The remaining behaviors are as follows:
If a blockhash is provided, check the corresponding block.
If no blockhash is provided, check the mempool.
If no blockhash is provided but txindex is enabled, also check txindex.
unloadwallet is now synchronous, meaning it will not return until the wallet is fully unloaded.
importmulti now supports importing of addresses from descriptors. A desc parameter can be provided instead of the "scriptPubKey" in are quest, as well as an optional range for ranged descriptors to specify the start and end of the range to import. Descriptors with key origin information imported through importmulti will have their key origin information stored in the wallet for use with creating PSBTs.
listunspent has been modified so that it also returns witnessScript, the witness script in the case of a P2WSH orP2SH-P2WSH output.
createwallet now has an optional blank argument that can be used to create a blank wallet. Blank wallets do not have any keys or HDseed. They cannot be opened in software older than 2.18.2. Once a blank wallet has a HD seed set (by using sethdseed) or private keys, scripts, addresses, and other watch only things have been imported, the wallet is no longer blank and can be opened in 2.17.2. Encrypting a blank wallet will also set a HD seed for it.
signrawtransaction is removed after being deprecated and hidden behind a special configuration option in version 2.17.2.
The 'account' API is removed after being deprecated in v2.17.2 The 'label' API was introduced in v2.17.2 as a replacement for accounts. See the release notes from v2.17.2 for a full description of the changes from the 'account' API to the 'label' API.
addwitnessaddress is removed after being deprecated in version 2.16.0.
generate is deprecated and will be fully removed in a subsequent major version. This RPC is only used for testing, but its implementation reached across multiple subsystems (wallet and mining), so it is being deprecated to simplify the wallet-node interface. Projects that are using generate for testing purposes should transition to using the generatetoaddress RPC, which does not require or use the wallet component. Calling generatetoaddress with an address returned by the getnewaddress RPC gives the same functionality as the old generate RPC. To continue using generate in this version, restart groestlcoind with the -deprecatedrpc=generate configuration option.
Be reminded that parts of the validateaddress command have been deprecated and moved to getaddressinfo. The following deprecated fields have moved to getaddressinfo: ismine, iswatchonly,script, hex, pubkeys, sigsrequired, pubkey, embedded,iscompressed, label, timestamp, hdkeypath, hdmasterkeyid.
The addresses field has been removed from the validateaddressand getaddressinfo RPC methods. This field was confusing since it referred to public keys using their P2PKH address. Clients should use the embedded.address field for P2SH or P2WSH wrapped addresses, and pubkeys for inspecting multisig participants.
A new /rest/blockhashbyheight/ endpoint is added for fetching the hash of the block in the current best blockchain based on its height (how many blocks it is after the Genesis Block).
A new Window menu is added alongside the existing File, Settings, and Help menus. Several items from the other menus that opened new windows have been moved to this new Window menu.
In the Send tab, the checkbox for "pay only the required fee" has been removed. Instead, the user can simply decrease the value in the Custom Fee rate field all the way down to the node's configured minimumrelay fee.
In the Overview tab, the watch-only balance will be the only balance shown if the wallet was created using the createwallet RPC and thedisable_private_keys parameter was set to true.
The launch-on-startup option is no longer available on macOS if compiled with macosx min version greater than 10.11 (useCXXFLAGS="-mmacosx-version-min=10.11" CFLAGS="-mmacosx-version-min=10.11" for setting the deployment sdkversion)
A new groestlcoin-wallet tool is now distributed alongside Groestlcoin Core's other executables. Without needing to use any RPCs, this tool can currently create a new wallet file or display some basic information about an existing wallet, such as whether the wallet is encrypted, whether it uses an HD seed, how many transactions it contains, and how many address book entries it has.
Since version 2.16.0, Groestlcoin Core's built-in wallet has defaulted to generating P2SH-wrapped segwit addresses when users want to receive payments. These addresses are backwards compatible with all widely used software. Starting with Groestlcoin Core 2.20.1 (expected about a year after 2.18.2), Groestlcoin Core will default to native segwitaddresses (bech32) that provide additional fee savings and other benefits. Currently, many wallets and services already support sending to bech32 addresses, and if the Groestlcoin Core project sees enough additional adoption, it will instead default to bech32 receiving addresses in Groestlcoin Core 2.19.1. P2SH-wrapped segwit addresses will continue to be provided if the user requests them in the GUI or by RPC, and anyone who doesn't want the update will be able to configure their default address type. (Similarly, pioneering users who want to change their default now may set the addresstype=bech32 configuration option in any Groestlcoin Core release from 2.16.0 up.)
BIP 61 reject messages are now deprecated. Reject messages have no use case on the P2P network and are only logged for debugging by most network nodes. Furthermore, they increase bandwidth and can be harmful for privacy and security. It has been possible to disable BIP 61 messages since v2.17.2 with the -enablebip61=0 option. BIP 61 messages will be disabled by default in a future version, before being removed entirely.
The submitblock RPC previously returned the reason a rejected block was invalid the first time it processed that block but returned a generic "duplicate" rejection message on subsequent occasions it processed the same block. It now always returns the fundamental reason for rejecting an invalid block and only returns "duplicate" for valid blocks it has already accepted.
A new submitheader RPC allows submitting block headers independently from their block. This is likely only useful for testing.
The signrawtransactionwithkey and signrawtransactionwithwallet RPCs have been modified so that they also optionally accept a witnessScript, the witness script in the case of a P2WSH orP2SH-P2WSH output. This is compatible with the change to listunspent.
For the walletprocesspsbt and walletcreatefundedpsbt RPCs, if thebip32derivs parameter is set to true but the key metadata for a public key has not been updated yet, then that key will have a derivation path as if it were just an independent key (i.e. no derivation path and its master fingerprint is itself).
The -usehd configuration option was removed in version 2.16.0 From that version onwards, all new wallets created are hierarchical deterministic wallets. This release makes specifying -usehd an invalid configuration option.
This release allows peers that your node automatically disconnected for misbehaviour (e.g. sending invalid data) to reconnect to your node if you have unused incoming connection slots. If your slots fill up, a misbehaving node will be disconnected to make room for nodes without a history of problems (unless the misbehaving node helps your node in some other way, such as by connecting to a part of the Internet from which you don't have many other peers). Previously, Groestlcoin Core banned the IP addresses of misbehaving peers for a period (default of 1 day); this was easily circumvented by attackers with multiple IP addresses. If you manually ban a peer, such as by using the setban RPC, all connections from that peer will still be rejected.
The key metadata will need to be upgraded the first time that the HDseed is available. For unencrypted wallets this will occur on wallet loading. For encrypted wallets this will occur the first time the wallet is unlocked.
Newly encrypted wallets will no longer require restarting the software. Instead such wallets will be completely unloaded and reloaded to achieve the same effect.
A sub-project of Bitcoin Core now provides Hardware Wallet Interaction (HWI) scripts that allow command-line users to use several popular hardware key management devices with Groestlcoin Core. See their project page for details.
This release changes the Random Number Generator (RNG) used from OpenSSL to Groestlcoin Core's own implementation, although entropy gathered by Groestlcoin Core is fed out to OpenSSL and then read back in when the program needs strong randomness. This moves Groestlcoin Core a little closer to no longer needing to depend on OpenSSL, a dependency that has caused security issues in the past. The new implementation gathers entropy from multiple sources, including from hardware supporting the rdseed CPU instruction.
On macOS, Groestlcoin Core now opts out of application CPU throttling ("app nap") during initial blockchain download, when catching up from over 100 blocks behind the current chain tip, or when reindexing chain data. This helps prevent these operations from taking an excessively long time because the operating system is attempting to conserve power.
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
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.
Groestlcoin Mainnet & Testnet supported
Multiple wallet support
Electrum - Support for both random and custom peers
Biometric + Pin authentication
Custom fee selection
Import mnemonic phrases via manual entry or scanning
BIP39 Passphrase functionality
Support for Segwit-compatible & legacy addresses in settings
Support individual private key sweeping
UTXO blacklisting - Accessible via the Transaction Detail view, this allows users to blacklist any utxo that they do not wish to include in their list of available utxo's when sending transactions. Blacklisting a utxo excludes its amount from the wallet's total balance.
Ability to Sign & Verify Messages
Support BitID for password-free authentication
Coin Control - This can be accessed from the Send Transaction view and basically allows users to select from a list of available UTXO's to include in their transaction.
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.
Simplified payment verification for fast mobile performance
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.
If a word is wrong, the tool will try to suggest the closest option.
If a word is missing or unknown, please type "?" instead and the tool will find all relevant options.
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).
Fixed size arithmetic
Fast Modular Inversion (Delayed Right Shift 62 bits)
SecpK1 Fast modular multiplication (2 steps folding 512bits to 256bits using 64 bits digits)
Use some properties of elliptic curve to generate more keys
SSE Secure Hash Algorithm SHA256 and RIPEMD160 (CPU)
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).
Ability to continue finding keys after first one is found
Includes warning on start-up if connected to the internet
Ability to output keys to a text file (And shows button to open that directory)
Show and hide the private key with a simple toggle switch
Show full output of commands
Ability to choose between Processor (CPU) and Graphics Card (GPU) ( NVidia ONLY! )
Features both a Light and Dark Material Design-Style Themes
Free software - MIT. Anyone can audit the code.
Written in C# - The code is short, and easy to review.
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.
Works via TOR or SOCKS5 proxy
Can use bootstrap.dat format as blockchain database
Import/Export blockchain to/from bootstrap.dat
Import wallet.dat from Groestlcoin-qt wallet
Export wallet to wallet.dat
Use both groestlcoin-wpf and groestlcoin-qt with the same addresses in parallel. When you send money from one program, the transaction will automatically be visible on the other wallet.
Rescan blockchain with a simple mouse click
Works as a full node and listens to port 1331 (listening port can be changed)
Fast Block verifying, parallel processing on multi-core CPUs
Mine Groestlcoins with your CPU by a simple mouse click
All private keys are kept encrypted on your local machine (or on a USB stick)
Lite - Has a lightweight "thin client" mode which does not require a new user to download the entire Groestlcoin chain and store it
Free and decentralised - Open Source under GNU license
Fixed Import/Export to wallet.dat
Rescan wallet option
Change wallet password option
Address type and Change type options through *.conf file
Import from bootstrap.dat - It is a flat, binary file containing Groestlcoin blockchain data, from the genesis block through a recent height. All versions automatically validate and import the file "grs.bootstrap.dat" in the GRS directory. Grs.bootstrap.dat is compatible with Qt wallet. GroestlCoin-Qt can load from it.
In Full mode file %APPDATA%\Groestlcoin-WPF\GRS\GRS.bootstrap.dat is full blockchain in standard bootstrap.dat format and can be used with other clients.
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.
Use your own node
Uses less CPU and RAM than ElectrumX
Used intermittently rather than needing to be always-on
Doesn't require an index of every Groestlcoin address ever used like on ElectrumX
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.
Add confidence messages, helping users to understand the confidence state of their payments.
Handle edge case when restoring via an external app.
Count devices with a memory class of 128 MB as low ram.
Introduce dark mode on Android 10 devices.
Reduce memory usage of PIN-protected wallets.
Tapping on the app's version will reveal a checksum of the APK that was installed.
Fix issue with confirmation of transactions that empty your wallet.
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.
Can i set my phone to connect to my own node during the initial block download?
I try to connect my phone to my node, but i get an error. Do I need to wait until the initial block download finishes? Update: I resolved the issue by adding the following to by bitcoin.conf rpcallowip=MY_PHONES_IP/24 rpcallowip=MY_NODES_IP/24 rpcport=8333 I was using 8332 in my Bitcoin.conf and also on my phone. I was port forwarding 8332 to my node. I don't know why this port not working. I used 'telnet MY_NODES_IP 8332' on another computer and the connection did not connect, however I tried 8333 for grins and laughs; which connected... In bitcoin.conf, once I changed my rpcport to 8333, my phone connected to my node on my local network. Are there any downsides to setting the rpcport to 8333? Thanks so much for everyone's help!!! rpcbind=10.0.0.4
[DEVELOPMENT] Bitcoind IPV4 testnet port (18332) is failing to bind
[SOLVED] Thanks for everyone that have helped!
Hello everyone, this is a development problem that I'm currently having. Since the BTC Development sub is kind of inactive and I couldn't find any rule contraty to posting about BTC Development, I'll try my luck in here as I'm hopeless already. I've posted on BTC Stack Exchange but no answers also. Please, don't get me wrong, I'm trying to solve this problem for many days now, I've looked up everywhere for this. I'm new to Bitcoin development and I'm currently having difficulties trying to make RPC calls from a Docker Container to a Bitcoin-Core daemon running in a SSH server. I suppose that the problem may be with Firewall or closed ports, but I also do not know much about Network settings. I'm using nbobtc/bitcoind-php package to make the RPC calls with HTTP requests, and it is running in a Docker container. I'm sure the container is functional and is not the problem. So here's what happening: when I run bitcoind in root user (but normal also won't work) in my SSH server, the IPV4 testnet port seems to be not opened. This message goes up when I run bitcoind:
Here's what my bitcoin.conf looks like (I want to use testnet in here). I'm using Bitcoin-Core "subversion": "Satoshi:0.17.1".
server=1 debug=net txindex=1 testnet=1 rpcuser=userb rpcpassword=test test.rpcport=18332 # I've already tried allowing the IP these 3 ways: # rpcallowip=192.168.xx.xx # My machine's IP # rpcallowip=172.19.x.x/xx # Docker's NBOBTC container IP # rpcallowip=0.0.0.0/0 # Allowing all IP datadir=/home/bitcoin-dev/.bitcoin debuglogfile=/home/bitcoin-dev/.bitcoin/debug.log
Here's what appears in debug.log right after I run Bitcoind:
2019-05-06T14:43:10Z Bitcoin Core version v0.17.1 (release build) 2019-05-06T14:43:10Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1 2019-05-06T14:43:10Z Assuming ancestors of block 0000000000000037a8cd3e06cd5edbfe9dd1dbcc5dacab279376ef7cfc2b4c75 have valid signatures. 2019-05-06T14:43:10Z Setting nMinimumChainWork=00000000000000000000000000000000000000000000007dbe94253893cbd463 2019-05-06T14:43:10Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation 2019-05-06T14:43:10Z Default data directory /root/.bitcoin 2019-05-06T14:43:10Z Using data directory /home/bitcoin-dev/.bitcoin/testnet3 2019-05-06T14:43:10Z Using config file /home/bitcoin-dev/.bitcoin/bitcoin.conf 2019-05-06T14:43:10Z Using at most 125 automatic connections (1024 file descriptors available) 2019-05-06T14:43:10Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements 2019-05-06T14:43:10Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements 2019-05-06T14:43:10Z Using 4 threads for script verification 2019-05-06T14:43:10Z scheduler thread start 2019-05-06T14:43:10Z Binding RPC on address 0.0.0.0 port 18332 failed. 2019-05-06T14:43:10Z HTTP: creating work queue of depth 16 2019-05-06T14:43:10Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation. 2019-05-06T14:43:10Z HTTP: starting 4 worker threads 2019-05-06T14:43:10Z Using wallet directory /home/bitcoin-dev/.bitcoin/testnet3/wallets 2019-05-06T14:43:10Z init message: Verifying wallet(s)... 2019-05-06T14:43:10Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010) 2019-05-06T14:43:10Z Using wallet wallet.dat 2019-05-06T14:43:10Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin-dev/.bitcoin/testnet3/wallets/database ErrorFile=/home/bitcoin-dev/.bitcoin/testnet3/wallets/db.log 2019-05-06T14:43:10Z net: setting try another outbound peer=false 2019-05-06T14:43:10Z Cache configuration: 2019-05-06T14:43:10Z * Using 2.0MiB for block index database 2019-05-06T14:43:10Z * Using 56.0MiB for transaction index database 2019-05-06T14:43:10Z * Using 8.0MiB for chain state database 2019-05-06T14:43:10Z * Using 384.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space) 2019-05-06T14:43:10Z init message: Loading block index... 2019-05-06T14:43:10Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/blocks/index 2019-05-06T14:43:10Z Opened LevelDB successfully 2019-05-06T14:43:10Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/blocks/index: 0000000000000000 2019-05-06T14:43:19Z LoadBlockIndexDB: last block file = 161 2019-05-06T14:43:19Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=755, size=30875345, heights=1513309...1514061, time=2019-04-29...2019-05-03) 2019-05-06T14:43:19Z Checking all blk files are present... 2019-05-06T14:43:20Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/chainstate 2019-05-06T14:43:20Z Opened LevelDB successfully 2019-05-06T14:43:20Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/chainstate: 2686d59caeb1917c 2019-05-06T14:43:20Z Loaded best chain: hashBestChain=00000000b3b6a5db140b6058b7abe5cb00d8af61afd2a237ae3468cd36e387fa height=927391 date=2016-09-08T15:04:00Z progress=0.311180 2019-05-06T14:43:20Z init message: Rewinding blocks... 2019-05-06T14:43:29Z init message: Verifying blocks... 2019-05-06T14:43:29Z Verifying last 6 blocks at level 3 2019-05-06T14:43:29Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE]. 2019-05-06T14:43:29Z No coin database inconsistencies in last 6 blocks (500 transactions) 2019-05-06T14:43:29Z block index 19450ms 2019-05-06T14:43:29Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/indexes/txindex 2019-05-06T14:43:30Z Opened LevelDB successfully 2019-05-06T14:43:30Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/indexes/txindex: 0000000000000000 2019-05-06T14:43:30Z init message: Loading wallet... 2019-05-06T14:43:30Z txindex thread start 2019-05-06T14:43:30Z [default wallet] nFileVersion = 170100 2019-05-06T14:43:30Z [default wallet] Keys: 2005 plaintext, 0 encrypted, 2005 w/ metadata, 2005 total. Unknown wallet records: 1 2019-05-06T14:43:30Z Syncing txindex with block chain from height 694205 2019-05-06T14:43:30Z [default wallet] Wallet completed loading in 123ms 2019-05-06T14:43:30Z [default wallet] setKeyPool.size() = 2000 2019-05-06T14:43:30Z [default wallet] mapWallet.size() = 7 2019-05-06T14:43:30Z [default wallet] mapAddressBook.size() = 4 2019-05-06T14:43:30Z mapBlockIndex.size() = 1515581 2019-05-06T14:43:30Z nBestHeight = 927391 2019-05-06T14:43:30Z torcontrol thread start 2019-05-06T14:43:30Z Bound to [::]:18333 2019-05-06T14:43:30Z Bound to 0.0.0.0:18333 2019-05-06T14:43:30Z init message: Loading P2P addresses... 2019-05-06T14:43:30Z Loaded 10420 addresses from peers.dat 36ms 2019-05-06T14:43:30Z init message: Loading banlist... 2019-05-06T14:43:30Z Loaded 0 banned node ips/subnets from banlist.dat 29ms 2019-05-06T14:43:30Z init message: Starting network threads... 2019-05-06T14:43:30Z net thread start 2019-05-06T14:43:30Z dnsseed thread start 2019-05-06T14:43:30Z addcon thread start 2019-05-06T14:43:30Z msghand thread start 2019-05-06T14:43:30Z init message: Done loading 2019-05-06T14:43:30Z opencon thread start
After all that appears above, there are just "UpdateTip", "Requesting block", "received block" and "getdata" messages. (so the P2P port, 18333, works). And here is when I netstat: sudo netstat -nap|grep bitcoin|grep LISTEN
I want to install a node machine to be able to receive payments in BTC mainnet and BTC LN, for a webshop and in store. So after testing different solutions I decided to go in this case for a solution using docker for BTC node and LN node, adding a woocommerce plugin for that LN node. The machine is an Ubuntu 18.04. I tested with docker c-lightning + spark wallet, works fine, the plugin for woocommerce also works fine. The restriction is that for c-lightning there is ONLY this Spark wallet and I would want to use/test also other wallets connected to my node, including RTL for a better management. So that's why I wanted to try LND. So please, if is somebody here willing to review my docker-compose file? I get error connecting the lnd so maybe I miss something in this setup. I have days and days reading githubs documentation, testing versions, but seems that for lnd is not that simple as it was with c-lightning docker. Here is my yml setup: version: '2' services: bitcoind: image: nicolasdoriedocker-bitcoin:0.17.0 container_name: bitcoind environment: BITCOIN_EXTRA_ARGS: | printtoconsole=1 rpcallowip=::/0 server=1 txindex=1 rpcuser=btcnodeuser rpcpassword=btcnodepwd externalip=myIP zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28333 expose: - "8332" ports: - "0.0.0.0:8333:8333" volumes: - "./bitcoin:/data" lnd: image: lightninglabs/lnd container_name: lndbtc restart: always command: >- lnd --debuglevel=info --alias="myalias" --color="#990099" --bitcoin.node=bitcoind --bitcoind.dir=./bitcoin --bitcoind.rpchost=127.0.0.1 --bitcoind.rpcuser=mybtcnodeuser --bitcoind.rpcpass=mypwd --bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 --bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 --bitcoin.active --bitcoin.mainnet --rpcuser=mybtcnodeuser --rpcpassword=mypwd --rpclisten=0.0.0.0:10009 --restlisten=0.0.0.0:8080 --datadir=./lightningd/data --logdir=./lightningd/logs --externalip=myIP:9735 --tlsextraip=myIP --maxpendingchannels=10 --minchansize=100000 ports: - "9735:9735" - "10009:10009" volumes: - "./lightningd:/data" - "./bitcoin:/data"
Lightning node on Windows - testing, get not connected
Ok after testing BTCPay, C-Lightning, LND on Ubuntu I said ok let's try also the Windows implementation, is just few clicks and done (as it is promoted). So I followed this github guide that actually send you to this one. OK, started Bitcoin-core client on Windows 7 x64, with an already synced data folder. Empty bitcoin.conf (none of guides says how to configure the conf file). Wait until the client is full synced. And then launched the windows-node-launcher (from a subfolder inside Bitcoin folder). All good, started slowly and a small popup appeared in systray saying Bitcoin node is syncing. Reviewed the config of Bitcoin and LND through that little app in systray and saw that bitcoin.conf was already filled with some settings. Didn't change anything. After 1 day (with the bitcoin blockchain already synced), the systray popup still says that is syncing and have a red dot. In the tutorial says that we have to leave it to sync until is blue and then green. I said, ok maybe it has more things to do. So I open that LND Output link, to see what is going on... And I see that LND is not well. Says: 2019-04-06 21:11:29.772 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default 2019-04-06 21:11:29.772 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2019-04-06 21:11:29.774 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8 2019-04-06 21:11:29.808 [INF] RPCS: password RPC server listening on 127.0.0.1:10009 2019-04-06 21:11:29.808 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080 2019-04-06 21:11:29.808 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it. 2019-04-06 21:11:32.673 [INF] LNWL: Opened wallet 2019-04-06 21:11:33.183 [INF] LTND: Primary chain is set to: bitcoin unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:36.087 [INF] LTND: Shutdown complete unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:39.229 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default Now the bitcoin.conf have this: printtoconsole=1 rpcallowip=::/0 whitelist=0.0.0.0/0 datadir=C:\Users\Admin\AppData\Roaming\Bitcoin prune=0 txindex=1 server=1 disablewallet=0 timeout=6000 rpcuser=user rpcpassword=defaultxzxxxxx zmqpubrawblock=tcp://127.0.0.1:18502 zmqpubrawtx=tcp://127.0.0.1:18503 dbcache=2408 And LND.conf have this: (#) Auto-Generated Configuration File (#) Node Launcher version 6.0.2 debuglevel=info restlisten=127.0.0.1:8080 rpclisten=127.0.0.1:10009 tlsextraip=127.0.0.1 listen=127.0.0.1:9735 alias=aliasme color=#00aa7f bitcoin.active=1 bitcoin.node=bitcoind bitcoind.rpchost=127.0.0.1:8332 bitcoind.rpcuser=user bitcoind.rpcpass=defaultxxxxx bitcoind.zmqpubrawblock=tcp://127.0.0.1:18502 bitcoind.zmqpubrawtx=tcp://127.0.0.1:18503 So what is going on here? I will have to wait indefinitely? Somebody can give some help or explanation? Is this LND node working on Windows Server 2008 or 2012?
Replace user, pass and ips to match your setup. You can make up your own usepass. You need to use the same ones when configuring ccminer. 192.168.1.100 needs to be changed to the IP of the machine running the wallet. This setup allows connections from all ips in the range 192.168.1.X
Restart your QT wallet. (You can start the ravend console version instead at this point.)
I run a full Bitcoin node. Lately I've been playing around with setting up solo mining with BFGMiner, just experimenting with CPUs and GPUs, in full knowledge its a purely academic thing with zero chance of succeeding, intending only to deepen my understanding of the system. Seems to work well, for the most part. Except when I point my S9's at the pool, I only get about 250 GH instead of 13.5 TH each. I've made sure to turn off overt asciboost when I point them at my experiment, no effect, and they definitely are connected. Does anyone else play around with this stuff and might know the solution already? FWIW: Ubuntu Bitcoin Core v0.17 BFGMiner v5.5.0 Bitcoin.conf, server, daemon, listen, and txindex set to 1. rpcuser and rpcpassword are set, rpcallowip and rpcport are all good(and proven as I can connect other pcs over the LAN just fine for cpu/gpu) BFGMiner -o http://127.0.01:8332 -u user - pword --generate-to $address --coinbase-sig "LOL" --stratum-port:3333 Any suggestions?
04-07 09:48 - 'Lightning node on Windows - testing, get not connected' (self.Bitcoin) by /u/Mr--Robot removed from /r/Bitcoin within 845-855min
''' Ok after testing BTCPay, C-Lightning, LND on Ubuntu I said ok let's try also the Windows implementation, is just few clicks and done (as it is promoted). So I followed this [github guide]1 that actually send you to [this one]2 . OK, started Bitcoin-core client on Windows 7 x64, with an already synced data folder. Empty bitcoin.conf (none of guides says how to configure the conf file). Wait until the client is full synced. And then launched the windows-node-launcher (from a subfolder inside Bitcoin folder). All good, started slowly and a small popup appeared in systray saying Bitcoin node is syncing. Reviewed the config of Bitcoin and LND through that little app in systray and saw that bitcoin.conf was already filled with some settings. Didn't change anything. After 1 day (with the bitcoin blockchain already synced), the systray popup still says that is syncing and have a red dot. In the tutorial says that we have to leave it to sync until is blue and then green. I said, ok maybe it has more things to do. So I open that LND Output link, to see what is going on... And I see that LND is not well. Says: 2019-04-06 21:11:29.772 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default 2019-04-06 21:11:29.772 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2019-04-06 21:11:29.774 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8 2019-04-06 21:11:29.808 [INF] RPCS: password RPC server listening on 127.0.0.1:10009 2019-04-06 21:11:29.808 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080 2019-04-06 21:11:29.808 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it. 2019-04-06 21:11:32.673 [INF] LNWL: Opened wallet 2019-04-06 21:11:33.183 [INF] LTND: Primary chain is set to: bitcoin unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:36.087 [INF] LTND: Shutdown complete unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:39.229 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default Now the bitcoin.conf have this: printtoconsole=1 rpcallowip=::/0 whitelist=0.0.0.0/0 datadir=C:\Users\Admin\AppData\Roaming\Bitcoin prune=0 txindex=1 server=1 disablewallet=0 timeout=6000 rpcuser=user rpcpassword=defaultxzxxxxx zmqpubrawblock=[link]3 zmqpubrawtx=[link]4 dbcache=2408 And LND.conf have this: (#) Auto-Generated Configuration File (#) Node Launcher version 6.0.2 debuglevel=info restlisten=127.0.0.1:8080 rpclisten=127.0.0.1:10009 tlsextraip=127.0.0.1 listen=127.0.0.1:9735 alias=aliasme color=#00aa7f bitcoin.active=1 bitcoin.node=bitcoind bitcoind.rpchost=127.0.0.1:8332 bitcoind.rpcuser=user bitcoind.rpcpass=defaultxxxxx bitcoind.zmqpubrawblock=[link]3 bitcoind.zmqpubrawtx=[link]4 So what is going on here? I will have to wait indefinitely? Somebody can give some help or explanation? Is this LND node working on Windows Server 2008 or 2012? ''' Lightning node on Windows - testing, get not connected Go1dfish undelete link unreddit undelete link Author: Mr--Robot 1: g*thub.c*m/light**ng**o*e*-users/no**-launc**r 2: me*ium.*o**lig*tn**g-p*wer-users/w*n**ws-m**os-l**ht*i*g-ne*work-2*4bd5034340 3: 127.0.0**:1*5*2 4: 127*0.0**:185*3 5: 1**.0.0*1:185*2 6: 12*.0**.1:*8503 Unknown links are censored to prevent spreading illicit content.
This is the error I'm getting while trying to run a P2P and I am not technical enough to know what to do now
This is the error I'm getting now and my batch is: server=1, rpcuser=node, rpcpassword=***************, rpcport=5888, rpcallowip="my public ip", rpcallowip=127.0.0.1 Error while checking Bitcoin connection: Traceback (most recent call last): File "twisted\internet\defer.pyc", line 653, in _runCallbacks File "twisted\internet\defer.pyc", line 1357, in gotResult File "twisted\internet\defer.pyc", line 1299, in _inlineCallbacks File "twisted\python\failure.pyc", line 393, in throwExceptionIntoGenerator --- --- File "p2pool\util\deferral.pyc", line 41, in f File "twisted\internet\defer.pyc", line 1299, in _inlineCallbacks File "twisted\python\failure.pyc", line 393, in throwExceptionIntoGenerator File "p2pool\bitcoin\helper.pyc", line 17, in check File "twisted\internet\defer.pyc", line 1299, in _inlineCallbacks File "twisted\python\failure.pyc", line 393, in throwExceptionIntoGenerator File "p2pool\util\jsonrpc.pyc", line 126, in _http_do twisted.web.error.Error: 401 Unauthorized
Just for the fun of it..... bitcoin-qt.exe -server=1 -rpcuser=michael -rpcpassword=pass -rpcthreads=4 -rpcallowip=192.168.1.8 -rpcport=8332 -rpcbind=192.168.1.8 bfgminer -o http://192.168.1.8:8332 -u michael -p pass --no-stratum -S opencl:auto --verbose --coinbase-addr 18SHLhskjwg7Sq7c45De8XS6mjke4f3nTb --coinbase-sig "Dan Conrad"
I’m so frustrated!!! I’ve been trying to set up a node for days and every time I think I have it, I run into another problem.
I’ve gotten 501 forbidden error, connection actively rejected by host and I thought my port forwarding was screwed up but it wasn’t. I really need some directions. I’ve tried every guide an tutorial I could find but none have any explanation of the errors I’m seeing EDIT: This is the error I'm getting now and my batch is: server=1, rpcuser=node, rpcpassword=***************, rpcport=5888, rpcallowip="my public ip", rpcallowip=127.0.0.1 Error while checking Bitcoin connection: Traceback (most recent call last): File "twisted\internet\defer.pyc", line 653, in _runCallbacks File "twisted\internet\defer.pyc", line 1357, in gotResult File "twisted\internet\defer.pyc", line 1299, in _inlineCallbacks File "twisted\python\failure.pyc", line 393, in throwExceptionIntoGenerator --- --- File "p2pool\util\deferral.pyc", line 41, in f File "twisted\internet\defer.pyc", line 1299, in _inlineCallbacks File "twisted\python\failure.pyc", line 393, in throwExceptionIntoGenerator File "p2pool\bitcoin\helper.pyc", line 17, in check File "twisted\internet\defer.pyc", line 1299, in _inlineCallbacks File "twisted\python\failure.pyc", line 393, in throwExceptionIntoGenerator File "p2pool\util\jsonrpc.pyc", line 126, in _http_do twisted.web.error.Error: 401 Unauthorized
using control wallet (Windows or Linux) Click Receive tab. write Label mn1 and click Request payment. Copy the Address and go Send tab on your control wallet. Paste in Pay To the copied address. Send 10,000 ZIO coin and wait for approval.
Open debug console, type the following command:masternode genkey
type the following command:masternode outputs
Edit masternode.conf (Tools - Open Wallet Configuration File)mn1 :17842
VPS remote wallet (if you need libraries try following commands) sudo apt-get install git sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils sudo apt-get install libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev sudo apt-get install libboost-all-dev sudo apt-get install software-properties-common sudo add-apt-repository ppa:bitcoin/bitcoin sudo apt-get update sudo apt-get install libdb4.8-dev libdb4.8++-dev sudo apt-get install libminiupnpc-dev sudo apt-get install libzmq3-dev sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler cd wget https://github.com/ziocoin/ziocoin/releases/download/v18.104.22.168/ziocoin-22.214.171.124-linux.tar.gz tar -xzvf ziocoin-126.96.36.199-linux.tar.gz cd mkdir .ziocoin cd .ziocoin nano ziocoin.conf rpcuser=ziocoinuser rpcpassword=longpassword rpcallowip=127.0.0.1 server=1 daemon=1 logtimestamps=1 maxconnections=256 masternode=1 externalip= masternodeprivkey= Ctrl + x, y cd linux-wallet/ziocoind -daemon your control wallet debug console, type the following command startmasternode alias false mn1 VPS remote wallet cd linux-wallet/ziocoin-cli startmasternode local false linux-wallet/ziocoin-cli masternode status
A simple guide to financial sovereignty (set up your Bitcoin fullnode)
In 2009, a 9 pages white paper by satoshi Nakamoto described a protocol that made central banking obselete. It's a new paradigm where monney is no longer controlled by a few, but by the whole network. The shift is already happening, as we speak, even if it's hard to see, especially if you lack the fundamental knowledege of cryptoghraphy, game theory and economics. It's just a matter of time before you realize that Bitcoin is hard money, and for the first time we have a framework to apply austrian economics, without permission. Time to reset the keynesian monopoly game. I don't think people are inherently bad, it's just that in the actual system (which I call the legacy system) people are incentivised to make decisions that are good from their individual perspective, but unfortunately, the sum of those individual decisions are bad from the collective group perspective. That's just plain simple game theory. What makes Bitcoin so special is it's perfectly aligned set of incentives that makes individuals and collectives outcomes better. It switches the economic model from keynesian to austrian, inflation to deflation, spending to saving, modern slavery (throught debt) to financial sovereingty, de-evolution to evolution. We are currently shifting from fiat to Bitcoin. What you think capitalism is has nothing to do with what Capitalism really is in a free market. Capitalism is beautiful, it's simply the act of evolution, saving and optimising for consumming only what's needed (don't forget with live in a world with limited ressources, yes we all forgot). Stop spending and start capitalising, that's what we should be doing. But it's near impossible in a world run by socialists imposing debt using violence. What do you think back the US dollar ? gold ? no no, only tanks, aircraft carriers, soldiers and corrupt politicians. Our only way out of this madness with the minimum violence is Bitcoin. To be clear, if you dont run a fullnode, then you don't validate the transactions yourself (which is one purpose of running a fullnode). If you don't do the job yourself, then you have no other choice then to trust someone else for it. That's not necesserely a bad thing, as long as you are aware of it. You have no say in what defines Bitcoin, you enforce no rules. You serve no purpose in the Bitcoin realm. Why not ! Now if you seek financial sovereignty and want to take part in the new money paradigm, you will need to operate a fullnode and get your hands a little dirty. This guide hopefuly will take you there while walking you through the steps of setting up your autonomous Bitcoin Core full node. Why Bitcoin Core ? simply because the Bitcoin core client implement and enforce the set of rules that I myself define as being Bitcoin.
Linux (recent ubuntu or debian)
willing to take responsibility for your kids future
check your firewall rules with sudo ufw status numbered
Start bitcoind so that it create the initial ~/.bitcoin folder structure.
bitcoind& # launch daemon (the & run the copmmand in the background) bitcoin-cli stop # stop the daemon once folder structure is created
In my case, for a personnal fullnode, I want to run a full txindexed chain. We only live once and i want all options to be possible/available :) If you plan to interact with the lightning network in the future and want to stay 100% trustless, I encourage you txindexing the chain (because you'll need an indexed chain). it's not hard to txindex the chain later on, but the less you touch the data, the better. so always better to start with txindex=1 if you want to go for the long run. It only adds 26Go on top of the 200Go non indexed chain. So it's worth it ! Just to get an idea of the size of the bitcoin core chain (August 23, 2018) :
blocks + chainstate
209Go + 2.7Go = 221.7
blocks + chainstate
193Go + 2.7Go = 195.7Go
blocks + chainstate
blocks + chainstate
20Go + 982Mo = 21Go
Create a bitcoin.conf config file in the ~/.bitcoin folder. This is my default settings, feel free to adjust to your need. [ see full config Running Bitcoin - Bitcoin Wiki ]
# see full config here https://en.bitcoin.it/wiki/Running_Bitcoin # Global daemon=1 txindex=1 rpcallowip=0.0.0.0/0 # bind network interface to local only for now server=1 rest=1 # RPC rpcport=8332 rpcuser=admin rpcpassword=password # define a password rpcworkqueue=100 # zmq zmqpubrawblock=tcp://*:8331 zmqpubrawtx=tcp://*:8331 #zmqpubhashblock=tcp://*:8331 #zmqpubhashtx=tcp://*:8331 # numbers of peers. default to 125 maxconnections=10 # utxo cache. default to 300M dbcache=100 # Spam protection limitfreerelay=10 minrelaytxfee=0.0001
Sync the blockchain
There are 2 ways you can donwload/sync the bitcoin blochain :
Network sync (default)
If this is the first time you are setting up a bitcoin full node, it's the only way to trust the data. It will take time, depending on your hardware and network speed, it could vary from hours to days. You have nothing to do but leave the bitcoind daemon running. check status with bitcoin-cli getblockchaininfo, kill daemon with bitcoin-cli stop. Remember that this is the only procedure you should use in order to sync the blockchain for the first time, as you don't want to trust anyone with that data except the network itself.
Skip this chapter if this is the first you're setting up a full node. Once you operate a fully "network trusted" node, if you'd like to operate other nodes, syncing them from your trusted node(s) will go much faster, since you simply have to copy the trusted data from server to server directly, instead of going throught the bitcoin core network sync. You will need to transfer the chainstate & blocks directory from the ~/.bitcoin folder of one of your trusted node to the new one. The way you achieve that transfer is up to you. At the time of writing (August 23, 2018), the txindexed blockchain (chainstate + blocks up to height 538.094) is around 220Go. Moving that quantity of data over the network is not a trivial task, but if the transfer happens between 2 reliable servers, then netcat will be great for the job. (netcat sends raw tcp packets, there is no authentification or resume feature). Note: with netcat, if one of the servers connection is not stable, and you lose connection, you will have to start again. that's a bummer. in that case you are better of with tools like rsync or rcp that let you resume a transfer. In order to make the transfer a simple task, make sure you do the following on both of the receiver and the sender server :
make sure port 7000 is open (or choose whatever port you want, make sure to reflect in .bashrc wrapper fucntions)
Install netcat & pv (pv is a utility that will show transfer progress)
Add 2 wrapper function in your .bashrc :
Reload your bash source ~/.bashrc
Once both your servers (receiver & sender) are netcat ready, proceed as follow :
On the receiver side (the node we are setting up)
Then on the sender side (trusted server)
Go grab a coffee, a spliff or whatever rewards you :)
Repeat ncpull/ncpush for the chainstate folder also.
This is the transfer times for my last data sync between 2 servers hosted at time4vps.eu (not too bad) | folder | size | transfer time | - | - | - | blocks | 209Go | 5h20 | chainstate | 2.7Go | 4min
bitcoind as a service
For ease of use and 100% uptime, simply add bitcoind to your system service manager (in my case systemd) create the file /etc/systemd/system/bitcoind.service and add the following to it :
[Unit] Description=Bitcoin daemon After=network.target [Service] User=larafale RuntimeDirectory=bitcoind Type=forking ExecStart=/uslocal/bin/bitcoind -conf=/home/larafale/.bitcoin/bitcoin.conf ExecStop=/uslocal/bin/bitcoin-cli stop KillMode=process Restart=always RestartSec=120 TimeoutSec=240 # Hardening measures #################### # Provide a private /tmp and /vatmp. PrivateTmp=true # Mount /usr, /boot/ and /etc read-only for the process. ProtectSystem=full # Disallow the process and all of its children to gain # new privileges through execve(). NoNewPrivileges=true # Use a new /dev namespace only populated with API pseudo devices # such as /dev/null, /dev/zero and /dev/random. PrivateDevices=true # Deny the creation of writable and executable memory mappings. MemoryDenyWriteExecute=true [Install] WantedBy=multi-user.target
Don't forget to correct the user name & the bitcoin.conf path. Once the systemd bitcoind config file is created, reload system services and start the bitcoind service:
sudo systemctl daemon-reload # reload new services sudo systemctl enable bitcoind # enable bitcoind sudo systemctl start bitcoind # start bitcoind sudo systemctl status bitcoind # check bitcoind status
If everything worked, status should output the following:
● bitcoind.service - Bitcoin daemon Loaded: loaded (/etc/systemd/system/bitcoind.service; enabled; vendor preset: enabled) Active: active (running) since jeu. 2018-08-23 21:17:41 CEST; 5s ago Process: 5218 ExecStart=/uslocal/bin/bitcoind -conf=/home/larafale/.bitcoin/bitcoin.conf (code=exited, status=0/SUCCESS) Main PID: 5219 (bitcoind) CGroup: /system.slice/bitcoind.service └─5219 /uslocal/bin/bitcoind -conf=/home/larafale/.bitcoin/bitcoin.conf
The bitcoind service is active and will automatically restart on statup/crash. Wait a couple minutes until the bitcoin-cli getblockchaininfo command returns the chain status. You can also query the rest interface by opening http://nodeIP:8332/rest/chaininfo.json in your browser.
You now have a full Bitcoin core node running on it's own. What's next ? Well I never blogged before, this is the first time I am outsourcing some of my work. I'm a passionnate enginner working on all kind of technologies. I've been dedicating half of my time to Bitcoin for the last 2 years already, so if this guide was usefull and want to go deeper , just let me know, depending on the feedback I get, i'll consider outsourcing more interesting work. For example next post could be about setting up an Electrum Server so you can safely use SPV wallets trusting your own fullnode. Also I'm currently working on a trustless bitcoin payment processor called 8333, make sure you follow @_8333_ on twitter. I think I will release the project end of 2018. Ping me if interested. The best way you can show support is via Bitcoin : 16FKGPiivpo3Z7FFPLdkoVRcV2ASBc7Ktu
After updating to Classic 0.12, now getting "error: couldn't connect to server"
Can anyone help me figure this out? After updating to Bitcoin Classic 0.12 and running the "getinfo" command I get "error: couldn't connect to server" but if I look it up at bitnodes.21.co (grnqrtr.ddns.net ) it seems to be running fine. It also seems that if I replace "getinfo" with anything (ghfutbcjd) I get the same thing.
[email protected]:~ $ bitcoin-cli - datadir=/home/pi/bitcoinData getinfo error: couldn't connect to server [email protected]:~ $ bitcoin-cli -datadir=/home/pi/bitcoinData ghfutbcjd error: couldn't connect to server
EDIT: I added "rpcallowip=127.0.0.1" to my bitcoin.conf and it fixed the issue.
So i've been playing around, in java (to build some crypto stuff, mainly something for myr) with the bitcoind/qt RPC making calls such as getinfo, getmininginfo, getblock (all of the btc RPC calls) and also have gotten the blocknotify/walletnotify working. However when i try the same methods with the myriadcoind/qt, with the same .conf file as the btc one, i don't get any response from the wallet or it's returning null Json objects? Is there something wrong with my .conf settings?
edit: just to add im using http POST requests which bitcoins rpc responds to, maybe the myriad client doesn't respond to POST, only json rpc calls which would mean i would have to attempt a different kind of implementation? edit2: i fixed it by chaning my .conf file to look like this
Would be great if someone who has the skills & tools could generate us a nice stable MacOS build? Anyone?
Backup your wallet before using this. You've probably already done that, as I am sure you backup your wallet on a regular basis, right? Something bad happens, your wallet is destroyed AND you didn't take a backup? Don't blame me.
A lot of stuff has been renamed to 'Myriad' - however there are a couple of exceptions for reasons of compatibility with older existing versions:
default data directory is still myriadcoin
config file is still myriadcoin.conf
daemon is myriadcoind, rpc client is myriadcoin-cli
If you are compiling yourself, please configure with something like this:
That will enable the SSE2 version of the Scrypt algorithm. This may reduce the CPU load when syncing the blockchain. Oh, and there's still some tests that fail if you build and run the testsuite. I've been unable to find the issue, so please, when you fix it, submit a pull request.
A big thanks to cryptapus and 8bitcoder for their help in getting this release completed. Obviously we must also thank all of the contributors to the Bitcoin Core project, as that is the base that this is all built upon. And again thanks to 8bitcoder for starting Myriad in the first place.
Because this release is based on Bitcoin Core 0.10.0 and upwards, it 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 Myriad 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.11.2 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 (Borrowed from Bitcoin Core's Release Notes)
Myriad Core now uses 'headers-first synchronization'. This means that we first ask peers for block headers 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.
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. 188.8.131.52 or fe80::0012:3456:789a:bcde)
a network/CIDR (e.g. 184.108.40.206/24 or fe80::0000/64)
a network/netmask (e.g. 220.127.116.11/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
-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. 18.104.22.168), a network/netmask (e.g. 22.214.171.124/255.255.255.0) or a network/CIDR (e.g. 126.96.36.199/24).
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.
It has been observed that many of the RPC functions offered by myriadcoind are "pure functions", and operate independently of the myriadcoind wallet. This included many of the RPC "raw transaction" API functions, such as createrawtransaction. myriadcoin-tx is a newly introduced command line utility designed to enable easy manipulation of myriad transactions. A summary of its operation may be obtained via "myriadcoin-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.
I'm trying to understand the difference between rpcallowip and rpcbind. I run bitcoind v0.17.0 in bitcoin.conf, I have: rpcport=8332 rpcallowip=0.0.0.0/0 which should allow every connection from... Bitcoin News Good and bad News about Bitcoin Menu Skip to content. Home; Bitcoin Ankauf-Verkauf = Buying-Selling; Bitcoin.name for Sale! Contact us; We hire talents facebook. Upgrading And Downgrading I recently downloaded bitcoin from github and changed the settings to allow for rpc. This is how I have it: rpcallowip=192.168.0.* This does not work anymore. However when running bitcoind, it complains that: Error: Invalid -rpcallowip subnet specification: 192.168.0.*. Valid are a single IP, a network/netmask or a network CIDR. There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just “Bitcoin”), and a 'headless' version (called bitcoind).They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and read and write the same data files.
PiVX Wallet Staking aktivieren und Coins dafür erhalten(Deutsch)
rpcallowip=127.0.0.1 daemon=1 server=1 listen=1 Start the ultracoin client, edit solo_mining.bat with the specified user and password, and run the .bat. Enjoy mining! NOTE: Please set expiry = 1 ... #Chaincoin revolution. I will do some live Chaincoin Masternode setup support. Thanks for watchin! For more help join the Chaincoin Team Slack: https://chain... How to Install Gossip Coin Windows Wallet In this video I will show you how to install Gossip Coin Wallet in windows. Download Link For Wallet Files: https:/... Htmlcoin Sincronização e mineração por CPU. Aprenda como minerar com a CPU, pela sua Wallet. Nodes rpcuser=username rpcpassword=password rpcallowip=127.0.0.1 rpcport=6876 port=6877 gen=0 ... rpcallowip=127.0.0.1 staking=1 listen=1 server=1 deamon=1 logtimestamps=1 maxconnections=256 enablezeromint=0 Ob dann Staking aktiviert ist seht ihr unten rechts in eurem Wallet! Da steht dann ...