Fully responsive mobile design, including connected nodes table
Simple file-based cache system to limit RPC calls
Can bypass the file-based cache system entirely. Please note that this could overload your Bitcoind with RPC calls, please use with caution!
IP-based whitelist for clearing/bypassing the file-based cache
Displays free disk space
Can either display the node's IP address via the PHP $_SERVER variable, or from the Bitcoin Daemon
Generates and displays a donation QR code for donations
Display if the node is running on testnet
Display the currently running Bitcoind version
Optionally display the remote port when listing connected peers.
Ships with two different CSS styles - "light" (default) and "dark" (viewable on my demo)
Includes an optional "Fork me on GitHub" ribbon (toggleable via config.php, enabled by default) - I'd really appreciate it if everyone could keep the ribbon enabled to try and boost exposure for the code :)
Compatability Tested with PHP 5.4, 5.5 and 5.6 as well as HHVM and Nightly builds. Contributions Please feel free to comment, suggest (or better still, contribute!) new features or improvements. Tips (via changetip) are also graciously accepted!
This was posted a few months back, but after making a few changes and improvements thought it was worth posting again. TL;DR - thought it would be cool to be able to show off the status of my Bitcoin nodes to the world, so I wrote this project to do just that. Live Demos:Tyr | Thor | Odin Code:GitHub | Travis CI (Testing) Features The project has grown substantially since it was first released, and a lot of pretty neat features have been added at the request of the community. If you feel the script could do with some extra functionality, please do feel free to suggest it or even contribute it.
Communicates with the Bitcoin node via RPC, with optional SSL configuration
Fully responsive mobile design, including connected nodes table
Simple file-based cache system to limit RPC calls (can be bypassed - use with caution!)
IP-based whitelist for clearing/bypassing the cache
Generates and displays a QR code for donations, and displays a customisable wallet address so that users can contribute and say thanks for your node
Extremely easy to skin and customise - ships with two different CSS styles - "light" (default) and "dark"
Includes an optional "Fork me on GitHub" ribbon
Information Display All of the below information is optional and can be disabled via the script's configuration file:
Node IP address - via the PHP $_SERVER variable, or from the Bitcoin Daemon's RPC output
List of connected nodes (both IPv4 and IPv6) and optionally remote ports
Geolocation of the node and peer IP addresses
Can also hide "dark" peers
Bitcoin daemon version and uptime
Node free disk space
Compatability The PHP code has been tested with PHP 5.4, 5.5 and 5.6 as well as HHVM and Nightly builds, and the script can be modified to run against any node that uses the same RPC engine as Bitcoin - this includes Litecoin, and most Altcoins. Contributions Please feel free to comment, suggest (or better still, contribute!) new features or improvements - tips are also graciously accepted via changetip.
Bitcoin Puppet Module & PHP Status Page Updated for Classic
Cross-posted from /Bitcoin_Classic, for info. I've just updated my Puppet module for installing/configuring Bitcoind to optionally use the Classic PPA on Ubuntu. To use Bitcoin Classic over Bitcoin Core, simply set the use_bitcoin_classic parameter to true - the default is to install Bitcoin Core. You can also migrate from Bitcoin Core to Classic and vice versa using this module. To do this, the module stops the bitcoind service and removes the bitcoind package, before placing the correct PPA and installing the bitcoind package again. Code: GitHub | Puppet Forge Also, my PHP status page has been updated to show full version (i.e. Satoshi, Classic) rather than a plain numeric version - for full feature-list, check out this on Bitcoin. Code: GitHub My nodes (all 24x7): Tyr | Thor | Odin
Bitcoin Puppet Module & PHP Status Page Updated for Classic
I've just updated my Puppet module for installing/configuring Bitcoind to optionally use the Classic PPA on Ubuntu. To use Bitcoin Classic over Bitcoin Core, simply set the use_bitcoin_classic parameter to true - the default is to install Bitcoin Core. You can also migrate from Bitcoin Core to Classic and vice versa using this module. To do this, the module stops the bitcoind service and removes the bitcoind package, before placing the correct PPA and installing the bitcoind package again. Code: GitHub | Puppet Forge Also, my PHP status page has been updated to show full version (i.e. Satoshi, Classic) rather than a plain numeric version - for full feature-list, check out this on Bitcoin. Code: GitHub My nodes (all 24x7): Tyr | Thor | Odin
I created Bitcoin Node Stats, a simple web app to log and view node statistics and status. Would like feedback on first demo version.
Demo: http://bitcoinnodestats.romgens.com I created a proof of concept of a simple Bitcoin Node Stats web app. It stores raw node status every n minutes. Time plots are generated from this data. See demo in link on top. This is just a small hobby project using Django, python-bitcoinlib, and D3js. You can find it on GitHub: https://github.com/bartromgens/bitcoinnodestats Any and all feedback is welcome! There are other node stats projects, such as http://statoshi.info, that have more features, and are much mature. bitcoinnodestats does not try to compete :) However, these are not always easy to install, or lose all data after a node restart. So there may be room for a simple Python/Django version.
There's a topic mourning the death of full nodes over on /r/Bitcoin. What's our status on incorporating a node-donor feature into the client?
As you know, I believe that if we don't incentivize something so fundamental, we will encounter a tragedy of the commons. This is precisely the situation bitcoin finds itself in today as the number of full nodes drop because people have no selfish incentive to run one. People will not mine out of the goodness of their heart, so it's silly to think they will run full nodes out of the goodness of their heart. ("it's OK, someone else will take care of it") I believe the most reasonable proposal presented last time we discussed this was a donation feature whereby anyone could donate and it would either be split amongst everyone running full nodes, or possibly distributed in a lottery type fashion. Not understanding the guts of the software as much as some of you, how radical would this be to implement? Is this something trivial to tack on, or is it a Pandora's box? It would be a fun bragging right to be able to say that Monero compensates full nodes without resorting to Proof of Stake. There is further discussion on the matter happening in a Technical topic over on bitcointalk.org: https://bitcointalk.org/index.php?topic=1185231.0;topicseen
Sure-fire cure for obsession with price/investment status: get involved in a serious way and run a full bitcoin node
Install bitcoind, open port 8333 on your router, and go to town. I've been doing this for a couple of months and it makes me really happy each time I type "bitcoind getinfo" and see a bunch of connections.
https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/184.108.40.206 Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that. Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap. We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout. Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.
Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now. Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date. The transition height is also when the team requirement will be relaxed for the network.
Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.
The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use. There are so many goodies here it is hard to summarize them all. I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures. The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!
Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.
Network magnitude unit pinned to a static value of 0.25
Max research reward allowed per block raised to 16384 GRC (from 12750 GRC)
New CPIDs begin accruing research rewards from the first superblock that contains the CPID instead of from the time of the beacon advertisement
500 GRC research reward limit for a CPID's first stake
6-month expiration for unclaimed rewards
10-block spacing requirement between research reward claims
Rolling 5-day payment-per-day limit
Legacy tolerances for floating-point error and time drift
The need to include a valid copy of a CPID's magnitude in a claim
10-block emission adjustment interval for the magnitude unit
One-time beacon activation requires that participants temporarily change their usernames to a verification code at one whitelisted BOINC project
Verification codes of pending beacons expire after 3 days
Self-service beacon removal
Burn fee for beacon advertisement increased from 0.00001 GRC to 0.5 GRC
Rain addresses derived from beacon keys instead of a default wallet address
Beacon expiration determined as of the current block instead of the previous block
The ability for developers to remove beacons
The ability to sign research reward claims with non-current but unexpired beacons
As a reminder:
Beacons expire after 6 months pass (180 days)
Beacons can be renewed after 5 months pass (150 days)
Renewed beacons must be signed with the same key as the original beacon
Magnitudes less than 1 include two fractional places
Magnitudes greater than or equal to 1 but less than 10 include one fractional place
A valid superblock must match a scraper convergence
Superblock popularity election mechanics
Yes/no/abstain and single-choice response types (no user-facing support yet)
To create a poll, a maximum of 250 UTXOs for a single address must add up to 100000 GRC. These are selected from the largest downwards.
Burn fee for creating polls scaled by the number of UTXOs claimed
50 GRC for a poll contract
0.001 GRC per claimed UTXO
Burn fee for casting votes scaled by the number of UTXOs claimed
0.01 GRC for a vote contract
0.01 GRC to claim magnitude
0.01 GRC per claimed address
0.001 GRC per claimed UTXO
Maximum length of a poll title: 80 characters
Maximum length of a poll question: 100 characters
Maximum length of a poll discussion website URL: 100 characters
Maximum number of poll choices: 20
Maximum length of a poll choice label: 100 characters
Magnitude, CPID count, and participant count poll weight types
The ability for developers to remove polls and votes
[220.127.116.11] 2020-09-03, mandatory, "Fern"
Backport newer uint256 types from Bitcoin #1570 (@cyrossignol)
Implement project level rain for rainbymagnitude #1580 (@jamescowens)
Upgrade utilities (Update checker and snapshot downloadeapplication) #1576 (@iFoggz)
Provide fees collected in the block by the miner #1601 (@iFoggz)
Add support for generating legacy superblocks from scraper stats #1603 (@cyrossignol)
Port of the Bitcoin Logger to Gridcoin #1600 (@jamescowens)
Implement zapwallettxes #1605 (@jamescowens)
Implements a global event filter to suppress help question mark #1609 (@jamescowens)
Add next target difficulty to RPC output #1615 (@cyrossignol)
Add caching for block hashes to CBlock #1624 (@cyrossignol)
Make toolbars and tray icon red for testnet #1637 (@jamescowens)
Add an rpc call convergencereport #1643 (@jamescowens)
Implement newline filter on config file read in #1645 (@jamescowens)
Implement beacon status icon/button #1646 (@jamescowens)
Add gridcointestnet.png #1649 (@caraka)
Add precision to support magnitudes less than 1 #1651 (@cyrossignol)
Replace research accrual calculations with superblock snapshots #1657 (@cyrossignol)
Publish example gridcoinresearch.conf as a md document to the doc directory #1662 (@jamescowens)
Add options checkbox to disable transaction notifications #1666 (@jamescowens)
Add support for self-service beacon deletion #1695 (@cyrossignol)
Add support for type-specific contract fee amounts #1698 (@cyrossignol)
Add verifiedbeaconreport and pendingbeaconreport #1696 (@jamescowens)
Add preliminary testing option for block v11 height on testnet #1706 (@cyrossignol)
Add verified beacons manifest part to superblock validator #1711 (@cyrossignol)
Implement beacon, vote, and superblock display categories/icons in UI transaction model #1717 (@jamescowens)
Disclaimer: This is sort of my own arbitrary editing, so there could be some misunderstandings. I root for the spread of good spirits and transparency of IF. 📷 Hans Moog [IF]어제 오후 2:45 So why don't we just copy Avalanche? Well that's pretty simple ... 📷 Hans Moog [IF]어제 오후 2:47 1. It doesn't scale very well with the amount of nodes in the network that have no say in the consensus process but are merely consensus consuming nodes(i.e. sensors, edge devices and so on). If you assume that the network will never have more than a few thousand nodes then thats fine butif you want to build a DLT that can cope with millions of devices then it wont work because of the message complexity. 2. If somebody starts spamming conflicts, then the whole network will stop to confirm any transactions and will grind to a halt until the conflict spamming stops.Avalanche thinks that this is not a huge problem because an attacker would have to spend fees for spamming conflicts which means that he couldn't do this forever and would at some point run out of funds. IOTA tries to build a feeless protocol and a consensus that stops to function if somebody spams conflicts is really not an option for us. 3. If a medium sized validator goes offline due to whatever reason, then the whole network will again stop to confirm any transactionsbecause whenever a query for a nodes opinion can not be answered they reset the counter for consecutive successful voting rounds which will prevent confirmations. Since nodes need to open some ports to be available for queries it is super easy to DDOS validators and again bring the network confirmations to 0. 📷 Hans Moog [IF]어제 오후 3:05 4. Avalanche still processes transactions in "chunks/blocks"by only applying them after they have gone through some consensus process (gathered enough successfull voting rounds),which means that the nodes will waste a significant amount of time where they "wait" for the next chunk to be finished before the transactions are applied to the ledger state. IOTA tries to streamline this process by decoupling consensus and the booking of transactions by using the "parallel reality based ledger state" which means that nodes in IOTA will never waste any time "waiting" for decisions to be made. This will give us much higher throughput numbers. 📷 Hans Moog [IF]어제 오후 3:11 5. Avalanche has some really severe game theoretic problems where nodes are incentivized to attach their transactions to the already decided parts of the DAG because then things like conflict spam won't affect these transactions as badly as the transactions issued by honest nodes.If however every node would follow this "better and selfish" tip selection mechanism then the network will stop to work at all. Overall the "being able to stop consensus" might not be too bad since you can't really do anything really bad (i.e. double spend) which is why we might not see these kind of attacks in the immediate future but just wait until a few DeFi apps are running on their platform where smart contracts are actually relying on more or less real time execution of the contracts. Then there might be some actual financial gains to be made if the contract halts and we might see alot of these things appear (including selfish tip selection). Avalanche is barely a top 100 project and nobody attacks these kind of low value networks unless there is something to be gained from such an attack. Saying that the fact that its live on mainnet and hasn't been attacked in 3 weeks is a proof for its security is completely wrong. Especially considering that 95% of all stake are controlled by avalanche itself If you control > 50% of the voting power then you essentially control the whole network and attacks can mostly be ignored I guess there is a reason for avalanche only selling 10% of the token supply to the public because then some of the named problems are less likely to appear 📷 Navin Ramachandran [IF]어제 오후 3:21 I have to say that wtf's suggestion is pretty condescending to all our researchers. It seems heavy on the troll aspect to suggest that we should ditch all our work because iota is only good at industrial adoption. Does wtf actually expect a response to this? Or is this grand standing? 📷 Hans Moog [IF]어제 오후 3:22 The whole argument of "why don't you just use X instead of trying to build a better version" is also a completely idiotic argument. Why did ETH write their own protocol if Bitcoin was already around? Well because they saw problems in Bitcoins approach and tried to improve it. 📷 Hans Moog [IF]어제 오후 3:27 u/NavinRamachandran [IF] Its like most of his arguments ... remember when he said we should implement colored coins in 2nd layer smart contracts instead of the base layer because they would be more expressive (i.e. turing complete) completely discarding that 2nd layer smart contracts only really work if you have a consensus on data and therefore state for which you need the "traceability" of funds to create these kind of mini blockchains in the tangle? Colored coins "enable" smart contracts and it wouldnt work the other way round - unless you have a platform that works exactly like ETH where all the nodes validate a single shared execution platform of the smart contracts which is not really scalable and is exactly what we are trying to solve with our approach. 📷 Navin Ramachandran [IF]어제 오후 3:28 Always easier to criticise than build something yourself. But yet he keeps posting these inflammatory posts. At this point is there any doubt if he is making these comments constructively? 📷 Hans Moog [IF]어제 오후 3:43 If he at least would try to understand IOTAs vision ... then maybe he wouldn't have to ask things like "Why don't you just copy a tech that only works with fees" 📷 Hans Moog [IF]어제 오후 4:35 u/Shaar
I thought this would only be used to 'override' finality, eg if there were network splits. But not in normal consensus
That is not correct. Every single transaction gets booked on arrival using the parallel reality based ledger state. If there are conflicts then we create a "branch" (container in the ledger state) that represents the perception that this particular double spend would be accepted by consensus. After consensus is reached, the container is simply marked as "accepted" and all transactions that are associated with this branch are immediately confirmed as well. This allows us to make the node use all of its computing ressources 24/7 without having to wait for any kind of decision to be made and allows us to scale the throughput to its physical limits. That's the whole idea of the "parallel reality based ledger state" instead of designing a data structure that models the ledger state "after consensus" like everybody else is doing it is tailored to model the ledger state "before consensus" and then you just flip a flag to persist your decision. The "resync mechanism" also uses the branches to measure the amount of approval a certain perception of the ledger state receives. So if my own opinion is not in line with what the rest of the network has accepted (i.e. because I was eclipsed or because there was a network split), then I can use the weight of these branches to detect this "being out of sync" and can do another larger query to re-evaluate my decision.(수정됨)
Also what happens in IOTA if DRNG notes would fall out, does the network continue if no new RNGs appear for a while? Or will new nodes be added sufficiently fast to the DRNG committee that no one notices?
Its a comittee and not just a single DRNG provider. If a few nodes fail then it will still produce random numbers. And even if the whole comittee fails there are fallback RNG's that would be used instead 📷 Hans Moog [IF]어제 오후 4:58 And multiverse doesn't use FPC but only the weight of these branches in the same way as blockchain uses the longest chain wins consensus to choose between conflicts. So nodes simply attach their transactions to the transactions that they have seen first and if there are conflicts then you simply monitor which version received more approval and adjust your opinion accordingly. 📷 Hans Moog [IF]어제 오후 5:07 We started integrating some of the non-controversial concepts (like the approval reset switch) into FPC and are currently refactoring goshimmer to support this We are also planning to make the big mana holders publish their opinion in the tangle as a public statement, which allows us to measure the rate of approval in a similar way as multiverse would do it So its starting to converge a bit but we are still using FPC as a metastability breaking mechanism Once the changes are implemented it should be pretty easy to simulate and test both approaches in parallel 📷 Serguei Popov [IF]어제 오후 5:53
So the ask is that we ditch all our work and fork Avalanche because it has not been attacked in the month or so it has been up?
u/NavinRamachandran [IF] yeah, that's hilarious. Avalanche consensus (at least their WP version) is clearly scientifically unsound. 📷 Hans Moog [IF]어제 오후 9:43 u/wtfmaybe you should research avalanche before proposing such a stupid idea and you will see that what I wrote is actually true 📷 Hans Moog [IF]어제 오후 9:44 paying fees is what "protects" them atm and simply the fact that nobody uses the network for anything of value yet we cant rely on fees making attack vectors "inattractive" 📷 Serguei Popov [IF]어제 오후 10:17
well (1.) very obviously the metastability problems are not a problem in practice,
putting "very obviously" before questionable statements very obviously shows that you are seeking a constructive dialogue📷(to make metastability work, the adversary needs to more-or-less know the current opinion vectors of most of the honest participants; I don't see why a sufficiently well-connected adversary cannot query enough honest nodes frequently enough to achieve that)
(2.) .... you'd need an unpredictable number every few tens/hundreds milliseconds, but your DRNG can only produce one every O(seconds).
the above assumption (about "every few tens/hundreds milliseconds") is wrong
We've had this discussion before, where you argued that the assumptions in the FPC-BI paper (incl. "all nodes must be known") are not to be taken 100% strictly, and that the results are to be seen more of an indication of overall performance.
Aham, I see. So, unfortunately, all that time that I invested into explaining that stuff during our last conversation was for nothing. Again, very briefly. The contents of the FPC-BI paper is not "an indication of overall performance". It rather shows (to someone who actually read and understood the paper) why the approach is sound and robust, as it makes one understand what is the mechanism that causes the consensus phenomenon occur.
Yet you don't allow for that same argument to be valid for the "metastability" problem in avalanche,
Incorrect. It's not "that same argument". FPC-BI is a decent academic paper that has precisely formulated results and proofs. The Ava WP (the probabilistic part of it), on the other hand, doesnotcontain proofs of what they call results. More importantly, they don't even show a clear path to those proofs. That's why their system is scientifically unsound.
even when there's a live network that shows that it doesn't matter.
No, it doesn't show that it doesn't matter. It only shows that it works when not properly attacked. Their WP doesn't contain any insight on why those attacks would be difficult/impossible. 📷 Hans Moog [IF]어제 오후 10:56 That proposal was so stupid - Avalanche does several things completely different and we are putting quite a bit og effort into our solution to pretty much fix all of Avalanches shortcomings If we just wanted to have a working product and dont care about security or performance then we could have just forked a blockchaib I am pretty confident that once we are done - its going to be extremely close to the besttheoretical thresholds that DLTs will ever be able to achieve for an unsharded baselayer ------------------------------------------------------------------------------------------------------------- 📷 Bas어제 오전 2:43 Yesterday I was asked how a reasonably big company no one has heard of could best move forward implementing Access for thousands of locations worldwide. (Sorry for the vagueness, it’s all confidential.) They read the article and want to implement it because it seems to fit a problem they’re currently trying to solve. Such moves will vastly increase the utility of protocols like IOTA, and is what the speculation is built on. I do not think you can overestimate what impact Access is going to have. It’s cutting out the middleman for simple things; no server or service needed. That’s huge. So yes, I think this space will continue to growu/Coinnave -------------------------------------------------------------------------------------------------------------- 📷 Angelo Capossele [IF]2020.10.02. In short: we are planning a new v0.3.0 release that should happen very soon. This version will bring fundamental changes to the structure of the entire codebase (but without additional features) so that progressing with the development will be easier and more consistent. We have also obtained outstanding results with the dRNG committee managed by the GoShimmer X-Team, so that will also be integral part of v0.3.0. After that, we will merge the Value Tangle with the Message Tangle, so to have only one Tangle and make the TSA and the orphanage easier to manage. And we are also progressing really well with Mana, that will be the focus after the merge. More or less this is what is going to happen this month. We will release further details with the upcoming Research Status Update📷
PSA: Enable Tor as a simple way to make your node reachable.
Become one of the 10% of node operators that receive incoming connections. Installing bitcoin core is easy, and with pruning it really isn't the space sink it is characterized as. Even a modest computer can complete the initial block download (IBD) and become a full node. But what some users (90%) find a bit more challenging, is how to become a listening node. Listening nodes are an important part of the network, and are simple enough to enable. I can think of 4 ways to do it:
Operate on an OS and Network that support uPnP, allowing bitcoin to open the ports for you.
Subscribe to a VPN that allows you to open ports through their service.
Manually configure your OS and network to forward port 8333 and 18333.
Run Tor and direct bitcoin to listen through it.
I'll discuss #4. Obviously #1 or #2 are easier, but require a VPN subscription or uPnP enabled HW. And if you live in a dorm or don't control the network, Tor may be the only free option available. As a bit of background, bitcoin supports three networks that your node can listen on:
IPv4 - This is the "legacy" internet that most are used to
IPv6 - A not so new upgrade allowing trillions of addresses instead of billions
Tor) - A privacy network allowing encrypted traffic to remain anonymous
Obviously, the more you enable, the better, but here are the basic steps for Tor in broad strokes. If you have any questions post them here and I'll see if we can't help you out:
Record the hostname: type .\HiddenService\hostname as
Add the bitcoin.conf options suggested below
Restart the bitcoin-qt program
(Optional) Activate the bitnodes crawler at https://bitnodes.io/nodes/-8333/
It may take a while for your node to show up on bitnodes. I've found the check button sometimes has trouble with onions. Of course you don't need to do it, but it can provide a simple way to check status once your on the list.
torrc file: (replace c:\windows with the proper path as needed)
Change to C:\Windows\ServiceProfiles\LocalService\AppData\Roaming
Log notice file \tor\service.log
Bridges may be needed if the Gov't shuts down Tor exit nodes. Get Bridges by
In "Does running an alternative full node implementation benefit the Bitcoin network?", I asked about running an alternative full node implementation for the benefit of the Bitcoin network. What is the current status of different alternative full node implementations with regard to. maturity (alpha/beta/stable) performance; compatibility tests ... NODE ADDRESS USER AGENT HEIGHT LOCATION NETWORK; 18.104.22.168:8342 22.214.171.124 Since 1 month ago /Bitcoin Gold:0.15.2/ (70016) NODE_NETWORK, NODE_BLOOM, NODE_WITNESS (13) Viewing myNode Bitcoin Status. Bitcoin runs automatically when your myNode device starts. It can often be helpful or informative to view the current status of bitcoind. By clicking on the "Status" button under Bitcoin on the home page, you can view the current state on the Bitcoin daemon. Bitcoin node status and statistics web interface based on Django - bartromgens/bitcoinnodestats Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network. ... If you are using Bitcoin Core GUI, you can monitor the progress of IBD in the status bar (left bottom corner).
Bitcoin hit $7600! Now What? Live scan of the charts for setups & watchlist
We finally see a meaningful pullback in crypto. These are some key support levels to watch for bitcoin as we kick off a new week. Join the Node Insiders! Trading Bot Status, Trending Names, Alerts ... Live Market update and chart reviews for BTC STOCKS and more. Join the Node Insiders! Trading Bot Status, Trending Names, Alerts, Training videos and more! Tools made by Crypto Traders for Crypto ... The new Node Insiders site is ready! Trading Bot Status, Trending Names, Alerts, Training videos and more! Tools made by Crypto Traders for Crypto Traders.! Learn more at: https ... Los Angeles, CA- Welcome to the 1 Bitcoin Show! This is my last video before the long awaited 2020 halving! I will see you on the other side! I am already pumped for the 2024 halving. Why are node ... Live Market update for 4.15.2020. We'll do chart reviews for BTC STOCKS and more. Join the Node Insiders! Trading Bot Status, Trending Names, Alerts, Training videos and more! Tools made by Crypto ...