Bitcoins43 free bitcoin miner

GlobalBoost- A CryptoCurrency To Help Wounded Veterans

BSTY brings a completely new algorithm to the digital currency scene, and combines it with our real products, real company, and visible & accountable leadership. We aim to improve the acceptance of digital money, providing a safe & attractive investment using Yescrypt as our POW.
[link]

Aeon

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

Gridcoin 5.0.0.0-Mandatory "Fern" Release

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

Highlights

Protocol

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

GUI

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

Blockchain

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

Summary Changelog

Accrual

Changed

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

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

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

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

Technical: The Path to Taproot Activation

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

The SegWit Wars

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

BIP9 Miner-Activated Soft Fork

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

The Great Battles of the SegWit Wars

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

BIP9 Feature Hostage

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

Covert ASICBoost

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

UASF: BIP148 and BIP8

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

BIP91, SegWit2X, and The Aftermath

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

Taproot Activation Proposals

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

Modern Softfork Activation

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

PSA: Being Resilient to Upgrades

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

Upcoming Major Riecoin 0.20 Upgrade

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

Reddcoin (RDD) 02/20 Progress Report - Core Wallet v3.1 Evolution & PoSV v2 - Commits & More Commits to v3.1! (Bitcoin Core 0.10, MacOS Catalina, QT Enhanced Speed and Security and more!)

Reddcoin (RDD) Core Dev Team Informal Progress Report, Feb 2020 - As any blockchain or software expert will confirm, the hardest part of making successful progress in blockchain and crypto is invisible to most users. As developers, the Reddcoin Core team relies on internal experts like John Nash, contributors offering their own code improvements to our repos (which we would love to see more of!) and especially upstream commits from experts working on open source projects like Bitcoin itself. We'd like tothank each and everyone who's hard work has contributed to this progress.
As part of Reddcoin's evolution, and in order to include required security fixes, speed improvements that are long overdue, the team has up to this point incorporated the following code commits since our last v3.0.1 public release. In attempting to solve the relatively minor font display issue with MacOS Catalina, we uncovered a complicated interweaving of updates between Reddcoin Core, QT software, MacOS SDK, Bitcoin Core and related libraries and dependencies that mandated we take a holistic approach to both solve the Catalina display problem, but in doing so, prepare a more streamlined overall build and test system, allowing the team to roll out more frequent and more secure updates in the future. And also to include some badly needed fixes in the current version of Core, which we have tentatively labeled Reddcoin Core Wallet v3.1.
Note: As indicated below, v3.1 is NOT YET AVAILABLE FOR DOWNLOAD BY PUBLIC. We wil advise when it is.
The new v3.1 version should be ready for internal QA and build testing by the end of this week, with luck, and will be turned over to the public shortly thereafter once testing has proven no unexpected issues have been introduced. We know the delay has been a bit extended for our ReddHead MacOS Catalina stakers, and we hope to have them all aboard soon. We have moved with all possible speed while attempting to incorproate all the required work, testing, and ensuring security and safety for our ReddHeads.
Which leads us to: PoSV v2 activation and the supermajority on Mainnet at the time of this writing has reached 5625/9000 blocks or 62.5%. We have progressed quite well and without any reported user issues since release, but we need all of the community to participate! This activation, much like the funding mechanisms currently being debated by BCH and others, and employed by DASH, will mean not only a catalyst for Reddcoin but ensure it's future by providing funding for the dev team. As a personal plea from the team, please help us support the PoSV v2 activation by staking your RDD, no matter how large or small your amount of stake.
Every block and every RDD counts, and if you don't know how, we'll teach you! Live chat is fun as well as providing tech support you can trust from devs and community ReddHead members. Join us today in staking and online and collect some RDD "rain" from users and devs alike!
If you're holding Reddcoin and not staking, or you haven't upgraded your v2.x wallet to v3.0.1 (current release), we need you to help achieve consensus and activate PoSV v2! For details, see the pinned message here or our website or medium channel. Upgrade is simple and takes moments; if you're nervous or unsure, we're here to help live in Telegram or Discord, as well as other chat programs. See our website for links.
Look for more updates shortly as our long-anticipated Reddcoin Payment Gateway and Merchant Services API come online with point-of-sale support, as we announce the cross-crypto-project Aussie firefighter fundraiser program, as well as a comprehensive update to our development roadmap and more.
Work has restarted on ReddID and multiple initiatives are underway to begin educating and sharing information about ReddID, what it is, and how to use it, as we approach a releasable ReddID product. We enthusiastically encourage anyone interested in working to bring these efforts to life, whether writers, UX/UI experts, big data analysts, graphic artists, coders, front-end, back-end, AI, DevOps, the Reddcoin Core dev team is growing, and there's more opportunity and work than ever!
Bring your talents to a community and dev team that truly appreciates it, and share the Reddcoin Love!
And now, lots of commits. As v3.1 is not yet quite ready for public release, these commits have not been pushed publicly, but in the interests of sharing progress transparently, and including our ReddHead community in the process, see below for mind-numbing technical detail of work accomplished.
e5c143404 - - 2014-08-07 - Ross Nicoll - Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope. *99a7dba2e - - 2014-08-15 - Cory Fields - tests: fix test-runner for osx. Closes ##4708 *8c667f1be - - 2014-08-15 - Cory Fields - build: add funcs.mk to the list of meta-depends *bcc1b2b2f - - 2014-08-15 - Cory Fields - depends: fix shasum on osx < 10.9 *54dac77d1 - - 2014-08-18 - Cory Fields - build: add option for reducing exports (v2) *6fb9611c0 - - 2014-08-16 - randy-waterhouse - build : fix CPPFLAGS for libbitcoin_cli *9958cc923 - - 2014-08-16 - randy-waterhouse - build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix. *342aa98ea - - 2014-08-07 - Cory Fields - build: fix automake warnings about the use of INCLUDES *46db8ad51 - - 2020-02-18 - John Nash - build: add build.h to the correct target *a24de1e4c - - 2014-11-26 - Pavel Janík - Use complete path to include bitcoin-config.h. *fd8f506e5 - - 2014-08-04 - Wladimir J. van der Laan - qt: Demote ReportInvalidCertificate message to qDebug *f12aaf3b1 - - 2020-02-17 - John Nash - build: QT5 compiled with fPIC require fPIC to be enabled, fPIE is not enough *7a991b37e - - 2014-08-12 - Wladimir J. van der Laan - build: check for sys/prctl.h in the proper way *2cfa63a48 - - 2014-08-11 - Wladimir J. van der Laan - build: Add mention of --disable-wallet to bdb48 error messages *9aa580f04 - - 2014-07-23 - Cory Fields - depends: add shared dependency builder *8853d4645 - - 2014-08-08 - Philip Kaufmann - [Qt] move SubstituteFonts() above ToolTipToRichTextFilter *0c98e21db - - 2014-08-02 - Ross Nicoll - URLs containing a / after the address no longer cause parsing errors. *7baa77731 - - 2014-08-07 - ntrgn - Fixes ignored qt 4.8 codecs path on windows when configuring with --with-qt-libdir *2a3df4617 - - 2014-08-06 - Cory Fields - qt: fix unicode character display on osx when building with 10.7 sdk *71a36303d - - 2014-08-04 - Cory Fields - build: fix race in 'make deploy' for windows *077295498 - - 2014-08-04 - Cory Fields - build: Fix 'make deploy' when binaries haven't been built yet *ffdcc4d7d - - 2014-08-04 - Cory Fields - build: hook up qt translations for static osx packaging *25a7e9c90 - - 2014-08-04 - Cory Fields - build: add --with-qt-translationdir to configure for use with static qt *11cfcef37 - - 2014-08-04 - Cory Fields - build: teach macdeploy the -translations-dir argument, for use with static qt *4c4ae35b1 - - 2014-07-23 - Cory Fields - build: Find the proper xcb/pcre dependencies *942e77dd2 - - 2014-08-06 - Cory Fields - build: silence mingw fpic warning spew *e73e2b834 - - 2014-06-27 - Huang Le - Use async name resolving to improve net thread responsiveness *c88e76e8e - - 2014-07-23 - Cory Fields - build: don't let libtool insert rpath into binaries *18e14e11c - - 2014-08-05 - ntrgn - build: Fix windows configure when using --with-qt-libdir *bb92d65c4 - - 2014-07-31 - Cory Fields - test: don't let the port number exceed the legal range *62b95290a - - 2014-06-18 - Cory Fields - test: redirect comparison tool output to stdout *cefe447e9 - - 2014-07-22 - Cory Fields - gitian: remove unneeded option after last commit *9347402ca - - 2014-07-21 - Cory Fields - build: fix broken boost chrono check on some platforms *c9ed039cf - - 2014-06-03 - Cory Fields - build: fix whitespace in pkg-config variable *3bcc5ad37 - - 2014-06-03 - Cory Fields - build: allow linux and osx to build against static qt5 *01a44ba90 - - 2014-07-17 - Cory Fields - build: silence false errors during make clean *d1fbf7ba2 - - 2014-07-08 - Cory Fields - build: fix win32 static linking after libtool merge *005ae2fa4 - - 2014-07-08 - Cory Fields - build: re-add AM_LDFLAGS where it's overridden *37043076d - - 2014-07-02 - Wladimir J. van der Laan - Fix the Qt5 build after d95ba75 *f3b4bbf40 - - 2014-07-01 - Wladimir J. van der Laan - qt: Change serious messages from qDebug to qWarning *f4706f753 - - 2014-07-01 - Wladimir J. van der Laan - qt: Log messages with type>QtDebugMsg as non-debug *98e85fa1f - - 2014-06-06 - Pieter Wuille - libsecp256k1 integration *5f1f2e226 - - 2020-02-17 - John Nash - Merge branch 'switch_verification_code' into Build *1f30416c9 - - 2014-02-07 - Pieter Wuille - Also switch the (unused) verification code to low-s instead of even-s. *1c093d55e - - 2014-06-06 - Cory Fields - secp256k1: Add build-side changes for libsecp256k1 *7f3114484 - - 2014-06-06 - Cory Fields - secp256k1: add libtool as a dependency *2531f9299 - - 2020-02-17 - John Nash - Move network-time related functions to timedata.cpp/h *d003e4c57 - - 2020-02-16 - John Nash - build: fix build weirdness after 54372482. *7035f5034 - - 2020-02-16 - John Nash - Add ::OUTPUT_SIZE *2a864c4d8 - - 2014-06-09 - Cory Fields - crypto: create a separate lib for crypto functions *03a4e4c70 - - 2014-06-09 - Cory Fields - crypto: explicitly check for byte read/write functions *a78462a2a - - 2014-06-09 - Cory Fields - build: move bitcoin-config.h to its own directory *a885721c4 - - 2014-05-31 - Pieter Wuille - Extend and move all crypto tests to crypto_tests.cpp *5f308f528 - - 2014-05-03 - Pieter Wuille - Move {Read,Write}{LE,BE}{32,64} to common.h and use builtins if possible *0161cc426 - - 2014-05-01 - Pieter Wuille - Add built-in RIPEMD-160 implementation *deefc27c0 - - 2014-04-28 - Pieter Wuille - Move crypto implementations to src/crypto/ *d6a12182b - - 2014-04-28 - Pieter Wuille - Add built-in SHA-1 implementation. *c3c4f9f2e - - 2014-04-27 - Pieter Wuille - Switch miner.cpp to use sha2 instead of OpenSSL. *b6ed6def9 - - 2014-04-28 - Pieter Wuille - Remove getwork() RPC call *0a09c1c60 - - 2014-04-26 - Pieter Wuille - Switch script.cpp and hash.cpp to use sha2.cpp instead of OpenSSL. *8ed091692 - - 2014-04-20 - Pieter Wuille - Add a built-in SHA256/SHA512 implementation. *0c4c99b3f - - 2014-06-21 - Philip Kaufmann - small cleanup in src/compat .h and .cpp *ab1369745 - - 2014-06-13 - Cory Fields - sanity: hook up sanity checks *f598c67e0 - - 2014-06-13 - Cory Fields - sanity: add libc/stdlib sanity checks *b241b3e13 - - 2014-06-13 - Cory Fields - sanity: autoconf check for sys/select.h *cad980a4f - - 2019-07-03 - John Nash - build: Add a top-level forwarding target for src/ objects *f4533ee1c - - 2019-07-03 - John Nash - build: qt: split locale resources. Fixes non-deterministic distcheck *4a0e46e76 - - 2019-06-29 - John Nash - build: fix version dependency *2f61699d9 - - 2019-06-29 - John Nash - build: quit abusing AMCPPFLAGS *99b60ba49 - - 2019-06-29 - John Nash - build: avoid the use of top and abs_ dir paths *c8f673d5d - - 2019-06-29 - John Nash - build: Tidy up file generation output *5318bce57 - - 2019-06-29 - John Nash - build: nuke Makefile.include from orbit *672a25349 - - 2019-06-29 - John Nash - build: add stub makefiles for easier subdir builds *562b7c5a6 - - 2020-02-08 - John Nash - build: delete old Makefile.am's *066120079 - - 2020-02-08 - John Nash - build: Switch to non-recursive make
Whew! No wonder it's taken the dev team a while! :)
TL;DR: Trying to fix MacOS Catalina font display led to requiring all kinds of work to migrate and evolve the Reddcoin Core software with Apple, Bitcoin and QT components. Lots of work done, v3.1 public release soon. Also other exciting things and ReddID back under active dev effort.
submitted by TechAdept to reddCoin [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent，in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction，original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to BitcoinSerious [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year(only pc-miner)

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent，in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction，original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to BitcoinMining [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent，in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction，original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to altcoin_news [link] [comments]

Groestlcoin 6th Anniversary Release

Introduction

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

UPDATED - Groestlcoin Core 2.18.2

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

How to Upgrade?

Windows
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

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

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

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

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

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

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

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

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

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

Features

Download

Source

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

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

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

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

Features

Download

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

Source

ALL NEW! – Electrum Personal Server

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

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

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

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Bitcoin Unlimited 1.6.0.1 has just been released

Download the latest release of Bitcoin Unlimited (1.6.0.1, July 19th, 2019) from:
 
https://www.bitcoinunlimited.info/download
 
This is a a bug fix release candidate of Bitcoin Unlimited compatible with the Bitcoin Cash protocol.
This is list of the main changes that have been merged in this release:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.6.0.1.md
 
PS Ubuntu PPA repository is currently being updated to serve for BUcash 1.6.0.1.
submitted by s1ckpig to btc [link] [comments]

⚡ Lightning Network Megathread ⚡

Last updated 2018-01-29
This post is a collaboration with the Bitcoin community to create a one-stop source for Lightning Network information.
There are still questions in the FAQ that are unanswered, if you know the answer and can provide a source please do so!

⚡What is the Lightning Network? ⚡

Explanations:

Image Explanations:

Specifications / White Papers

Videos

Lightning Network Experts on Reddit

  • starkbot - (Elizabeth Stark - Lightning Labs)
  • roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • stile65 - (Alex Akselrod - Lightning Labs)
  • cfromknecht - (Conner Fromknecht - Lightning Labs)
  • RustyReddit - (Rusty Russell - Blockstream)
  • cdecker - (Christian Decker - Blockstream)
  • Dryja - (Tadge Dryja - Digital Currency Initiative)
  • josephpoon - (Joseph Poon)
  • fdrn - (Fabrice Drouin - ACINQ )
  • pmpadiou - (Pierre-Marie Padiou - ACINQ)

Lightning Network Experts on Twitter

  • @starkness - (Elizabeth Stark - Lightning Labs)
  • @roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • @stile65 - (Alex Akselrod - Lightning Labs)
  • @bitconner - (Conner Fromknecht - Lightning Labs)
  • @johanth - (Johan Halseth - Lightning Labs)
  • @bvu - (Bryan Vu - Lightning Labs)
  • @rusty_twit - (Rusty Russell - Blockstream)
  • @snyke - (Christian Decker - Blockstream)
  • @JackMallers - (Jack Mallers - Zap)
  • @tdryja - (Tadge Dryja - Digital Currency Initiative)
  • @jcp - (Joseph Poon)
  • @alexbosworth - (Alex Bosworth - yalls.org)

Medium Posts

Learning Resources

Books

Desktop Interfaces

Web Interfaces

Tutorials and resources

Lightning on Testnet

Lightning Wallets

Place a testnet transaction

Altcoin Trading using Lightning

  • ZigZag - Disclaimer You must trust ZigZag to send to Target Address

Lightning on Mainnet

Warning - Testing should be done on Testnet

Atomic Swaps

Developer Documentation and Resources

Lightning implementations

  • LND - Lightning Network Daemon (Golang)
  • eclair - A Scala implementation of the Lightning Network (Scala)
  • c-lightning - A Lightning Network implementation in C
  • lit - Lightning Network node software (Golang)
  • lightning-onion - Onion Routed Micropayments for the Lightning Network (Golang)
  • lightning-integration - Lightning Integration Testing Framework
  • ptarmigan - C++ BOLT-Compliant Lightning Network Implementation [Incomplete]

Libraries

Lightning Network Visualizers/Explorers

Testnet

Mainnet

Payment Processors

  • BTCPay - Next stable version will include Lightning Network

Community

Slack

IRC

Slack Channel

Discord Channel

Miscellaneous

⚡ Lightning FAQs ⚡

If you can answer please PM me and include source if possible. Feel free to help keep these answers up to date and as brief but correct as possible
Is Lightning Bitcoin?
Yes. You pick a peer and after some setup, create a bitcoin transaction to fund the lightning channel; it’ll then take another transaction to close it and release your funds. You and your peer always hold a bitcoin transaction to get your funds whenever you want: just broadcast to the blockchain like normal. In other words, you and your peer create a shared account, and then use Lightning to securely negotiate who gets how much from that shared account, without waiting for the bitcoin blockchain.
Is the Lightning Network open source?
Yes, Lightning is open source. Anyone can review the code (in the same way as the bitcoin code)
Who owns and controls the Lightning Network?
Similar to the bitcoin network, no one will ever own or control the Lightning Network. The code is open source and free for anyone to download and review. Anyone can run a node and be part of the network.
I’ve heard that Lightning transactions are happening “off-chain”…Does that mean that my bitcoin will be removed from the blockchain?
No, your bitcoin will never leave the blockchain. Instead your bitcoin will be held in a multi-signature address as long as your channel stays open. When the channel is closed; the final transaction will be added to the blockchain. “Off-chain” is not a perfect term, but it is used due to the fact that the transfer of ownership is no longer reflected on the blockchain until the channel is closed.
Do I need a constant connection to run a lightning node?
Not necessarily,
Example: A and B have a channel. 1 BTC each. A sends B 0.5 BTC. B sends back 0.25 BTC. Balance should be A = 0.75, B = 1.25. If A gets disconnected, B can publish the first Tx where the balance was A = 0.5 and B = 1.5. If the node B does in fact attempt to cheat by publishing an old state (such as the A=0.5 and B=1.5 state), this cheat can then be detected on-chain and used to steal the cheaters funds, i.e., A can see the closing transaction, notice it's an old one and grab all funds in the channel (A=2, B=0). The time that A has in order to react to the cheating counterparty is given by the CheckLockTimeVerify (CLTV) in the cheating transaction, which is adjustable. So if A foresees that it'll be able to check in about once every 24 hours it'll require that the CLTV is at least that large, if it's once a week then that's fine too. You definitely do not need to be online and watching the chain 24/7, just make sure to check in once in a while before the CLTV expires. Alternatively you can outsource the watch duties, in order to keep the CLTV timeouts low. This can be achieved both with trusted third parties or untrusted ones (watchtowers). In the case of a unilateral close, e.g., you just go offline and never come back, the other endpoint will have to wait for that timeout to expire to get its funds back. So peers might not accept channels with extremely high CLTV timeouts. -- Source
What Are Lightning’s Advantages?
Tiny payments are possible: since fees are proportional to the payment amount, you can pay a fraction of a cent; accounting is even done in thousandths of a satoshi. Payments are settled instantly: the money is sent in the time it takes to cross the network to your destination and back, typically a fraction of a second.
Does Lightning require Segregated Witness?
Yes, but not in theory. You could make a poorer lightning network without it, which has higher risks when establishing channels (you might have to wait a month if things go wrong!), has limited channel lifetime, longer minimum payment expiry times on each hop, is less efficient and has less robust outsourcing. The entire spec as written today assumes segregated witness, as it solves all these problems.
Can I Send Funds From Lightning to a Normal Bitcoin Address?
No, for now. For the first version of the protocol, if you wanted to send a normal bitcoin transaction using your channel, you have to close it, send the funds, then reopen the channel (3 transactions). In future versions, you and your peer would agree to spend out of your lightning channel funds just like a normal bitcoin payment, allowing you to use your lightning wallet like a normal bitcoin wallet.
Can I Make Money Running a Lightning Node?
Not really. Anyone can set up a node, and so it’s a race to the bottom on fees. In practice, we may see the network use a nominal fee and not change very much, which only provides an incremental incentive to route on a node you’re going to use yourself, and not enough to run one merely for fees. Having clients use criteria other than fees (e.g. randomness, diversity) in route selection will also help this.
What is the release date for Lightning on Mainnet?
Lightning is already being tested on the Mainnet Twitter Link but as for a specific date, Jameson Lopp says it best
Would there be any KYC/AML issues with certain nodes?
Nope, because there is no custody ever involved. It's just like forwarding packets. -- Source
What is the delay time for the recipient of a transaction receiving confirmation?
Furthermore, the Lightning Network scales not with the transaction throughput of the underlying blockchain, but with modern data processing and latency limits - payments can be made nearly as quickly as packets can be sent. -- Source
How does the lightning network prevent centralization?
Bitcoin Stack Exchange Answer
What are Channel Factories and how do they work?
Bitcoin Stack Exchange Answer
How does the Lightning network work in simple terms?
Bitcoin Stack Exchange Answer
How are paths found in Lightning Network?
Bitcoin Stack Exchange Answer
How would the lightning network work between exchanges?
Each exchange will get to decide and need to implement the software into their system, but some ideas have been outlined here: Google Doc - Lightning Exchanges
Note that by virtue of the usual benefits of cost-less, instantaneous transactions, lightning will make arbitrage between exchanges much more efficient and thus lead to consistent pricing across exchange that adopt it. -- Source
How do lightning nodes find other lightning nodes?
Stack Exchange Answer
Does every user need to store the state of the complete Lightning Network?
According to Rusty's calculations we should be able to store 1 million nodes in about 100 MB, so that should work even for mobile phones. Beyond that we have some proposals ready to lighten the load on endpoints, but we'll cross that bridge when we get there. -- Source
Would I need to download the complete state every time I open the App and make a payment?
No you'd remember the information from the last time you started the app and only sync the differences. This is not yet implemented, but it shouldn't be too hard to get a preliminary protocol working if that turns out to be a problem. -- Source
What needs to happen for the Lightning Network to be deployed and what can I do as a user to help?
Lightning is based on participants in the network running lightning node software that enables them to interact with other nodes. This does not require being a full bitcoin node, but you will have to run "lnd", "eclair", or one of the other node softwares listed above.
All lightning wallets have node software integrated into them, because that is necessary to create payment channels and conduct payments on the network, but you can also intentionally run lnd or similar for public benefit - e.g. you can hold open payment channels or channels with higher volume, than you need for your own transactions. You would be compensated in modest fees by those who transact across your node with multi-hop payments. -- Source
Is there anyway for someone who isn't a developer to meaningfully contribute?
Sure, you can help write up educational material. You can learn and read more about the tech at http://dev.lightning.community/resources. You can test the various desktop and mobile apps out there (Lightning Desktop, Zap, Eclair apps). -- Source
Do I need to be a miner to be a Lightning Network node?
No -- Source
Do I need to run a full Bitcoin node to run a lightning node?
lit doesn't depend on having your own full node -- it automatically connects to full nodes on the network. -- Source
LND uses a light client mode, so it doesn't require a full node. The name of the light client it uses is called neutrino
How does the lightning network stop "Cheating" (Someone broadcasting an old transaction)?
Upon opening a channel, the two endpoints first agree on a reserve value, below which the channel balance may not drop. This is to make sure that both endpoints always have some skin in the game as rustyreddit puts it :-)
For a cheat to become worth it, the opponent has to be absolutely sure that you cannot retaliate against him during the timeout. So he has to make sure you never ever get network connectivity during that time. Having someone else also watching for channel closures and notifying you, or releasing a canned retaliation, makes this even harder for the attacker. This is because if he misjudged you being truly offline you can retaliate by grabbing all of its funds. Spotty connections, DDoS, and similar will not provide the attacker the necessary guarantees to make cheating worthwhile. Any form of uncertainty about your online status acts as a deterrent to the other endpoint. -- Source
How many times would someone need to open and close their lightning channels?
You typically want to have more than one channel open at any given time for redundancy's sake. And we imagine open and close will probably be automated for the most part. In fact we already have a feature in LND called autopilot that can automatically open channels for a user.
Frequency will depend whether the funds are needed on-chain or more useful on LN. -- Source
Will the lightning network reduce BTC Liquidity due to "locking-up" funds in channels?
Stack Exchange Answer
Can the Lightning Network work on any other cryptocurrency? How?
Stack Exchange Answer
When setting up a Lightning Network Node are fees set for the entire node, or each channel when opened?
You don't really set up a "node" in the sense that anyone with more than one channel can automatically be a node and route payments. Fees on LN can be set by the node, and can change dynamically on the network. -- Source
Can Lightning routing fees be changed dynamically, without closing channels?
Yes but it has to be implemented in the Lightning software being used. -- Source
How can you make sure that there will be routes with large enough balances to handle transactions?
You won't have to do anything. With autopilot enabled, it'll automatically open and close channels based on the availability of the network. -- Source
How does the Lightning Network stop flooding nodes (DDoS) with micro transactions? Is this even an issue?
Stack Exchange Answer

Unanswered Questions

How do on-chain fees work when opening and closing channels? Who pays the fee?
How does the Lightning Network work for mobile users?
What are the best practices for securing a lightning node?
What is a lightning "hub"?
How does lightning handle cross chain (Atomic) swaps?

Special Thanks and Notes

  • Many links found from awesome-lightning-network github
  • Everyone who submitted a question or concern!
  • I'm continuing to format for an easier Mobile experience!
submitted by codedaway to Bitcoin [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.5.0.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.5.0.0, October 12th, 2018) from:
 
https://www.bitcoinunlimited.info/download
 
This release is a major release which is compatible with the Bitcoin Cash compatible with the Bitcoin Cash specifications you could find here:
 
List of notable changes and fixes to the code base:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.5.0.0.md
 
Ubuntu PPA repository for BUcash 1.5.0.0 will be updated later today.
edit: fix BUIP 135 voting guide URL
submitted by s1ckpig to btc [link] [comments]

Bitcoin Unlimited - Bitcoin Cash edition 1.4.0.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.4.0.0, August 17th, 2018) from:
 
https://www.bitcoinunlimited.info/download
 
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: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.4.0.0.md
 
Ubuntu PPA repository for BUcash 1.4.0.0 has been updated
submitted by s1ckpig to btc [link] [comments]

Bitcoin Unlimited 1.6.0.1 has just been released

Download the latest release of Bitcoin Unlimited (1.6.0.1, July 19th, 2019) from:
 
https://www.bitcoinunlimited.info/download
 
This is a a bug fix release candidate of Bitcoin Unlimited compatible with the Bitcoin Cash protocol.
This is list of the main changes that have been merged in this release:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.6.0.1.md
 
PS Ubuntu PPA repository is currently being updated to serve for BUcash 1.6.0.1.
submitted by s1ckpig to Bitcoincash [link] [comments]

About reducing the BCH block time, I have something to say...

I want to introduce myself by first (to avoid to be considered to be troll).
My name is Danny, Chinese, my first contact with Bitcoin was in 2013. My background is integrated circuit design. I studied C/C++ and linux in the college 15 years ago. I am not very familiar with open source software design, but my technology background is good enough to let me learn things quickly. I have developed a FPGA based SHA-256 miner and succesfully connect to the Eligius pool in early 2014 (Just for fun), all by C and verilog. I am a developer but not a professional software developer.
I am familiar with Bitcoin, transaction and block structure. I developed a program which can upload and download arbitrary file from/to the Bitcoincash blockchain. The downloader code is open sourced: https://github.com/bchfile/BCHFILE-extractor
I think I am not a troll.
Although many users and devs think Blocktime is not an issue, but a simple fact is that there is no single mainstream crypto choose a blocktime equal or larger than 10 minutes (No offense to anyone, I just express the idea that this is an undeniable proof that a shortter confirmation time has real needs).
For wallet users: If someone send me some BCH, although 0-conf gives some confidence, but I still need to wait for at least 1 confirmation to "make sure" someone else is not cheeting me (not 100%, but 1 confirm really means something), each more confirmation makes more confidence.
For nodes: You cannot spend a unconfirmed UTXO by default, you need to list the unspent UTXO and use createrawtransaction, signrawtransaction to manually create the TX and broadcast it. That means you need to wait for the TX to be confirmed before spend it by default.
Variance: (Here, I want to say sorry to many people especially some devs, in the previous posts, I did not show enough respect to them. In fact, the developers have done a lot of excellent work, most of which are unpaid, but not well known to the public.) The Variance is already been discussed by devs a long time, bobtail algorithm is a potential alternative, I have not figure it out by now, but reduce the block time can achieve a similar result, it's simple, 10 1-min block have an averagy effect, it has much less variance than 1 10-min block.
For exchanges: Obviously the exchanges plays the most important role in the crypto eco-system. Exchanges usually run "official" bitcoin cash nodes (bitcoin-abc), change the block time does not affect them (because the RPC call is not changed), the only affection is that they need to increase the confirmation numbers for deposit.
For developers: They need to upgrade the software before the HF just as the previous ones. Although change the blocktime is a major change, but in Code, the changes are rare, only a few lines of codes are affected for the core functions. (To approve this, I created a Bitcoin-abc fork in github, modified the blocktime to 2-min and reduce the subsidy to 1/5 at the same time, all the changes canbe seen here: https://github.com/Danyu-Wu/bitcoin-abc/commit/884414a04884a462c8e424ab1bde2fe632f59591). I spend 1 week to study the source code, and spend 2 days to complete the modification (Changes for test-code and some non-core functions are not completed yet), and 3 days for run the test (includes run a pool and connect to the testnet, in here you can find the blocks I mined in the testnet: https://www.blocktrail.com/tBCC/address/mmBG7ReKgGQgqhSZQjR28NvVDfeekjpnpV). I am not a professional programmer but can finish the core changes within 2-weeks, so it is clear that the change does not need much work.
----------------------------------------------------
In summary, I think change the blocktime maybe not the perfect consensus change for BCH, but that is the simplest one to improve the user experience significantly.
BTW: Anyone, especially developers who are interested in this topic, you can find the telegram group link here: https://github.com/Danyu-Wu/blocktime/blob/masteworkgroup.md
submitted by wudanyu to btc [link] [comments]

Bitcoin Miner 2020 no fee Bitcoin Miner software PC 2020 windows 10 free download ... Bitcoin Miner software PC 2020 windows 10 free download ... Bitcoin Mining Software for PC 2020 Free Download How ... Best Bitcoin Miner Machine Free download ️ Best BTC Miners ...

The Bitcoin remote RPC Miner, also referred to as puddinpop's miner after the author's forum name, is a pool miner client.. There are four miner client binaries distributed: A application-packaged frontend for RPC Miner that can be run on Mac OS 10.6 or higher. Double-click on the icon to start mining. Yields 1100–1400 khash/s on a recent MacBook Air and Mac Mini (2011 models). Features integration with Mac OS APIs and systems such as user defaults for storing configuration, LaunchAgents, and more. Bitcoin Core is a community-driven free software project, released under the MIT license. Verify release signatures Download torrent Source code Show version history Bitcoin Core Release Signing Keys v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ The 1.5 version of RPC Miner for Mac is provided as a free download on our website. This Mac download was checked by our built-in antivirus and was rated as clean. This free software for Mac OS X was originally designed by RPC Miner Developers. The software lies within Business Tools, more precisely Finances. The Best Bitcoin mining Software, try it Now! Depending on the difficulty of mining the block and the value to be deciphered, your profit may change, however, on average our users with the key of the Silver plan, with 3 uses in a day, have been able to generate between 0.15 BTC and 0.32 BTC, which is profitable if you compare it with the investment of the Mining key.

[index] [18834] [44194] [53431] [31502] [12209] [5709] [36118] [30150] [34782] [14179]

Bitcoin Miner 2020 no fee

#best bitcoin miner software 2020 #best bitcoin mining app 2020 #bitcoin mining android 2020 #telegram bitcoin mining bot 2020 #best bitcoin miner 2020 #best bitcoin miner hardware 2020 #bitcoin ... ️ Download for free from http://bitsoftmachine.com/?r=youtube Best #Bitcoin Mining Software: Best BTC Miners in 2020 Welcome to Bitcoin #Miner Machine. Bitc... download now https://bit.ly/3frEAXG DOWNLOAD NOW https://bit.ly/2BaKNsb earn 3 btc free no Fee required https://youtu.be/S3aMr6cnqIE subscribe now 10 btc giv... Download for free from https://bit.ly/319pJNH Best Bitcoin Mining Software: Best BTC Miners in 2020 Welcome to Smart Miner #Bitcoin #Miner #Machine a graphic... Best Bitcoin Mining Tool 2020 No Download [PAYING] PC Only generatebitcoins.online In this video you will learn how i have generated almost 800K euro in bitcoin. Watch this video ...

https://forex-portugal.360-porno.eu