Build Your Own Bitcoin API using Node.js and Bitcoin Core ...

Gridcoin 5.0.0.0-Mandatory "Fern" Release

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

Highlights

Protocol

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

GUI

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

Blockchain

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

Summary Changelog

Accrual

Changed

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

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

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

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

Technical: The Path to Taproot Activation

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

The SegWit Wars

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

BIP9 Miner-Activated Soft Fork

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

The Great Battles of the SegWit Wars

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

BIP9 Feature Hostage

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

Covert ASICBoost

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

UASF: BIP148 and BIP8

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

BIP91, SegWit2X, and The Aftermath

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

Taproot Activation Proposals

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

Modern Softfork Activation

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

PSA: Being Resilient to Upgrades

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

hodlmon.sh: a UTXO monitoring methodology and script for true connoisseurs of security, paranoia and BTC maximalism

EDIT:
Disclaimer: the below script is provided for example purposes only. You're responsible for your own security. Don't trust, verify.
tldr: the script is literally just an example wrapper to call "gettxout" on your own node via cron to check if your own utxo has been spent yet
OK, since there are a few questions on security below, let me clarify: this script is only for people who are 1) already running their own nodes and 2) can understand the bash script below. And obviously, don't trust some random person on the internet, always verify. I provided this as an example for a way to monitor your own UTXOs with your existing node. Those of you who understand what the below script does will see it's painfully simple and obviously harmless. Those of you who don't understand it, just ignore this post, or better yet, research what the below means until you do understand it. What's important is the idea of monitoring your own UTXO, and this script is an example of how to do that with gettxout.
ORIGINAL POST:
Submitting this to help strengthen the community, and for review:
hodlmon.sh: a UTXO monitoring methodology and script for true connoisseurs of security, paranoia and BTC maximalism
Monitor canary UTXOs for early detection of compromised private keys BEFORE funds are lost, using your own full node for maximum privacy and trustlessness. Note that you will need to implement your own notification strategy (email, push, sms, etc). This script is intended to run on your full node, but can be run from any machine with RPC access to your full node.
hodlmon.sh is designed to check if a given UTXO (i.e. a specific output of a specific btc transaction) has been spent or not. This can be used for early and proactive detection if a seed phrase or private key has been compromised, so you have time to move your btc before full compromise happens. In order for this to work, a small amount of btc should be sent to an address controlled only by a given seedphrase, with that seedphrase being part of a multisig wallet or a seedphrase+passphrase wallet, and the majority of your funds controlled in the seedphrase+passphrase or multisig wallet. The idea is to leave the small amount of btc (the canary utxo) in the address, so that it never moves unless the seedphrase that controls it has been compromised and all funds in the wallet swept. In this way, you use those compromised sats to buy information about the current security status of your wallet(s).
Example usage:Set up a cron job to run hodlmon.sh every 30 min to check if transaction output at index "0" for transaction with id "123" has been spent already. Use "my_utxo_nickname" as a friendly name for the UTXO (to differentiate between multiple wallets)
*/30 * * * * /path/to/hodlmon.sh 123 0 my_utxo_nickname > /tmp/hodlmon_log 2> /tmp/hodlmon_err_log
Usage scenario #1: Seedphrase (A) + passphrase (A')Majority of funds are held in a wallet controlled by both the seedphrase and passphrase, A and A'. A token amount of btc is controlled only by seedphrase A.
A + A': majority of funds
A: canary UTXO
hodlmon.sh is used to monitor the canary funds locked by A, so that if it is discovered that A has been compromised, the funds locked by A and A' can be moved to a new wallet before the passphrase A' can be cracked and all your funds exfiltrated.
Usage scenario #2: multisig e.g. 2 of 3, with seed phrases A, B and CMajority of funds held in a multisig wallet controlled by 3 seedphrases A, B, and C. 3 small canary UTXOs are held in wallets each controlled by A, B or C, respectively.
A + B + C: majority of funds
A: canary UTXO 1
B: canary UTXO 2
C: canary UTXO 3
One benefit of multisig (e.g. 2 of 3) is that even if 1 key is compromised, your funds are safe, since at least 2 keys are needed to release funds. But how do you that none of the keys has yet been compromised? If you create separate wallets controlled each by only 1 of the individual keys, and use hodlmon.sh to monitor whether those UTXOs have been exfiltrated, then you can detect partial compromise of your setup before a full exfiltration event takes place, so you can move your funds to a new multisig wallet with freshly generated and uncompromised keys.
Example of 3 cronjobs to monitor all 3 canary UTXOs:
*/30 * * * * /path/to/hodlmon.sh 123 0 key1 > /tmp/hodlmon_log_1 2> /tmp/hodlmon_err_log_1
*/30 * * * * /path/to/hodlmon.sh 456 0 key2 > /tmp/hodlmon_log_2 2> /tmp/hodlmon_err_log_2
*/30 * * * * /path/to/hodlmon.sh 789 0 key3 > /tmp/hodlmon_log_3 2> /tmp/hodlmon_err_log_3

Example hodlmon script:
#########################################################################
#!/bin/bash
touch /tmp/hodlmon_last_run
echo "Transaction ID: $1"
echo "Output #: $2"
echo "Nickname: $3"
NODE_IP=127.0.0.1 #TODO: use actual value
USER=user#TODO: use actual value
PASS=pass #TODO: use actual value
PORT=8332 #TODO: use actual value
CHECK_CMD="/uslocal/bin/bitcoin-cli -rpcconnect=$NODE_IP -rpcuser=$USER -rpcpassword=$PASS -rpcport=$PORT gettxout $1 $2"
RESULT="$($CHECK_CMD)"
echo "${RESULT}"
if [ "$RESULT" == "" ]
then
echo "UTXO HAS BEEN SPENT! RED ALERT!!"
MSG="The UTXO for $3 from tx $1 output $2 has moved!"
#TODO: ADD YOUR FAVORITE NOTIFICATION STRATEGY E.G. EMAIL, PUSH NOTIFICATION, SMS
else
echo "UTXO is still on ice"
fi
############################################

submitted by facepalm5000 to Bitcoin [link] [comments]

Groestlcoin 6th Anniversary Release

Introduction

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

UPDATED - Groestlcoin Core 2.18.2

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

How to Upgrade?

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

Other Linux

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

Download

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

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

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

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

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

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

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

Features

Live Version (Not Recommended)

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

Download

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

Source

ALL NEW! – Vanity Search Vanity Address Generator

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

Features

Usage

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

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

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

Features

Download

Source

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

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

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

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

Features

Download

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

Source

ALL NEW! – Electrum Personal Server

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

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

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

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

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

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

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

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Daily analysis of cryptocurrencies 20191005(Market index 31 — Fear state)

Daily analysis of cryptocurrencies 20191005(Market index 31 — Fear state)

https://preview.redd.it/oly12rv9rqq31.png?width=1500&format=png&auto=webp&s=6667e09b78b0edc6dc3b411e5f96bba36f4a6430

Attorney General Barr Signs Letter To Facebook From US, UK, And Australian Leaders Regarding Use Of End-To-End Encryption The Department of Justice published an open letter on October 3 to Facebook from international law enforcement partners from the United States, United Kingdom, and Australia in response to the company’s publicly announced plans to implement end-to-end-encryption across its messaging services. The letter is signed by Attorney General William P. Barr, United Kingdom Home Secretary Priti Patel, Australia’s Minister for Home Affairs Peter Dutton, and Acting Homeland Security Secretary Kevin McAleenan. Addressed to Facebook’s CEO, Mark Zuckerberg, the letter requests that Facebook not proceed with its end-to-end encryption plan without ensuring there will be no reduction in the safety of Facebook users and others, and without providing law enforcement court-authorized access to the content of communications to protect the public, particularly child users.
Coincheck Launches New Service That Rewards Gas Users With Bitcoin In an attempt to bring crypto to the mass audience, Japanese crypto exchange Coincheck inked a partnership deal with E-net Systems to reward gas users in the Tokyo Gas area, the company announced Oct 4. Under the partnership agreement, the two companies will start offering Coincheck Gas with two crypto-related plans for its customers. The gas service by the crypto company will offer a Bitcoin Rewards Plan under which customers will receive Bitcoin as rewards for the usage of gas. In addition, customers can also pay their gas bills using Bitcoin under the Bitcoin Payment Plan.
Libra Association: 1500 Entities Have Indicated Enthusiastic Interest To Join Libra After PayPal announced to withdraw their support for Facebook’s Libra cryptocurrency, Libra posted a series of tweets in response to the striking news. Libra Association tweeted: “Building a modern, low-friction, high-security payment network that can empower billions of financially underserved people is a journey, not a destination. This journey to build a generational payment network like the Libra project is not an easy path.” “We recognize that change is hard, and that each organization that started this journey will have to make its own assessment of risks and rewards of being committed to seeing through the change that Libra promises,” they continued. The final tweet read: “We look forward to the first Libra Council meeting in 10 days and will be sharing updates following that, including details of the 1,500 entities that have indicated enthusiastic interest to participate.”
Prysmatic Labs Team Unveils Updates On The Ethereum Serenity Roadmap Prysmatic Labs team has unveiled biweekly updates on the Ethereum Serenity roadmap via Medium. According to the article, the testnet has been restarted for everyone to experience staking and becoming a validator. This testnet includes beacon chain spec v0.8.4, various performance improvements, faster BLS paring library, new syncing strategies and more RPC end point support.
Japan: Using Virtual Currency To Make Donations To Politicians Is Legal Citing Yomiuri Shimbun, the Japanese Ministry of Internal Affairs and Communications, a cabinet-level ministry in the Government of Japan, indicated that the use of virtual currency to donate to politicians is not illegal. According to Japan’s Political Fund Control Law, it is prohibited to conduct donations to politicians in principle, but virtual currency is not in the category of “money and securities” which are covered by law.

Encrypted project calendar(October 05, 2019)

Ontology (ONT): Ony Ji will attend the blockchain event in Japan on October 5th and explain the practical application based on the ontology network. BNB/Binance Coin: The Binance Coin (BNB) Oasis Game Hackathon will be held on October 5th in Bangalore, India, and will be hosted by Binance Labs, Matic Network, Cocos-BCX, Celer Network, Marlin Protocol.

Encrypted project calendar(October 06, 2019)

SPND/ Spendcoin: Spendcoin (SPND) will be online on October 6th

Encrypted project calendar(October 07, 2019)

GNO/Gnosis: Gnosis (GNO) will discuss the topic “Decentralized Trading Agreement Based on Ethereum” will be held in Osaka, Japan on October 7th. Kyber and Uniswap, Gnosis and Loopring will attend and give speeches.

Encrypted project calendar(October 08, 2019)

BTC/Bitcoin: The 2nd Global Digital Mining Summit will be held in Frankfurt, Germany from October 8th to 10th.

Encrypted project calendar(October 09, 2019)

CENNZ/Centrality: Centrality (CENNZ) will meet in InsurTechNZ Connect — Insurance and Blockchain on October 9th in Auckland.

Encrypted project calendar(October 10, 2019)

INB/Insight Chain: The Insight Chain (INB) INB public blockchain main network will be launched on October 10. VET/Vechain: VeChain (VET) will attend the BLOCKWALKS Blockchain Europe Conference on October 10. CAPP/Cappasity: Cappasity (CAPP) Cappasity will be present at the Osaka Global Innovation Forum in Osaka (October 10–11).

Encrypted project calendar(October 11, 2019)

OKB/OKB: OKB (OKB) OKEx series of talks will be held in Istanbul on October 11th to discuss “the rise of the Turkish blockchain.”

Encrypted project calendar(October 12, 2019)

BTC/Bitcoin: The 2019 Global Mining Leaders Summit will be held in Chengdu, China from October 12th to 14th.

Encrypted project calendar(October 14, 2019)

BCH/Bitcoin Cash: The ChainPoint 19 conference will be held in Armenia from October 14th to 15th.

Encrypted project calendar(October 15, 2019)

RUFF/RUFF Token: Ruff will end the three-month early bird program on October 15th KAT/Kambria: Kambria (KAT) exchanges ERC20 KAT for a 10% bonus on BEP2 KAT-7BB, and the token exchange reward will end on October 15. BTC/Bitcoin: The Blockchain Technology Investment Summit (CIS) will be held in Los Angeles from October 15th to 16th.

Encrypted project calendar(October 16, 2019)

BTC/Bitcoin: The 2019 Blockchain Life Summit will be held in Moscow, Russia from October 16th to 17th. MIOTA/IOTA: IOTA (MIOTA) IOTA will host a community event on the theme of “Technology Problem Solving and Testing IoT Devices” at the University of Southern California in Los Angeles on October 16. ETH/Ethereum: Ethereum launches Istanbul (Istanbul) main network upgrade, this main network upgrade involves 6 code upgrades. QTUM/Qtum: Qtum (QTUM) Qtum main network hard fork is scheduled for October 16.

Encrypted project calendar(October 18, 2019)

BTC/Bitcoin: The SEC will give a pass on the VanEck/SolidX ETF on October 18th and make a final decision HB/HeartBout: HeartBout (HB) will officially release the Android version of the HeartBout app on October 18.

Encrypted project calendar(October 19, 2019)

PI/PCHAIN Network: The PCHAIN (PI) backbone (Phase 5, 82 nodes, 164, 023, 802 $ PI, 7 candidates) will begin on October 19. LINK/ChainLink: Diffusion 2019 will be held in Berlin, Germany from October 19th to 20th

Encrypted project calendar(October 21, 2019)

KNC/Kyber Network: The official online hackathon of the Kyber Network (KNC) project will end on October 21st, with more than $42,000 in prize money.

Encrypted project calendar(October 22, 2019)

ZRX/0x: The 0x protocol (ZRX) Pantera blockchain summit will be held on October 22.

Encrypted project calendar(October 23, 2019)

MIOTA/IOTA: IOTA (MIOTA) IOTA will host a community event on October 23rd at the University of Southern California in Los Angeles with the theme “Connecting the I3 Market and Experiencing Purchase and Sales Data.” BTC/Bitcoin: The WBS World Blockchain Summit (Middle East) will be held in Dubai from October 23rd to 24th.

Encrypted project calendar(October 24, 2019)

BCN/Bytecoin: Bytecoin (BCN) released the hidden amount of the Bytecoin block network on October 24.

Encrypted project calendar(October 25, 2019)

ADA/Cardano: Cardano (ADA) The Ada community will host a community gathering in the Dominican Republic for the first time on October 25.

Encrypted project calendar(October 26, 2019)

KAT/Kambria: Kambria (KAT) Kambria will host the 2019 Southern California Artificial Intelligence and Data Science Conference in Los Angeles on October 26th with IDEAS. BTC/Bitcoin: CoinAgenda Global Summit will be held in Las Vegas from October 26th to 28th

Encrypted project calendar(October 28, 2019)

LTC/Litecoin: Litecoin (LTC) 2019 Litecoin Summit will be held from October 28th to October 29th in Las Vegas, USA BTC/Bitcoin: Mt.Gox changes the debt compensation plan submission deadline to October 28 ZEC/Zcash: Zcash (ZEC) will activate the Blossom Agreement on October 28th

Encrypted project calendar(October 29, 2019)

BTC/Bitcoin: The 2nd World Encryption Conference (WCC) will be held in Las Vegas from October 29th to 31st.

Encrypted project calendar(October 30, 2019)

MIOTA/IOTA: IOTA (MIOTA) IOTA will host a community event on October 30th at the University of Southern California in Los Angeles on the topic “How to store data on IOTA Tangle.”
https://preview.redd.it/jfxnwvgcrqq31.png?width=473&format=png&auto=webp&s=6adc6ab9f1c8a5f14874041d1e57a6721b8023b3

On the chart, we can see that the price made a break of the lower resistance boundary of the “triangle with a flat bottom” formation in the zone of $9560–9580. At the same time, 157 SMA was broken, which confirmed the dominance of sellers. Now the price is trading around $8100–8250, at the border of the resistance of descending channel. Consolidation of the price indicates the current period of accumulation, interest of buyers and a potential return to the upper boundary of the descending channel to $9100–9200 zone. After the middle of the month, the price may rebound from the support level of the descending channel and return to the area of $​​8900–9300, where there is a strong resistance. Also, the other day, the level of 8200 was traded and once again protected. The common mood is to fall, and we know that often the market goes against the majority. A lot of people are in shorts and this is an excellent point for growth (their stops and liquidation of positions, as was the case recently with longsters)
Review previous articles: https://medium.com/@to.liuwen

Telegram: https://t.me/Lay126
Twitter:https://twitter.com/mianhuai8
Facebook:https://www.facebook.com/profile.php?id=100022246432745
Reddi:https://www.reddit.com/useliuidaxmn
LinkedIn:https://www.linkedin.com/in/liu-wei-294a12176/
submitted by liuidaxmn to u/liuidaxmn [link] [comments]

Weekly Dev Update #19

THORChain Weekly Dev Update for Week 19–02 Nov 2019

Overview

1 Rune Fee

Reasoning about gas costs on networks with non-deterministic fee schedules (such as Bitcoin) becomes unnecessarily complex. The issue is that the final gas cost cannot be known ahead of time so the system must cover any variability in the gas cost so that the user can be charged a flat rate. If the user is not charged anything, then the system can be depleted of funds, passing the cost back to stakers. Additionally, swaps below 1 Rune bring negligible economic value to the network and saturate the mempool with low value transactions. As such the solution is to charge a flat 1 Rune fee (or 1 Rune equivalent) on all outgoing transactions (swap and withdrawals). This 1 Rune fee is moved into the Protocol Reserve and increases the network’s future income. When the nodes report on the final transaction, they include the observed transaction fee. This transaction fee is then reimbursed back to the pool that paid for it ( BNB.BNB, BTC.BTC, ETH.ETH etc). There are cases that the outgoing transaction fee may exceed 1 Rune (Bitcoin in high use), but more than likely 1 Rune will be more than sufficient to cover the costs and ensure the network grows its reserves. Additionally, it sets a floor on the minimum transaction that the network will process. A swap of less than 1 Rune will end up becoming a donation to the network.

THORChain Development

The team are working on 4 parallel streams of effort. Cross-chain infrastructure has now been merged into a single repo called “THORNode”. * THORChain * Midgard Public API * Threshold Signature Scheme implementation * Front-end Integration for BEPSwap

THORChain

Much work has been done to refactor and clean up the codebase which will make public audits easier. This includes splitting up the keeper, separating out the events module and more. Smoke tests have been fully-integrated into the test schedule. Safer subtraction and division methods were added to prevent the likelihood of panic events. * [refactor] split keeper funcs/interface into separate files * [tests] use gow * [refactor] Redo how get key works in keeper * [security] require no signers on tx ins * Resolve “ADD: 1 Rune Fee on all Swaps” * [bug] fix smoke tests * [ADD] semantic versioning * [Refactor] Keeper chains * [Refactor] Events Keeper * Resolve “Adds a SafeSub method” * [Refactor] Last Height Keeper * [Refactor] keeper liquidity fees * FIX: Issue 208 * [ISSUE] Get smoke tests to 100%

Midgard Public API

Midgard is now ready for integration into the FrontEnd. The manner in which USD price of assets in now updated to source only from internal pool pricing. This includes BNB.BUSD, BNB.TUSD, BNB.USDS. ROI endpoints are now added. * Fix : Updated our mock data to include a correct BNB address. * Add: Return the date a staker first staked. * Add: Previously missing implementations for pool data (24hr and 12m). * Fix: Several potential query issues. Updates to return the TX date as a UNIX timestamp. * Fix: Additional query updates/fixes. * Fix: Build system * Add: Filtering implementation for TxID and Asset. * Added missing import. * Fix/build issues * Fixed issue with my auto refactor * Add: Filtering updates. DB Config fix. * Add: Missing Staker methods for ROI and earnings. * Added fix to enabled timescale extension * Fix: Added build config for rpc_host * Add: Support to Calculate USD price of an asset. * Added: Health check for mainnet to test that we still have a db connection… * Add: Tests for the recent endpoints work. * jq syntax fix. * Additional jq fixes. * [ADD] Manage docker image on gitlab

Threshold Signature Scheme

The Binance Go TSS library is now fully implemented and deploys in a four-node chain. integrate with new go-tss * 212-issue export private key thus we can use it to start tss * 214-issue consolidate tss keygen and tss keysign config, with our new go-tss… * [ADD] Setup go-tss in genesis docker * [ADD] Have CI run smoke tests on a four node chain with TSS

Frontend Implementation

The frontend makes some final tweaks on the interface, before integrating the Midgard APIs. * Resolve “Update stake page share panel” * Resolve “UPDATE: Network Dropdown Titles” * Resolve “ADD: Sorting of columns in pool list” * Resolve “ADD: Sorting of columns in pool list” * Resolve “FIX: Close token selection drop down when clicking outside” * Resolve “Add redux saga for midgard apis” * Resolve “Update protect price UI” * Resolve “Update wallet drawer”

Timelines

The next milestone is: ChaosNet: 03 January 2020 on-time

Community

To keep up to date, please monitor community channels, particularly Telegram and Twitter: Twitter: https://twitter.com/thorchain_org Telegram Community: https://t.me/thorchain_org Telegram Announcements: https://t.me/thorchain Reddit: https://reddit.com/thorchain Github: https://github.com/thorchain Medium: https://medium.com/thorchain
submitted by thorchain_org to THORChain [link] [comments]

WaykiChain(WICC) Weekly Report-5.20 — 5.26

WaykiChain(WICC) Weekly Report-5.20 — 5.26

https://preview.redd.it/e0kc333y8v031.jpg?width=620&format=pjpg&auto=webp&s=0bdb93dc22c50979587e6b746acd53b49752db90
Technology & Product Development
Stable Coin
· The design of Stable Coin system mechanism basically completed.The system code framework has been adjusted at the bottom of the public chain, so that it can be modularized and expandable, which has laid a solid foundation for the follow-up development of Stable Coin. Among them, the decentralized feeding mechanism has been finalized in the public chain technology and completed 50% of the development progress.
Public Chain Development
· Public chain construction support, modifed the automated test cases based on the latest nodes. (100%)
· Revised voting transaction rpc parsing parameters error. (100%)
· Use soft forks compatible with one coin for eleven and one coin for one (100%)
· Refactored the code to prevent transaction replay attacks (100%)
· Refactored voting storage logic (100%)
· Revised the fuel calculation of contract execution steps to campatible with v1.0 (100%)
· Added the fuel calculation of each interface in contract mylib library (100%)
Application Development
· Blockchain explorer v2.0.0 is official launched. Based on the original blockchain explorer, functions and interface has been optimized, users can easily query any WaykiChain related information.
· WaykiTimes v1.3.0: Added game horizontal screen and token list functions to strengthen the WaykiChain ecological construction.(30%)
· WaykiTimes v2.0.0: the design of prototype (10%), optimizing the existing interfaces and features to further enhance user experience.
· WaykiMax (Explorer plug-in wallet) is successfully live on 360 Explorer Appstore!
T2D2 Development
· WaykiMix (WaykiChain smart contract development tool)
· v2.0.0 prototype design completed (100%)
· Code plugin replaced with ace-based development, support for grammar checking (100%)
· Added Log area output (50%)
· Swagger2CaseManager (Interface automation test management platform)
· New added: Test environment configuration and switching, test report mailing, error logging.
· Debugged jointly the front-end and back-end, repaired related bugs: some problems caused by the unverification of form data input, external key error association in the database, deleted API referred by test cases, etc.
· Ansible automated deployment (25%)
· Used GitLab + Ansible to implement explorer front-end automated deployment.
· Use Ansible to implement the deployment of R&D nodes at t1-t11.
· Use Ansible to implement zabbix-agnt deployment.
Work Plan for This Week
· Continue to develop WaykiMix and complete the technology online (100%)
· WaykiTimes v1.3.0: game horizontal screen development and token list technology be online.
· WaykiTimes v2.0.0: the design of prototype (60%)
· WaykiTimes management background: the development of bulk currency distribution (50%)
· Support the free activation for contract transaction account (compatible with RegID).
· Add rollback mechanism in Ansible automation deployment
· Implement Zabbix email alerts, and basic monitoring of all machines.

Community Development
Overseas
· CCN, Issuewire etc. well-known blockchain medias reported WaykiChain CEO interview, revealing the 'Win-Win-Win business model' of WaykiChain.
· On May 22, official Twitter launched "Bitcoin Pizza Day" event.
· WaykiChian Korean official Kakao group launched award-winning (Starbucks) event.
· Maintaining the overseas official channels, posted “WaykiChain(WICC) Weekly Report", "WaykiChain Aims Far Beyond What ETH or EOS Is Now","WaykiChain Launches Block Explorer Upgrade — WaykiScan (Beta)","Blockchain Future Spotlights: Win-Win-Win Business Mode" etc.
· Disclosed the latest updates of WaykiChain project to the communities including “WaykiChain Official Group” and “WaykiChain Developers-Global” telegram groups.
· Updated “Crypto Weekly Roundup”.
China
· "Wayki Legend" developed by the third-party game development team Vododo joined the one-week ranking competition, the game is covered by some blockchain industry medias reports including DOGIgames, Fisho, Jin Se Media, Mars Finance and Sharing Finance.
· "Wayki Legend" released this week launched 8 welfare activities: charge money and cash back, Top 10 gain WICC, 520 couples power list, game-related essay collecting activity, continuous landing reward,level 100 rewards, as well as enter Wayki Legend Official QQ group (648976748) to enjoy Airdrop welfare. the response from game fans is good.
· The WaykiChain Joint Atlas Protocol hosted the “Participating in the WaykiChain Questionnaire to Win WICC” event, which ended on May 27th and currently has 302 participants.
· Produced 1 episode of “WaykiChain Daily News” live broadcast, with 1,222 views and 201 likes, and 22 comments.
· WaykiChain DApp Funding Program has received 4 DApp project plan this week.
· The first phase of the "Blockchain Preschool" has ended in 5 courses, with a total of 60 students, of which 5 students passed the examination and obtained a diploma.
submitted by Waykichain to WICCProject [link] [comments]

Transcript of Developer Meeting in Discord - March 29, 2019

Pho3nix Monk3y03/29/2019
Is this unlocked?
oh cool. yes it is
Guess we need an admin to unlock it. Some of our devs cant type in here yet.
@shiggidy @traysi ★★★★★ Can yall unlock this channel?
traysi ★★★★★03/29/2019
Should be open now
bhorn03/29/2019
open!
GhostDogsGhost03/29/2019
heya!
SamzOnline [w1ne]03/29/2019
Woot
theking03/29/2019
Glad to be here.
traysi ★★★★★03/29/2019
@Jeroz can you type now?
Jeroz03/29/2019
Works now
ty
Pho3nix Monk3y03/29/2019
Great. Didn't really have an agenda for this meeting I'm told. Can open it up? Anyone have anything to start?
Bianca_NL03/29/2019
YaY
GhostDogsGhost03/29/2019
testnet voting on messaging bip?
Pho3nix Monk3y03/29/2019
I like it.
@GhostDogsGhost You might be the main "answerer of questions" for this. Not sure where @[Dev-Happy] Blondfrogs is.
GhostDogsGhost03/29/2019
anyone know if it's passed? if and when it'd be great to get some usage
Vincent03/29/2019
all good @traysi ★★★★★
Jeroz03/29/2019
Messaging is active on testnet now. The vote passed.
traysi ★★★★★03/29/2019
I'll try to clean up the permissions for this channel to make it simpler for future meetings.
Jeroz03/29/2019
There is no GUI yet to test it.
GhostDogsGhost03/29/2019
sweet -- yeah just rpc for now
[Dev-Happy] Blondfrogs03/29/2019
here
Pho3nix Monk3y03/29/2019
yay
[Dev-Happy] Blondfrogs03/29/2019
So, for messaging. There is not GUI, we really want to test the protocol which you can use fully through the rpc console.
We understand that this limits the number of users that will want to do testing but we wanted to get it out there asap to find bugs
Jeroz03/29/2019
Is there list of commands / little guide on how to get started with them in the console?
[Dev-Happy] Blondfrogs03/29/2019
Also, we wanted to let everyone know that we are going to try and get messaging protocol and restricted assets on mainnet at the same time. This means that the release for messaging might be delayed by a couple weeks. The devs are working really hard to make this happen and hope that the community is willing to wait a little longer for mainnet messaging.
There are commands like sendmessage listmessages and subscribe rpc calls yes
Jeroz03/29/2019
That would mean 1 hardfork instead of 2 right?
[Dev-Happy] Blondfrogs03/29/2019
Exactly @Jeroz
[Master] Roshii03/29/2019
Hello!
[Dev-Happy] Blondfrogs03/29/2019
Also, the Qt for messaging wont be released until after the hardfork, but the Qt for messaging and restricted assets would be in the same release.
S1LVA | GetRavencoin.org03/29/2019
Hello! Thanks for holding this meeting.
Jeroz03/29/2019
Will dividends also be included to that? @WhaleStreet (BW) (not sure if you are here)
[Dev-Happy] Blondfrogs03/29/2019
Dividends can be released at anytime it is completed as it doesn't require a hardfork
Jeroz03/29/2019
I meant the GUI update
S1LVA | GetRavencoin.org03/29/2019
For restricted assets, will owners of !uniquename have a grace period to claim $uniquename ?
[Dev-Happy] Blondfrogs03/29/2019
I am not sure on the GUI for dividends.
We are still figuring out if we are going to allow for a grave period or not. I think we are leading to the answer of Yes there will be a grace period.
but we aren't sure yet
SamzOnline [w1ne]03/29/2019
I've been studying and out of the loop of the RVN scene for a long time - is there any chance of someone updating me on what y'all talking about?
Pho3nix Monk3y03/29/2019
We have also been going through and cleaning up issues in GitHub. Tried to clean up tags in there as well. We will probably start going though those on a weekly ->monthly basis to stay ahead of things.
Vincent03/29/2019
community seens to agree !ASSET has exclsuvie on $ASSET
GhostDogsGhost03/29/2019
Silva -- that's open for discussion -- I think the general sentiment is that there should be some preference given to current asset owners
[Dev-Happy] Blondfrogs03/29/2019
@SamzOnline [w1ne] We are talking about the roadmap and how the development of the new features are coming along.
SamzOnline [w1ne]03/29/2019
Lovely many thanks
Vincent03/29/2019
what is the justification on only a grace period?
S1LVA | GetRavencoin.org03/29/2019
Is it possible to reissue a !ownership as a $ownership?
Jeroz03/29/2019
@SamzOnline [w1ne]
https://medium.com/@tronblack/ravencoin-tags-and-restricted-assets-84fe3070a226
https://medium.com/@tronblack/ravencoin-kaaawww-2f72077aece
[Dev-Happy] Blondfrogs03/29/2019
@Vincent I don't think is has exclusive rights. More like a first right of refusal for a couple months
Synicide03/29/2019
agree there should be some kind of grace period, or users that originally registered those assets will feel shafted
Vincent03/29/2019
but what is that justification?
if you are building Applein ur garage, you may need a few yrs to go public
S1LVA | GetRavencoin.org03/29/2019
Issue being assets will cease to be unique with two different types about
[Dev-Happy] Blondfrogs03/29/2019
True.
We aren't sure on what approach will be taken yet
Synicide03/29/2019
should regular and restricted assets share the same 'uniqueness of naming'?
[Dev-Happy] Blondfrogs03/29/2019
Please the community let us know what you think is fair.
This topic will 100% need to be discussed a lot
Vincent03/29/2019
when it was announced, there was a lot of discussion; most seemed to agree
SamzOnline [w1ne]03/29/2019
@Jeroz Many thanks
[Dev-Happy] Blondfrogs03/29/2019
If the consensus is that we shouldn't allow for ASSET! and $ASSET to be issued by different people then we will need to make sure that is the right approach. The code hasn't been written yet.
GhostDogsGhost03/29/2019
Some of this will depend on what we end up pricing the $ASSETS at (burn for issuance)..
Vincent03/29/2019
prcing shouldnt matter imo
S1LVA | GetRavencoin.org03/29/2019
We need to determine how important unique asset names are, for varying types.
Vincent03/29/2019
should be the owner of the asset name
[Dev-Happy] Blondfrogs03/29/2019
@S1LVA | GetRavencoin.org Exactly
push | ravenland.org03/29/2019
hey all, sorry im late :thumbsup:
[Dev-Happy] Blondfrogs03/29/2019
Howdy
Synicide03/29/2019
If someone registers !company123, and starts building a platform for themselves, seems they should be given an option to convert to $company123, and shouldnt have to worry about another party creating $company123
[Dev-Happy] Blondfrogs03/29/2019
They will be given that option
Vincent03/29/2019
indefinately
[Dev-Happy] Blondfrogs03/29/2019
the question is, is that option going to exist for forever, or maybe only 4 months
Vincent03/29/2019
then the worry still exists
Rikki RATTOE Sr. SEC Impresantor03/29/2019
I definitely vote for ! And $ to only be issued by the same people
Synicide03/29/2019
lets say they choose not to, can someone else create $company123? Or is that unqiue name shared?
S1LVA | GetRavencoin.org03/29/2019
I believe, ideally, a reissuance option would be available at anytime from !ownership
[Dev-Happy] Blondfrogs03/29/2019
@Synicide That decision hasn't been made yet
theking03/29/2019
@[Dev-Happy] Blondfrogs I do agree that releasing both messaging and restricted assets at same time makes sense so there is only one hard fork. What is the current thinking on tentative timeline before they would both be on main net?
push | ravenland.org03/29/2019
im excited about this memo indication, its useful because it means a buyer of an asset sending rvn can indicate the 'return address' without the 'seller of the asset receiving ravencoin' having to transverse the full vin/vout chain to obtain the source address to dispatch asset to. Is there a timeline for this feature or any documentation on it @[Dev-Happy] Blondfrogs ?
Synicide03/29/2019
my 2 cents, they should be a shared pool of unique names. The door is opened for scammers galore if it isnt.
[Dev-Happy] Blondfrogs03/29/2019
@theking A couple months atleast.
To make sure it is tested on testnet for long enough
theking03/29/2019
That makes perfect sense!
[Dev-Happy] Blondfrogs03/29/2019
@push | ravenland.org It will be on mainnet as soon as it and restricted assets are tested. Is the goal
push | ravenland.org03/29/2019
excellent, i look forward to it
Chill03/29/2019
Thank you for taking the time to bring up the ! and $ ownership issue. It's of extreme importance imo
push | ravenland.org03/29/2019
its gods work your doing there
bitnaive03/29/2019
yeah it seems like any modifiers to the original !NAME should belong to !NAME
DirkDiggler (RVN ded)03/29/2019
I would like to voice concern over the idea of the "grace period".... The idea of a UNIQUE asset name is key to our success. Many of us jumped on names we wanted. This doesn't feel right to need to have yet another name floating around if it's not controlled by the !OWNERSHIP token
S1LVA | GetRavencoin.org03/29/2019
@Chill NP :p
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Yes please on only 1 hard fork
Chill03/29/2019
unique is unique. I have 510 of them!
Synicide03/29/2019
@DirkDiggler (RVN ded) grace peroid wont matter if the naming pool is shared for uniqueness
[Dev-Happy] Blondfrogs03/29/2019
So, If I own GOOGLE!, and I don't want $GOOGLE, no one should be allowed to own it?
DirkDiggler (RVN ded)03/29/2019
exactly
S1LVA | GetRavencoin.org03/29/2019
@[Dev-Happy] Blondfrogs Ideally, yes
bhorn03/29/2019
that feels right to me
Jeroz03/29/2019
yes
SamzOnline [w1ne]03/29/2019
Interesting
DirkDiggler (RVN ded)03/29/2019
yes
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@[Dev-Happy] Blondfrogs I'm good w that
Synicide03/29/2019
that makes the most sense to me. As said, opens the door to scammers if not
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Would add extra value to the ownership token as well
S1LVA | GetRavencoin.org03/29/2019
If more power is given to !ownership(changing type), more value is added to said asset, by way of design and ability
Vincent03/29/2019
and if you want to covert your assets to restricted yrs from now you will have a logistic nightmare if you have a bunch of owners
[Dev-Happy] Blondfrogs03/29/2019
I feel like, if we give people the option to register the restricted asset $ and they don't want it, that it is only fair that it is up for grabs
bitnaive03/29/2019
maybe no one else should be allowed to issue it but it can be transferred
Vincent03/29/2019
why?
Chill03/29/2019
I really don't think that's fair, to be honest
S1LVA | GetRavencoin.org03/29/2019
@[Dev-Happy] Blondfrogs Unique names are lost, in that case.
And in that way, !ownership loses value by not having the ability to change, if need be
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Yeah I'd rather see the one name issued only forever
bitnaive03/29/2019
that way, if some one wants it. the can contact the owner for it.
[Dev-Happy] Blondfrogs03/29/2019
I think restricted assets have a different use case than regular assets, and they can be frozen.
Vincent03/29/2019
i can buy ravenland and revent push from moving forward with is project (after grace)
DirkDiggler (RVN ded)03/29/2019
seems like from a "code" perspective... the idea of 2 different (but similar names) would be a nightmare as well
Jeroz03/29/2019
Ideally give reissuable the extra option of making it restricted in my mind. I have mixed feelings about tokens traveling around that have the same asset name but are a different type.
Vincent03/29/2019
all his logos would have to change to his new name
S1LVA | GetRavencoin.org03/29/2019
They not have them remain one in the same? With the ability to change to restricted, should they have to. Though reissuance?
[Dev-Happy] Blondfrogs03/29/2019
@Vincent That is why push would have plenty of time to pick up the ravenland restricted asset if he wanted it
Rikki RATTOE Sr. SEC Impresantor03/29/2019
One of our selling points over ETH is that ETH can issue a bunch of the same named assets as long as the contract address is different
Vincent03/29/2019
bbut who says what is enough time
i may need yrs
bhorn03/29/2019
the extra cost could be onerous as well
Chill03/29/2019
when the asset layer was launched, it was billed as being unique names. Be careful in changing this, please.
[Dev-Happy] Blondfrogs03/29/2019
True, that amount of time isn't determined yet, if this is the route that is taken
bhorn03/29/2019
some have many many many assets
Rikki RATTOE Sr. SEC Impresantor03/29/2019
RVN, u issue that name once, it can never be duplicated
DirkDiggler (RVN ded)03/29/2019
where as having just another sub asset type ($RESTRICTED) falls under the same hierarchy already defined
bhorn03/29/2019
and the RVN is not as cheaply replaced
[Dev-Happy] Blondfrogs03/29/2019
@Chill Not changing that, just talking about the next asset usecase and how it could be coded is all
Rikki RATTOE Sr. SEC Impresantor03/29/2019
What kind of burn costs are we thinking w issuing restricted assets?
Synicide03/29/2019
@[Dev-Happy] Blondfrogs what if push decides not to, then someone else registers it for malicious intent with the same name? Surely the person who built their company on chain doesnt want another token of their company name out there
Vincent03/29/2019
@[Dev-Happy] Blondfrogs you seem to be the only one fighting for the garce period
[Dev-Happy] Blondfrogs03/29/2019
@Rikki RATTOE Sr. SEC Impresantor Not sure yet, going to be more than regular issuanace is the thought.
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Agreed
S1LVA | GetRavencoin.org03/29/2019
@Vincent Simply bringing it into conversation, no harm
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Not fighting, just keeping an open mind. I just code it, I am not the one making the decision.
push | ravenland.org03/29/2019
hey this is a bit of a random question but i get a lot of subassets send to me, what about wildcard sending via the wallet? like if i wanted to send RAVENLAND/* to an address
Vincent03/29/2019
true but just showing what the concesous is
[Dev-Happy] Blondfrogs03/29/2019
@push | ravenland.org Create a request in the issues on github for extra functionality
push | ravenland.org03/29/2019
:thumbsup:
will do mate
Synicide03/29/2019
seems if ! and $ arent shared unique, then companies will have to register both just to protect themselves
Rikki RATTOE Sr. SEC Impresantor03/29/2019
How about a unique asset w re-issuable IPFS?
S1LVA | GetRavencoin.org03/29/2019
We should be giving more power to !ownership by allowing it the ability to change to $ - Not giving less power to !ownership by duplicating unique names.
Rikki RATTOE Sr. SEC Impresantor03/29/2019
GUNCERT provided a valid use case IMO for unique w re-issuable IPFS
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Sure I get that.
Sevvy (not worried til 500sats)03/29/2019
Agrees
If this is a possibility, to give the restricted assets to those who own the normal ones, it ought to be done
[Dev-Happy] Blondfrogs03/29/2019
@Rikki RATTOE Sr. SEC Impresantor Looking in on how to do that. The request is on github just don't have the time to implement it yet.
restricted assets, will have to be issued. and the corresponding amount of rvn will be burned for them
push | ravenland.org03/29/2019
it'd be nice to see a ravencoin network swarm, us and mango farms are doing something with that so if anyone else wants to get involved, i think its a worthwhile thing to build the power of the ravencoin ipfs hash network to keep them hashes alive
Sevvy (not worried til 500sats)03/29/2019
Yikes
Ah well
push | ravenland.org03/29/2019
i wrote a programmatic script to scrape all the ipfs files, so i can probably runa simple enough shellscript to ipfs add pin everything from chain
Vincent03/29/2019
plus ravenland sent me a bunch of tokens...they will be worthless now!!! :sunglasses:
push | ravenland.org03/29/2019
:joy:
vincent
one day tho eh
Chill03/29/2019
my 250,000 RVN that were spent on RVN assets are feeling pretty weak at the moment
[Dev-Happy] Blondfrogs03/29/2019
@Vincent haha ravenland assets are still assets. They just don't have the ability to freeze then and stop you from trading them
DirkDiggler (RVN ded)03/29/2019
you got to have one ring to rule them all... the Unique Ownership Token does that
SamzOnline [w1ne]03/29/2019
@Chill That puts my 80 to shame!
[Dev-Happy] Blondfrogs03/29/2019
@Chill Like I said, no decision has been made yet.
Vincent03/29/2019
@[Dev-Happy] Blondfrogs just playing with that one
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Yeah, I understand
S1LVA | GetRavencoin.org03/29/2019
Changing gears alittle, Has any further thought been put into privacy?
push | ravenland.org03/29/2019
a tor network with proxychains could be effectively used to privatize a node
Jeroz03/29/2019
Seems that we need to continue discussions about the asset naming and make a write up about the proposals.
I have a different question:
About metadata and transactions. Tron mentioned that it will be possible to attach metadata to every transaction. It was unclear to me whether he meant every messaging transaction or every regular RVN/Asset transaction.
push | ravenland.org03/29/2019
ive been looking into this a little bit
Synicide03/29/2019
@S1LVA | GetRavencoin.org been wondering that too, and if restricted assets for KYC/AML NEED to be trackable
[Dev-Happy] Blondfrogs03/29/2019
@S1LVA | GetRavencoin.org Privacy isn't the main thing ravencoin wants right now. We need to be able to send and trade assets with visibility of amounts and the asset names. Once the main core components are finished, we can start thinking about integration privacy.
push | ravenland.org03/29/2019
as i understand it tor could as a protocol be built into ravencoin itself and distroed as a private tor based connector or hardened in such a way not to leak dns or requests that are not 'tor' proxied .. but you could do this already with some modifications to most linux systems (without the need for a ravencoin release)
S1LVA | GetRavencoin.org03/29/2019
Understood
[Dev-Happy] Blondfrogs03/29/2019
@Jeroz With messaging, all asset transactions can contain a metadata field yes.
Jeroz03/29/2019
RVN too?
[Dev-Happy] Blondfrogs03/29/2019
Not RVN at this time, as that already exists with the OP_RETURN functionality of bitcoin
Jeroz03/29/2019
Yeah I was about to say
S1LVA | GetRavencoin.org03/29/2019
I dream of one day Ravencoin giving users the ability to protect themselves from state level actors looking to oversee transactions on chain.
[Master] Roshii03/29/2019
What's the subject?
[Dev-Happy] Blondfrogs03/29/2019
@S1LVA | GetRavencoin.org That would be amazing, however the dividends and voting require a public ledger in order to send
Synicide03/29/2019
@[Master] Roshii large one is if regular and restricted assets should share unique names, and/or if a grace peroid should be allowed for original owners to register restricted assets
[Dev-Happy] Blondfrogs03/29/2019
So we would need to figure out a way to have that info public and keep privacy
S1LVA | GetRavencoin.org03/29/2019
Agree'd
Synicide03/29/2019
that was my worry, that it HAS to be public for a lot of uses. Privacy would have to be optional
[Dev-Happy] Blondfrogs03/29/2019
ravencoin was built and is being built to support asset trading. Privacy is important but isn't currently the focus of the dev team.
Synicide03/29/2019
sounds good, focus on our roadmap and can research it more in the future
S1LVA | GetRavencoin.org03/29/2019
Privacy is one of the very lasts subjects brought up in the whitepaper, after all :wink:
Vincent03/29/2019
to bring up an old topic; assets that haven't been reissued, there was talk about lowering the decimal places to reissue; i know not important but if it needed to be in a hard fork; should it be looked at the add to th next?
[Dev-Happy] Blondfrogs03/29/2019
@Vincent I have found a way to do this, however it requires the reissuer to own all assets
Synicide03/29/2019
how would you determine the correct values if lowering decimals? rounding?
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@[Dev-Happy] Blondfrogs Yes!
Vincent03/29/2019
correct
nice
Synicide03/29/2019
if they all own, I guess its a non-issue
[Dev-Happy] Blondfrogs03/29/2019
We aren't currently working on that, but I will try and get it into the hard fork release
Vincent03/29/2019
it would be a 1 time option, correct?
Rikki RATTOE Sr. SEC Impresantor03/29/2019
In that event too, ability to reduce total supply as well if u still own every asset created would also be an excellent Option to have
When 350? (350club)03/29/2019
Is Bruces worry about the security of Ravencoin a curent issue?
Chill03/29/2019
That seems to be the talk of the day
Zaab03/29/2019
Its just honesty
Sevvy (not worried til 500sats)03/29/2019
We know a 51% attack is cheap
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Depends on if it meets requirements.
Sevvy (not worried til 500sats)03/29/2019
But reorg depth protection is good
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Yes Ravencoin currently doesn't have the network security that Bitcoin does, and water is wet
push | ravenland.org03/29/2019
more full nodes is the answer to a stronger consensus and therefore a more securer network
Sevvy (not worried til 500sats)03/29/2019
Hmmm checks out
push | ravenland.org03/29/2019
:ThinkBlack:
Vincent03/29/2019
right i guess my question is one time at most?
Synicide03/29/2019
It feels like more than just honesty. The last 4 post in a row from the Ravencoin twitter have some type of FUD based around it. Its all you see on the first page when looking at it. Some of that stuff needs to be kept to his personal account
Sevvy (not worried til 500sats)03/29/2019
Probably not a development Question, what Bruce says on his own time. :persevere:
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@Synicide Bruce don't wanna spend a fortune on restricted assets :yum:
Sevvy (not worried til 500sats)03/29/2019
I don't like it myself either though @Synicide
boatsandhoes03/29/2019
yeah the ravencoin twitter has been a bit..... not good to put it easy
Vincent03/29/2019
this is bruces baby...and fud should be taken lightly imo
[Dev-Happy] Blondfrogs03/29/2019
Bruce can say what he wants :_)
Chill03/29/2019
well, it is the unofficial official Twitter page, so it kind of does matter
[Dev-Happy] Blondfrogs03/29/2019
We have taken measures to make sure ravencoin is safe and to stop 51% attacks
Synicide03/29/2019
I agree on his personal account. When people look up this project on twitter, they dont need a full page of fud
push | ravenland.org03/29/2019
its not a very development orientated debate tho in fairness
Vincent03/29/2019
no news will stop a well designed code
S1LVA | GetRavencoin.org03/29/2019
Many new users are asking about IPFS integration. Is this still being researched?
When 350? (350club)03/29/2019
I only asked as it appeared Bruce was saying there is a current security vulnerability..
push | ravenland.org03/29/2019
@[Dev-Happy] Blondfrogs what can people do to help secure the ravencoin network into 2019 and in the future?
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@When 350? (350club) Bruce doesn't code, he wouldn't know
boatsandhoes03/29/2019
sorry, got a late start on this meeting. is kyc stuff on the table for discussion today, or is that at a later meeting?
[Dev-Happy] Blondfrogs03/29/2019
@push | ravenland.org Looks at the PR's, make sure the code being added is well written and secure.
push | ravenland.org03/29/2019
sure thing
and run fullnodes right?
[Dev-Happy] Blondfrogs03/29/2019
Run nodes, and mine ravencoin!
haha
hashpower
push | ravenland.org03/29/2019
:thumbsup:
boatsandhoes03/29/2019
that part
Pho3nix Monk3y03/29/2019
Looks like its time.
Jeroz03/29/2019
Alright, I have to pick up my son. Thanks everyone!
Pho3nix Monk3y03/29/2019
Thanks all
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Thx!
Vincent03/29/2019
:sunglasses:
push | ravenland.org03/29/2019
cheers again :thumbsup: keep up the good work :rvn_hop:
Chill03/29/2019
thanks for everyone's hard work
Synicide03/29/2019
great talks today, thanks guys
Pho3nix Monk3y03/29/2019
Can have an admin shut it down and move this over to another channel until next time.
[Dev-Happy] Blondfrogs03/29/2019
Thanks for voicing your concerns.
S1LVA | GetRavencoin.org03/29/2019
Thanks everyone
Pho3nix Monk3y03/29/2019
@traysi ★★★★★ can you lock it back?
traysi ★★★★★03/29/2019
The channel is locked now.
submitted by mrderrik to Ravencoin [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.72.214.222.226] 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.172.58.37.35] 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.172.58.37.35] 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. https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:09] <@Chatturga> I have made posts on discord, telegram, bitcointalk, reddit, and ravencointalk.org 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.185.245.87.219] has joined #ravencoin-dev
[14:13] == roshii [[email protected]/web/freenode/ip.41.251.25.100] 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.172.58.37.35] 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 [[email protected]/web/freenode/ip.72.200.168.56] 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.173.241.144.77] 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.173.241.144.77] has joined #ravencoin-dev
[14:25] <@wolfsokta> See Tron's post for more details about that.
[14:25] <@spyder_> Hi Tron
[14:25] <@wolfsokta> https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[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.172.58.37.35] 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.24.218.60.237] 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 ravencoin.org 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> https://raven.wiki/wiki/Exchange_notifications#Pools
[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.67.189.233.170] 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.67.189.233.170] 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.138.68.243.202] 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.105.67.2.212] 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.173.241.144.77] 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.173.241.144.77] 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/kiwiirc.com/ip.67.255.25.134] 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.72.200.168.56] 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.185.245.87.219] 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.138.68.243.202] 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]

Bitcoin JSON-RPC Tutorial 7 - Wallet Notify 9. bitcoind Chat app using Node.js and WebSockets - part 2 (JSON-RPC) Dev++ 01-08-EN  Remote Procedure Calls (RPC) - Anditto Heristyo Bitcoin JSON-RPC Tutorial 1

Bitcoin Cash Node documentation bitcoin-qt Initializing search GitLab Bitcoin Cash Node documentation ... -torpassword=<pass> Tor control port password (default: empty)-upnp: Use UPnP to map the listening port (default: 0) -useextversion: Enable extended versioning handshake (default: 0)-whitebind=<addr> Bind to given address and whitelist peers connecting to it. Use [host]:port notation for ... Introduction. In this tutorial, we will be taking a closer look at bitcoin's ZeroMQ messaging interface. This interface is useful for developing applications which might require data related to block and transaction events from a Bitcoin core node. Some applications which include block explorers, wallets and reporting dash boards to name just a few. Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up. Sign up to join this community. Anybody can ask a question Anybody can answer The best answers are voted up and rise to the top Bitcoin . Home ; Questions ; Tags ; Users ; Jobs; Unanswered ; How do you change rpc password? Ask Question Asked 2 years, 6 months ago ... walletlock¶. walletlock. Removes the wallet encryption key from memory, locking the wallet. After calling this method, you will need to call walletpassphrase again before being able to call any methods which require the wallet to be unlocked. Every Bitcoin RPC command can be added as an endpoint in this API to make fully functional Bitcoin applications. With these 12 methods we have setup a communication with our Bitcoin node that will ...

[index] [1932] [17791] [21341] [9709] [51388] [7239] [16618] [23742] [16485] [16164]

Bitcoin JSON-RPC Tutorial 7 - Wallet Notify

How to run a Bitcoin Full Node(Linux + Build from Source) - Duration: 14 ... Bitcoin JSON-RPC Tutorial 4 - Command Line Interface - Duration: 5:14. m1xolyd1an Recommended for you. 5:14 . Bitcoin ... Bitcoin JSON-RPC tutorial. How to set up and use bitcoind wallet notify feature. How to set up and use bitcoind wallet notify feature. My Book: Building Bitcoin Websites - https://www.amazon.com ... Bitcoin JSON-RPC Tutorial 5 - Your First Calls - Duration: 10:06. m1xolyd1an 11,766 views. 10:06. ... Buổi 1 - Build web real time với NODEJS + SOCKETIO - Duration: 1:19:31. Trung Tâm Đào ... Anditto covers basics of Remote Procedure Calls (RPC) that allow developer to use Bitcoin client to interact with Bitcoin network. How to configure and interact with Bitcoin using RPC (create ... In this video we will build a complete authentication app with login, register and access control using Node.js, Express, Passport, Mongoose and more. Sponso...

#