Change difficulty using bitcoin-cli/bitcoind in regtest ...

Chatter Report: Pacia Shows Avalanche Regtest Data, Powell Advocates Hardware Wallets - Bitcoin News

Chatter Report: Pacia Shows Avalanche Regtest Data, Powell Advocates Hardware Wallets - Bitcoin News submitted by ABitcoinAllBot to BitcoinAll [link] [comments]

Do you need Testnet coins? Do you have Testnet coins that you aren't using? Please read.

We're seeing a lot of requests for Bitcoin Testnet token donations. Apparently they're hard to come by because many testnet faucets are broken.
If you are a developer in need of tokens for testing your software, post your testnet address in the comments below. People might also be curious what kind of project you're working on! No guarantees, but maybe some people reading this will be willing to distribute testnet coins they're not using. If you receive a transaction, please edit your comment.
Please note that you may not actually need any testnet coins at all, as Regtest Mode may be sufficient for your needs. Regtest allows you to generate new blocks and mint as many tokens as you need for testing. It's basically a self-hosted testnet.
If you are not a developer, don't bother: Testnet coins are completely worthless.

Read about testnet and regtest here.

submitted by BashCo to Bitcoin [link] [comments]

Upcoming Major Riecoin 0.20 Upgrade

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

Having Trouble with Regtest Running Inside a Docker Container

Hello everyone. First of all, thanks in advance for any help.
I'm running a BTCPay server using BTCPay server docker. If I understand it correctly, it exposes the regtest Bitcoin core through a Tor network.
I followed the instructions on the [BTCPay Server docs to Connect Wasabi to BTCPay Server Full Node. Unfortunately, after following these instructions, the bottom-left corner of Wasabi Wallet still reads "Connecting...".
My logs.txt reveals:
2020-03-29 20:34:51 INFO Program (44) Wasabi GUI started (14879af3-85dd-42aa-9d41-674d87a5dd77). 2020-03-29 20:34:52 INFO Global (164) Config is successfully initialized. 2020-03-29 20:34:52 INFO TransactionStore (28) ConfirmedStore.InitializeAsync finished in 4 milliseconds. 2020-03-29 20:34:52 INFO TransactionStore (28) MempoolStore.InitializeAsync finished in 12 milliseconds. 2020-03-29 20:34:52 INFO Global (401) Fake AddressManager is initialized on the RegTest. 2020-03-29 20:34:52 INFO AllTransactionStore (27) InitializeAsync finished in 16 milliseconds. 2020-03-29 20:34:52 INFO IndexStore (43) InitializeAsync finished in 40 milliseconds. 2020-03-29 20:34:52 INFO BitcoinStore (39) InitializeAsync finished in 43 milliseconds. 2020-03-29 20:34:52 INFO TorProcessManager (249) Starting Tor monitor... 2020-03-29 20:34:52 INFO Global (230) TorProcessManager is initialized. 2020-03-29 20:34:52 INFO HostedServices (49) Started Software Update Checker. 2020-03-29 20:34:52 INFO TorProcessManager (66) Tor is already running. 2020-03-29 20:34:53 ERROR Global (328) System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (61): Connection refused [::ffff:]:18444 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(Exception source) at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult) at NBitcoin.Protocol.Connectors.SocketExtensions.<>c.b__0_0(IAsyncResult iar) --- End of stack trace from previous location where exception was thrown --- at NBitcoin.Extensions.WithCancellation[T](Task`1 task, CancellationToken cancellationToken) at NBitcoin.Protocol.Connectors.DefaultEndpointConnector.ConnectSocket(Socket socket, EndPoint endpoint, NodeConnectionParameters nodeConnectionParameters, CancellationToken cancellationToken) at NBitcoin.Protocol.Node.ConnectAsync(Network network, EndPoint endpoint, NetworkAddress peer, NodeConnectionParameters parameters) at WalletWasabi.Gui.Global.InitializeNoWalletAsync() 2020-03-29 20:34:53 INFO Global (349) Start connecting to nodes... 2020-03-29 20:34:53 INFO Global (373) Start synchronizing filters... 2020-03-29 20:34:53 INFO MainWindow.xaml (74) UiConfig is successfully initialized. 2020-03-29 20:34:57 ERROR PeriodicRunner (72) System.NotSupportedException: Invalid StatusLine: ?. - System.IndexOutOfRangeException: Index was outside the bounds of the array. at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) --- End of inner exception stack trace --- at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) at System.Net.Http.HttpResponseMessageExtensions.CreateNewAsync(Stream responseStream, HttpMethod requestMethod) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpRequestMessage request, CancellationToken cancel) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpMethod method, String relativeUri, HttpContent content, CancellationToken cancel) at TorHttpClientExtensions.SendAndRetryAsync(ITorHttpClient client, HttpMethod method, HttpStatusCode expectedCode, String relativeUri, Int32 retry, HttpContent content, CancellationToken cancel) at WalletWasabi.WebClients.Wasabi.WasabiClient.GetVersionsAsync(CancellationToken cancel) at WalletWasabi.WebClients.Wasabi.WasabiClient.CheckUpdatesAsync(CancellationToken cancel) at WalletWasabi.Services.UpdateChecker.ActionAsync(CancellationToken cancel) at WalletWasabi.Bases.PeriodicRunner.ExecuteAsync(CancellationToken stoppingToken) 2020-03-29 20:35:01 ERROR WasabiSynchronizer (305) System.NotSupportedException: Invalid StatusLine: ?. - System.IndexOutOfRangeException: Index was outside the bounds of the array. at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) --- End of inner exception stack trace --- at WalletWasabi.Http.Models.StatusLine.Parse(String statusLineString) at System.Net.Http.HttpResponseMessageExtensions.CreateNewAsync(Stream responseStream, HttpMethod requestMethod) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpRequestMessage request, CancellationToken cancel) at WalletWasabi.TorSocks5.TorHttpClient.SendAsync(HttpMethod method, String relativeUri, HttpContent content, CancellationToken cancel) at TorHttpClientExtensions.SendAndRetryAsync(ITorHttpClient client, HttpMethod method, HttpStatusCode expectedCode, String relativeUri, Int32 retry, HttpContent content, CancellationToken cancel) at WalletWasabi.WebClients.Wasabi.WasabiClient.GetSynchronizeAsync(uint256 bestKnownBlockHash, Int32 count, Nullable`1 estimateMode, CancellationToken cancel) at System.Threading.Tasks.TaskExtensions.WithAwaitCancellationAsync[T](Task`1 me, CancellationToken cancel, Int32 waitForGracefulTerminationMilliseconds) at WalletWasabi.Services.WasabiSynchronizer.<>c__DisplayClass60_0.<b__0>d.MoveNext()
while my config.json is:
json { "Network": "RegTest", "MainNetBackendUriV3": "http://wasabiukrxmkdgve5kynjztuovbg43uxcbcxn6y2okcrsg7gb6jdmbad.onion/", "TestNetBackendUriV3": "http://testwnp3fugjln6vh5vpj7mvq3lkqqwjj3c2aafyu7laxz42kgwh2rad.onion/", "MainNetFallbackBackendUri": "", "TestNetFallbackBackendUri": "", "RegTestBackendUriV3": "http://oqaqivyaxctrp2gix5id4bbd7mav2xt5n4fzqsnwtrhtsmgjhg7sneqd.onion:8333/", "UseTor": true, "StartLocalBitcoinCoreOnStartup": false, "StopLocalBitcoinCoreOnShutdown": true, "LocalBitcoinCoreDataDir": "/Users/my-name-here/Library/Application Support/Bitcoin", "TorSocks5EndPoint": "", "MainNetBitcoinP2pEndPoint": "", "TestNetBitcoinP2pEndPoint": "", "RegTestBitcoinP2pEndPoint": "", "MixUntilAnonymitySet": 50, "PrivacyLevelSome": 2, "PrivacyLevelFine": 21, "PrivacyLevelStrong": 50, "DustThreshold": "0.00005" }
The environment in which bitcoind runs is here: (I would copy and paste but quite long).
I'm 98% sure the error lies in this line of the log: 2020-03-29 20:34:53 ERROR Global (328) System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (61): Connection refused [::ffff:]:18444. However, I haven't a clue what port regtest normally runs on.
FWIW, main and testnet connect just fine (both nodes also running on my local machine).
submitted by TheWebDevCoach to WasabiWallet [link] [comments]

Groestlcoin 6th Anniversary Release


Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

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.
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.

Other Linux


Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here


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.





ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.



Main Release (Main Net)
Testnet Release


ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.


Live Version (Not Recommended)



ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).





ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).




Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.


Remastered Improvements



ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.



Linux :
 pip3 install -r requirements.txt python3 bip39\ 


ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.



Linux / OSX (Instructions)


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.



Main Net
Main Net (FDroid)
Test Net


UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.




UPDATED – P2Pool Test Net



Pre-Hosted Testnet P2Pool is available via


submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Xthinner/Blocktorrent development status update -- Jan 12, 2018

Edit: Jan 12, 2019, not 2018.
Xthinner is a new block propagation protocol which I have been working on. It takes advantage of LTOR to give about 99.6% compression for blocks, as long as all of the transactions in the block were previously transmitted. That's about 13 bits (1.6 bytes) per transaction. Xthinner is designed to be fault-tolerant, and to handle situations in which the sender and receiver's mempools are not well synchronized with gracefully degrading performance -- missing transactions or other decoding errors can be detected and corrected with one or (rarely) two additional round trips of communication. My expectation is that when it is finished, it will perform about 4x to 6x better than Compact Blocks and Xthin for block propagation. Relative to Graphene, I expect Xthinner to perform similarly under ideal circumstances (better than Graphene v1, slightly worse than Graphene v2), but much better under strenuous conditions (i.e. mempool desynchrony).
The current development status of Xthinner is as follows:
  1. Python proof-of-concept encodedecoder -- done 2018-09-15
  2. Detailed informal writeup of the encoding scheme -- done 2018-09-29
  3. Modify TxMemPool to allow iterating on a view sorted by TxId -- done 2018-11-26
  4. Basic C++ segment encoder -- done 2018-11-26
  5. Basic c++ segment decoder -- done 2018-11-26
  6. Checksums for error detection -- done 2018-12-09
  7. Serialization/deserialization -- done 2018-12-09
  8. Prefilled transactions, coinbase handling, and non-mempool transactions -- done 2018-12-25
  9. Missing/extra transactions, re-requests, and handling mempool desynchrony for segment decoding -- done 2019-01-12
  10. Block transmission coupling the block header with one or more Xthinner segments -- 50% done 2019-01-12
  11. Missing/extra transactions, re-requests, and handling mempool desynchrony for block decoding -- done 2019-01-12
  12. Integration with Bitcoin ABC networking code
  13. Networking testing on regtest/testnet/mainnet with real blocks
  14. Write BIP/BUIP and formal spec
  15. Bitcoin ABC pull request and begin of code review
  16. Unit tests, performance tests, benchmarks -- started
  17. Bitcoin Unlimited pull request and begin of code review
  18. Alpha release of binaries for testing or low-security block relay networks
  19. Merging code into ABC/BU, disabled-by-default
  20. Complete security review
  21. Enable by default in ABC and/or BU
  22. (Optional) parallelize encoding/decoding of blocks
Following is the debugging output from a test run done with coherent senderecipient mempools with a 1.25 million tx block, edited for readability:
Testing Xthinner on a block with 1250003 transactions with sender mempool size 2500000 and recipient mempool size 2500000 Tx/Block creation took 262 sec, 104853 ns/tx (mempool) CTOR block sorting took 2467 ms, 987 ns/tx (mempool) Encoding is 1444761 pushBytes, 2889520 1-bit commands, 103770 checksum bytes total 1910345 bytes, 12.23 bits/tx Single-threaded encoding took 2924 ms, 1169 ns/tx (mempool) Serialization/deserialization took 1089 ms, 435 ns/tx (mempool) Single-threaded decoding took 1912314 usec, 764 ns/tx (mempool) Filling missing slots and handling checksum errors took 0 rounds and 12 usec, 0 ns/tx (mempool) Blocks match! *** No errors detected 
If each transaction were 400 bytes on average, this block would be 500 MB, and it was encoded in 1.9 MB of data, a 99.618% reduction in size. Real-world performance is likely to be somewhat worse than this, as it's not likely that 100% of the block's transactions will always be in the recipient's mempool, but the performance reduction from mempool desychrony is smooth and predictable. If the recipient is missing 10% of the sender's transactions, and has another 10% that the sender does not have, the transaction list is still able to be successfully transmitted and decoded, although in that case it usually takes 2.5 round trips to do so, and the overall compression ratio ends up being around 71% instead of 99.6%.
Anybody who wishes can view the WIP Xthinner code here.
Once Xthinner is finished, I intend to start working on Blocktorrent. Blocktorrent is a method for breaking a block into small independently verifiable chunks for transmission, where each chunk is about one IP packet (a bit less than 1500 bytes) in size. In the same way that Bittorrent was faster than Napster, Blocktorrent should be faster than Xthinner. Currently, one of the big limitations on block propagation performance is that a node cannot forward the first byte of a block until the last byte of the block has been received and completely validated. Blocktorrent will change that, and allow nodes to forward each IP packet shortly after that packet was received, regardless of whether any other packets have also been received and regardless of the order in which the packets are received. This should dramatically improve the bandwidth utilization efficiency of nodes during block propagation, and should reduce the block propagation latency for reaching the full network quite a lot -- my current estimate is about 10x improvement over Xthinner. Blocktorrent achieves this partial validation of small chunks by taking advantage of Bitcoin blocks' Merkle tree structure. Chunks of transactions are transmitted in a packet along with enough data from the rest of the Merkle tree's internal nodes to allow for that chunk of transactions to be validated back to the Merkle root, the block header, and the mining PoW, thereby ensuring that packet being forwarded is not invalid spam data used solely for a DoS attack. (Forwarding DoS attacks to other nodes is bad.) Each chunk will contain an Xthinner segment to encode TXIDs My performance target with Blocktorrent is to be able to propagate a 1 GB block in about 5-10 seconds to all nodes in the network that have 100 Mbps connectivity and quad core CPUs. Blocktorrent will probably perform a bit worse than FIBRE at small block sizes, but better at very large blocksizes, all without the trust and centralized infrastructure that FIBRE uses.
submitted by jtoomim to btc [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (, August 17th, 2018) from:
This release is a major release which is compatible with the Bitcoin Cash compatible with the Bitcoin Cash specifications you could find here:
A subsequent release containing the implementation of the November 2018 specification will be released soon after this one.
List of notable changes and fixes to the code base:
Release notes:
Ubuntu PPA repository for BUcash has been updated
submitted by s1ckpig to btc [link] [comments]

Groestlcoin June Development Update & Release!

Another Quarter, Another Release! The Groestlcoin production factory has been working overtime as always in order to deliver even more tech to push Groestlcoin mainstream when the time comes.
There have been many new fantastic wallets and exchanges added to Groestlcoins repertoire over the past 3 months so we will re-cap these before moving on to what is new today.


What's New

Re-forged: Groestlcoin Samourai

Groestlcoin Samourai is a wallet for the streets. A modern Groestlcoin wallet hand-forged to keep your transactions private, your identity masked, and your funds secure. Its main advantages are its extreme portability and is the most secure Groestlcoin mobile HD wallet.
We've built a wallet that Groestlcoin deserves. If you are looking for a wallet that Silicon Valley will never build, the regulators will never allow, and the VC's will never invest in, this is the perfect wallet for you.
![Groestlcoin Samourai Release Video](

Head over to the Groestlcoin Samourai Release Page here for the full release announcement.

New: GroestlImage

Groestlimage turns any file into a mnemonic phrase allowing users to generate Groestlcoin private keys and addresses based on the data URI of the provided file. A picture is worth a thousand Groestls.



Source Code

New: Groestlcoin Core Config Generator

Groestlcoin Core Config Generator is a simple GUI to configure the groestlcoin.conf file – A developers dream tool!
Each configuration option is available via the user interface, grouped by what attributes they affect. For ease of getting started with a new configuration, a variety of preset "node classes" are available on the right-hand-side of the screen. Selecting a preset will load our recommended base configuration for a node fitting that description, at which point you can then tune the configuration at the single option level.



Source Code

New: Groestlcoin Dumb Block Explorer

Dumb Block Explorer is a trivial block explorer written in a single PHP file. Now everybody can run their own block explorer.



Source Code

New: Groestlcoin SMS Push TX

Groestlcoin Simple Push TX is a server to push Groestlcoin transactions via SMS. Now everybody can send new transactions via SMS if the Internet is not usable (i.e. blocked by government entities or becomes otherwise unavailable).


Source Code

Update: Electrum-GRS 3.3.6

Electrum-GRS is Groestlcoins #1 thin-client for Windows, MacOS, Linux and Android, based on a client-server protocol. Supporting multi-sig wallets without the bloat of downloading the entire blockchain.

New Features (Universal)

New Features (Windows, MacOS, Linux)

New Features (Android)


Source Code
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Six Hundred Microseconds.

A perspective from the Bitcoin Cash and Bitcoin Unlimited developer who discovered CVE-2018–17144.
That is about the time that Matt Corallo wanted to shave off of block validation with his pull request in 2016 to Bitcoin Core. 600µs is a lot less than what is saved with more efficient block propagation, like XThin, Compact Blocks, or now Graphene over typical links, especially those that are of similar low-end quality in network speed like Raspberry Pis are in compute speed. An optimization that was not in the focus by Core until XThin from Bitcoin Unlimited came onto the scene and kicked the Core team into gear on this issue. Furthermore, 600 microseconds is an order of magnitude or more below the variance between node validation speeds from a Raspberry Pi to a more high-end miner node and thus wholly in the range that the network already deals with. This 600 microsecond optimization now resulted in CVE-2018–17144. Certainly the most catastrophic bug in recent years, and certainly one of the most catastrophic bugs in Bitcoin ever. This bug was initially suspected to potentially cause inflation, was reported because it led to reliable crashes and confirmed by closer analysis… to be actually allowing inflation! I have consistently and repeatedly criticized hubris and arrogance in the most prominent Core developers, and done so since 2013, when the bullshitting around the 1MB block size limit started. Here we have an optimization that talks about avoiding “duplicate” validation like validation is nothing to worry about, an afterthought in Bitcoin almost. And a change that is quickly found to be good in peer reviewed, ACKed in Core-speak, in a rubber-stamp-like manner by Core developers such as Gregory Maxwell. Developers which I fully respect for their intelligence and knowledge by the way, but still, well, dislike as much for their overblown egos and underhanded discussion style as well as having done all they can to handicap Bitcoin with the 1MB limit. I also have to be honest, this change creates an unavoidable element of suspicion in me. For anyone who knows what went down and what the code paths do, it is just unavoidable to have this thought here. I like to qualify that this is not what I assert nor think is happening, but definitely crosses my mind as a potentiality! Because what is better to destroy the value of Bitcoin in the public’s eye than a silent inflation bug? What is better than creating code paths that look harmless for themselves but combined with some other, seemingly harmless rework in other areas of the code, result in utter catastrophe? And it looks like CVE-2018–17144 would eventually have become exactly this. The only thing that saved Core is their effective client diversity between revisions and someone actually noticing that there is a problem. After two years of this bug sitting around idle and exploitable. Client diversity that has been much criticized on the Bitcoin Cash side of things, but it obviously shows its advantages now. Reading the title of the original PR: “Remove duplicatable duplicate-input check from CheckTransaction” , as well as the message therein: “Benchmark results indicate this saves about 0.5–0.7ms during CheckBlock.” almost reads like it could be a sick joke being played on us all now. I always feared that someone from the bankster circles, someone injected into the Bitcoin development circles with the sole goal of wreaking unsalvageable havoc, would do exactly what happened. Injecting a silent inflation bug. Because that is what would destroy one of the very core advantages that Bitcoin has over the current status quo. That of transparency and a verifiable money supply. And, even though as a Bitcoin/BCHer, I do not see true long term prospects in Bitcoin/BTC anymore, calling the whole foundation of crypto into question just like that would have been equally disastrous to “our” variant of Bitcoin. Now, again, I am definitely not saying this is the case with PR 9049 for sure. I actually think the explanation of a young, cocky Core developer, a new “master of the universe” wreaking havoc by sheer arrogance and hubris, is the more likely explanation. People in general, but I don’t even exclude myself here, tend to believe in the competence of others if they appear just self-assured enough. This is part of the problem with attitude and psychological dynamics in this space. It creates a dangerous aura of ‘these guys know what they are doing’. I myself have done some minor work on sensitive areas in the Bitcoin Unlimited implementation. And I am working on some more “consensus critical” code for BCH now (see below). And, yes, I sometimes do lose some sleep over what could go wrong. I know I make mistakes. I have done so. I will. We all do. But I have yet to see anything resembling an admission of being imperfect by the developer in question, or any other prominent Core developer for that matter. The folks in question know exactly who I mean. There must be more reasonable folks in Core, but they are rather silent. Much worse even: In the discussion on github that follows this PR, user freetrader (a well known anonymous but still respected member of the Bitcoin Cash community who helped to create the Bitcoin Cash initial fork) asks the very valid question:
Which is answered in the, all-too-typical for Core, smug manner by Matt Corallo, notably the original author of the bug who has all reason to be a bit more careful and respectful:
The bug was disclosed in an absolutely responsible manner. As even the full disclosure on’s own pages notices, it went to a set of trustworthy people by the person who found the bug and did so in an encrypted PGP message only. This leaves the question why Core recklessly endangered the security of Bitcoin Cash as well endangering the myriad of altcoins that are out there and still susceptible with this premature and hasty publication. The back references from altcoins merging the change trickling into PR #14247 are a glimpse into this process. Now, Matt talks about “running out of time” in the above reply. But what time is that exactly? If you think hard about this, this can only be a distrust in any of the informed parties that they’ll leak this secret prematurely and thus catch Bitcoin Core with their pants down, or as a worse assumption, be actually exploited by one of the informed parties against BTC. Bitcoin Unlimited was ferociously attacked, presumably by deranged BTC supporters from the wider ‘community’, when it had a bug. And it seems a bit like Core members assumed a payback by deranged BCH supporters in kind here (I am not doubting those supporters exist), given the hints in the original disclosure that this bug has actually been discovered by someone aligned with the Bitcoin Cash side of things. But not only that, Core seems to have assumed that members on the BCH side of things who have been informed are deranged or at least irresponsible enough to leak this info to the wrong parties! I like to applaud deadalnix and the ABC team for what I was thinking the Core team should have done here as well: Bury the fix in a bit more and unrelated refactoring code so as to fix it but also to buy some more time for an upgrade. Maybe Core wasn’t creative enough to see a way to hide the problem, but then they also had no reason to blare it out like they did here. This was very irresponsible, and, and this should reach any altcoin impacted by this, this is definitely solely Bitcoin Core’s responsibility. No one else said anything in public before Core published their PR. It should also be noted by the Core team that this creates a strong disincentive to keep them in the loop with initial disclosure for anyone finding a bug. Cory Fields has talked about the risks and dangers with regards to sitting on the knowledge of a 0-day on Bitcoin Cash, and this bug discussed herein is one that was worth at least 10x more in potential damage and thus also shorting value and angry deranged people (a.k.a. “31337 crypto trading bros”) capable of violence. If a party behaves this irresponsibly, it shouldn’t be surprised if it degrades itself to a lower position in the food chain with regards to vulnerability disclosures. I am not saying I won’t inform next time I might stumble upon something, but this is not a good way to create the necessary trust. The Discovery and Disclosure Sitting in my little van by the sea on Monday, I was working on getting the new CHECKDATASIG/-VERIFY opcodes that are about to activate for Bitcoin (Cash) in November implemented on the Bitcoin Unlimited client. I have been looking at a potentially neat use case for those and am motivated to get this done. Around noon, I noticed that there is a lot of divergence in the way that signature operations counting was done in ABC vs. how it was done in Bitcoin Unlimited (BU). I agreed earlier with the BU team that I would go and port most of the CDS/-V stuff over from ABC, but I felt overwhelmed. My thoughts were that: Ok, this is doable, but this needs a lot more analysis and also many more eyeballs for review. And will take a lot longer. Sigh. While doing so, I stumbled upon this comment in the ABC code base: Check for duplicate inputs — note that this check is slow so we skip it in CheckBlock My initial reaction was a slight “Eh, WTF is going on with that comment?”. And then I looked up uses of CheckRegularTransaction in ABC, which is the renamed variant of CheckTransaction in Core (but I didn’t know at that time). I dug through the code to try to understand the logic. I noticed that block validation skips this test as it is assumed to have already happen during mempool ingress. My next thought was a bit of a sinking feeling and a “Uh-oh, I really hope the folks from ABC have thought about the difference between the mempool and block transmission and that those are distinct ways into the system. There might be a problem here!”. And then I went and thought about a way to test this. I patched an ABC node to not relay transactions even when asked and connected one unpatched and one patched node together in -regtest mode and created a transaction with a duplicate input (which the above test was skipping). Wham! assert(), Aborted. Next thought was along the lines: “Oh fuck, this doesn’t look good, gotta notify deadalnix and the crew what is lurking in ABC, this doesn’t look good at all. [email protected]#%!!”. Being aware of the danger that this could maybe be further exploited towards an actual inflation and chain-splitting bug (but I didn’t further check the specifics of this, as a node crash bug with assert() failure was already enough to be worried about), I quickly and somewhat inaccurately noted to myself (and timestamped): BitcoinABC does not check for duplicate inputs when processing a block, only when inserting a transaction into the mempool. This is dangerous as blocks can be generated with duplicate transactions and then sent through e.g. compact block missing transactions and avoid hitting the mempool, creating money out of thin air. awemany [Footnote: I timestamped this message in the BU slack, adding an innocuous situational lie of ‘Ooops, wrong channel’ to it. I also tried timestamping my findings on on my usual go-to site but they only submit timestamps every 24h due to the fees on Bitcoin being too high to do more often… I guess I should maybe get into the habit of doing timestamping transactions myself..] Opening up a disclosure email to deadalnix, I started to have a thought of: “Ok, actually, where is this stuff coming from, when and where did they introduce it into the code, might we be lucky and this is not in a release yet?” And then I noticed that this stuff was coming from Core. Already having written a disclosure report, I rechecked whether Core was vulnerable as well. And, once again: Wham! assert(), Aborted. I started to get shivers up my spine. Uh oh! Core has a crash bug, potentially worse. Stuff in the code since 2016. NOT good. NOT good at all. I like to say here that I actually had a feeling of this is bad, not this is good because of Core vs. Cash or something like that. I (unfortunately) still own a (for my poor soul significant) amount of BTC and for that reason and others do not like having bugs in Core either. Being a responsible citizen in this space, I then wrote the encrypted disclosure email to Wladimir, sickpig and some others, attaching a variant of the ABC and the Core patch to exploit this problem to my disclosure. I also put in a BCH address for a bounty payment to myself into that email (disclosed as proof below), as I feel this should be something worth a little performance bonus 🙂 No money has been received at the time of this writing yet. If you want to change this, you can send me BCH here: bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5 (1NBKDco2EctDXvBv6r4hqJRPWfgX9jFpqs) I chose the handle beardnboobies as this is the first thing that came into my mind when I thought about this very discovery here. I thought: Ok, I am slowly becoming a pale nerd working on just code, with beard and manboobies. Oh well. I have noticed that this handle was — for whatever reason- taken out of the release notes that are checked into the main development branch of Bitcoin Core and is only available in the release branch / tag, being replaced with anonymous contributor on the main branch. I wonder: Do you Core guys feel this is too unprofessional to have this pseudonym appear in the main branch? Have some humor please! 🙂 By the way, a plea: I urge everyone in BCH as well as BTC (as well as impacted altcoins), to take a fine-toothed comb through the code with the goal of looking for similar issues! More specifically, I faintly remember (though might be wrong) from discussions back with Core devs on reddit in 2016 and before, that the idea that there’s a lot of “duplicate validation” between mempool and block validation was kind of en vogue back then. Potentially more code is vulnerable because it assumes that mempool validation can stand in for block validation. I suspect more, though maybe not as grave bugs, in this area. Reactions After I submitted it, I felt relief and then I started to watch the space from the back. A weird situation. Only then I also fully realized what Core contributor Cory Fields described with a bit of a different angle and on a smaller scale, the weirdness of having found a bug that you know is worth millions at least, massively impacting a $100 billion currency. The fact that I could have gone and rented hash power and shorted BTC and exploited this. But also the fact that I did not! Wladimir eventually wrote me an email that they’re preparing releases (and at that time or around it they published the PR), so I responded expressing my astonishment of the quite public handling of this serious issue. What I was amazed by in general was the long time it took for the bug to blow up to its full proportions, with the process seemingly even not over now. One thing is certainly others digging into this and realizing the full severity of this — as it turns out, yes it CAN be used to double-spend and inflate on BTC after all! — but also the time it takes from the initial PR being public, seemingly not noticed at all and the first media article being written. And then I noticed the usual spin. The “stupid BCashers can’t code and are irresponsible and what not” angle that is all too often repeated then by seemingly cerebrally insufficient Core supporters. I quote the below to gloat maybe. But also to show the world WHAT kind of bullshit the Bitcoin Cash side of things is facing here in a constant barrage. This is just from a few of the more prominent Core supporters and devs. There is, of course, a lot more folks foaming “btrash, bcash” at the mouth on reddit and twitter. Tone Vays and Jimmy Song Here we have Tone Vays, who likes to pose with the undercurrent of violence by wielding weapons on Twitter and apparently also on Youtube, discussing this bug with Jimmy Song in an unwillingly hilarious Youtube video:
Luke-Jr I like to say some words about this tweet of Luke-Jr, committing the sin of bearing false witness about us irresponsible “BCashers”…
I suspect Luke-Jr has been left in the dark about the background of this disclosure as well, not belonging to the innermost circles either. Careful observers might have noticed even more of this dynamic happening with other people. And note again: I have done everything that is necessary to make this a responsible disclosure. The initial, unobfuscated public disclosure happened by Bitcoin Core on their github! This is exactly the opposite situation compared to what Luke-Jr is describing. This is despicable.
Closing remarks Apart from pointing out the insane spin of some Core supporters in the preceding part, I simply want to take the opportunity now to urge caution for everyone here. Bugs lurk everywhere. Everyone is imperfect. Myself included, of course. I started to like Jihan Wu’s credo of “Don’t play hatred, don’t wish competing coins ill. Just wish and try to make BCH better” (from twitter) and see BCH and BTC in fierce but still civil competition. Civil competition obviously meaning no violence, including no violence like attacking each other’s nodes. I like to reiterate that, despite the gloating and strong words you might find in this article, I did everything to play fair. I also agree in general with Cory Fields from Core that it is not very easy to find the necessary disclosure addresses and information. He’s right about the lack of easily accessible GPG keys both on the BCH as well as — I like to add- on the BTC side of things. I didn’t find a non-retracted key of Pieter Wuille in time. I also like to note that a few things went finally completely out of the window here with this bug, for example Core’s idea of ‘the code being law’. If the code is law, does that mean that you have to accept inflation now? Or is it actually the Core devs steering the ship? Is an element of reasonableness entering the space? And yes, I sincerely believe, despite the current price ratio that BCH has a much brighter future than BTC, by being fundamentalist on the principles that matter and came along with the original white paper while not being fundamental on things that were created post-hoc — like the 1MB (now 4MW) limit in the Bitcoin Core implementation. As I also don’t think extended inflation is crucial for BTC’s operation. But anyone is free to buy or sell as they want. Let’s continue competing. Let’s civilly inform each other of bugs. May the best chain win. Finally, I like to thank Andrea Suisani, Andrew Stone and Peter Rizun for their review of this article and valuable input.
submitted by Cobi-communities to u/Cobi-communities [link] [comments]


Major new release:
if using git:
git clone git checkout v0.14.2.3 
New in this release:
Thanks to all who have contributed to this release!
For issues, please post them here:
previous rc0 announce:
previous release (0.11):
submitted by cryptapus to myriadcoin [link] [comments]

PSA: Line-by-line breakdown of the logic used in the 2016-block difficulty adjustment. Posted here because there is some confusion about difficulty on Bitcoin Cash.

I am posting this here because I see people in other threads afraid that difficulty may rise because we had EDA (emergency difficulty adjustment) take us down to 13% of hashrate difficulty, when in reality it will not have taken us ~16 weeks to get to 2016 blocks (as 13% would indicate).
In an attempt to provide some insight as to exactly how the difficulty retarget works, I am posting the below line-by-line breakdown.
TL;DR: Difficulty will adjust off the current working difficulty, whatever it may be. If it takes longer than 2-weeks, we adjust down. If shorter, we adjust up. Since it took us longer than 2 weeks already, we are definitely adjusting down!
. .
Line-by-line breakdown of the "CalculateNextWorkRequired()" function in pow.cpp, which is called for every 2016th block in the chain to retarget difficulty:
Comments: Note how clearly it's written. Very clear, concise and simple code.
This function is called every 2016 blocks to determine the correct acceptable difficulty of the next block (basically it is what does the adjusting every 2016 blocks). This function is "orthogonal to" (separate from) the "emergency difficulty adjustment" that Bitcoin Cash introduces and it works off the current difficulty (which may have been previously readjusted down by the emergency difficulty adjustment code or not).
Basically bitcoin has a single 'difficulty' variable, conceptually, and EDA readjusts this variable and/or this function does every 2016 -- but it's the same variable that both sets of code tweak.
uint32_t CalculateNextWorkRequired(const CBlockIndex *pindexPrev, int64_t nFirstBlockTime, const Consensus::Params ¶ms) { 
The incoming parameters explained:
  • pindexPrev -- a pointer to the tip of the blockchain right before a new block arrives.
  • nFirstBlockTime -- the timestamp of the first block in this 2016-block series
  • params -- the consensus params being used -- basically bitcoin has alternate consensus rules if it's on testnet or on mainnet or if it's in the developer debug REGTEST chain. The params variable captures the consensus rules being used.
    if (params.fPowNoRetargeting) { return pindexPrev->nBits; } 
The above is simply checking if we're in a special test/debug mode where a global flag disabling difficulty retargeting is set (as might be done on the REGTEST or TESTNET, optionally). Not used in mainnet, so safe to ignore the above lines. If the flag is set, return early and do no difficulty retarget.
 // Limit adjustment step int64_t nActualTimespan = pindexPrev->GetBlockTime() - nFirstBlockTime; 
Takes the current time and the time of 2016 blocks ago and measures the space in between. No magic here -- this is basically how much time has elapsed in 2016 blocks. EDIT: Unit is seconds
 if (nActualTimespan < params.nPowTargetTimespan / 4) { nActualTimespan = params.nPowTargetTimespan / 4; } 
params.nPowTargetTimespan for mainnet is set to 2 weeks' worth of seconds, or 120960 seconds. Compute readjustment but if it's below 25%, limit it to 25%
 if (nActualTimespan > params.nPowTargetTimespan * 4) { nActualTimespan = params.nPowTargetTimespan * 4; } 
Limits readjustment to 400%.
 // Retarget const arith_uint256 bnPowLimit = UintToArith256(params.powLimit); 
bnPowLimit is the absolute maximum pow limit set. For mainnet I believe the limit is MAX_INT_256 (which is an obscenely large number). For testnet it may be much lower.
 arith_uint256 bnNew; 
This will be the new difficulty.
Pre-set the new difficulty to current difficulty (note how current difficulty may have been readjusted previously by Bitcoin Cash's emergency difficulty readjust).
 bnNew *= nActualTimespan; 
Scale the difficulty up to the actual timespan. Note actual timespan is clamped in the range (25%,400%) of 120960 seconds aka (30240,483840) seconds.
 bnNew /= params.nPowTargetTimespan; 
Divide the computed product back by the idealized timespan (120960). This basically is what retargets difficulty right here, in simple math.
 if (bnNew > bnPowLimit) bnNew = bnPowLimit; 
Cap the difficulty at the limit for this configuration.
 return bnNew.GetCompact(); 
Return the result as a 32-bit 'compact' representation of the difficulty.. the details of what this number means I won't go into here as they aren't important.
submitted by NilacTheGrim to btc [link] [comments]

Notes on a first quick test of NTumblebit, on Linux and regtest.

I just thought I'd jot down a few notes on the experience of trying out the current NTumbleBit code.
This is testing on regtest, done for the simple reason that you don't have to wait for testnet blocks (nor sync testnet which is mildly annoying). At this stage I just wanted to learn how this works.
Your starting point is this wiki page.


You need to download Bitcoin Core. Use at least 0.13.1 - this turned out to be only major blocking point in the whole test, funnily enough, for me - it took me a few hours(!) in debugging to realize that the reason my wallet's coins were not being recognized was simply because 0.12.1 didn't support the necessary RPC syntax. (Note to devs: is there a way to expose errors/exception to the user in the client to help with under-the-hood errors like that? RPC configuration errors are exposed, so that's good of course).
Since this is regtest, that's it: you don't need to sync any blockchains :)
However, you do of course have to configure and start it. Put a bitcoin.conf somewhere (if you're currently running a node it's easiest to make a separate one from your main ~/.bitcoin/bitcoin.conf one, of course. I put one in ~/bitcoin.conf with these settings:
rpcuser=bitcoinrpc rpcpassword=123456abcdef 
(you'll need those values again in a minute) and then run with
~/bitcoininstallationdibitcoind -regtest -daemon -conf=homedibitcoin.conf 
(I didn't need to add server=1 to config).
Note that coins are not available until maturity, so you need to use the generate command to mine blocks, like this:
~/bitcoininstallationdibitcoin-cli -regtest -rpcuser=bitcoinrpc -rpcpassword=123456abcdef generate 101 
Now your regtest bitcoind is running, you can move on to Tumblebit. Follow the instructions in the wiki page mentioned at the start; install .Net Core - the Microsoft instructions are easy to follow, just a couple of apt-gets and install the *.deb. Next, clone the github repo and run the Unit Tests. They passed first time for me.


Next, start up the server, following the instructions in the wiki, except note you're using regtest, so:
cd NTumbleBit.TumblerServer dotnet run -regtest 
The first start up will compile but also set up RSA keys, all that is fine without changes, but you'll need to edit the config so that the RPC is pointing at your regtest instance properly. In this case it (the new config should be located in ~/.ntumblebit/RegTest/server.config) should be edited to look like:
rpc.url=http://localhost:18332/ rpc.user=bitcoinrpc rpc.password=123456abcdef #rpc.cookiefile=yourbitcoinfolde.cookie 
Then restart and check you get no RPC errors. Leave that console open, it's running a server loop.
Next, configure and start the client. Note, we are still following the wiki page, except for the regtest element, so:
cd NTumbleBit.CLI dotnet run -regtest 
You'll most likely get an RPC error again, before it shuts down. Now we need to edit the ~/.ntumblebit/RegTest/client.config file. The server can be left as the default localhost:5000, but you need the right RPC settings:
rpc.url=http://localhost:18332/ rpc.user=bitcoinrpc rpc.password=123456abcdef #rpc.cookiefile=yourbitcoinfolde.cookie tumbler.server=http://localhost:5000 outputwallet.extpubkey= outputwallet.keypath=0 
the last two fields are the important bit, which the wiki page explains in some detail for the testnet case.

Details on setting up a receiving wallet (for this test!)

What you need is a BIP32 based wallet (HD) that supports testnet, and can be run against regtest here (which in most cases will be the same thing to a wallet, as long as it can connect via RPC to sync itself). The good news is the wallet doesn't need to contain any coins. The details of the following probably won't be suitable for most (if you've never used joinmarket it's a bit convoluted), so you'll probably want to find another easy to use wallet; the wiki page should be a good starting point.
For my test I used joinmarket; all we need to do is (a) hook it up to the regtest instance, and (b) extract the BIP32 xpub key that we'll be sending coins to. So in my case the flow of coins is:
Regtest Bitcoin Core wallet (containing 'mined' coins) one branch of my BIP32 joinmarket wallet, configured to sync against the same regtest instance.
I used my new joinmarket code but it's the same for the main joinmarket code. I overwrote joinmarket.cfg to have regtest settings (use this file; only the highlighted settings matter, those are the right ones for this test), then just run python randomseed. "randomseed" there can be literally anything, it's read as a brainwallet style seed for the bip32 wallet (because testnet, we don't care about its insecurity). The tpub.. keys seen for each branch are the "xpub" public keys at that branch of the BIP32 wallet. Tumblebit is going to send to a branch below whatever xpub we need, so the simplest is to add a print statement to print the xpub key above that; e.g. add this code:
for i in range(max_mix_depth): print('master for index: ' + str( i) + ' : ' + btc.bip32_privtopub(mixing_depth_keys[i])) 
immediately above this line. Then run again python randomseed.
Extract an xpub for any one of the "mixdepths", e.g. I chose:
master for index: 3 : tpubDBFGvUbWtEPKXeWPeG7rUh98iV9GuXSDbnk6ZrZHjcmp134BPByT293HPPQ93DktrVFKpZeAU1ULSdyfmwWuUGvUVLP19JkdUq2mzNKFJPR 
and put that tpub.. key into the field pubkey in the above mentioned 'client.config':
outputwallet.extpubkey=tpubDBFGvUbWtEPKXeWPeG7rUh98iV9GuXSDbnk6ZrZHjcmp134BPByT293HPPQ93DktrVFKpZeAU1ULSdyfmwWuUGvUVLP19JkdUq2mzNKFJPR outputwallet.keypath=0 
Now save and quit.

Running the tumble

Restart the client. If RPC is right, it'll start running, waiting for blocks. Your regtest Core instance will have coins (after the previous generate 101), and those coins will be automatically tumbled, one coin at a time, into the output wallet (in my case, the branch m/0/3/0 which is labelled there 'mixdepth 3, external').
Now you can test and watch the process! Open up a third console and repeatedly generate blocks:
/path/to/bitcoin/bin/bitcoin-cli -regtest -rpcpassword=123456abcdef generate 1 
As each block is generated you'll see the state in the client terminal window updating, showing the phases. A new 'epoch' (right term?) is started every N blocks (I haven't investigated the timing yet), and several epochs run concurrently. In each one, the client can pay in 1 Bitcoin (from Core) and eventually get out 1 coin - fees to the destination (Joinmarket in my case, any other BIP32 in yours). You can replace generate 1 with generate N but I'm not sure if the code will always correctly handle you mining lots of blocks at once! After a large enough number of blocks you'll start to see 'ClientCashout phase' occurring, and txids being printed out. You can go back to your (JM or other) wallet and see the coins arriving; here's what I see after a few epochs have gone through (using my python randomseed command):
for mixdepth=2 balance=0.00000000btc mixing depth 3 m/0/3/ external addresses m/0/3/0 tpubDDMAxSHJmxzeXwDnATuvtDizqNSsQKpXGufBDnER44BzEbHy7kg485zZwHqvzprgf6yEQYg9qYYfsLYS1HMmdSuXDzQb2dJSiga9geyM62R m/0/3/0/007 mw9s7tYucxB9yr2L6HkqeDVsh3wdgMdcyK used 0.99995750 btc m/0/3/0/008 mq5TgTNgwYHv88Q4T7wL6kTb1MBSPE3mqK used 0.99995750 btc m/0/3/0/009 mhzQFY8FNvux6SKWKLKmhBB3Sw4MLaSnyu used 0.99995750 btc m/0/3/0/010 mrYECmCf5UKa1BBRMuzprVugsCi9z7oiHo new 0.00000000 btc m/0/3/0/011 mopUNXmHT8ngfBymM3c3EYMg7RLZAf6Zc6 new 0.00000000 btc m/0/3/0/012 mmaVXVfQP4UAYJPhMpQ3FhgXfHzujaxyw4 new 0.00000000 btc m/0/3/0/013 mzYD1AcUFz8SVwJM8EjVCfEM6pcYnHooBR new 0.00000000 btc m/0/3/0/014 my5unLCEMWQBkXBdeJ75VVGk1wrMrT8iDE new 0.00000000 btc m/0/3/0/015 muA76YSTtKKmD6HnVKYhkd9K9TZnPLh8pp new 0.00000000 btc internal addresses m/0/3/1 for mixdepth=3 balance=2.99987250btc 
As you can see, 3 coins have arrived.
submitted by waxwing to TumbleBit [link] [comments]

What has Dash ever copied from others besides the original BTC codebase?

In the spirit of not biting the hand that feeds us, I'm starting this thread to raise awareness of how much Dash copies from Bitcoin Core.
It's disappointing to see even some Dash Mods don't understand how much Dash benefits from all the hard work of BTC Core, so let's look at precisely what Dash 12.3 has copied from Bitcoin.
What has Dash ever copied from others besides the original BTC codebase?
Dash copies ("backports") 1000s of BTC Core commits on every major release.
Do you know how to use github? If you do, the scale of what Dash has copied from BTC is perfectly clear from looking at
You can see most so-called Dash commits were written by Bitcoin devs, and only one Dash dev (UdjinM6) with a significant number of original (IE non-backported) commits.
Here are the specifics on all the latest things in Dash 12.3 copied from BTC as well as a statement of Dash's intention to continue copying from BTC for the foreseeable future:
We backported many performance improvements and refactoring from Bitcoin Core and aligned most of our codebase with version 0.14.
+Most notable ones besides various performance and stability improvements probably are
+Compact Block support (BIP 152),
+Mining transaction selection ("Child Pays For Parent"),
+Null dummy soft fork (BIP 147, without SegWit), +Nested RPC Commands in Debug Console and
+Support for JSON-RPC Named Arguments.
+You can read more about all changes in Bitcoin Core 0.13 and 0.14 in following documents: +-; +-; +-; +-; +-; +-
+Note that some features were already backported earlier (per-UTXO fix, -assumevalid, GUI overlay etc.) and some were not backported at all +(SegWit and feefilter, you can read more about why we did so here and here). +The alert system was also kept in place for now.

We are going to continue backporting the most notable fixes and improvements from Bitcoin Core versions 0.15 and 0.16 in future releases.

Here is a tiny part of the list of the latest things Dash has copied from BTC Core
I'd post the entire list but Reddit says "(THIS IS TOO LONG (MAX: 10000)" LOL!

12.3 backports and related fixes:

bc45a2f87 Backport compact blocks functionality from bitcoin (#1966)
8b4c419ed Revert "Merge #7542: Implement "feefilter" P2P message" (#2025)
a4b313fd3 Fix std in DBG macro
6a6e4cdc1 Remove remaining using namespace std
08b5c69ef Merge #9643: [refactor] Remove using namespace from wallet/ & util*
ccca7af09 Merge #9476: [refactor] Remove using namespace from rpc/ & script/ sources
4ac4e96e8 Merge #9765: Harden against mistakes handling invalid blocks
662ec024a Make peer id logging consistent ("peer=%d" instead of "peer %d")
592d8f073 Use a temp pindex to avoid a const_cast in ProcessNewBlockHeaders
15a8fcf99 Add a CValidationInterface::NewPoWValidBlock callback
d28172f57 Call AcceptBlock with the block's shared_ptr instead of CBlock&
c99dd9733 [qa] Avoid race in preciousblock test.
807ae74c2 Make CBlockIndex*es in net_processing const
1d1c31052 Fix cmd args handling for -bip9params
64817fe1d [qa] Fix race condition in
b2bc78099 Fix argument to wait_until
026f2e2a8 Merge #8446: [Trivial] BIP9 parameters on regtest cleanup
e326bda69 Tests: refactor compact size serialization in mininode
2c810d2c3 Allow changing BIP9 parameters on regtest
45151bd13 Move context-required checks from CheckBlockHeader to Contextual...
cef919f18 Merge #9486: Make peer=%d log prints consistent
55ef4d0a9 [wallet] Add include_unsafe argument to listunspent RPC
e1e03f42c [wallet] Add IsAllFromMe: true if all inputs are from wallet
611b31ece Merge #9650: Better handle invalid parameters to signrawtransaction
ff335e47f [qa] test_framework: Add wrapper for stop_node
64e1bfacd Add BIP32 to
4bb2af8d1 Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8
61af31531 Merge #8976: libconsensus: Add input validation of flags (#1891)
00a0bc710 Remove "TODO: fix off-by-one"
625252fb4 Allow to pass redirect_stderr=True to initialize_chain and use in
d56ac5a74 Fix and add workaround for pruning mode
submitted by Dash_2_The_Future to dashpay [link] [comments]


NOTICE We have found issues with this release, please do not use:
A major release for Myriadcoin (v0.14.2.1) has been released here:
New in this release:
PLEASE NOTE: It is always a good idea to take a moment to backup your wallet.dat file before updating.
If you would like to use git, please use the "v0.14.2.1" tag for the release:
git clone cd myriadcoin git checkout v0.14.2.1 
Please Note: A consensus critical bug was found in v0.14.2.0 and this update is REQUIRED for those running 0.14 nodes. It will most likely also require a "-reindex" to be performed. Updated binaries are being prepared and will be available as soon as possible. edit: a "-reindex" is required if you were running v0.14.2.0
Reasons for required update. Here's what happened: At ~block 2223644 v0.14.2.0 nodes were banned. Most likely this was due to a missing AUX-POW check in validation.cpp. The change is noted here:
It may have been a miner attempting to submit an AUX-POW block for an algo that is not allowed, or it could have been something not nefarious. Regardless this has been fixed in v0.14.2.1.
Here is a link to the previous announce:
submitted by cryptapus to myriadcoin [link] [comments]

Groestlcoin Release September 2018


As always, the past 3 months since 22nd June have been crazy busy. The bears might still be around, but the show must go on and of course has not slowed the Groestlcoin development team in the slightest. Here’s a quick overview of what has already happened since the last release: - Integrated into the bitbns exchange, with the ability to buy Groestlcoin directly with the Indian Rupee. - Groestlcoin Rebrand Vote – Whilst there was much talk and push for a rebrand vote, the overall result was almost unanimously in favour of keeping our unique and conversation-starting name. With just 83 votes to Rebrand, and 2577 votes to No Rebrand. Thank you for all who voted, the funds raised are being used to fund ongoing hosting and development costs. - Integrated into the Cryptobridge exchange. Cryptobridge is a popular decentralised exchange where you always hold the private keys to your funds, only YOU have access to them. - Groestlcoin has been added to SimpleSwap – Groestlcoin can now be swapped with over 100 other cryptocurrencies, without signing up! - Groestlcoin has been added to UnoDax, one of the leading cryptocurrency exchanges in India, with TUSD, BTC and INR trading pairs. - Groestlcoin has been added to, where you can buy Groestlcoin using Bitcoin and over 50 other altcoins. Purchasing with VISA/Mastercard is coming VERY SOON. Discussed later: - Groestlcoin has been listed on #3 largest exchange in the world on volume, Huobi Global! More on this to come further on in the announcements. - Groestlcoin has been added to the Guarda Multi-Currency Wallet. - Groestlcoin has been added to Melis Multi-Device, Multi-Account, Multi-Platform, Multi-Signature advanced wallet! Already this list is far more than most other cryptocurrencies have achieved in the past 3 months. But this is just the tip of the iceberg of what has been developed.

What's been Happening?

GRSPay Released

We are so excited for this, that it has it's own separate reddit thread. Head over there now at to see more on this!

Melis Wallet

The the most advanced wallet for Bitcoin, Bitcoin Cash, Litecoin and now Groestlcoin.
With Melis you have the complete control of your bitcoins and private keys, you can define spending limits policies and make use of two or more factors authentication. Melis is open source, published on GitHub.

How Melis Works?

You can create as many accounts as you want. An account is a part of your wallet that can be customised to your requirements. You can choose how many co-signers are required to spend funds. The accounts are completely independent and act like separate wallets from each other but can be accessed via the same details. A core feature of Melis is the ability to set a ‘primary’ device. With this you can set an account as ‘Secure’ so it is only viewable (and accessible at all) from the Primary device. You can have a savings account hidden from the outside world whilst also having your ‘spending’ funds available on the go. With Melis you can create a multi-signature account between N people, where up to N signatures are required to sign a transaction, choosing if any of those should be mandatory.
Core Features:

Guarda Wallet

Safer than ever! Desktop Light Wallet - Anonymous and fast!
With Guarda Multi-currency Desktop Light Wallet you don’t need to register. Guarda has no access to your private keys or funds. You can receive, send, store, buy and exchange cryptocurrencies in complete anonymity and safety. All these features are available on Linux, Windows or MacOS. Choose the one that suits you!
More info about Guarda wallet on

Integrated into HolyTransaction

What is HolyTransaction?

HolyTransaction gives users access to the crypto world with a universal cryptocurrency wallet and instant exchange.


For more information, visit Holy Transaction here.

Integrated into NEXT Wallet

What is NEXT?

NEXT is a modern, next-generation stylish open-source Desktop wallet.


For more information, visit NextWallet here.

Integrated into Blockchain Financial

What is Blockchain Financial?

Blockchain Financial is a set of web based services for individuals and companies that want to make things happen with the Cryptocurrencies Ecosystem. - For those that don't know anything about cryptocurrencies, we offer tools that will let them receive, send and operate with an assortment of coins. - For those that are already riding the wave, we offer tools that will let them do all those things that they weren't able to do.

Blockchain Financials mission

We're not here to reinvent the wheel. We're here to make it run smoother for you, and we provide some of the most useful services you'll find on the internet, made in a way that is easy to understand and use on a daily basis. In short, we're a bunch of people that claim to be Crypto Evangelists. We strongly believe in cryptocurrencies, and our main promise is to push them up so more people get involved and take all the advantages they offer.

More information from Blockchain Financial

Back in 2014, the world was taken by storm when Facebook approved the first cryptocurrencies tipping apps. The first was for Dogecoin, and the second was for multiple coins.
The project was hosted on, and persisted for almost two years, built up a massive user community and gave a home to Bitcoin, Litecoin, Dogecoin and dozens of other bitcoin-based altcoins.
After very active months, the tipping hype started to fade away. Then, the developers decided to jump into the next stage: bringing not only tipping, but also mining and a widget that could be embedded on websites to allow everyone to accept payments. Sadly, the work was never completed because the project started to require an unsustainable amount of resources. Then, in a painful decision, a shutdown was announced by December 2015.
A couple of months after was closed, the source code was released by its creator as Open Source on GitHub. But it wasn't maintained.
Now, some of the original members of the dev and admin teams gathered up with a handful of the WhitePuma's elite users, and decided to make something good with the best pieces of the old source code. That, with fresh new ideas and the power of the BardCanvas engine, synthesized the core of Blockchain Financial.
More info about Blockchain Financial wallet on .
For more information, visit [Blockchain Financial](

Groestlcoin Listed on Huobi

Who are Huobi?

Huobi was founded in China and is now based in Singapore, with offices in Hong Kong, South Korea, Japan and the North America, currently sitting #3 in volume on Coinmarketcap. Huobi is a great leap forward for our growing presence in Asia and we are very excited to be listed here!
You can find the official Huobi announcement here.

Groestlcoin Core v2.16.3 - Please Update ASAP

A new major Groestlcoin Core version 2.16.3 is now available for download which includes both a Denial of Service component and a critical inflation vulnerability, so it is recommended to upgrade to it if you are running a full Groestlcoin node or a local Groestlcoin Core wallet.
v2.16.3 is now the official release version of Groestlcoin Core. This is a new major version release with a very important security updates. It is recommended to upgrade to this version as soon as possible. Please stop running versions of Groestlcoin Core affected by CVE-2018-17144 ASAP: These are 2.13.3 and 2.16.0.
As a result in this, all exchanges and services have been asked to upgrade to this version, so please be patient if wallets go in to maintenance mode on these services.

What's new in version v2.16.3?

This is a major release of Groestlcoin Core fixing a Denial of Service component and a critical inflation vulnerability ( exploitable by miners that has been discovered in Groestlcoin Core version 2.13.3 and 2.16.0. It is recommended to upgrade to 2.16.3 as soon as possible. If you only occasionally run Groestlcoin Core, then it's not necessary to run out and upgrade it right this second. However, you should upgrade it before you next run it. If you know anyone who is running an older version, tell them to upgrade it ASAP. Stored funds are not at risk, and never were at risk. At this time we believe over half of the Groestlcoin hashrate has upgraded to patched nodes. We are unaware of any attempts to exploit this vulnerability. However, it still remains critical that affected users upgrade and apply the latest patches to ensure no possibility of large reorganizations, mining of invalid blocks, or acceptance of invalid transactions occurs.

The Technicals

In Groestlcoin Core 2.13.3, an optimization was added (Bitcoin Core PR #9049) which avoided a costly check during initial pre-relay block validation that multiple inputs within a single transaction did not spend the same input twice which was added in 2012 (Bitcoin Core PR #443). While the UTXO-updating logic has sufficient knowledge to check that such a condition is not violated in 2.13.3 it only did so in a sanity check assertion and not with full error handling (it did, however, fully handle this case twice in prior to Thus, in Groestlcoin Core 2.13.3, any attempts to double-spend a transaction output within a single transaction inside of a block will result in an assertion failure and a crash, as was originally reported. In Groestlcoin Core 2.16.0, as a part of a larger redesign to simplify unspent transaction output tracking and correct a resource exhaustion attack the assertion was changed subtly. Instead of asserting that the output being marked spent was previously unspent, it only asserts that it exists. Thus, in Groestlcoin Core 2.16.0, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur. However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion. This could allow a miner to inflate the supply of Groestlcoin as they would be then able to claim the value being spent twice.
Groestlcoin would like to publicly thank Reddit user u/Awemany for finding CVE-2018-17144 and reporting it ( You deserve gratitude and appreciation from cryptoworld, and you have ours. If you want to support him for his work, please consider donating to him on his bitcoin cash address: bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5

Groestlcoin Electrum-GRS 3.2.2 - Ledger & Trezor Edition

What is Electrum-GRS?
Electrum-GRS is a lightweight "thin client" groestlcoin wallet Windows, MacOS and Linux based on a client-server protocol. Its main advantages over the original Groestlcoin client include support for multi-signature wallets and not requiring the download of the entire block chain.


Electrum-GRS Mobile Android

What is Electrum-GRS Mobile?

Electrum-grs is a lightweight "thin client" groestlcoin wallet Android based on a client-server protocol. Its main advantages over the original Groestlcoin client include support for multi-signature wallets and not requiring the download of the entire block chain.


Groestlcoin EasyVanity Released

Groestlcoin EasyVanity is a Windows app is built from the ground-up in C# and makes it easier than ever before to create your very own bespoke Groestlcoin address(es), even whilst not connected to the internet! You can even generate multiple keys with the same prefix and leave it on overnight whilst your CPU or GPU collects and stores these addresses locally.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then Groestlcoin EasyVanity is the right choice for you to create a more personalized address.


• Ability to continue finding keys after first one is found • Includes warning on startup if connected to the internet • Ability to output keys to a text file (And shows button to open that directory) • Ability to make your match case sensitive (Where possible) • Show and hide the private key with a simple toggle switch, and copy the private key straight to your clipboard • Show full output of commands • Includes statistics whilst the application is running • Ability to choose between Processor (CPU) and Graphics Card (GPU) • Automatically detects 32 or 64 bit systems • Features both a Light and Dark Material Design inspired Themes • EasyVanity's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky. • EasyVanity includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). Both can be built from source, and both are included in the Windows binary package. • Prefixes are exact strings that must appear at the beginning of the address. When searching for prefixes, Easyvanity will ensure that the prefix is possible, and will provide a difficulty estimate. • The percentage displayed just shows how probable it is that a match would be found in the session so far. If it finds your address with 5% on the display, you are extremely lucky. If it finds your address with 92% on the display, you are unlucky. If you stop EasyVanity with 90% on the display, restart it, and it finds your address with 2% on the display, your first session was unlucky, but your second session was lucky. • EasyVanity uses the OpenSSL random number generator. This is the same RNG used by groestlcoin and a good number of HTTPS servers. It is regarded as well-scrutinized. Guessing the private key of an address found by EasyVanity will be no easier than guessing a private key created by groestlcoin itself. • To speed up address generation, EasyVanity uses the RNG to choose a private key, and literally increments the private key in a loop searching for a match. As long as the starting point is not disclosed, if a match is found, the private key will not be any easier to guess than if every private key tested were taken from the RNG. EasyVanity will also reload the private key from the RNG after 10,000,000 unsuccessful searches (100M for oclvanitygen), or when a match is found and multiple patterns are being searched for. • Free software - MIT. Anyone can audit the code. • Written in C# - The code is short, and easy to review.

Groestlcoin Sentinel (Android & Blackberry) – Mainnet + Testnet

What is Sentinel?

Groestlcoin Sentinel is the easiest and fastest way to track/receive/watch payments in your offline Groestlcoin Wallets. Groestlcoin Sentinel is compatible with any standard Groestlcoin address, BIP44 XPUB (Extended Public Key) BIP49 YPUB and BIP84 ZPUB
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 particular wallet.

What's New?

The P2SH paperwallet supports creating P2SH paperwallets in bulk, keypair generation with QR codes and sweeping tool. Groestlcoin believes strongly in privacy, the live version does not collect and store IP or transaction data.
The BECH32 paperwallet supports creating BECH32 paperwallets in bulk, keypair generation with QR codes and sweeping tool. Groestlcoin believes strongly in privacy, the live version does not collect and store IP or transaction data.

Groestlcoin Web Wallet Update 1.4

What is Groestlcoin Web Wallet?
Groestlcoin Webwallet is an open source, multisignature, HD Wallet and more! Webwallet is a a open source browser based Groestlcoin webwallet.
Webwallet is a playground for Groestlcoin in javascript to experiment with. It supports multisig, OP_HODL, RBF and many more. Groestlcoin believes strongly in privacy, the live version does not collect and store IP or transaction data.
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Qtum GitHub Development Guide

(translated from original on WeChat
This article will serve as a quick start guide for Qtum developers to develop projects that use Qtum on GitHub.
What is Qtum?
The official developer described Qtum as a decentralized blockchain project that supports smart contracts based on the UTXO model integrated into Qtum's unique Account Abstraction Layer.
Qtum Developer
No matter what product or technical tool you want to develop with Qtum's technical tools, you'll find development tools that will help you get the most out of it. This article will guide you through the basic setup, including setting up a local Qtum network, and will give you a number of tool features, such as showing how to connect to the test network for more detailed testing, how to connect to the main network when preparing for deployment, with QRC20 tokens for example, using a smart contract to issue tokens.
For Qtum developers, the most useful part is how to use the Qtum JS library to manipulate the parts of the smart contract, and even more cool is to use React to create a simple DAPP part.
Read through the entire guide for development in the Qtum environment.
I believe that after using Qtum's series of tools, you will be more interested in exploring Qtum's content and projects for developers. Let's take a look at some of the key GitHub projects that Qtum offers.
Qtum GitHub Developer Project
The following Qtum development tools are very useful for the development of any Qtum DAPP or Qtum-related projects.
Qtum Boilerplate Project
An introductory project created by Qtum developers to help you get started creating DAPPs on Qtum. Follow the code repository instructions to gain insight into many aspects of Qtum and what it means to create a Qtum DAPP.
Qtum Docker
For developers involved in Qtum development, the Qtum docker project is very important. The Qtum team created a docker image so that all developers can run the Qtum network locally, and any operating system is available from the docker hub.
So, if you have already downloaded docker, congratulations, you are already advanced. (If you need help setting up your Qtum regtest environment, you can see the instructions in the connection guide, which explains in detail how to set up the environment:
regtest is easy to use and provides a better understanding of how Qtum works, and whether it's a smart contract or DAPP, it's a key tool for testing projects.
Developed as a Qtum version of Ethereum’s remix, Qmix is ​​a browser-based IDE that lets you write the right smart contracts.
Not only can you write contracts and ensure correctness, but you can also deploy and interact directly with the Qmix UI. In order to be able to deploy and interact with smart contracts, you need to connect to the Qtum network. Click on the application's help options to find instructions on how to connect your Qmix to your local regtest network. Once connected, you can thoroughly test smart contracts before actually deploying to the main network. If you plan to develop Qtum DAPPs, you will most likely need to be familiar with this tool.
Qmix was developed as a Qtum contract, so the GitHub repository for this project is not on Qtum's GitHub, but here:
Qtum JS
Qtum JS is a JavaScript library specifically developed for Qtum Smart Contracts that is very useful for DAPP development. Use this tool to build an application and interact with a smart contract, or you can interact directly with Qtum RPC using a framework you like (such as react or angular). Find all the operations that use the Qtum JS library in the documentation.
Qtum JS Wallet
Similar to Qtum JS, this is a simplified library that helps you build a lean wallet. It extracts from another Qtum project and uses the Qtum explorer API to get information about the Qtum blockchain. It's a simple yet powerful library that meets all your needs for your wallet.
Qtum API
The Qtum API is another very useful tool that you might use in any application. Use the API to get information from the Qtum network that your project might need. On the GitHub page, you can see a complete list of all API calls and the responses they return. For example, Qtum explorer uses this tool and can also use it as a sample project.
Qtum project under development
If you are interested in participating in the ongoing Qtum project, do your best to learn more. If you find any problems, you can submit a GitHub issue, and look forward to discovering and resolving and providing pull requests, which will help us grow with Qtum.
Other Qtum projects worth studying
Qtum Electrum Lightweight Qtum Wallet.
Qtum Enterprise (QtumX) is currently under development and is Qtum's enterprise environment, so group companies can run their own alliance chains.
Qtum Explorer This is the explorer's GitHub repository discussed earlier in this article.
Qtum Solar is a prototype project that Qtum is working on to deploy smart contracts.
The Qtum x86 team is about to launch exciting new features. The project is a virtual machine that emulates an x86 processor, thus allowing users to write and compile smart contracts on popular programming languages, rather than being limited to Solidity.
Qtum Lightning is the Qtum implementation of Bitcoin Lightning Network
Qtum Portal is a web server that allows you to run third-party DAPPS
Qtum IOS wallet is a Qtum wallet repository built for iOS.
Qtum android wallet is a Qtum wallet repository that can be found in the Google Store.
submitted by realJB395 to Qtum [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (, August 17th, 2018) from:
This release is a major release which is compatible with the Bitcoin Cash compatible with the Bitcoin Cash specifications you could find here:
A subsequent release containing the implementation of the November 2018 specification will be released soon after this one.
List of notable changes and fixes to the code base:
Release notes:
Ubuntu PPA repository for BUcash has been updated
submitted by s1ckpig to Bitcoincash [link] [comments]

Bitcoin Regtest, Manual Transaction Bitcoin Time Traveler Deletes Post! Predictions Spot On ... History Suggests HUGE Bitcoin Bull Run Incoming ... (BITCOIN NEWS) BILLIONAIRES WARN ABOUT BITCOIN - RICHARD ... Bitcoin News - YouTube

In today’s chatter report, Chris Pacia reveals his BCH transaction using Avalanche on regtest finalized in just 185.822377 milliseconds. Also, Changpeng Zhao advocates storing crypto on reputable exchanges while Jesse Powell advises his followers to store crypto on hardware wallets. Lastly, Eric Wall proposes targeting children to spread crypto adoption. How Bitcoin works, what is Bitcoin, what is blockchain, how to buy Bitcoin, what is Bitcoin mining and more. How do I send and receive Bitcoin? Note: Bitcoin is sent and received using a digital wallet. To get started, download one for free from us here. Follow @bitcoincom. ... Get the latest Bitcoin news in your inbox. A Bitcoin signet, proposed by Karl-Johan Alm, could provide a more predictable and stable Bitcoin testnet for development. ... Regtest can’t play the role of the public testnet, however, as users would have to ask the specific regtest administrator to spin the nodes for them, assign permissions and access. ... I would like to receive news and ... I am trying to run a private Bitcoin network for testing. I tried to run a RegTest network, but I need the addresses to be in the format of the ainnet. Can I configure the RegTest to run with Mainnet Bitcoin News. Home; News. News. Change difficulty using bitcoin-cli/bitcoind in regtest mode. News. ... Hodlers Can Earn Attractive Interests by Investing into Hodlnaut Crypto Loans… News. Bitcoin, Gold and the S&P 500 Are Increasingly Correlated : Bitcoin.

[index] [6964] [27067] [30945] [3756] [32126] [2604] [22333] [32623] [21223] [30331]

Bitcoin Regtest, Manual Transaction

We try to manually create and send a transaction on the bitcoin regtest test network. Bitcoin is the future method of payment that will be accepted by most consumers, due to its ease of use, and prices will likely skyrocket said Robert Herjave... Discover How To Profit with Cryptocurrencies: Bitcoin Bitcoin price Bitcoin news Bitcoin scam Bitcoin warning Billionaire Bitcoin Bi... VICE News Recommended for you. 3:49. Autodesk Inventor ... Creating a Local Bitcoin Testnet / Regtest - Programming Bitcoin - Duration: 23:19. Programming Bitcoin 19,207 views. 23:19. The infamous Bitcoin subreddit (r/bitcoin) post in which a supposed time traveler tells the world about Bitcoin, has been deleted by the author. In the post,...