Bitcoin Core Version 0.14.0 Released

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]

QuarkChain Monthly Project Progress Report: Feb, 2020

QuarkChain Monthly Project Progress Report: Feb, 2020
Welcome to the 50th QuarkChain Monthly Report. This is our February issue. We will post monthly reports including development progress, monthly news, and events at the end of each month. In the future, QuarkChain strive to do better. Let’s see what happened in the past month!
  • Engineering team implemented a simulation model of Uniswap to test the relation between liquidity and depth of order book
  • We fixed potential timeout when mining shard chain in goquarkchain
  • The QuarkChain team introduced the goals and plans of technology, marketing and business development in the first half of 2020 in detail

1) Development Progress

# Major Updates
## Added
  • Added gRPC Client in pyquarkchain for issuing root-chain-related commands
  • Added Github actions for unit test CI and nightly CI check
  • Added prototype implementation of election for Raft consensus research
  • Implemented a simulation model of Uniswap to test the relation between liquidity and depth of order book
## Updated
  • Improved log subscription through websocket in goquarkchain
  • Fixed potential timeout when mining shard chain in goquarkchain

2) Developer Events

Ongoing QuarkChain Foundation Grants Program
QuarkChain Foundation Grants Program is ongoing with the first project revolves around building a web front-end for multinative token auction, issuance, and gas reserve management. Developers and engineers who finish tasks will receive huge rewards.
Please consult this website for more details:

3) Articles Summary

3.1 QuarkChain and Blockchain In Transport Alliance (BiTA) Partnership Update
The cooperation between QuarkChain and Blockchain In Transport Alliance (BiTA) has entered a new stage. At present, the QuarkChain LOGO has been updated on the BiTA official website. As the cooperation progresses, we will publish more information.
3.2 QuarkChain Monthly AMA Summary-02/22/2020
During QuarkChain’s February AMA, Dr. Zhou, CMO Anthurine and CBO Du Ting began the discussion by overviewing the whole public chain industry then answered the questions such as the impact of Bitcoin’s third halving on the whole blockchain industry, whether QuarkChain will consider joining the consortium blockchain, and the direction of innovation of the blockchain industry in 2020. After that, they introduced the goals and plans of technology, marketing and business development of the QuarkChain team in the first half of 2020 in detail. The team will release new products built with the Boson consensus framework later.
For the full summary:
3.3 Adding a Korean News Channel on Telegram
To better communicate the news of the QuarkChain project to the ever-supportive Korean community, QuarkChain has created a Korean News Channel on Telegram. From now on, all Korean announcements can be found here:
  1. Korean Telegram Chat Channel:
  2. Korean Kakao Talk Channel: (non-commitment: qkcgo)
3.4 QuarkChain Valentine’s Day Event Successfully Closed
QuarkChain held a 10-day event at home and abroad around Valentine’s Day to help community members express love to each other. We received nearly 100 touching stories. After the voting, 8 winners were selected for the eternal love fund and the team will record all the selected stories on the chain.

4) Events

4.1 2020 Stanford Blockchain Conference
The fourth Stanford Blockchain Conference took place between February 20–22, 2020 with industry veterans and experts from prestigious institutions. QuarkChain CEO Dr. Qi Zhou and CMO Anthurine Xiang, were among the honorable guests of the conference. During the conference, Dr. Qi Zhou delivered a speech on “What The Future Blockchain Looks Like to Empower Business.” He introduced the Boson consensus framework which can be applied into both consortium blockchain and public chains.
Click the event summary here:
4.2 2/20 World Blockchain Summit 2020 in Busan
The World Blockchain Summit Busan 2020 was held in Busan, South Korea on 20th February 2020, jointly organised by Blockchain MARVELS and Busan Economic Promotion Agency, and hosted by the Korea CEO Summit, Busan City, BNK Financial Group, Korea Blockchain Association and Korea e-Sports Industry Association.
Jonathan Kim, the head of QuarkChain Korea, delivered a speech on the topic of “DID-based life innovation” and held panel talks with MakerDAO and Simverse.
In his speech, Jonathan said “DID is one of the best areas to take advantage of blockchain” and added that “QuarkChain’s flexible and scalable design can support DID service well.” The event was attended by many experts from Busan Economic Promotion Agency, Future Industry of Busan Metropolitan City, BNK Gold Group, IBM, Block72 and LG CNS and they had in-depth discussion on the blockchain project of Busan.

5) Upcoming Events

5.1 2020 Silicon Valley Women in Engineering Conference
This conference will bring together students, professors, and women leaders for learning, networking, and helping college students make well-informed decisions about their career and future. QuarkChain CMO Anthurine Xiang will attend this event during which she will share her experience as CMO in a blockchain company.

6) FYI

Thanks for reading this report. QuarkChain always appreciates your support and company.
submitted by QuarkChain to quarkchainio [link] [comments]

node information on explorers

I'm trying to set my first c-lightning node with docker-compose using image from currently, my node can connect and open channel with other nodes (and I can open a channel to the node just fine), but it's still not updated (ie. has no information) on most explorers.
the following is result of getinfo and listconfigs
getinfo { "id": "03db40337c2de299a8fa454fdf89d311615d50a27129d43286696d9e497b2b027a", "alias": "TestName", "color": "fff000", "num_peers": 3, "num_pending_channels": 0, "num_active_channels": 3, "num_inactive_channels": 0, "address": [ { "type": "ipv4", "address": "", "port": 9735 } ], "binding": [ { "type": "ipv4", "address": "", "port": 9735 } ], "version": "v0.7.1-906-gf657146", "blockheight": 601917, "network": "bitcoin", "msatoshi_fees_collected": 0, "fees_collected_msat": "0msat" } listconfigs { "# version": "v0.7.1-906-gf657146", "lightning-dir": "/root/.lightning", "wallet": "sqlite3:///root/.lightning/lightningd.sqlite3", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/pay", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/autoclean", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/fundchannel", "network": "bitcoin", "allow-deprecated-apis": true, "always-use-proxy": false, "daemon": "false", "rpc-file": "lightning-rpc", "rgb": "fff000", "alias": "HubTest", "bitcoin-rpcuser": [redacted], "bitcoin-rpcpassword": [redacted], "bitcoin-rpcconnect": "bitcoind", "bitcoin-retry-timeout": 60, "pid-file": "", "ignore-fee-limits": false, "watchtime-blocks": 144, "max-locktime-blocks": 2016, "funding-confirms": 3, "commit-fee-min": 200, "commit-fee-max": 2000, "commit-fee": 500, "cltv-delta": 14, "cltv-final": 10, "commit-time": 10, "fee-base": 0, "rescan": 15, "fee-per-satoshi": 1, "max-concurrent-htlcs": 30, "min-capacity-sat": 10000, "bind-addr": "", "announce-addr": "", "offline": "false", "autolisten": true, "disable-dns": "false", "enable-autotor-v2-mode": "false", "encrypted-hsm": false, "log-level": "DEBUG", "log-prefix": "lightningd(7):" } 
is there something wrong with this configuration? or is it another issue?
I understand that explorers update their node list irregularly, and as far as the node can open channels (and can be connected), everything is fine. but this thing has bugging me for weeks.
thank you~
submitted by 17hubest to lightningnetwork [link] [comments]

Weekly Dev Update #20

THORChain Weekly Dev Update for Week 03–09 Dec 2019



The team believe the current bottleneck to THORChain’s decentralisation is the number of nodes that can participate in a single TSS signing ceremony. As the number of participants grows, the complexity becomes exponential. This is in part because THORChain uses a TSS scheme that has no trusted dealer, which is a non-negotiable aspect. The team scoped out two features this week to address this.

Multi-realm Asgard

Instead of a single Asgard with 66 of 99 participating, Asgard can be broken up into different realms, each with a smaller participation number, such as three 22 of 33 realms. This also means that each realm can be rolled at different times, increasing the availability of the network. THORChain has no opinion on where funds are located, they just have to exist and be accounted for in the network. A Multi-realm Asgard does not change any security characteristics of the network, rather it works to shard the funds and increase the scalability. With Multi-realm Asgard, TSS scalability is no longer a concern, instead the upper limit of nodes now becomes a Tendermint scalability issue. Cosmos Hub is working hard to solve this, recently increasing their node count to 125, and with 300 as their long-term target.

TSS Timeout

The trigger to shard Asgard into smaller realms will no longer be a hard-coded number, instead it will be triggered when the key-gen process in a new vault times out after 10 minutes. This means that if the TSS key-generation process for the increased participation number takes too long, it should be sharded. This prevents the network ever generating a committee size with too many members. 10 minutes was chosen as the cutoff due to diminishing returns above that, and a pre-existing shelling point existing on that particular time-point, thanks to Bitcoin.

Trailing Gas Fee

A 1 Rune Fee was hard-coded into THORChain a week ago as the simple solution to a hard problem. The community had a lot of feedback about this, mainly concerns about ease of updating this in future, and they were correct. THORChain must take the governance-minimal approach to all things, and as a result a programmatic solution has been scoped out. The Network Fee will now be twice the 7-day trailing average of gas fees. This will ensure that it always exceeds the expected gas, and drives long-term income into the system. Currently it is global, but it could easily become chain-specific.

Incentive Pendulum

The system is theoretically unsafe when staked assets exceed bonded assets, whether a cartel exists or not. The reason is that a single node could craft an outgoing transaction that spends asset equally to other defecting nodes, and assuming profit-seeking entities, the assumptions around mutually assured destruction no longer hold. While incredibly unlikely to happen, since defecting nodes would need a modified binary to facilitate this transaction and be able to communicate, the system should protect around this edge case. The solution is to disencentivise staking as the system approaches the edge, so that staking rates reduce and the system becomes safe again. The only tool at the system’s disposal is incentives, and the approach is reduce pool rewards and increase bond rewards. This is known as the “Incentive Pendulum”, designed to keep the system at its happy centre; 67% bonded and 33% staked. The Incentive Pendulum also works in the other direction, increasing incentives to stake at high bond rates. The equation is: poolRewards = (y + x) / (y — x), where x = totalStaked, y = totalBonded. * At exactly 50% bonded and 50% staked, pool rewards will be 0%, incentivising bonding. * At 67% bonded and 33% staked, pool rewards will be 33%, the intended amount. * At 100% bonded and 0% staked, pool rewards will be 100%, incentivising staking.

Removal of Hard-coded Constants

The team intend to remove as many constants as possible from the constants.go file, and replace them with programmatic logic. TSS Timeout, Trailing Gas Fees and Churn Heights help solve this. The team will continue the effort.


Cosmos was upgraded to the latest version, allowing the team to begin removing uint64 casting and replacing it with BigInt casting which is better when handling large numbers. The team are also in the process of removing float64 from the codebase, which is unsafe when computed on different machines. * [Upgrade] upgrade to cosmos v0.37.4 * [Bug] fix code coverage counter * stabilize smoke test runs * 224-issue fix validator meta keeper * panic on genesis * Add SafeDivision and removes Float * Resolve: Remove Stake Validation * Resolve “Add min bond requirement” * Resolve “ADD: Incentive Pendulum” * 264-issue fix the way how we broadcast tx to binance RPC host * [Add] Slash bond on bond refund * [Bug] Track gas in yggdrasil vaults * 233-issue add stake handler * add 30 sec timeout to wait for binance txs * Work continues to refactor the codebase to be more modular, testable and easier to grok. * [Refactor] Add unit tests to node account keeper * Resolve “[Refactor] Yggdrasil keeper” * Resolve “[Refactor] Vault Data keeper” * [Refactor] pool addresses keeper * 220-issue refactor Reserve Contributor * [Refactor] observer keeper * Resolve “[Refactor] Pool Staker keeper” * [Refactor] Pool keeper * [Refactor] Staker pool keeper * [Refactor] tx in keeper * [Refactor] reserve contributor handler * [Refactor] Rewrite tx in handler, msg, etc * Resolve “[Refactor] handleMsgBond” * Resolve “[Refactor] handleMsgAck” * [Refactor] add mock txout store * [Refactor] create pool address manager interface * [Refactor] create mock validator manager * Resolve “[Refactor] handleMsgLeave” * Resolve “[Refactor] handleMsgAdd” * [Refactor] version handler * refactor-stake unit tests * [Refactor] TxOutStore * 236-issue handler unstake * [Refactor] Breakout TxIn into two handlers * Resolve “[Refactor] handleMsgConfirmNextPoolAddress”

Bifröst Module

Work begins on the feature/bifrostv2 branch, which is a chain-agnostic Bifröst Module that will be verified to work on Binance Chain, Bitcoin, Ethereum prior to mainnet. Monero has also been scoped out, but testing it may not happen prior to mainnet.


The team will soon move away from signalling dates for releases, instead will work to signal around completion status of milestones. Whilst ChaosNet seems to be on time for 03 January, much is left to be done: * [ChaosNet] Artificial Ragnarok * [ChaosNet] 1 Day rotations * Add bond reward events * Create pubkeys endpoint * [ChaosNet] Cap staked rune at 600k * Versionize the constants * Emit Validator Events * THORNode Telegram Bot


To keep up to date, please monitor community channels, particularly Telegram and Twitter: Twitter: Telegram Community: Telegram Announcements: Reddit: Github: Medium:
submitted by thorchain_org to THORChain [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? ⚡


Image Explanations:

Specifications / White Papers


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 -

Medium Posts

Learning Resources


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]


Lightning Network Visualizers/Explorers



Payment Processors

  • BTCPay - Next stable version will include Lightning Network




Slack Channel

Discord Channel


⚡ 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 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]

Dosen't inizialize propriety inside the class with the constructor compiling error

Hello guys,
I'm a java programmer and I'm studying C++ with my personal project I want to create a Singleton pattern that contains the proprieties, but when go to initialize the propriety inside the private constructor no-arg I have a compiling error with, it is this
[ 5%] Building CXX object CMakeFiles/SpyCBlockRPC.dicommands/DecodeScriptCommand.cpp.o [ 11%] Building CXX object CMakeFiles/SpyCBlockRPC.diClientBitcoinSingleton.cpp.o /home/vincenzo/Github/SpyCBlockRPC/ClientBitcoinSingleton.cpp: In constructor ‘spyCBlockRPC::ClientBitcoinSingleton::ClientBitcoinSingleton()’: /home/vincenzo/Github/SpyCBlockRPC/ClientBitcoinSingleton.cpp:9:62: error: no matching function for call to ‘BitcoinAPI::BitcoinAPI()’ spyCBlockRPC::ClientBitcoinSingleton::ClientBitcoinSingleton() ^ In file included from /home/vincenzo/Github/SpyCBlockRPC/ClientBitcoinSingleton.h:7:0, from /home/vincenzo/Github/SpyCBlockRPC/ClientBitcoinSingleton.cpp:3: /uslocal/include/bitcoinapi/bitcoinapi.h:28:5: note: candidate: BitcoinAPI::BitcoinAPI(const string&, const string&, const string&, int, int) BitcoinAPI(const std::string& user, const std::string& password, const std::string& host, int port, int httpTimeout = 50000); ^~~~~~~~~~ /uslocal/include/bitcoinapi/bitcoinapi.h:28:5: note: candidate expects 5 arguments, 0 provided /uslocal/include/bitcoinapi/bitcoinapi.h:19:7: note: candidate: constexpr BitcoinAPI::BitcoinAPI(const BitcoinAPI&) class BitcoinAPI ^~~~~~~~~~ /uslocal/include/bitcoinapi/bitcoinapi.h:19:7: note: candidate expects 1 argument, 0 provided 
This is my file ClientBitcoinSingleton.h

namespace spyCBlockRPC { class ClientBitcoinSingleton { public: static ClientBitcoinSingleton& getInstance() { static ClientBitcoinSingleton SINGLETON; return SINGLETON; } BitcoinAPI getBitcoinApi() const; private: ClientBitcoinSingleton(); //BitcoinAPI bitcoinApi{"", "", "", 8332}; //TODO chanhe this resolve the problem, I don't want inizialize it with this code BitcoinAPI bitcoinApi; } 
This is my file ClientBitcoinSingleton.cpp
#include  #include "ClientBitcoinSingleton.h" using namespace std; using namespace cppproperties; using namespace spyCBlockRPC; spyCBlockRPC::ClientBitcoinSingleton::ClientBitcoinSingleton() { string user =""; string pass = ""; string ip =""; int port = 8080; this->dirLogTest = config.GetProperty(DIR_LOG_TEST); this->dirDatatest = config.GetProperty(DIR_DATA_TEST); bitcoinApi = BitcoinAPI{user, pass, ip, port}; } 
I'm not understanding the error, how I want to write this code with no one error?

Thanks so much for your help
submitted by crazyjoker96 to cpp_questions [link] [comments]

Problems checking wallet, bitcoin core on another server

So my setup is that currently Bitcoin core is running on a Windows server, and joinmarket is a fresh install on debian. Bitcoin core is a full node, no pruning, fully synced. I had some problems opening up RPC but I think that part works now (no longer getting timeouts).
But instead this happens:
[email protected]:/home/johan/joinmarket-0.2.3# python wallet.json 2019-08-22 12:12:57,613 [MainThread ] [INFO ] hello joinmarket 2019-08-22 12:12:57,613 [MainThread ] [INFO ] Joinmarket directory is: /home/johan/joinmarket-0.2.3 Enter wallet decryption passphrase: 2019-08-22 12:13:07,323 [MainThread ] [INFO ] requesting detailed wallet history from Bitcoin Core client Traceback (most recent call last): File "", line 126, in  sync_wallet(wallet, fast=options.fastsync) File "/home/johan/joinmarket-0.2.3/joinmarket/", line 79, in sync_wallet jm_single().bc_interface.sync_wallet(wallet) File "/home/johan/joinmarket-0.2.3/joinmarket/", line 959, in sync_wallet super(BitcoinCoreInterface, self).sync_wallet(wallet) File "/home/johan/joinmarket-0.2.3/joinmarket/", line 88, in sync_wallet self.sync_addresses(wallet) File "/home/johan/joinmarket-0.2.3/joinmarket/", line 1065, in sync_addresses imported_addr_set = set(self.rpc('getaddressesbyaccount', [wallet_name])) File "/home/johan/joinmarket-0.2.3/joinmarket/", line 935, in rpc res =, args) File "/home/johan/joinmarket-0.2.3/joinmarket/", line 117, in call raise JsonRpcError(response["error"]) joinmarket.jsonrpc.JsonRpcError [email protected]:/home/johan/joinmarket-0.2.3# 
Any idea what could be wrong? I am stuck....
submitted by hides_dirty_secrets to joinmarket [link] [comments]

Lightning node on Windows - testing, get not connected

Ok after testing BTCPay, C-Lightning, LND on Ubuntu I said ok let's try also the Windows implementation, is just few clicks and done (as it is promoted).
So I followed this github guide that actually send you to this one.
OK, started Bitcoin-core client on Windows 7 x64, with an already synced data folder. Empty bitcoin.conf (none of guides says how to configure the conf file). Wait until the client is full synced. And then launched the windows-node-launcher (from a subfolder inside Bitcoin folder). All good, started slowly and a small popup appeared in systray saying Bitcoin node is syncing. Reviewed the config of Bitcoin and LND through that little app in systray and saw that bitcoin.conf was already filled with some settings. Didn't change anything. After 1 day (with the bitcoin blockchain already synced), the systray popup still says that is syncing and have a red dot. In the tutorial says that we have to leave it to sync until is blue and then green.
I said, ok maybe it has more things to do. So I open that LND Output link, to see what is going on... And I see that LND is not well. Says: 2019-04-06 21:11:29.772 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default 2019-04-06 21:11:29.772 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2019-04-06 21:11:29.774 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8 2019-04-06 21:11:29.808 [INF] RPCS: password RPC server listening on 2019-04-06 21:11:29.808 [INF] RPCS: password gRPC proxy started at 2019-04-06 21:11:29.808 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it. 2019-04-06 21:11:32.673 [INF] LNWL: Opened wallet 2019-04-06 21:11:33.183 [INF] LTND: Primary chain is set to: bitcoin unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:36.087 [INF] LTND: Shutdown complete unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:39.229 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default
Now the bitcoin.conf have this: printtoconsole=1 rpcallowip=::/0 whitelist= datadir=C:\Users\Admin\AppData\Roaming\Bitcoin prune=0 txindex=1 server=1 disablewallet=0 timeout=6000 rpcuser=user rpcpassword=defaultxzxxxxx zmqpubrawblock=tcp:// zmqpubrawtx=tcp:// dbcache=2408
And LND.conf have this: (#) Auto-Generated Configuration File (#) Node Launcher version 6.0.2 debuglevel=info restlisten= rpclisten= tlsextraip= listen= alias=aliasme color=#00aa7f bitcoin.node=bitcoind bitcoind.rpchost= bitcoind.rpcuser=user bitcoind.rpcpass=defaultxxxxx bitcoind.zmqpubrawblock=tcp:// bitcoind.zmqpubrawtx=tcp://
So what is going on here? I will have to wait indefinitely? Somebody can give some help or explanation? Is this LND node working on Windows Server 2008 or 2012?
submitted by Mr--Robot to Bitcoin [link] [comments]

Decred Journal – September 2018

Note: you can read this on GitHub (link), Medium (link) or old Reddit (link).


Final version 1.3.0 of the core software was released bringing all the enhancements reported last month to the rest of the community. The groundwork for SPV (simplified payment verification) is complete, another reduction of fees is being deployed, and performance stepped up once again with a 50% reduction in startup time, 20% increased sync speed and more than 3x faster peer delivery of block headers (a key update for SPV). Decrediton's integrations of SPV and Politeia are open for testing by experienced users. Read the full release notes and get the downloads on GitHub. As always, don't forget to verify signatures.
dcrd: completed several steps towards multipeer downloads, improved introduction to the software in the main README, continued porting cleanups and refactoring from upstream btcd.
Currently in review are initial release of smart fee estimator and a change to UTXO set semantics. The latter is a large and important change that provides simpler handling, and resolves various issues with the previous approach. A lot of testing and careful review is needed so help is welcome.
Educational series for new Decred developers by @matheusd added two episodes: 02 Simnet Setup shows how to automate simnet management with tmux and 03 Miner Reward Invalidation explains block validity rules.
Finally, a pull request template with a list of checks was added to help guide the contributors to dcrd.
dcrwallet: bugfixes and RPC improvements to support desktop and mobile wallets.
Developers are welcome to comment on this idea to derive stakepool keys from the HD wallet seed. This would eliminate the need to backup and restore redeem scripts, thus greatly improving wallet UX. (missed in July issue)
Decrediton: bugfixes, refactoring to make the sync process more robust, new loading animations, design polishing.
Politeia: multiple improvements to the CLI client (security conscious users with more funds at risk might prefer CLI) and security hardening. A feature to deprecate or timeout proposals was identified as necessary for initial release and the work started. A privacy enhancement to not leak metadata of ticket holders was merged.
Android: update from @collins: "Second test release for dcrandroid is out. Major bugs have been fixed since last test. Latest code from SPV sync has been integrated. Once again, bug reports are welcome and issues can be opened on GitHub". Ask in #dev room for the APK to join testing.
A new security page was added that allows one to validate addresses and to sign/verify messages, similar to Decrediton's Security Center. Work on translations is beginning.
Overall the app is quite stable and accepting more testers. Next milestone is getting the test app on the app store.
iOS: the app started accepting testers last week. @macsleven: "the test version of Decred Wallet for iOS is available, we have a link for installing the app but the builds currently require your UDID. Contact either @macsleven or @raedah with your UDID if you would like to help test.".
Nearest goal is to make the app crash free.
Both mobile apps received new design themes.
dcrdata: v3.0 was released for mainnet! Highlights: charts, "merged debits" view, agendas page, Insight API support, side chain tracking, Go 1.11 support with module builds, numerous backend improvements. Full release notes here. This release featured 9 contributors and development lead @chappjc noted: "This collaboration with @raedahgroup on our own block explorer and web API for @decredproject has been super productive.".
Up next is supporting dynamic page widths site wide and deploying new visual blocks home page.
Trezor: proof of concept implementation for Trezor Model T firmware is in the works (previous work was for Model One).
Ticket splitting: updated to use Go modules and added simnet support, several fixes.
docs: beginner's guide overhaul, multiple fixes and cleanups. added 3rd party wallets, removed inactive PoW pools and removed web wallet.
@Richard-Red is building a curated list of Decred-related GitHub repositories.
Welcome to new people contributing for the first time: @klebe, @s_ben, @victorguedes, and PrimeDominus!
Dev activity stats for September: 219 active PRs, 197 commits, 28.7k added and 18.8k deleted lines spread across 6 repositories. Contributions came from 4-10 developers per repository. (chart)


Hashrate: started and ended the month around 75 PH/s, hitting a low of 60.5 and a new high of 110 PH/s. BeePool is again the leader with their share varying between 23-54%, followed by F2Pool 13-30%, Coinmine 4-6% and Luxor 3-5%. As in previous months, there were multiple spikes of unidentified hashrate.
Staking: 30-day average ticket price is 98 DCR (+2.4). The price varied between 95.7 and 101.9 DCR. Locked DCR amount was 3.86-3.96 million DCR, or 45.7-46.5% of the supply.
Nodes: there are 201 public listening nodes and 325 normal nodes per Version distribution: 5% are v1.4.0(pre) dev builds (+3%), 30% on v1.3.0 (+25%), 42% on v1.2.0 (-20%), 15% on v1.1.2 (-7%), 6% on v1.1.0. More than 76% of nodes run v1.2.0 and higher and therefore support client filters. Data as of Oct 1.


Obelisk posted two updates on their mailing list. 70% of Batch 1 units are shipped, an extensive user guide is available, Obelisk Scanner application was released that allows one to automatically update firmware. First firmware update was released and bumped SC1 hashrate by 10-20%, added new pools and fixed multiple bugs. Next update will focus on DCR1. It is worth a special mention that the firmware source code is now open! Let us hope more manufacturers will follow this example.
A few details about Whatsminer surfaced this month. The manufacturer is MicroBT, also known as Bitwei and commonly misspelled as Bitewei. Pangolinminer is a reseller, and the model name is Whatsminer D1.
Bitmain has finally entered Decred ASIC space with their Antminer DR3. Hash rate is 7.8 TH/s while pulling 1410 W, at the price of $673. These specs mean it has the best GH/W and GH/USD of currently sold miners until the Whatsminer or others come out, although its GH/USD of 11.6 already competes with Whatsminer's 10.5. Discussed on Reddit and bitcointalk, unboxing video here.


Meet our 17th voting service provider: It is operated by @david, has 2% fee and supports ticket splitting. Reddit thread is here.
For a historical note, the first VSP to support ticket splitting was
@matheusd started tests on testnet several months ago. I contacted him so we could integrate with the pool in June this year. We set up the machine in July and bought the first split ticket on mainnet, using the decredbrasil pool, on July 19. It was voted on July 30. After this first vote on mainnet, we opened the tests to selected users (with more technical background) on the pool. In August we opened the tests to everyone, and would call people who want to join to the #ticket_splitting channel, or to our own Slack (in Portuguese, so mostly Brazilian users). We have 28 split tickets already voted, and 16 are live. So little more than 40 split tickets total were bought on decredbrasil pool. (@girino in #pos-voting)
KuCoin exchange listed DCBTC and DCETH pairs. To celebrate their anniversary they had a 99% trading fees discount on DCR pairs for 2 weeks.
Three more wallets integrated Decred in September:
ChangeNow announced Decred addition to their Android app that allows accountless swaps between 150+ assets.
Coinbase launched informational asset pages for top 50 coins by market cap, including Decred. First the pages started showing in the Coinbase app for a small group of testers, and later the web price dashboard went live.


The birth of a Brazilian girl was registered on the Decred blockchain using OriginalMy, a blockchain proof of authenticity services provider. Read the full story in Portuguese and in English.


Advertising report for September is ready. Next month the graphics for all the ads will be changing.
Marketing might seem quiet right now, but a ton is actually going on behind the scenes to put the right foundation in place for the future. Discovery data are being analyzed to generate a positioning strategy, as well as a messaging hierarchy that can guide how to talk about Decred. This will all be agreed upon via consensus of the community in the work channels, and materials will be distributed.
Next, work is being done to identify the right PR partner to help with media relations, media training, and coordination at events. While all of this is coming up to speed, we believe the website needs a refresher reflecting the soon to be agreed upon messaging, plus a more intuitive architecture to make it easier to navigate. (@Dustorf)


We'll begin shortly reviewing conferences and events planned for the first half of 2019. Highlights are sure to include The North American Bitcoin Conference in Miami (Jan 16-18) and Consensus in NYC (May 14-16). If you have suggestions of events or conferences Decred should attend, please share them in #event_planning. In 2019, we would like to expand our presence in Europe, Asia, and South America, and we're looking for community members to help identify and staff those events. (@Dustorf)


August issue of Decred Journal was translated to Russian. Many thanks to @DZ!
Rency cryptocurrency ratings published a report on Decred and incorporated a lot of feedback from the community on Reddit.
September issue of Chinese CCID ratings was published (snapshot), Decred is still at the bottom.
Featured articles:

Community Discussions

Community stats:
Comm systems news: Several work channels were migrated to Matrix, #writers_room is finally bridged.
Twitter: why decentralized governance and funding are necessary for network survival and the power of controlling the narrative; learning about governance more broadly by watching its evolution in cryptocurrency space, importance of community consensus and communications infrastructure.
Reddit: yet another strong pitch by @solar; question about buyer protections; dcrtime internals; a proposal to sponsor hoodies in the University of Cape Town; Lightning Network support for altcoins.
Chats: skills to operate a stakepool; voting details: 2 of 3 votes can approve a block, what votes really approve are regular tx, etc; scriptless script atomic swaps using Schnorr adaptor signatures; dev dashboard, choosing work, people do best when working on what interests them most; opportunities for governments and enterprise for anchoring legal data to blockchain; terminology: DAO vs DAE; human-friendly payments, sharing xpub vs payment protocols; funding btcsuite development; Politeia vote types: approval vote, sentiment vote and a defund vote, also linking proposals and financial statements; algo trading and programming languages (yes, on #trading!); alternative implementation, C/C++/Go/Rust; HFTs, algo trading, fake volume and slippage; offline wallets, usb/write-only media/optical scanners vs auditing traffic between dcrd and dcrwallet; Proof of Activity did not inspire Decred but spurred Decred to get moving, Wikipedia page hurdles; how stakeholders could veto blocks; how many votes are needed to approve a proposal; why Decrediton uses Electron; CVE-2018-17144 and over-dependence on single Bitcoin implementation, btcsuite, fuzz testing; tracking proposal progress after voting and funding; why the wallet does not store the seed at all; power connectors, electricity, wiring and fire safety; reasonable spendings from project fund; ways to measure sync progress better than block height; using Politeia without email address; concurrency in Go, locks vs channels.
#support is not often mentioned, but it must be noted that every day on this channel people get high quality support. (@bee: To my surprise, even those poor souls running Windows 10. My greatest respect to the support team!)


In September DCR was trading in the range of USD 34-45 / BTC 0.0054-0.0063. On Sep 6, DCR revisited the bottom of USD 34 / BTC 0.0054 when BTC quickly dropped from USD 7,300 to 6,400. On Sep 14, a small price rise coincided with both the start of KuCoin trading and hashrate spike to 104 PH/s. Looking at coinmarketcap charts, the trading volume is a bit lower than in July and August.
As of Oct 4, Decred is #18 by the number of daily transactions with 3,200 tx, and #9 by the USD value of daily issuance with $230k. (source: onchainfx)
Interesting observation by @ImacallyouJawdy: while we sit at 2018 price lows the amount locked in tickets is testing 2018 high.

Relevant External

ASIC for Lyra2REv2 was spotted on the web. Vertcoin team is preparing a new PoW algorithm. This would be the 3rd fork after two previous forks to change the algorithm in 2014 and 2015.
A report titled The Positive Externalities of Bitcoin Mining discusses the benefits of PoW mining that are often overlooked by the critics of its energy use.
A Brief Study of Cryptonetwork Forks by Alex Evans of Placeholder studies the behavior of users, developers and miners after the fork, and makes the cases that it is hard for child chains to attract users and developers from their parent chains.
New research on private atomic swaps: the paper "Anonymous Atomic Swaps Using Homomorphic Hashing" attempts to break the public link between two transactions. (bitcointalk, decred)
On Sep 18 Poloniex announced delisting of 8 more assets. That day they took a 12-80% dive showing their dependence on this one exchange.
Circle introduced USDC markets on Poloniex: "USDC is a fully collateralized US dollar stablecoin using the ERC-20 standard that provides detailed financial and operational transparency, operates within the regulated framework of US money transmission laws, and is reinforced by established banking partners and auditors.".
Coinbase announced new asset listing process and is accepting submissions on their listing portal. (decred)
The New York State Office of the Attorney General posted a study of 13 exchanges that contains many insights.
A critical vulnerability was discovered and fixed in Bitcoin Core. Few days later a full disclosure was posted revealing the severity of the bug. In a bitcointalk thread btcd was called 'amateur' despite not being vulnerable, and some Core developers voiced their concerns about multiple implementations. The Bitcoin Unlimited developer who found the bug shared his perspective in a blog post. Decred's vision so far is that more full node implementations is a strength, just like for any Internet protocol.

About This Issue

This is the 6th issue of Decred Journal. It is mirrored on GitHub, Medium and Reddit. Past issues are available here.
Most information from third parties is relayed directly from source after a minimal sanity check. The authors of Decred Journal have no ability to verify all claims. Please beware of scams and do your own research.
Feedback is appreciated: please comment on Reddit, GitHub or #writers_room on Matrix or Slack.
Contributions are also welcome: some areas are adding content, pre-release review or translations to other languages.
Credits (Slack names, alphabetical order): bee, Dustorf, jz, Haon, oregonisaac, raedah and Richard-Red.
submitted by jet_user to decred [link] [comments]

How to track segwit signalling.

The Segwit signalling starts at the first difficulty retarget after 15th November 2016. After that, Bitcoin Core is programmed to start signalling in its mined blocks.
The next difficulty retarget is at block 439488 (because 439488 divides by 2016 exactly.) So after that block, check the below graph and the signalling line should start rising.
Here is a graph of the signalling by miners:
Also you can check the signalling in a trustless way by running Bitcoin Core 0.13.1 and using the getblockchaininfo RPC call.
Segwit needs 95% signalling over a 2016 block period to activate. So that means if non-segwit-signalling reaches 101 blocks (or 5% of 2016) then that retarget period won't result in segwit being activated.
Just like in Orwell's Nineteen Eighty-Four, 101 is a number to be afraid of.
The Segwit soft fork has a timeout of 15th November 2017. That is just one year. Difficulty re-adjusts every 2016 blocks or approximately two weeks, which means there are only 26 chances for it to happen.
submitted by belcher_ to Bitcoin [link] [comments]

[How To]Full Node (Beta) + GUI + Staking on Raspberry PI 3

Hello everyone,
With the Full Node Beta recently being released on 3/28 and the Full Node GUI on 4/11, I thought it would be an excellent time to update the RPi tutorial by olcko and demon for the RPi. I've been running it now for about 1 week and it has been working great so far, but I haven't been connected to many peers running the full node. Hopefully this tutorial will help change that!
This tutorial will take over from the previous tutorial's step 4. Steps 1-3 cover installing Raspbian and SSH on the RPi and are excellent.
mkdir StratisFullNode
cd StratisFullNode
git clone
cd StratisBitcoinFullNode
git submodule update --init --recursive
cd src
cd Stratis.StratisD
run -apiuri=
The "apiuri" option enables access to the API from another device on your network (Thanks Daan Damhuis!).
That's it! Your node should be running now, but may take a while to sync. You can test the node's API by pointing your browser to http://:37221/swagge
If you don't plan on using RPC, make sure you follow the instructions from the previous tutorial step 3 to block RPC connections.
sudo ufw deny 16174
Full Node GUI Setup
Now that the Core Daemon is running, we can install the GUI frontend. We will be following the instructions from here. The GUI that interacts with the node can be installed on the RPi or another device on your network (with some tweaks to the underlying code, below).
cd ~/StratisFullNode
git clone
cd FullNodeUI/FullNodeUI.UI
npm run mainnet
That's it! Go ahead and set up your new wallet!
Remote GUI Tweaks
I'm adding this section for RPi owners who don't run a GUI on their RPi device, but may want to run the GUI on another device on their network. This can be done because the GUI interacts with the full node through the API; however it will take some tweaks to the code before compiling to make this set-up work. The instructions for "Full Node GUI Setup" above should be run on that device.
There is one place in the code where you need to replace "localhost" with your RPi's local private network IP address.
  • src/app/shared/services/api.service.ts#38
this.stratisApiUrl = 'http://:' + this.apiPort + '/api';
You will also need to comment out a few sections to prevent the GUI from starting up or shutting down the full node when you open/close the GUI.
  • main.ts#86
  • main.ts#96
Helpful RPi tips for remote management
  • Use Screen + SSH! Screen is a wonderful utility that will leave your session running when you disconnect from ssh. This is available via sudo apt-get install screen on your RPi. You can reconnect when you return at another ssh session with:
screen -x
  • Sometimes the full node on your RPi will hang or unexpectedly crash - stopping staking in the process. Borrowing from here, I have created a script that will monitor for hangs or crashes and restart the node.
  • If the node is restarted, you will still need to re-enable staking. This can be accomplished through the GUI, a browser using swagger, or with an API call through a local script (insecure).
Sample helper scripts, including a .screenrc configuration, for the above can be found in a pastebin here.
Example API calls can be found on the full node's swagger API interface.
  • Note: your wallet passphrase must be sent via POST to re-enable staking.
I hope you found this helpful!
Please feel free to message me with questions/errors/improvements or find me on the discord/telegram as @TjadenFroyda. I'll update this post with feedback.
Donations are welcome as well: SNSwQVvB5FB6KPVT7325tJGWXbxVd4xceR
submitted by gopherdoc to stratisplatform [link] [comments]

IRC Log from Ravencoin Open Developer Meeting - Aug 24, 2018

[14:05] <@wolfsokta> Hello Everybody, sorry we're a bit late getting started
[14:05] == block_338778 [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:06] <@wolfsokta> Here are the topics we would like to cover today • 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] == Chatturga changed the topic of #ravencoin-dev to: 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] <@wolfsokta> Daben, could you mention what we have done to communicate the need for the 2.0.4 upgrade?
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:07] <@wolfsokta> Others here are free to chime in where they saw the message first.
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.] has quit [Client Quit]
[14:08] Whats up bois
[14:08] hi everyone
[14:08] hi hi
[14:08] <@wolfsokta> Discussing the 2.0.4 update and the need to upgrade.
[14:08] <@Chatturga> Sure. As most of you are aware, the community has been expressing concerns with the difficulty oscillations, and were asking that something be done to the difficulty retargeting. Many people submitted suggestions, and the devs decided to implement DGW.
[14:09] <@Tron> I wrote up a short description of why we're moving to a new difficulty adjustment.
[14:09] <@Chatturga> I have made posts on discord, telegram, bitcointalk, reddit, and from testnet stages through current.
[14:10] <@Chatturga> If there are any other channels that can reach a large number of community members, I would love to have more.
[14:10] <@wolfsokta> Thanks Tron, that hasn't been shared to the community at large yet, but folks feel free to share it.
[14:10] When was this decision made and by whom and how?
[14:10] <@Chatturga> I have also communicated with the pool operators and exchanges about the update. Of all of the current pools, only 2 have not yet updated versions.
[14:11] <@wolfsokta> The decision was made by the developers through ongoing requests for weeks made by the community.
[14:12] <@wolfsokta> Evidence was provided by the community of the damages that could be caused to projects when the wild swings continue.
[14:12] So was there a meeting or vote? How can people get invited
[14:12] <@Tron> It was also informed by my conversations with some miners that recommended that we make the change before the coin died. They witnessed similar oscillations from which other coins never recovered.
[14:13] only two pools left to upgrade is good, what about the exchanges? Any word on how many of those have/have not upgraded?
[14:13] <@wolfsokta> We talked about here in our last meeting Bruce_. All attendees were asked if they had any questions or concerns.
[14:13] == blondfrogs [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:13] == roshii [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:13] sup roshii long time no see
[14:14] <@Chatturga> Bittrex, Cryptopia, and IDCM have all either updated or have announced their intent to update.
[14:14] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:15] sup russki
[14:15] what's the status here?
[14:15] I don’t think that was at all clear from the last dev meeting
[14:15] I can’t be the only person who didn’t understand it
[14:15] <@wolfsokta> Are there any suggestions on how to communicate the need to upgrade even further? I am concerned that others might also not understand.
[14:17] I’m not sold on the benefit and don’t understand the need for a hard fork — I think it’s a bad precedent to simply go rally exchanges to support a hard fork with little to no discussion
[14:17] so just to note, the exchanges not listed as being upgraded or have announced their intention to upgrade include: qbtc, upbit, and cryptobridge (all with over $40k usd volume past 24 hours according to coinmarketcap)
[14:18] <@wolfsokta> I don't agree that there was little or no discussion at all.
[14:19] <@wolfsokta> Looking back at our meeting notes from two weeks ago "fork" was specifically asked about by BrianMCT.
[14:19] If individual devs have the power to simple decide to do something as drastic as a hard fork and can get exchanges and miners to do it that’s got a lot of issues with centralization
[14:19] <@wolfsokta> It had been implemented on testnet by then and discussed in the community for several weeks before that.
[14:19] == under [48c8a838[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:19] howdy
[14:19] Everything I’ve seen has been related to the asset layer
[14:19] I have to agree with Bruce_, though I wasn't able to join the last meeting here. That said I support the fork
[14:20] Which devs made this decision to do a fork and how was it communicated?
[14:20] well mostly the community made the decision
[14:20] Consensus on a change is the heart of bitcoin development and I believe the devs have done a great job building that consensus
[14:20] a lot of miners were in uproar about the situation
[14:20] <@wolfsokta> All of the devs were supporting the changes. It wasn't done in isolation at all.
[14:21] This topic has been a huge discussion point within the RVN mining community for quite some time
[14:21] the community and miners have been having issues with the way diff is adjusted for quite some time now
[14:21] Sure I’m well aware of that -
[14:21] Not sold on the benefits of having difficulty crippled by rented hashpower?
[14:21] The community saw a problem. The devs got together and talked about a solution and implemented a solution
[14:21] I’m active in the community
[14:22] So well aware of the discussions on DGW etc
[14:22] Hard fork as a solution to a problem community had with rented hashpower (nicehash!!) sounds like the perfect decentralized scenario!
[14:23] hard forks are very dangerous
[14:23] mining parties in difficulty drops are too
[14:23] <@wolfsokta> Agreed, we want to keep them to an absolute minimum.
[14:23] But miners motivation it’s the main vote
[14:24] What would it take to convince you that constantly going from 4 Th/s to 500 Gh/s every week is worse for the long term health of the coin than the risk of a hard fork to fix it?
[14:24] == Tron [[email protected]/web/freenode/ip.] has quit [Ping timeout: 252 seconds]
[14:24] This hardfork does include the asset layer right? if so why is it being delayed in implementation?
[14:24] <@wolfsokta> Come back Tron!
[14:24] coudl it have been implement through bip9 voting?
[14:24] also hard fork is activated by the community! that's a vote thing!
[14:24] @mrsushi to give people time to upgrade their wallet
[14:25] @under, it would be much hard to keep consensus with a bip9 change
[14:25] <@wolfsokta> We investigated that closely Under.
[14:25] == Tron [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:25] <@wolfsokta> See Tron's post for more details about that.
[14:25] <@spyder_> Hi Tron
[14:25] <@wolfsokta>
[14:25] Sorry about that. Computer went to sleep.
[14:26] I'm wrong
[14:26] 2 cents. the release deadline of october 31st puts a bit of strain on getting code shipped. (duh). but fixing daa was important to the current health of the coin, and was widely suppported by current mining majority commuity. could it have been implemented in a different manner? yes . if we didnt have deadlines
[14:27] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.] has quit [Quit: Page closed]
[14:27] sushi this fork does not include assets. it's not being delayed though, we're making great progress for an Oct 31 target
[14:28] I don’t see the urgency but my vote doesn’t matter since my hash power is still CPUs
[14:28] <@wolfsokta> We're seeing the community get behind the change as well based on the amount of people jumping back in to mine through this last high difficulty phase.
[14:28] So that will be another hardfork?
[14:28] the fork does include the asset code though set to activate on oct 30th
[14:28] yes
[14:29] <@wolfsokta> Yes, it will based on the upgrade voting through the BIP9 process.
[14:29] I wanted to ask about burn rates from this group: and make a proposal.
[14:29] we're also trying hard to make it the last for awhile
[14:29] Can you clear up the above — there will be this one and another hard fork?
[14:29] <@wolfsokta> Okay, we could discuss that under towards the end of the meeting.
[14:30] If this one has the asset layer is there something different set for October
[14:30] <@wolfsokta> Yes, there will be another hard fork on October 31st once the voting process is successful.
[14:31] <@wolfsokta> The code is in 2.0.4 now and assets are active on testnet
[14:31] Bruce, the assets layer is still being worked on. Assets is active on mainnet. So in Oct 31 voting will start. and if it passes, the chain will fork.
[14:31] this one does NOT include assets for mainnet Bruce -- assets are targeted for Oct 31
[14:31] not***
[14:31] not active****
[14:31] correct me if I'm wrong here, but if everyone upgrades to 2.0.4 for this fork this week, the vote will automatically pass on oct 31st correct? nothing else needs to be done
[14:31] Will if need another download or does this software download cover both forks?
[14:31] <@wolfsokta> Correct Urgo
[14:32] thats how the testnet got activated and this one shows "asset activation status: waiting until 10/30/2018 20:00 (ET)"
[14:32] Will require another upgrade before Oct 31
[14:32] thank you for the clarification wolfsokta
[14:32] <@wolfsokta> It covers both forks, but we might have additional bug fixes in later releases.
[14:32] So users DL one version now and another one around October 30 which activates after that basically?
[14:33] I understand that, but I just wanted to make it clear that if people upgrade to this version for this fork and then don't do anything, they are also voting for the fork on oct 31st
[14:33] Oh okay — one DL?
[14:33] Bruce, Yes.
[14:33] Ty
[14:33] well there is the issue that there maybe some further consensus bugs dealing with the pruneability of asset transactions that needs to be corrected between 2.0.4 and mainnet. so i would imagine that there will be further revisions required to upgrade before now and october 31
[14:33] @under that is correct.
[14:34] I would highly recommend bumping the semver up to 3.0.0 for the final pre 31st release so that the public know to definitely upgrade
[14:34] @under +1
[14:35] out of curiosity, have there been many bugs found with the assets from the version released in july for testnet (2.0.3) until this version? or is it solely a change to DGW?
[14:35] <@wolfsokta> That's not a bad idea under.
[14:35] <@spyder_> @under good idea
[14:35] @urgo. Bugs are being found and fixed daily.
[14:35] Any time the protocol needs to change, there would need to be a hard fork (aka upgrade). It is our hope that we can activate feature forks through the BIP process (as we are doing for assets). Mining pools and exchanges will need to be on the newest software at the point of asset activation - should the mining hash power vote for assets.
[14:35] blondfrogs: gotcha
[14:35] There have been bugs found (and fixed). Testing continues. We appreciate all the bug reports you can give us.
[14:36] <@wolfsokta> Yes! Thank you all for your help in the community.
[14:37] (pull requests with fixes and test coverage would be even better!)
[14:37] asset creation collision is another major issue. current unfair advantage or nodes that fore connect to mining pools will have network topologies that guarantee acceptance. I had discussed the possibility of fee based asset creation selection and i feel that would be a more equal playing ground for all users
[14:38] *of nodes that force
[14:38] <@wolfsokta> What cfox said, we will always welcome development help.
[14:38] So just to make sure everyone know. When assets is ready to go live on oct 31st. Everyone that wants to be on the assets chain without any problems will have to download the new binary.
[14:39] <@wolfsokta> The latest binary.
[14:39] under: already in the works
[14:39] excellent to hear
[14:39] == UserJonPizza [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:39] <@wolfsokta> Okay, we've spent a bunch of time on that topic and I think it was needed. Does anybody have any other suggestions on how to get the word out even more?
[14:40] maybe preface all 2.0.X releases as pre-releases... minimize the number of releases between now and 3.0 etc
[14:41] <@wolfsokta> Bruce_ let's discuss further offline.
[14:41] wolfsokta: which are the remaining two pools that need to be upgraded? I've identified qbtc, upbit, and cryptobridge as high volume exchanges that haven't said they were going to do it yet
[14:41] so people can help reach out to them
[14:41] f2pool is notoriously hard to contact
[14:41] are they on board?
[14:42] <@wolfsokta> We could use help reaching out to QBTC and Graviex
[14:42] I can try to contact CB if you want?
[14:42] <@Chatturga> The remaining pools are Ravenminer and PickAxePro.
[14:42] <@Chatturga> I have spoken with their operators, the update just hasnt been applied yet.
[14:42] ravenminer is one of the largest ones too. If they don't upgrade that will be a problem
[14:42] okay good news
[14:42] (PickAxePro sounds like a Ruby book)
[14:43] I strongly feel like getting the word out on would be beneficial
[14:44] that site is sorely in need of active contribution
[14:44] Anyone can volunteer to contribute
[14:44] <@wolfsokta> Okay, cfox can you talk about the status of unique assets?
[14:44] sure
[14:45] <@wolfsokta> I'll add website to the end of our topics.
[14:45] code is in review and will be on the development branch shortly
[14:45] would it make sense to have a page on the wiki (or somewhere else) that lists the wallet versions run by pools & exchanges?
[14:45] will be in next release
[14:45] furthermore, many sites have friendly link to the standard installers for each platform, if the site linked to the primary installers for each platform to reduce github newb confusion that would be good as well
[14:46] likely to a testnetv5 although that isn't settled
[14:46] <@wolfsokta> Thanks cfox.
[14:46] <@wolfsokta> Are there any questions about unique assets, and how they work?
[14:47] after the # are there any charachters you cant use?
[14:47] will unique assets be constrained by the asset alphanumeric set?
[14:47] ^
[14:47] <@Chatturga> @Urgo there is a page that tracks and shows if they have updated, but it currently doesnt show the actual version that they are on.
[14:47] a-z A-Z 0-9
[14:47] <@Chatturga>
[14:47] There are a few. Mostly ones that mess with command-line
[14:47] you'll be able to use rpc to do "issueunique MATRIX ['Neo','Tank','Tank Brother']" and it will create three assets for you (MATRIX#Neo, etc.)
[14:47] @cfox - No space
[14:48] @under the unique tags have an expanded set of characters allowed
[14:48] Chatturga: thank you
[14:48] @UJP yes there are some you can't use -- I'll try to post gimmie a sec..
[14:49] Ok. Thank you much!
[14:49] 36^36 assets possible and 62^62 uniques available per asset?
[14:49] <@spyder_> std::regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$");
[14:50] regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$")
[14:50] oh thanks Mark
[14:51] <@wolfsokta> Okay, next up. I want to thank everybody for helping test the iOS wallet release.
[14:51] <@wolfsokta> We are working with Apple to get the final approval to post it to the App Store
[14:51] @under max asset length is 30, including unique tag
[14:51] Does the RVN wallet have any other cryptos or just RVN?
[14:52] == BruceFenton [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[14:52] will the android and ios source be migrated to the ravenproject github?
[14:52] I've been adding beta test users. I've added about 80 new users in the last few days.
[14:52] <@wolfsokta> Just RVN, and we want to focus on adding the asset support to the wallet.
[14:53] == Bruce_ [[email protected]/web/freenode/ip.] has quit [Ping timeout: 252 seconds]
[14:53] <@wolfsokta> Yes, the code will also be freely available on GitHub for both iOS and Android. Thank you Roshii!
[14:53] Would you consider the iOS wallet to be a more secure place for one's holdings than say, a Mac connected to the internet?
[14:53] will there be a chance of a more user freindly wallet with better graphics like the iOS on PC?
[14:53] the android wallet is getting updated for DGW, correct?
[14:53] <@wolfsokta> That has come up in our discussion Pizza.
[14:54] QT framework is pretty well baked in and is cross platform. if we get some qt gurus possibly
[14:54] Phones are pretty good because the wallet we forked uses the TPM from modern phones.
[14:54] Most important is to write down and safely store your 12 word seed.
[14:54] TPM?
[14:54] <@wolfsokta> A user friendly wallet is one of our main goals.
[14:55] TPM == Trusted Platform Module
[14:55] Ahhh thanks
[14:55] just please no electron apps. they are full of security holes
[14:55] <@spyder_> It is whats makes your stuffs secure
[14:55] not fit for crypto
[14:55] under: depends on who makes it
[14:55] The interface screenshots I've seen look like Bread/Loaf wallet ... I assume that's what was forked from
[14:55] ;)
[14:56] <@wolfsokta> @roshii did you see the question about the Android wallet and DGW?
[14:56] Yes, it was a fork of breadwallet. We like their security.
[14:56] chromium 58 is the last bundled electron engine and has every vuln documented online by google. so unless you patch every vuln.... methinks not
[14:56] Agreed, great choice
[14:57] <@wolfsokta> @Under, what was your proposal?
[14:58] All asset creation Transactions have a mandatory OP_CHECKLOCKTIMEVERIFY of 1 year(or some agreed upon time interval), and the 500 RVN goes to a multisig devfund, run by a custodial group. We get: 1) an artificial temporary burn, 2) sustainable community and core development funding for the long term, after OSTK/Medici 3) and the reintroduction of RVN supply at a fixed schedule, enabling the removal of the 42k max cap of total As
[14:58] *im wrong on the 42k figure
[14:58] <@wolfsokta> Interesting...
[14:59] <@wolfsokta> Love to hear others thoughts.
[14:59] Update: I posted a message on the CryptoBridge discord and one of their support members @stepollo#6276 said he believes the coin team is already aware of the fork but he would forward the message about the fork over to them right now anyway
[14:59] Ifs 42 million assets
[14:59] yep.
[15:00] I have a different Idea. If the 500 RVN goes to a dev fund its more centralized. The 500 RVN should go back into the unmined coins so miners can stay for longer.
[15:01] *without a hardfork
[15:01] <@wolfsokta> lol
[15:01] that breaks halving schedule, since utxos cant return to an unmined state.
[15:01] @UJP back into coinbase is interesting. would have to think about how that effects distribution schedule, etc.
[15:01] only way to do that would be to dynamicaly grow max supply
[15:02] and i am concerned already about the max safe integer on various platforms at 21 billion
[15:02] js chokes on ravencoin already
[15:02] <@wolfsokta> Other thoughts on Under's proposal? JS isn't a real language. ;)
[15:02] Well Bitcoin has more than 21 bn Sats
[15:02] Is there somebody who wants to volunteer to fix js.
[15:02] hahaha
[15:03] I honestly would hate for the coins to go to a dev fund. It doesn't seem like Ravencoin to me.
[15:03] Yep, but we're 21 billion x 100,000,000 -- Fits fine in a 64-bit integer, but problematic for some languages.
[15:03] <@wolfsokta> Thanks UJP
[15:04] <@wolfsokta> We're past time but I would like to continue if you folks are up for it.
[15:04] Yeah no coins can go anywhere centrality contorted like a dev fund cause that would mean someone has to run it and the code can’t decide that so it’s destined to break
[15:05] currently and long term with out the financial backing of development then improvements and features will be difficult. we are certainly thankful for our current development model. but if a skunkworks project hits a particular baseline of profitability any reasonable company would terminate it
[15:05] Yes let’s contibue for sure
[15:05] the alternative to a dev fund in my mind would be timelocking those funds back to the issuers change address
[15:06] But we can’t have dev built in to the code — it has to be open source like Bitcoin and monero and Litecoin - it’s got drawbacks but way more advantages- it’s the best model
[15:06] Dev funding
[15:06] i highly reccommend not reducing the utility of raven by removing permanently the supply
[15:07] == BW_ [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[15:07] timelocking those funds accompllishes the same sacrifice
[15:07] @under timelocking is interesting too
[15:07] How exactly does timelocking work?
[15:07] <@wolfsokta> ^
[15:07] I mean you could change the price of assets with the Block reward halfing.
[15:07] == Roshiix [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[15:08] funds cant be spent from an address until a certain time passes
[15:08] but in a what magical fairy land do people continue to work for free forever. funding development is a real issue... as much as some might philosphically disagree. its a reality
[15:08] You’d still need a centralized party to decide how to distribute the funds
[15:08] even unofficially blockstream supports bitcoin devs
[15:08] on chain is more transparent imho
[15:09] == Tron_ [[email protected]/web/freenode/ip.] has joined #ravencoin-dev
[15:09] @UJP yes there are unlimited strategies. one factor that I think is v important is giving application developers a way to easily budget for projects which leads to flat fees
[15:09] If the project is a success like many of believe it will be, I believe plenty of people will gladly done to a dev fund. I don't think the 500 should be burned.
[15:09] *donate
[15:09] centralized conservatorship, directed by community voting process
[15:10] == Tron [[email protected]/web/freenode/ip.] has quit [Ping timeout: 252 seconds]
[15:10] <@wolfsokta> Thanks Under, that's an interesting idea that we should continue to discuss in the community. You also mentioned the existing website.
[15:10] It would need to be something where everyone with a QT has a vote
[15:10] think his computer went to sleep again :-/
[15:10] I agree UJP
[15:10] with the website
[15:10] No that’s ico jargon — any development fund tied to code would have to be centralized and would therefor fail
[15:11] ^
[15:11] ^
[15:11] ^
[15:11] dashes model for funding seems to be pretty decentralized
[15:11] community voting etc
[15:11] Once you have a dev fund tied to code then who gets to run it? Who mediates disputes?
[15:11] oh well another discussion
[15:11] Dash has a CEO
[15:12] <@wolfsokta> Yeah, let's keep discussing in the community spaces.
[15:12] Dash does have a good model. It's in my top ten.
[15:12] having the burn go to a dev fund is absolute garbage
[15:12] These dev chats should be more target than broad general discussions — changing the entire nature of the coin and it’s economics is best discussed in the RIPs or other means
[15:13] <@wolfsokta> Yup, let's move on.
[15:13] just becuase existing implementation are garbage doesnt mean that all possible future governance options are garbage
[15:13] <@wolfsokta> To discussing the website scenario mentioned by under.
[15:13] the website needs work. would be best if it could be migrated to github as well.
[15:13] What about this: Anyone can issue a vote once the voting feature has been added, for a cost. The vote would be what the coins could be used for.
[15:14] features for the site that need work are more user friendly links to binaries
[15:14] <@wolfsokta> We investigated how bitcoin has their website in Github to make it easy for contributors to jump in.
[15:14] that means active maintenance of the site instead of its current static nature
[15:15] <@wolfsokta> I really like how it's static html, which makes it super simple to host/make changes.
[15:15] the static nature isn’t due to interface it’s due to no contributors
[15:15] no contribution mechanism has been offered
[15:15] github hosted would allow that
[15:16] We used to run the Bitcoin website from the foundation & the GitHub integration seemed to cause some issues
[15:16] its doesnt necessarily have to be hosted by github but the page source should be on github and contributions could easily be managed and tracked
[15:17] for example when a new release is dropped, the ability for the downlaods section to have platform specific easy links to the general installers is far better for general adoption than pointing users to github releases
[15:18] <@wolfsokta> How do people currently contribute to the existing website?
[15:18] they dont?
[15:18] We did that and it was a complete pain to host and keep working — if someone wants to volunteer to do that work hey can surely make the website better and continually updated — but they could do that in Wordpress also
[15:19] I’d say keep an eye out for volunteers and maybe we can get a group together who can improve the site
[15:19] == digitalvap0r-xmr [[email protected]/web/cgi-irc/] has joined #ravencoin-dev
[15:19] And they can decide best method
[15:20] I host the source for the explorer on github and anyone can spin it up instantly on a basic aws node. changes can be made to interface etc, and allow for multilingual translations which have been offered by some community members
[15:20] there are models that work. just saying it should be looked at
[15:20] i gotta run thank you all for your contributions
[15:20] <@wolfsokta> I feel we should explore the source for the website being hosted in GitHub and discuss in our next dev meeting.
[15:21] <@Chatturga> Thanks Under!
[15:21] == under [[email protected]/web/freenode/ip.] has quit [Quit: Page closed]
[15:21] <@wolfsokta> Thanks, we also need to drop soon.
[15:21] There is no official site so why care. Someone will do better than the next if RVN is worth it anyway. That's already the case.
[15:21] <@wolfsokta> Let's do 10 mins of open Q&A
[15:22] <@wolfsokta> Go...
[15:23] <@Chatturga> Beuller?
[15:24] No questions ... just a comment that the devs and community are great and I'm happy to be a part of it
[15:24] I think everyone moved to discord. I'll throw this out there. How confident is the dev team that things will be ready for oct 31st?
[15:24] <@wolfsokta> Alright! Thanks everybody for joining us today. Let's plan to get back together as a dev group in a couple of weeks.
[15:25] thanks block!
[15:25] <@wolfsokta> Urgo, very confident
[15:25] Please exclude trolls from discord who havent read the whitepaper
[15:25] great :)
[15:25] "things" will be ready..
[15:25] Next time on discord right?
[15:25] woah why discord?
[15:25] some of the suggestions here are horrid
[15:25] this is better less point
[15:25] == blondfrogs [[email protected]/web/freenode/ip.] has quit [Quit: Page closed]
[15:25] Assets are working well on testnet. Plan is to get as much as we can safely test by Sept 30 -- this includes dev contributions. Oct will be heavy testing and making sure it is safe.
[15:26] people
[15:26] <@wolfsokta> Planning on same time, same IRC channel.
[15:26] == BW_ [[email protected]/web/freenode/ip.] has quit [Quit: Page closed]
[15:26] @xmr any in particular?
[15:27] (or is "here" discord?)
[15:27] Cheers - Tron
[15:27] "Cheers - Tron" - Tron
submitted by Chatturga to Ravencoin [link] [comments]

04-07 09:48 - 'Lightning node on Windows - testing, get not connected' (self.Bitcoin) by /u/Mr--Robot removed from /r/Bitcoin within 845-855min

Ok after testing BTCPay, C-Lightning, LND on Ubuntu I said ok let's try also the Windows implementation, is just few clicks and done (as it is promoted).
So I followed this [github guide]1 that actually send you to [this one]2 .
OK, started Bitcoin-core client on Windows 7 x64, with an already synced data folder. Empty bitcoin.conf (none of guides says how to configure the conf file). Wait until the client is full synced. And then launched the windows-node-launcher (from a subfolder inside Bitcoin folder). All good, started slowly and a small popup appeared in systray saying Bitcoin node is syncing. Reviewed the config of Bitcoin and LND through that little app in systray and saw that bitcoin.conf was already filled with some settings. Didn't change anything. After 1 day (with the bitcoin blockchain already synced), the systray popup still says that is syncing and have a red dot. In the tutorial says that we have to leave it to sync until is blue and then green.
I said, ok maybe it has more things to do. So I open that LND Output link, to see what is going on... And I see that LND is not well. Says: 2019-04-06 21:11:29.772 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default 2019-04-06 21:11:29.772 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2019-04-06 21:11:29.774 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8 2019-04-06 21:11:29.808 [INF] RPCS: password RPC server listening on 2019-04-06 21:11:29.808 [INF] RPCS: password gRPC proxy started at 2019-04-06 21:11:29.808 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it. 2019-04-06 21:11:32.673 [INF] LNWL: Opened wallet 2019-04-06 21:11:33.183 [INF] LTND: Primary chain is set to: bitcoin unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:36.087 [INF] LTND: Shutdown complete unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:39.229 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default
Now the bitcoin.conf have this: printtoconsole=1 rpcallowip=::/0 whitelist= datadir=C:\Users\Admin\AppData\Roaming\Bitcoin prune=0 txindex=1 server=1 disablewallet=0 timeout=6000 rpcuser=user rpcpassword=defaultxzxxxxx zmqpubrawblock=[link]3 zmqpubrawtx=[link]4 dbcache=2408
And LND.conf have this: (#) Auto-Generated Configuration File (#) Node Launcher version 6.0.2 debuglevel=info restlisten= rpclisten= tlsextraip= listen= alias=aliasme color=#00aa7f bitcoin.node=bitcoind bitcoind.rpchost= bitcoind.rpcuser=user bitcoind.rpcpass=defaultxxxxx bitcoind.zmqpubrawblock=[link]3 bitcoind.zmqpubrawtx=[link]4
So what is going on here? I will have to wait indefinitely? Somebody can give some help or explanation? Is this LND node working on Windows Server 2008 or 2012?
Lightning node on Windows - testing, get not connected
Go1dfish undelete link
unreddit undelete link
Author: Mr--Robot
1: g*thub.c*m/light**ng**o*e*-users/no**-launc**r 2: me*ium.*o**lig*tn**g-p*wer-users/w*n**ws-m**os-l**ht*i*g-ne*work-2*4bd5034340 3: 127.0.0**:1*5*2 4: 127*0.0**:185*3 5: 1**.0.0*1:185*2 6: 12*.0**.1:*8503
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

Antminer S9 no longer hashing?

Good morning folks,
I have an Antminer S9 that has performed flawlessly. After I moved it to a better location, I noticed that it no longer seems to be working. The green light is flashing, but it doesn't seem to be hashing to my pool (Nicehash).
I'm fairly new to Bitcoining mining and can't make sense of some of the information on my status screen. Before I jump into Bitmain support, I was wondering if anyone could clue me in as to what the problem might be.
I'll post my Kernal Log here.
Thank you in advance!!!
KERNAL LOG: [ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.14.0-xilinx-ge8a2f71-dirty ([email protected]) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-23) ) #82 SMP PREEMPT Tue May 16 19:49:53 CST 2017
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine model: Xilinx Zynq
[ 0.000000] cma: CMA: reserved 128 MiB at 27800000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] On node 0 totalpages: 258048
[ 0.000000] free_area_init_node: node 0, pgdat c0740a40, node_mem_map e6fd8000
[ 0.000000] Normal zone: 1520 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 194560 pages, LIFO batch:31
[ 0.000000] HighMem zone: 496 pages used for memmap
[ 0.000000] HighMem zone: 63488 pages, LIFO batch:15
[ 0.000000] PERCPU: Embedded 8 pages/cpu @e6fc0000 s9088 r8192 d15488 u32768
[ 0.000000] pcpu-alloc: s9088 r8192 d15488 u32768 alloc=8*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 256528
[ 0.000000] Kernel command line: noinitrd mem=1008M console=ttyPS0,115200 root=ubi0:rootfs ubi.mtd=1 rootfstype=ubifs rw rootwait
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 884148K/1032192K available (5032K kernel code, 283K rwdata, 1916K rodata, 204K init, 258K bss, 148044K reserved, 253952K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06d1374 (6949 kB)
[ 0.000000] .init : 0xc06d2000 - 0xc0705380 ( 205 kB)
[ 0.000000] .data : 0xc0706000 - 0xc074cf78 ( 284 kB)
[ 0.000000] .bss : 0xc074cf84 - 0xc078d9fc ( 259 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Dump stacks of tasks blocking RCU-preempt GP.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] ps7-slcr mapped to f0004000
[ 0.000000] zynq_clock_init: clkc starts at f0004100
[ 0.000000] Zynq clock init
[ 0.000015] sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 3298534883328ns
[ 0.000308] ps7-ttc #0 at f0006000, irq=43
[ 0.000618] Console: colour dummy device 80x30
[ 0.000658] Calibrating delay loop... 1325.46 BogoMIPS (lpj=6627328)
[ 0.040207] pid_max: default: 32768 minimum: 301
[ 0.040436] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.040459] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.042612] CPU: Testing write buffer coherency: ok
[ 0.042974] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.043036] Setting up static identity map for 0x4c4b00 - 0x4c4b58
[ 0.043263] L310 cache controller enabled
[ 0.043282] l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72760000, Cache size: 512 kB
[ 0.121037] CPU1: Booted secondary processor
[ 0.210227] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.210357] Brought up 2 CPUs
[ 0.210376] SMP: Total of 2 processors activated.
[ 0.210385] CPU: All CPU(s) started in SVC mode.
[ 0.211051] devtmpfs: initialized
[ 0.213481] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.214724] regulator-dummy: no parameters
[ 0.223736] NET: Registered protocol family 16
[ 0.226067] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.228361] cpuidle: using governor ladder
[ 0.228374] cpuidle: using governor menu
[ 0.235908] syscon f8000000.ps7-slcr: regmap [mem 0xf8000000-0xf8000fff] registered
[ 0.237440] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.237453] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.237572] zynq-ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xf0080000
[ 0.259435] bio: create slab at 0
[ 0.261172] vgaarb: loaded
[ 0.261915] SCSI subsystem initialized
[ 0.262814] usbcore: registered new interface driver usbfs
[ 0.262985] usbcore: registered new interface driver hub
[ 0.263217] usbcore: registered new device driver usb
[ 0.263743] media: Linux media interface: v0.10
[ 0.263902] Linux video capture interface: v2.00
[ 0.264150] pps_core: LinuxPPS API ver. 1 registered
[ 0.264162] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[[email protected]](mailto:[email protected])>
[ 0.264286] PTP clock support registered
[ 0.264656] EDAC MC: Ver: 3.0.0
[ 0.265719] Advanced Linux Sound Architecture Driver Initialized.
[ 0.268708] DMA-API: preallocated 4096 debug entries
[ 0.268724] DMA-API: debugging enabled by kernel config
[ 0.268820] Switched to clocksource arm_global_timer
[ 0.289596] NET: Registered protocol family 2
[ 0.290280] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.290375] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.290535] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.290612] TCP: reno registered
[ 0.290633] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.290689] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.290971] NET: Registered protocol family 1
[ 0.291346] RPC: Registered named UNIX socket transport module.
[ 0.291359] RPC: Registered udp transport module.
[ 0.291368] RPC: Registered tcp transport module.
[ 0.291376] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.291391] PCI: CLS 0 bytes, default 64
[ 0.291857] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[ 0.293945] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.295408] bounce pool size: 64 pages
[ 0.296323] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[ 0.296525] msgmni has been set to 1486
[ 0.297330] io scheduler noop registered
[ 0.297343] io scheduler deadline registered
[ 0.297385] io scheduler cfq registered (default)
[ 0.308358] dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-2364208
[ 0.308380] dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
[ 0.434378] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 82, base_baud = 3124999) is a xuartps
[ 1.006815] console [ttyPS0] enabled
[ 1.011106] xdevcfg f8007000.ps7-dev-cfg: ioremap 0xf8007000 to f0068000
[ 1.018731] [drm] Initialized drm 1.1.0 20060810
[ 1.036029] brd: module loaded
[ 1.045494] loop: module loaded
[ 1.055163] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[ 1.060985] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[ 1.068779] libphy: XEMACPS mii bus: probed
[ 1.073341] ------------- phy_id = 0x3625e62
[ 1.078112] xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
[ 1.087072] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.093912] ehci-pci: EHCI PCI platform driver
[ 1.101155] zynq-dr e0002000.ps7-usb: Unable to init USB phy, missing?
[ 1.107952] usbcore: registered new interface driver usb-storage
[ 1.114850] mousedev: PS/2 mouse device common for all mice
[ 1.120975] i2c /dev entries driver
[ 1.127946] zynq-edac f8006000.ps7-ddrc: ecc not enabled
[ 1.133474] cpufreq_cpu0: failed to get cpu0 regulator: -19
[ 1.139426] Xilinx Zynq CpuIdle Driver started
[ 1.144261] sdhci: Secure Digital Host Controller Interface driver
[ 1.150384] sdhci: Copyright(c) Pierre Ossman
[ 1.154700] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.161601] mmc0: no vqmmc regulator found
[ 1.165614] mmc0: no vmmc regulator found
[ 1.208845] mmc0: SDHCI controller on e0100000.ps7-sdio [e0100000.ps7-sdio] using ADMA
[ 1.217539] usbcore: registered new interface driver usbhid
[ 1.223054] usbhid: USB HID core driver
[ 1.227806] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[ 1.234107] nand: Micron MT29F2G08ABAEAWP
[ 1.238074] nand: 256MiB, SLC, page size: 2048, OOB size: 64
[ 1.244027] Bad block table found at page 131008, version 0x01
[ 1.250251] Bad block table found at page 130944, version 0x01
[ 1.256303] 3 ofpart partitions found on MTD device pl353-nand
[ 1.262080] Creating 3 MTD partitions on "pl353-nand":
[ 1.267174] 0x000000000000-0x000002000000 : "BOOT.bin-env-dts-kernel"
[ 1.275230] 0x000002000000-0x00000b000000 : "angstram-rootfs"
[ 1.282582] 0x00000b000000-0x000010000000 : "upgrade-rootfs"
[ 1.291630] TCP: cubic registered
[ 1.294869] NET: Registered protocol family 17
[ 1.299597] Registering SWP/SWPB emulation handler
[ 1.305497] regulator-dummy: disabling
[ 1.309875] UBI: attaching mtd1 to ubi0
[ 1.836565] UBI: scanning is finished
[ 1.848221] UBI: attached mtd1 (name "angstram-rootfs", size 144 MiB) to ubi0
[ 1.855302] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 1.862063] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 1.868728] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 1.875605] UBI: good PEBs: 1152, bad PEBs: 0, corrupted PEBs: 0
[ 1.881586] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 1.888693] UBI: max/mean erase counter: 4/1, WL threshold: 4096, image sequence number: 1134783803
[ 1.897736] UBI: available PEBs: 0, total reserved PEBs: 1152, PEBs reserved for bad PEB handling: 40
[ 1.906953] UBI: background thread "ubi_bgt0d" started, PID 1080
[ 1.906959] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.911038] ALSA device list:
[ 1.911042] No soundcards found.
[ 1.927420] UBIFS: background thread "ubifs_bgt0_0" started, PID 1082
[ 1.956473] UBIFS: recovery needed
[ 2.016970] UBIFS: recovery completed
[ 2.020709] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 2.026635] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 2.035771] UBIFS: FS size: 128626688 bytes (122 MiB, 1013 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[ 2.045653] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 2.050693] UBIFS: media format: w4/r0 (latest is w4/r0), UUID B079DD56-06BB-4E31-8F5E-A6604F480DB2, small LPT model
[ 2.061987] VFS: Mounted root (ubifs filesystem) on device 0:11.
[ 2.069184] devtmpfs: mounted
[ 2.072297] Freeing unused kernel memory: 204K (c06d2000 - c0705000)
[ 2.920928] random: dd urandom read with 0 bits of entropy available
[ 3.318860]
[ 3.318860] bcm54xx_config_init
[ 3.928853]
[ 3.928853] bcm54xx_config_init
[ 7.929682] xemacps e000b000.ps7-ethernet: Set clk to 124999998 Hz
[ 7.935787] xemacps e000b000.ps7-ethernet: link up (1000/FULL)
[ 22.563181] In axi fpga driver!
[ 22.566260] request_mem_region OK!
[ 22.569676] AXI fpga dev virtual address is 0xf01fe000
[ 22.574751] *base_vir_addr = 0x8c510
[ 22.590723] In fpga mem driver!
[ 22.593791] request_mem_region OK!
[ 22.597361] fpga mem virtual address is 0xf3000000
[ 23.408156]
[ 23.408156] bcm54xx_config_init
[ 24.038071]
[ 24.038071] bcm54xx_config_init
[ 28.038487] xemacps e000b000.ps7-ethernet: Set clk to 124999998 Hz
[ 28.044593] xemacps e000b000.ps7-ethernet: link up (1000/FULL)
This is XILINX board. Totalram: 1039794176
Detect 1GB control board of XILINX
DETECT HW version=0008c510
miner ID : 8118b4c610358854
Miner Type = S9
AsicType = 1387
real AsicNum = 63
use critical mode to search freq...
get PLUG ON=0x000000e0
Find hashboard on Chain[5]
Find hashboard on Chain[6]
Find hashboard on Chain[7]
set_reset_allhashboard = 0x0000ffff
Check chain[5] PIC fw version=0x03
Check chain[6] PIC fw version=0x03
Check chain[7] PIC fw version=0x03
chain[5]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
has freq in PIC, will disable freq setting.
chain[5] has freq in PIC and will jump over...
Chain[5] has core num in PIC
Chain[5] ASIC[15] has core num=5
Check chain[5] PIC fw version=0x03
chain[6]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
has freq in PIC, will disable freq setting.
chain[6] has freq in PIC and will jump over...
Chain[6] has core num in PIC
Chain[6] ASIC[17] has core num=8
Check chain[6] PIC fw version=0x03
chain[7]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
has freq in PIC, will disable freq setting.
chain[7] has freq in PIC and will jump over...
Chain[7] has core num in PIC
Chain[7] ASIC[8] has core num=13
Chain[7] ASIC[9] has core num=11
Chain[7] ASIC[13] has core num=11
Chain[7] ASIC[19] has core num=14
Chain[7] ASIC[30] has core num=6
Chain[7] ASIC[32] has core num=1
Chain[7] ASIC[42] has core num=2
Chain[7] ASIC[55] has core num=1
Chain[7] ASIC[57] has core num=2
Check chain[7] PIC fw version=0x03
get PIC voltage=108 on chain[5], value=880
get PIC voltage=74 on chain[6], value=900
get PIC voltage=108 on chain[7], value=880
set_reset_allhashboard = 0x00000000
chain[5] temp offset record: 62,0,0,0,0,0,35,28
chain[5] temp chip I2C addr=0x98
chain[5] has no middle temp, use special fix mode.
chain[6] temp offset record: 62,0,0,0,0,0,35,28
chain[6] temp chip I2C addr=0x98
chain[6] has no middle temp, use special fix mode.
chain[7] temp offset record: 62,0,0,0,0,0,35,28
chain[7] temp chip I2C addr=0x98
chain[7] has no middle temp, use special fix mode.
set_reset_allhashboard = 0x0000ffff
set_reset_allhashboard = 0x00000000
CRC error counter=0
set command mode to VIL
--- check asic number
After Get ASIC NUM CRC error counter=0
The min freq=700
set real timeout 52, need sleep=379392
After TEST CRC error counter=0
set_reset_allhashboard = 0x0000ffff
set_reset_allhashboard = 0x00000000
search freq for 1 times, completed chain = 3, total chain num = 3
set_reset_allhashboard = 0x0000ffff
set_reset_allhashboard = 0x00000000
restart Miner chance num=2
waiting for receive_func to exit!
waiting for pic heart to exit!
bmminer not found= 1643 root 0:00 grep bmminer
bmminer not found, restart bmminer ...
This is user mode for mining
Detect 1GB control board of XILINX
Miner Type = S9
Miner compile time: Fri Nov 17 17:57:49 CST 2017 type: Antminer S9set_reset_allhashboard = 0x0000ffff
set_reset_allhashboard = 0x00000000
set_reset_allhashboard = 0x0000ffff
miner ID : 8118b4c610358854
set_reset_allhashboard = 0x0000ffff
Checking fans!get fan[2] speed=6120
get fan[2] speed=6120
get fan[2] speed=6120
get fan[2] speed=6120
get fan[2] speed=6120
get fan[2] speed=6120
get fan[5] speed=13440
get fan[2] speed=6120
get fan[5] speed=13440
get fan[2] speed=6120
get fan[5] speed=13440
chain[5]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
Chain[J6] has backup chain_voltage=880
Chain[J6] test patten OK temp=-126
Check chain[5] PIC fw version=0x03
chain[6]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
Chain[J7] has backup chain_voltage=900
Chain[J7] test patten OK temp=-120
Check chain[6] PIC fw version=0x03
chain[7]: [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255] [63:255]
Chain[J8] has backup chain_voltage=880
Chain[J8] test patten OK temp=-125
Check chain[7] PIC fw version=0x03
Chain[J6] orignal chain_voltage_pic=108 value=880
Chain[J7] orignal chain_voltage_pic=74 value=900
Chain[J8] orignal chain_voltage_pic=108 value=880
set_reset_allhashboard = 0x0000ffff
set_reset_allhashboard = 0x00000000
Chain[J6] has 63 asic
Chain[J7] has 63 asic
Chain[J8] has 63 asic
Chain[J6] has core num in PIC
Chain[J6] ASIC[15] has core num=5
Chain[J7] has core num in PIC
Chain[J7] ASIC[17] has core num=8
Chain[J8] has core num in PIC
Chain[J8] ASIC[8] has core num=13
Chain[J8] ASIC[9] has core num=11
Chain[J8] ASIC[13] has core num=11
Chain[J8] ASIC[19] has core num=14
Chain[J8] ASIC[30] has core num=6
Chain[J8] ASIC[32] has core num=1
Chain[J8] ASIC[42] has core num=2
Chain[J8] ASIC[55] has core num=1
Chain[J8] ASIC[57] has core num=2
miner total rate=13999GH/s fixed rate=13500GH/s
read PIC voltage=940 on chain[5]
Chain:5 chipnum=63
Chain[J6] voltage added=0.2V
Chain:5 temp offset=0
Chain:5 base freq=487
Asic[ 0]:618
Asic[ 1]:631 Asic[ 2]:681 Asic[ 3]:618 Asic[ 4]:631 Asic[ 5]:681 Asic[ 6]:618 Asic[ 7]:631 Asic[ 8]:675
Asic[ 9]:618 Asic[10]:631 Asic[11]:681 Asic[12]:631 Asic[13]:637 Asic[14]:606 Asic[15]:487 Asic[16]:637
Asic[17]:675 Asic[18]:618 Asic[19]:637 Asic[20]:675 Asic[21]:631 Asic[22]:650 Asic[23]:687 Asic[24]:631
Asic[25]:537 Asic[26]:687 Asic[27]:631 Asic[28]:587 Asic[29]:687 Asic[30]:612 Asic[31]:650 Asic[32]:687
Asic[33]:631 Asic[34]:650 Asic[35]:687 Asic[36]:631 Asic[37]:662 Asic[38]:693 Asic[39]:631 Asic[40]:662
Asic[41]:662 Asic[42]:543 Asic[43]:668 Asic[44]:693 Asic[45]:568 Asic[46]:675 Asic[47]:700 Asic[48]:631
Asic[49]:568 Asic[50]:700 Asic[51]:631 Asic[52]:625 Asic[53]:700 Asic[54]:631 Asic[55]:675 Asic[56]:662
Asic[57]:631 Asic[58]:662 Asic[59]:687 Asic[60]:631 Asic[61]:681 Asic[62]:700
Chain:5 max freq=700
Chain:5 min freq=487
read PIC voltage=940 on chain[6]
Chain:6 chipnum=63
Chain[J7] voltage added=0.1V
Chain:6 temp offset=0
Chain:6 base freq=687
Asic[ 0]:650
Asic[ 1]:650 Asic[ 2]:650 Asic[ 3]:650 Asic[ 4]:650 Asic[ 5]:650 Asic[ 6]:650 Asic[ 7]:650 Asic[ 8]:650
Asic[ 9]:650 Asic[10]:650 Asic[11]:650 Asic[12]:650 Asic[13]:650 Asic[14]:650 Asic[15]:650 Asic[16]:650
Asic[17]:650 Asic[18]:650 Asic[19]:650 Asic[20]:650 Asic[21]:650 Asic[22]:650 Asic[23]:650 Asic[24]:650
Asic[25]:650 Asic[26]:656 Asic[27]:656 Asic[28]:656 Asic[29]:656 Asic[30]:656 Asic[31]:656 Asic[32]:656
Asic[33]:656 Asic[34]:656 Asic[35]:656 Asic[36]:656 Asic[37]:656 Asic[38]:656 Asic[39]:656 Asic[40]:656
Asic[41]:656 Asic[42]:656 Asic[43]:656 Asic[44]:656 Asic[45]:656 Asic[46]:656 Asic[47]:656 Asic[48]:656
Asic[49]:656 Asic[50]:656 Asic[51]:656 Asic[52]:656 Asic[53]:656 Asic[54]:656 Asic[55]:656 Asic[56]:656
Asic[57]:656 Asic[58]:656 Asic[59]:656 Asic[60]:656 Asic[61]:656 Asic[62]:656
Chain:6 max freq=656
Chain:6 min freq=650
read PIC voltage=940 on chain[7]
Chain:7 chipnum=63
Chain[J8] voltage added=0.2V
Chain:7 temp offset=0
Chain:7 base freq=637
Asic[ 0]:656
Asic[ 1]:656 Asic[ 2]:656 Asic[ 3]:656 Asic[ 4]:656 Asic[ 5]:656 Asic[ 6]:656 Asic[ 7]:656 Asic[ 8]:637
Asic[ 9]:637 Asic[10]:656 Asic[11]:656 Asic[12]:656 Asic[13]:637 Asic[14]:656 Asic[15]:662 Asic[16]:662
Asic[17]:662 Asic[18]:662 Asic[19]:637 Asic[20]:662 Asic[21]:662 Asic[22]:662 Asic[23]:662 Asic[24]:662
Asic[25]:662 Asic[26]:662 Asic[27]:662 Asic[28]:662 Asic[29]:662 Asic[30]:637 Asic[31]:662 Asic[32]:662
Asic[33]:662 Asic[34]:662 Asic[35]:662 Asic[36]:662 Asic[37]:662 Asic[38]:662 Asic[39]:662 Asic[40]:662
Asic[41]:662 Asic[42]:650 Asic[43]:662 Asic[44]:662 Asic[45]:662 Asic[46]:662 Asic[47]:662 Asic[48]:662
Asic[49]:662 Asic[50]:662 Asic[51]:662 Asic[52]:662 Asic[53]:662 Asic[54]:662 Asic[55]:650 Asic[56]:662
Asic[57]:650 Asic[58]:662 Asic[59]:662 Asic[60]:662 Asic[61]:662 Asic[62]:662
Chain:7 max freq=662
Chain:7 min freq=637
Miner fix freq ...
read PIC voltage=940 on chain[5]
Chain:5 chipnum=63
Chain[J6] voltage added=0.2V
Chain:5 temp offset=0
Chain:5 base freq=487
Asic[ 0]:618
Asic[ 1]:631 Asic[ 2]:650 Asic[ 3]:618 Asic[ 4]:631 Asic[ 5]:656 Asic[ 6]:618 Asic[ 7]:631 Asic[ 8]:656
Asic[ 9]:618 Asic[10]:631 Asic[11]:656 Asic[12]:631 Asic[13]:637 Asic[14]:606 Asic[15]:487 Asic[16]:637
Asic[17]:656 Asic[18]:618 Asic[19]:637 Asic[20]:656 Asic[21]:631 Asic[22]:650 Asic[23]:656 Asic[24]:631
Asic[25]:537 Asic[26]:656 Asic[27]:631 Asic[28]:587 Asic[29]:656 Asic[30]:612 Asic[31]:650 Asic[32]:656
Asic[33]:631 Asic[34]:650 Asic[35]:656 Asic[36]:631 Asic[37]:656 Asic[38]:656 Asic[39]:631 Asic[40]:656
Asic[41]:656 Asic[42]:543 Asic[43]:656 Asic[44]:656 Asic[45]:568 Asic[46]:656 Asic[47]:656 Asic[48]:631
Asic[49]:568 Asic[50]:656 Asic[51]:631 Asic[52]:625 Asic[53]:656 Asic[54]:631 Asic[55]:656 Asic[56]:656
Asic[57]:631 Asic[58]:656 Asic[59]:656 Asic[60]:631 Asic[61]:656 Asic[62]:656
Chain:5 max freq=656
Chain:5 min freq=487
read PIC voltage=940 on chain[6]
Chain:6 chipnum=63
Chain[J7] voltage added=0.1V
Chain:6 temp offset=0
Chain:6 base freq=687
Asic[ 0]:631
Asic[ 1]:631 Asic[ 2]:631 Asic[ 3]:631 Asic[ 4]:631 Asic[ 5]:631 Asic[ 6]:631 Asic[ 7]:631 Asic[ 8]:631
Asic[ 9]:631 Asic[10]:631 Asic[11]:631 Asic[12]:631 Asic[13]:631 Asic[14]:631 Asic[15]:631 Asic[16]:631
Asic[17]:631 Asic[18]:631 Asic[19]:631 Asic[20]:631 Asic[21]:631 Asic[22]:631 Asic[23]:631 Asic[24]:631
Asic[25]:631 Asic[26]:631 Asic[27]:631 Asic[28]:631 Asic[29]:631 Asic[30]:631 Asic[31]:631 Asic[32]:631
Asic[33]:631 Asic[34]:631 Asic[35]:637 Asic[36]:637 Asic[37]:637 Asic[38]:637 Asic[39]:637 Asic[40]:637
Asic[41]:637 Asic[42]:637 Asic[43]:637 Asic[44]:637 Asic[45]:637 Asic[46]:637 Asic[47]:637 Asic[48]:637
Asic[49]:637 Asic[50]:637 Asic[51]:637 Asic[52]:637 Asic[53]:637 Asic[54]:637 Asic[55]:637 Asic[56]:637
Asic[57]:637 Asic[58]:637 Asic[59]:637 Asic[60]:637 Asic[61]:637 Asic[62]:637
Chain:6 max freq=637
Chain:6 min freq=631
read PIC voltage=940 on chain[7]
Chain:7 chipnum=63
Chain[J8] voltage added=0.2V
Chain:7 temp offset=0
Chain:7 base freq=637
Asic[ 0]:637
Asic[ 1]:637 Asic[ 2]:637 Asic[ 3]:637 Asic[ 4]:637 Asic[ 5]:637 Asic[ 6]:637 Asic[ 7]:637 Asic[ 8]:637
Asic[ 9]:637 Asic[10]:637 Asic[11]:637 Asic[12]:637 Asic[13]:637 Asic[14]:637 Asic[15]:637 Asic[16]:637
Asic[17]:637 Asic[18]:637 Asic[19]:637 Asic[20]:637 Asic[21]:637 Asic[22]:637 Asic[23]:637 Asic[24]:637
Asic[25]:637 Asic[26]:637 Asic[27]:637 Asic[28]:637 Asic[29]:637 Asic[30]:637 Asic[31]:637 Asic[32]:637
Asic[33]:637 Asic[34]:637 Asic[35]:637 Asic[36]:637 Asic[37]:637 Asic[38]:637 Asic[39]:637 Asic[40]:637
Asic[41]:637 Asic[42]:637 Asic[43]:637 Asic[44]:637 Asic[45]:637 Asic[46]:637 Asic[47]:637 Asic[48]:637
Asic[49]:643 Asic[50]:643 Asic[51]:643 Asic[52]:643 Asic[53]:643 Asic[54]:643 Asic[55]:643 Asic[56]:643
Asic[57]:643 Asic[58]:643 Asic[59]:643 Asic[60]:643 Asic[61]:643 Asic[62]:643
Chain:7 max freq=643
Chain:7 min freq=637
max freq = 656
set baud=1
Chain[J6] PIC temp offset=62,0,0,0,0,0,35,28
chain[5] temp chip I2C addr=0x98
chain[5] has no middle temp, use special fix mode.
Chain[J6] chip[244] use PIC middle temp offset=0 typeID=55
New offset Chain[5] chip[244] local:26 remote:27 offset:29
Chain[J6] chip[244] get middle temp offset=29 typeID=55
Chain[J7] PIC temp offset=62,0,0,0,0,0,35,28
chain[6] temp chip I2C addr=0x98
chain[6] has no middle temp, use special fix mode.
Chain[J7] chip[244] use PIC middle temp offset=0 typeID=55
New offset Chain[6] chip[244] local:26 remote:27 offset:29
Chain[J7] chip[244] get middle temp offset=29 typeID=55
Chain[J8] PIC temp offset=62,0,0,0,0,0,35,28
chain[7] temp chip I2C addr=0x98
chain[7] has no middle temp, use special fix mode.
Chain[J8] chip[244] use PIC middle temp offset=0 typeID=55
New offset Chain[7] chip[244] local:26 remote:28 offset:28
Chain[J8] chip[244] get middle temp offset=28 typeID=55
miner rate=13501 voltage limit=900 on chain[5]
get PIC voltage=880 on chain[5], check: must be < 900
miner rate=13501 voltage limit=900 on chain[6]
get PIC voltage=900 on chain[6], check: must be < 900
miner rate=13501 voltage limit=900 on chain[7]
get PIC voltage=880 on chain[7], check: must be < 900
Chain[J6] set working voltage=880 [108]
Chain[J7] set working voltage=900 [74]
Chain[J8] set working voltage=880 [108]
do heat board 8xPatten for 1 times
start send works on chain[5]
start send works on chain[6]
start send works on chain[7]
get send work num :57456 on Chain[5]
get send work num :57456 on Chain[6]
get send work num :57456 on Chain[7]
wait recv nonce on chain[5]
wait recv nonce on chain[6]
wait recv nonce on chain[7]
get nonces on chain[5]
require nonce number:912
require validnonce number:57456
asic[00]=912 asic[01]=912 asic[02]=912 asic[03]=912 asic[04]=912 asic[05]=912 asic[06]=912 asic[07]=912
asic[08]=912 asic[09]=912 asic[10]=912 asic[11]=912 asic[12]=912 asic[13]=912 asic[14]=912 asic[15]=912
asic[16]=912 asic[17]=912 asic[18]=912 asic[19]=912 asic[20]=912 asic[21]=912 asic[22]=912 asic[23]=912
asic[24]=912 asic[25]=912 asic[26]=912 asic[27]=912 asic[28]=912 asic[29]=912 asic[30]=912 asic[31]=912
asic[32]=912 asic[33]=912 asic[34]=912 asic[35]=912 asic[36]=912 asic[37]=912 asic[38]=912 asic[39]=912
asic[40]=912 asic[41]=912 asic[42]=912 asic[43]=912 asic[44]=912 asic[45]=912 asic[46]=912 asic[47]=912
asic[48]=912 asic[49]=912 asic[50]=912 asic[51]=912 asic[52]=912 asic[53]=912 asic[54]=912 asic[55]=912
asic[56]=912 asic[57]=912 asic[58]=912 asic[59]=912 asic[60]=912 asic[61]=912 asic[62]=912
Below ASIC's core didn't receive all the nonce, they should receive 8 nonce each!
freq[00]=618 freq[01]=631 freq[02]=650 freq[03]=618 freq[04]=631 freq[05]=656 freq[06]=618 freq[07]=631
freq[08]=656 freq[09]=618 freq[10]=631 freq[11]=656 freq[12]=631 freq[13]=637 freq[14]=606 freq[15]=487
freq[16]=637 freq[17]=656 freq[18]=618 freq[19]=637 freq[20]=656 freq[21]=631 freq[22]=650 freq[23]=656
freq[24]=631 freq[25]=537 freq[26]=656 freq[27]=631 freq[28]=587 freq[29]=656 freq[30]=612 freq[31]=650
freq[32]=656 freq[33]=631 freq[34]=650 freq[35]=656 freq[36]=631 freq[37]=656 freq[38]=656 freq[39]=631
freq[40]=656 freq[41]=656 freq[42]=543 freq[43]=656 freq[44]=656 freq[45]=568 freq[46]=656 freq[47]=656
freq[48]=631 freq[49]=568 freq[50]=656 freq[51]=631 freq[52]=625 freq[53]=656 freq[54]=631 freq[55]=656
freq[56]=656 freq[57]=631 freq[58]=656 freq[59]=656 freq[60]=631 freq[61]=656 freq[62]=656
total valid nonce number:57456
total send work number:57456
require valid nonce number:57456
get nonces on chain[6]
require nonce number:912
require validnonce number:57456
asic[00]=912 asic[01]=912 asic[02]=912 asic[03]=912 asic[04]=912 asic[05]=912 asic[06]=912 asic[07]=912
asic[08]=912 asic[09]=912 asic[10]=912 asic[11]=912 asic[12]=912 asic[13]=912 asic[14]=912 asic[15]=912
asic[16]=912 asic[17]=912 asic[18]=912 asic[19]=912 asic[20]=912 asic[21]=912 asic[22]=912 asic[23]=912
asic[24]=912 asic[25]=912 asic[26]=912 asic[27]=912 asic[28]=912 asic[29]=912 asic[30]=912 asic[31]=912
asic[32]=912 asic[33]=912 asic[34]=912 asic[35]=912 asic[36]=912 asic[37]=912 asic[38]=912 asic[39]=912
asic[40]=912 asic[41]=912 asic[42]=912 asic[43]=912 asic[44]=912 asic[45]=912 asic[46]=912 asic[47]=912
asic[48]=912 asic[49]=912 asic[50]=912 asic[51]=912 asic[52]=912 asic[53]=912 asic[54]=912 asic[55]=912
asic[56]=912 asic[57]=912 asic[58]=912 asic[59]=912 asic[60]=912 asic[61]=912 asic[62]=912
Below ASIC's core didn't receive all the nonce, they should receive 8 nonce each!
freq[00]=631 freq[01]=631 freq[02]=631 freq[03]=631 freq[04]=631 freq[05]=631 freq[06]=631 freq[07]=631
freq[08]=631 freq[09]=631 freq[10]=631 freq[11]=631 freq[12]=631 freq[13]=631 freq[14]=631 freq[15]=631
freq[16]=631 freq[17]=631 freq[18]=631 freq[19]=631 freq[20]=631 freq[21]=631 freq[22]=631 freq[23]=631
freq[24]=631 freq[25]=631 freq[26]=631 freq[27]=631 freq[28]=631 freq[29]=631 freq[30]=631 freq[31]=631
freq[32]=631 freq[33]=631 freq[34]=631 freq[35]=637 freq[36]=637 freq[37]=637 freq[38]=637 freq[39]=637
freq[40]=637 freq[41]=637 freq[42]=637 freq[43]=637 freq[44]=637 freq[45]=637 freq[46]=637 freq[47]=637
freq[48]=637 freq[49]=637 freq[50]=637 freq[51]=637 freq[52]=637 freq[53]=637 freq[54]=637 freq[55]=637
freq[56]=637 freq[57]=637 freq[58]=637 freq[59]=637 freq[60]=637 freq[61]=637 freq[62]=637
total valid nonce number:57456
total send work number:57456
require valid nonce number:57456
get nonces on chain[7]
require nonce number:912
require validnonce number:57456
asic[00]=912 asic[01]=912 asic[02]=912 asic[03]=912 asic[04]=912 asic[05]=912 asic[06]=912 asic[07]=912
asic[08]=907 asic[09]=912 asic[10]=912 asic[11]=912 asic[12]=912 asic[13]=912 asic[14]=912 asic[15]=912
asic[16]=912 asic[17]=912 asic[18]=912 asic[19]=909 asic[20]=912 asic[21]=912 asic[22]=912 asic[23]=912
asic[24]=912 asic[25]=912 asic[26]=912 asic[27]=912 asic[28]=912 asic[29]=912 asic[30]=912 asic[31]=912
asic[32]=912 asic[33]=912 asic[34]=912 asic[35]=912 asic[36]=912 asic[37]=912 asic[38]=912 asic[39]=912
asic[40]=912 asic[41]=912 asic[42]=912 asic[43]=912 asic[44]=912 asic[45]=912 asic[46]=912 asic[47]=912
asic[48]=912 asic[49]=912 asic[50]=912 asic[51]=912 asic[52]=912 asic[53]=912 asic[54]=912 asic[55]=911
asic[56]=912 asic[57]=912 asic[58]=912 asic[59]=912 asic[60]=912 asic[61]=912 asic[62]=912
Below ASIC's core didn't receive all the nonce, they should receive 8 nonce each!
core[049]=7 core[053]=5 core[056]=7
core[064]=7 core[112]=6
freq[00]=637 freq[01]=637 freq[02]=637 freq[03]=637 freq[04]=637 freq[05]=637 freq[06]=637 freq[07]=637
freq[08]=637 freq[09]=637 freq[10]=637 freq[11]=637 freq[12]=637 freq[13]=637 freq[14]=637 freq[15]=637
freq[16]=637 freq[17]=637 freq[18]=637 freq[19]=637 freq[20]=637 freq[21]=637 freq[22]=637 freq[23]=637
freq[24]=637 freq[25]=637 freq[26]=637 freq[27]=637 freq[28]=637 freq[29]=637 freq[30]=637 freq[31]=637
freq[32]=637 freq[33]=637 freq[34]=637 freq[35]=637 freq[36]=637 freq[37]=637 freq[38]=637 freq[39]=637
freq[40]=637 freq[41]=637 freq[42]=637 freq[43]=637 freq[44]=637 freq[45]=637 freq[46]=637 freq[47]=637
freq[48]=637 freq[49]=643 freq[50]=643 freq[51]=643 freq[52]=643 freq[53]=643 freq[54]=643 freq[55]=643
freq[56]=643 freq[57]=643 freq[58]=643 freq[59]=643 freq[60]=643 freq[61]=643 freq[62]=643
total valid nonce number:57447
total send work number:57456
require valid nonce number:57456
chain[5]: All chip cores are opened OK!
Test Patten on chain[5]: OK!
chain[6]: All chip cores are opened OK!
Test Patten on chain[6]: OK!
chain[7]: All chip cores are opened OK!
Test Patten on chain[7]: OK!
setStartTimePoint total_tv_start_sys=217 total_tv_end_sys=218
restartNum = 2 , auto-reinit enabled...
do read_temp_func once...
do check_asic_reg 0x08
get RT hashrate from Chain[5]: (asic index start from 1-63)
Asic[01]=72.5110 Asic[02]=68.6020 Asic[03]=74.4230 Asic[04]=74.6750 Asic[05]=71.4540 Asic[06]=77.5610 Asic[07]=74.7760 Asic[08]=74.3900
Asic[09]=77.7790 Asic[10]=76.7220 Asic[11]=73.8020 Asic[12]=68.5850 Asic[13]=76.1680 Asic[14]=72.4770 Asic[15]=73.0470 Asic[16]=57.8810
Asic[17]=74.4740 Asic[18]=76.4530 Asic[19]=67.8800 Asic[20]=70.1280 Asic[21]=73.7520 Asic[22]=74.6580 Asic[23]=73.6850 Asic[24]=78.5170
Asic[25]=73.6850 Asic[26]=63.6860 Asic[27]=80.9660 Asic[28]=73.9200 Asic[29]=68.9870 Asic[30]=75.6310 Asic[31]=74.9770 Asic[32]=69.4570
Asic[33]=74.6580 Asic[34]=79.8930 Asic[35]=76.6710 Asic[36]=74.3730 Asic[37]=66.6050 Asic[38]=76.7380 Asic[39]=71.4540 Asic[40]=69.3060
Asic[41]=72.5610 Asic[42]=73.8530 Asic[43]=58.9210 Asic[44]=75.3800 Asic[45]=73.1310 Asic[46]=68.4000 Asic[47]=77.6780 Asic[48]=73.1150
Asic[49]=69.2890 Asic[50]=62.8130 Asic[51]=74.2720 Asic[52]=73.1480 Asic[53]=67.4440 Asic[54]=72.4940 Asic[55]=68.1990 Asic[56]=72.4100
Asic[57]=75.3460 Asic[58]=66.1350 Asic[59]=72.9800 Asic[60]=78.1480 Asic[61]=72.3260 Asic[62]=72.5610 Asic[63]=77.7950
get RT hashrate from Chain[6]: (asic index start from 1-63)
Asic[01]=67.6620 Asic[02]=75.9840 Asic[03]=70.3300 Asic[04]=75.5640 Asic[05]=62.8470 Asic[06]=70.2790 Asic[07]=74.5240 Asic[08]=72.9130
Asic[09]=70.6320 Asic[10]=72.5610 Asic[11]=73.9370 Asic[12]=77.3420 Asic[13]=72.4440 Asic[14]=68.8030 Asic[15]=73.0810 Asic[16]=73.8360
Asic[17]=73.5510 Asic[18]=73.9700 Asic[19]=71.0340 Asic[20]=71.1680 Asic[21]=72.1580 Asic[22]=78.8190 Asic[23]=71.9230 Asic[24]=69.4570
Asic[25]=67.7630 Asic[26]=71.7220 Asic[27]=76.4030 Asic[28]=71.1180 Asic[29]=68.7360 Asic[30]=69.7090 Asic[31]=77.5610 Asic[32]=70.1790
Asic[33]=67.9140 Asic[34]=72.3930 Asic[35]=64.5920 Asic[36]=72.1920 Asic[37]=74.6080 Asic[38]=75.4470 Asic[39]=73.8700 Asic[40]=73.9370
Asic[41]=66.2860 Asic[42]=79.4230 Asic[43]=75.8160 Asic[44]=68.6350 Asic[45]=74.7920 Asic[46]=70.7990 Asic[47]=71.2360 Asic[48]=73.8700
Asic[49]=66.5380 Asic[50]=70.6150 Asic[51]=72.6280 Asic[52]=75.7490 Asic[53]=71.8400 Asic[54]=76.5370 Asic[55]=73.5340 Asic[56]=69.2390
Asic[57]=75.1280 Asic[58]=74.3230 Asic[59]=73.4330 Asic[60]=72.3430 Asic[61]=77.6780 Asic[62]=82.4600 Asic[63]=69.5240
get RT hashrate from Chain[7]: (asic index start from 1-63)
Asic[01]=73.5510 Asic[02]=75.9160 Asic[03]=80.1110 Asic[04]=76.9900 Asic[05]=76.1510 Asic[06]=73.5170 Asic[07]=74.9940 Asic[08]=73.1150
Asic[09]=70.6650 Asic[10]=70.6990 Asic[11]=72.4770 Asic[12]=70.1450 Asic[13]=74.3060 Asic[14]=71.8060 Asic[15]=74.7420 Asic[16]=75.6650
Asic[17]=76.8220 Asic[18]=69.5240 Asic[19]=72.0910 Asic[20]=75.2620 Asic[21]=72.0240 Asic[22]=73.2660 Asic[23]=76.2690 Asic[24]=69.9440
Asic[25]=67.7290 Asic[26]=71.7050 Asic[27]=74.6250 Asic[28]=78.2320 Asic[29]=69.8430 Asic[30]=68.4670 Asic[31]=71.5210 Asic[32]=68.9540
Asic[33]=74.6250 Asic[34]=71.8730 Asic[35]=74.4400 Asic[36]=74.8760 Asic[37]=73.9030 Asic[38]=72.9300 Asic[39]=69.6250 Asic[40]=74.9430
Asic[41]=72.7620 Asic[42]=69.4910 Asic[43]=67.4270 Asic[44]=71.4870 Asic[45]=74.4570 Asic[46]=66.6550 Asic[47]=67.5450 Asic[48]=75.4800
Asic[49]=72.2590 Asic[50]=72.9300 Asic[51]=75.6820 Asic[52]=71.9070 Asic[53]=67.9640 Asic[54]=67.8470 Asic[55]=74.3900 Asic[56]=71.0010
Asic[57]=75.8490 Asic[58]=74.9270 Asic[59]=72.3930 Asic[60]=74.3730 Asic[61]=75.5310 Asic[62]=73.8190 Asic[63]=72.4440
Check Chain[J6] ASIC RT error: (asic index start from 1-63)
Check Chain[J7] ASIC RT error: (asic index start from 1-63)
Check Chain[J8] ASIC RT error: (asic index start from 1-63)
Done check_asic_reg
do read temp on Chain[5]
Chain[5] Chip[62] TempTypeID=55 middle offset=29
Chain[5] Chip[62] local Temp=60
Chain[5] Chip[62] middle Temp=70
Special fix Chain[5] Chip[62] middle Temp = 75
Done read temp on Chain[5]
do read temp on Chain[6]
Chain[6] Chip[62] TempTypeID=55 middle offset=29
Chain[6] Chip[62] local Temp=60
Chain[6] Chip[62] middle Temp=72
Special fix Chain[6] Chip[62] middle Temp = 75
Done read temp on Chain[6]
do read temp on Chain[7]
Chain[7] Chip[62] TempTypeID=55 middle offset=28
Chain[7] Chip[62] local Temp=62
Chain[7] Chip[62] middle Temp=72
Special fix Chain[7] Chip[62] middle Temp = 77
Done read temp on Chain[7]
set FAN speed according to: temp_highest=62 temp_top1[PWM_T]=62 temp_top1[TEMP_POS_LOCAL]=62 temp_change=0 fix_fan_steps=0
read_temp_func Done!
CRC error counter=0
submitted by Timsierramist to BitcoinMining [link] [comments]

Solved Vulkan-1.dll missing error solution 2020 Programmation réseau - ép. 4 - ping-pong et SO_TIMEOUT (Université Paris Diderot) gRPC Deadline Vs REST HTTP timeout (Explained) SF Linkerd Meetup - REST to gRPC with Linkerd Learn JSON in 10 Minutes

Python interface to bitcoin's JSON-RPC API. Contribute to jgarzik/python-bitcoinrpc development by creating an account on GitHub. A new RPC command preciousblock has been added which marks a block as precious. A precious block will be treated as if it were received earlier than a competing block. A new RPC command importmulti has been added which receives an array of JSON objects representing the intention of importing a public key, a private key, an address and script/p2sh Bitcoin Core installation binaries can be downloaded from and the Existing wallets can be loaded by calling the loadwallet RPC. The wallet can be specified (“Do not make it trivial for inbound peers to generate log entries”) to include “version handshake timeout” message (clemtaylor) #12218 9a32114 Move How to Do RPC Calls with C++ Bitcoind . bitcoin deamon = core value of the software (bitcoind -printtoconsole -debug=1) Bitcoind provide the RPC "interface" in which user can query with bitcoin-cli (or a library in c++). You must run bitcoind before using bitcoin-cli. $ ./bitcoind -daemon bitcoin server starting $ ./bitcoin-cli -rpcwait help # shows the help text A list of RPC calls will be shown. $ ./bitcoin-cli getbalance 2000.00000 If you are learning the API, it is a very good idea to use the test network (run bitcoind -testnet and bitcoin-cli -testnet). JSON-RPC

[index] [3372] [11736] [461] [17619] [1862] [27777] [7758] [28373] [20336] [10817]

Solved Vulkan-1.dll missing error solution 2020

On the server side, the server can query to see if a particular RPC has timed out, or how much time is left to complete the RPC. Specifying a deadline or timeout is language specific: some ... In this video we will cover everything you need to know about JSON in only 10 minutes. We will cover what JSON is, why JSON is important, what JSON is used for, the syntax of JSON, and multiple ... Fix Entry Point Not Found The Procedure Entry Point Could Not Be Located The Dynamic Link Library - Duration: 3:45. MK TECH 28,864 views How To Pay Off Your Mortgage Fast Using Velocity Banking How To Pay Off Your Mortgage In 5-7 Years - Duration: 41:34. Think Wealthy with Mike Adams Recommended for you Comment pallier au mode bloquant dans le cadre général d'une transmission non-fiable (SO_TIMEOUT) ? Une vidéo de Jean-Baptiste Yunès (Université Paris Diderot). Plus d'informations : http ...

Flag Counter