GregGriffith

I am looking for a place to find current information about cashfusion usage statistics. In the past stats.cash has been a good source of information but recently I am under the impression that they are out of sync. The last reported cashfusion transaction on the website occurred about 3000 blocks ago. If anyone knows of another website that tracks the same statistics as stats.cash please post a comment with the link.

Assuming that cashfusion has not stopped working, if anyone knows who runs stats.cash or how to contact them please let them know that they are out of sync or something is wrong with their displayed data.

My favorite part about BCH is implementations holding solutions and/or refusing to implement fixes to known problems for ransom until said implementation gets a payout they deem acceptable to edit their codebase. /s
https://read.cash/@Bitcoin_ABC/what-is-bitcoin-abcs-fix-block-time-oscillations-project-7aa24b51

more specifically:
"With adequate funding in hand by 30 Apr 2020, and assuming the availability of qualified engineering talent, Bitcoin ABC aims to deliver a solution to the network in time for the 15 Nov 2020 network upgrade."

Fundraising is one thing. But saying tha

Lets assume that:

- the proposal continues as stated in the article and the coinbase reward donations are NOT added to the bch block validation consensus rules. Miners will instead forcibly orphan a block that doesnt support the donations every time one is mined.

- BSV hashrate is static because NChain is the only people mining that chain.

​

Basic rational economics dictates that if btc or bch is more profitable to mine at any given time then hashrate will flow to that coin until the profitability between the two hits equilibrium (again after difficulty adjustment adjusts mining profitability). Otherwise the miners are mining for less profit than they could be.

The bch hash

Binaries and changelog are available here: https://github.com/project-ecc/eccoin/releases/tag/eccoin0.2.5.18

This release contains some cleanup and improvements to the new debugger, some minor code refactoring, and some new beta features.

We have started to implement routing features as beta features into this release. They are off by default and require a beta parameter to be passed on startup to turn them on. The beta routing features that have been added do need some refinement and are still subject to change although their overall functionality is pretty much set.

With this release the people working on user interfac

Is there any data available anywhere for bitcoinsvd (bitcoin sv daemon) sync times on differing system setups?

im looking for something along the lines of...
It took N minutes with X cpu, Y ram, with Z internet connection speed with a (hdd/ssd) connected via (sata/nvme).

I am ideally looking for any data where the machine had more than 4 logical cores and 8 gigs of ram although any information is helpful.

Binaries and changelog are available here: https://github.com/project-ecc/eccoin/releases/tag/eccoin0.2.5.17

This release contains some cleanup of the syncing process, a reversion back to mit licensing, a new debugger, and some bug fixes mostly addressing issues with the freezing/locking up.

Whats been happening:

In the past ECC has had some issues with long sync times and at one point some people were reporting that it was taking longer than a day for them to sync. We did consider this a high priority issue so over the last few releases we have been tweaking the way the client works to cut down on sync time and impro

Binaries and changelog here: https://github.com/project-ecc/lynx/releases/tag/lynx0.2.1

Changes:

• Moved staking options to status page
• Fixed issues with delays when pushing buttons
• Added support for eccoind 0.2.5.16 (fixed issue where transactions arent being displayed and a few other minor things)

​

​

updating to eccoind 0.2.5.16 does require reindexing, this post might be helpful for those of you wishing to skip the reindex step: [https://www.reddit.com/r/ecc/comments/c053gw/eccoin_02516_has_been_released/er3byv4/](https://www.reddit.com/r/ecc/comments/c053gw/eccoin_02516_has_been_released/er3

Binaries and changelog are available here: https://github.com/project-ecc/eccoin/releases/tag/eccoin0.2.5.16

​

To summarise, this release contains mostly bugfixes, new seed nodes, and better general network connectivity.

The network and seed node changes should solve some issues with staking where nodes are unable to find the minimum required number of peers to stake. 0.2.5.14 and before require 6 peers to stake. This was lowered in 0.2.5.15 to 4 peers, 0.2.5.16 also requires only 4 peers.

​

Notable bug fixes:

- A bug where the node would read bad data on startup causing the node to consider the

One of the changes that we have been getting a lot of questions about is why the balance is no longer displayed for each address in the address list in newer versions of lynx and sapphire. The development team has decided to make this change to better reflect how the wallet actually works. I will try to explain how the wallet works internally without getting into any technicals. The explaination isn't quite correct, but it should be good enough for explaination purposes in this post.

​

Most people think of an address as an account that holds a balance and the wallet is a group of addresses.

This is a bad way to think about it.

It is much better to use the analogy where the wal

Lynx 0.2.0 has been released. You can download it here: https://github.com/project-ecc/lynx/releases/tag/lynx0.2.0

The update includes:- some security patches that fix vulnerabilities in the js libraries used.

- information on the about page.

- fixes to the current eccoin updater to use the new download file formats and checksums that eccoin version 0.2.5.15 and higher are compiled with.

older versions of lynx will no longer be able to update eccoin. An update to this version is required to update to eccoin 0.2.5.15 unless you choose to update eccoin manually.

0.2.X will be the last minor version of lynx to support mac. Unf

I have a miscalculation in my description of the percieved problem below. It turns out yes, i was missing something. For some reason when i initially went over the problem i wrote down that OP_PUSHDATA4 was much smaller than it is. Making my noticed issue essentially a nitpick.

Formal issue has been opened here: https://github.com/simpleledger/slp-specifications/issues/14

Does anyone know? Has there been any recent announcements on this?

The Eccoind 0.2.5.15 release candidate 1 has been published on github. We have entered final testing for this update which has a few new minor features, a lot of performance improvements, some bug fixes, and greatly increased test coverage. An official release should be published in about a week along with a complete changelog noting all of the changes made. This release does not include any of the 3 new larger features we have been working on, some of those are planned for 0.2.5.16 which i very roughly estimate will be out by the end of May.

This post was last updated: 2019/6/15

What is ECC

ECC is a digital currency, which can be transacted for a low-cost nearly instantly from anywhere in the world, with an additional focus on using the ECC network to provide its users with a wide variety of privacy focused services. ECC runs on a blockchain, which is a public immutable and decentralized global ledger that is managed without the need for any central authority whatsoever. There is no government, company, or bank in charge of ECC.

Wiki

https://github.com/project-ecc/ecc-wiki/wiki

What is a hard fork?

A hard fork is when a block is broadcast under a new and different set of protocol rules which is accepted by nodes

We are no longer going to keep the older pre-compiled version of eccoin available on github starting with the release of v0.2.5.15. After this coming release, only the 3 most recent versions will be available for download. The tags and source code of all versions will be available for as long as we continue to use that repository.