Giter Club home page Giter Club logo

hush's People

Contributors

ageis avatar bitcartel avatar codeshark avatar cozz avatar daira avatar defuse avatar ebfull avatar fanquake avatar firemartz avatar gavinandresen avatar gmaxwell avatar j-stuhlman avatar jonasschnelli avatar jtimon avatar laanwj avatar leto avatar lludlow avatar luke-jr avatar muggenhor avatar non-github-bitcoin avatar paveljanik avatar petertodd avatar radix42 avatar rebroad avatar sdaftuar avatar sipa avatar str4d avatar thebluematt avatar theuni avatar zkbot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hush's Issues

Hush Messenger Protocol Spec

Describe the issue

We need an HMP spec on Github

Can you reliably reproduce the issue?

Yes

Bounty

TBD

If so, please list the steps to reproduce below:

  1. No
  2. Spec
  3. Exists (outside of @radix42's head)

Expected behaviour

A publicly viewable spec which we can point people at and take Github Pull Requests on.

Web Wallet

Why I'm unable to open my hush web wallet. I stored my hush coins in web wallet but the link for web wallet doesn't work.

This issue tracker is only for technical issues related to hushd, the Hush node daemon.

General Hush questions and/or support requests and are best directed to the Hush Forums or Slack Chat.

For reporting security vulnerabilities or for sensitive discussions with our security team, please contact your local nasal demon via ICMP.

Describe the issue

Please provide a general summary of the issue you're experiencing

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

Expected behaviour

Tell us what should happen

Actual behaviour + errors

Tell us what happens instead including any noticable error output (any messages displayed on-screen when e.g. a crash occurred)

The version of Hush you were using:

Run hushd --version to find out

Machine specs:

  • OS name + version:
  • CPU:
  • RAM:
  • Disk size:
  • Disk Type (HD/SDD):
  • Linux kernel version (uname -a):
  • Compiler version (gcc -version):

Any extra information that might be useful in the debugging process.

This includes the relevant contents of ~/.hush/debug.log. You can paste raw text, attach the file directly in the issue or link to the text via a pastebin type site.
Please also include any non-standard things you did during compilation (extra flags, dependency version changes etc.) if applicable.

Do you have a back up of ~/.hush directory and/or take a VM snapshot?

  • Backing up / making a copy of the ~/.hush directory might help make the problem reproducible. Please redact appropriately.
  • Taking a VM snapshot is really helpful for interactively testing fixes

new difficulty algorithm

The current difficulty algorithm appears to have an averaging window of N=50 which is pretty long and 3x more than Zcash. This allows big miners to come on and off, "stealing" blocks before the diff algo is able to rise, leaving small miners with a higher-than-necessary difficulty. There appears to be 5 to 10 "attacks" like this per day of miners with ~2x the network hashrate, getting 10 to 20 blocks at 1/3 the correct difficulty setting.

An argument can be made for just copying Zcash, but N=17 still invites attacks. Also, Daira has said they should have gone to < 3600 +/- timestamp limit. I think +/- 1000 is good.

N=10 is better and if it is used I recommend using my zawy v1b. Karbowanek coin has spent a lot of time with me testing it and looking for something better. N=10 in the Zcash algo may be pretty much the same but I distrust trying to use median like they do, especially with smaller N, at least without tweaking it again to make sure the average comes out correct. Str4d said it was to deal with bad timestamps, but now I know the average immediately corrects the bad timestamp's effect in the next block (if it is allowed to go negative) and it should be better due to accuracy.

But I would like to see N=8 used and call it "Gandalf's difficulty algorithm" (see below). No attacker could profit from it, assuming it's not worth getting only 2 to 4 free blocks before having to change coins again. The "free blocks" obtainable from diff algo's is 1/4 the N averaging window, but up to 1/2 N if they begin the attack when D is accidentally low, and then mine for 3/4 N with > 3x hash rate.

The following looks simple, but the link above shows how much work I've done in advanced techniques like a variable averaging window, hash-attack detection using statistics, least-squares slope prediction, significant-slope-change detection, mixtures of avg and median, recent-blocks-more-heavily-weighted, and "discrete D/T averaging" as a hashrate measurement. I was able to get all of them only as good as simple averaging, and none of them better than simply going to a smaller N for averaging.

# Gandalf's difficulty algorithm v1.  "Hash attacks shall not pass!"
# This is Zawy v1b with low N=8 (and X=5)
# Timestamp manipulation protection is not needed due to limits on next_D.  
# Negative timestamps must be allowed.
# 0.92 keeps avg solvetime on track but makes median come out 8% low. I can't find a fix.
# Increase N to 30 if you want correct avg & median, but expect 10% of blocks in small 
# coins to be stolen.   Median mixed in w/ avg will not help. 
# Do not use sum(D's) * T / [max(timestamp)-min(timestamp)] method.
#  5% block solvetimes are > 5x target solvetime under constant HEAVY attack.
#  1.3%  block solvetimes > 5x target solvetime when hashrate is constant. 
#  3% of blocks will be < 0.5x or > 2x the correct difficulty on accident.
#  When N=15 these numbers are 5%,, 1%, and 0.5%.   
https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a

avg(last 8 solvetimes) = 1 if avg(last 8 solvetimes) < 1; # prevent divide by zero
next_D = avg(last 8 Ds) * TargetInterval / avg(last 8 solvetimes] *0.92;
next_D = 1.6*previous_D  if next_D/previous_D > 1.6;
next_D = 0.63*previous_D  if next_D/previous_D < 0.63;

The only potential problem I see is that the D will swing below 0.5 the correct D a lot, attracting an attack. But they can only get ~4 blocks at low difficulty. A question I need an answer to is this: How short of a "hash attack" can a big miner with 2x network hashrate accept before it is not worth switching coins to go work on a coin that is going to know his difficulty in X blocks? What is the upper bound on X for 90% of miners? What is the time cost in switching coins? I can go to N=5 which will result in a lot of D < 0.33 correct D, which is really attractive, but is worth 3 blocks for them to switch coins?

backend miner.myhush.org upgrades

Describe the issue

miner.myhush.org does not support SSL. To fully support SSL, we must support Secure WebSockets (WSS), which requires opening up new server ports, and new nginx configs and updating HTML/JS with relevant URL and code changes.

Additionally, the Perl code that is the dynamic part of the codebase needs to be made into a CPAN module, to be testable and trivially distributable via-known-trusted channels like package managers.

Additionally, we need to be able to payout to N addresses with arbitrary ratios, to enable many use cases.

Can you reliably reproduce the issue?

Yes

Bounty

250 Hush

Expected behavior

miner.myhush.org has modern TLS security deployed and is able to ask people to input a taddr and then send a certain percentage of that browser tab's mining to their custom address.

Additionally, it is a CPAN module which reads in a custom config file, and is trivially installable on every server Perl exists (just about every one).

Actual behaviour + errors

We use HTTP currently which can be re-written by evil network operators, and leaks metadata.

The version of Hush you were using:

All

Changes required for upstream 1.0.13 merge

Upstream files left to merge for 1.0.13

Docs need to be generated and decision needs to be made about how long to wait before deprecation.

Hush has not had a valid regtest genesis block. So, that should be generated as well otherwise there is no real qa.

  • doc/man/zcash-cli.1
  • doc/man/zcash-tx.1
  • doc/man/zcashd.1
  • doc/release-notes/release-notes-1.0.13-rc1.md
  • doc/release-notes/release-notes-1.0.13-rc2.md
  • doc/release-notes/release-notes-1.0.13.md
  • src/clientversion.cpp
  • src/deprecation.h
  • src/gtest/test_foundersreward.cpp

Bounty

400 Hush to be paid by @Acidut

Continuous Integration

Describe the issue

Hush does not have CI.

Can you reliably reproduce the issue?

Yup

If so, please list the steps to reproduce below:

  1. Observe
  2. No CI
  3. Exists

Expected behaviour

Continuously integrated goodness

Actual behaviour + errors

No way to tell if a commit breaks the build!!!

The version of Hush you were using:

All

hush-cli restart

Describe the issue

No easy way to restart hushd

$ ./src/hush-cli restart
error code: -32601
error message:
Method not found

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. Try to restart
  2. Get an amazingly not useful error message
  3. See above

Expected behaviour

The hushd daemon should restart.

Actual behaviour + errors

Silly error message that is confusing to new users.

The version of Hush you were using:

$ ./src/hushd --version
Zcash Daemon version v1.0.9-c54a837

TLS

Describe the issue

Hush only supports HTTP and therefore connecting to an RPC backend is only "safe" over localhost, otherwise it would leak lots of metadata and rpc user/pass. Hush should support TLS like Bitcoin and other coins like Zen. Encrypted p2p connections will additionally greatly reduce network metadata available to snoopy people.

Bounty

TBD

Can you reliably reproduce the issue?

Yup

If so, please list the steps to reproduce below:

  1. Observe
  2. No
  3. TLS

Expected behaviour

Support TLS connections,

Actual behaviour + errors

No TLS

The version of Hush you were using:

All

Prior Art

See ZEN's TLS_integration branch: https://github.com/zencashio/zen/compare/master...ZencashOfficial:TLS_integration?expand=1
and the corresponding issue: HorizenOfficial/zen#26

Private vs Anonymous on myhush.org

Describe the issue

We need to very clearly explain privacy and anonymity on our homepage and how they relate to Hush.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. Privacy
  2. Does Not Equal
  3. Anonymity

But our homepage confuses them.

Expected behaviour

Privacy is not the same as anonymity, and we need to explain that to our potential users.

Actual behaviour + errors

Teach people good stuff instead of spreading FUD

Change Hard-coded Nodes

Issue

We need to adjust the hard-coded nodes to account for removal of myhush.network.

Replacement list

  • explorer.myhush.org
  • hushipv4.matthewreichardt.com

doc/authors.md is kind of confusing

Describe the issue

This file lists Zcash contributors and commit counts. We need to decide if we want to start fresh with a list of Hush contributors or keep this list and add to it in some way.

Can you reliably reproduce the issue?

Yes, erryday

If so, please list the steps to reproduce below:

  1. Look
  2. at
  3. doc/authors.md

Expected behaviour

A nice list of Hush contributors should be seen.

Actual behaviour + errors

Old list of Zcash contributors is currently there.

The version of Hush you were using:

All

cannot connect anymore to peers

since 4 days (4 february) I cannot sync anymore to network

I also try to port forward 8888 with no succes. any idea ?

in ~/.hush/debug.log

2018-02-08 19:31:31 socket recv error Connection reset by peer (104)
2018-02-08 19:31:31 connect() to [2001:0:9d38:953c:1ca7:e871:a472:fde9]:8888 failed: Network is unreachable (101)
2018-02-08 19:31:32 socket recv error Connection reset by peer (104)
2018-02-08 19:31:33 connect() to [2001:0:9d38:90d7:c8f:3875:b635:d6a8]:8888 failed: Network is unreachable (101)
2018-02-08 19:31:39 socket recv error Connection reset by peer (104)
2018-02-08 19:31:40 connect() to 46.147.23.0:8888 failed after select(): Connection refused (111)
2018-02-08 19:31:41 socket recv error Connection reset by peer (104)
2018-02-08 19:31:48 socket recv error Connection reset by peer (104)
2018-02-08 19:31:50 socket recv error Connection reset by peer (104)
2018-02-08 19:31:55 connect() to [2001:0:4137:9e76:c60:6ad2:2ac8:4f36]:8888 failed: Network is unreachable (101)
2018-02-08 19:31:56 socket recv error Connection reset by peer (104)
2018-02-08 19:31:57 socket recv error Connection reset by peer (104)
2018-02-08 19:31:58 socket recv error Connection reset by peer (104)
2018-02-08 19:31:59 socket recv error Connection reset by peer (104)
2018-02-08 19:32:05 connect() to [2a01:cb08:5c:300:35e9:622f:2ab0:29f4]:8888 failed: Network is unreachable (101)
2018-02-08 19:32:11 connect() to [2001:0:4137:9e76:4de:3453:b992:c6b9]:8888 failed: Network is unreachable (101)
2018-02-08 19:32:12 connect() to [2001:0:9d38:6abd:c5d:c204:a88b:4f82]:8888 failed: Network is unreachable (101)
2018-02-08 19:32:14 socket recv error Connection reset by peer (104)
2018-02-08 19:32:14 socket recv error Connection reset by peer (104)
2018-02-08 19:32:15 socket recv error Connection reset by peer (104)

Testnet explorer

Describe the issue

We have a testnet, but no explorer! It would make it easier on devs if they could look at explorer pages for testnet xtns and stuff like that.

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. Observe
  2. No
  3. Testnet explorer

Bounty

TBD

Expected behaviour

Awesome testnet explorer exists

Actual behaviour + errors

No testnet explorer

Default hush nodes

Describe the issue

No list of default nodes

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. No
  2. Default
  3. Nodes

Expected behaviour

This:

addnode=us.madmining.club
addnode=183.89.226.141
addnode=163.172.70.26
addnode=76.188.211.191
addnode=173.212.196.148
addnode=78.94.32.197
addnode=77.78.12.89
addnode=78.46.88.113
addnode=163.172.70.26
addnode=192.99.3.29
addnode=144.76.62.229
addnode=163.172.64.208
addnode=37.187.167.145
addnode=[2607:5300:60:341d::1]
addnode=[2001:41d0:d:691::]
addnode=[2a02:c207:2008:8708::1]
addnode=[2001:470:1f09:3b6:7285:c2ff:fe0e:1664]
addnode=[2a02:908:162:67dc:225:90ff:fe50:2b9b]

Actual behaviour + errors

Nothing

The version of Hush you were using:

All

sorry this is not an issue i need orientation

sorry i need orientation on how to edit the chainparams to make my own chain and have my own coin
i was using different sources but i was success with the litecoin source but i'm searching for the equihash algo
please can anyone help me or give me some link where i can read what to do?

thanks

Barterdex issue

This issue tracker is only for technical issues related to hushd, the Hush node daemon.

General Hush questions and/or support requests and are best directed to the Hush Forums or Slack Chat.

For reporting security vulnerabilities or for sensitive discussions with our security team, please contact your local nasal demon via ICMP.

Describe the issue

Please provide a general summary of the issue you're experiencing

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

Expected behaviour

Tell us what should happen

Actual behaviour + errors

Tell us what happens instead including any noticable error output (any messages displayed on-screen when e.g. a crash occurred)

The version of Hush you were using:

Run hushd --version to find out

Machine specs:

  • OS name + version:
  • CPU:
  • RAM:
  • Disk size:
  • Disk Type (HD/SDD):
  • Linux kernel version (uname -a):
  • Compiler version (gcc -version):

Any extra information that might be useful in the debugging process.

This includes the relevant contents of ~/.hush/debug.log. You can paste raw text, attach the file directly in the issue or link to the text via a pastebin type site.
Please also include any non-standard things you did during compilation (extra flags, dependency version changes etc.) if applicable.

Do you have a back up of ~/.hush directory and/or take a VM snapshot?

  • Backing up / making a copy of the ~/.hush directory might help make the problem reproducible. Please redact appropriately.
  • Taking a VM snapshot is really helpful for interactively testing fixes

New official Hush testnet #bounty

Describe the issue

We do not have a testnet for core devs to develop new features on and use as a testing ground.

Bounty

This is worth 500 Hush

Can you reliably reproduce the issue?

Yes.

If so, please list the steps to reproduce below:

  1. Observe
  2. No
  3. Testnet

Expected behaviour

A testnet should exist.

Actual behaviour + errors

To close this issue, we must have a new Genesis block created and mined. Then, the IP of the origin testnet node needs to be added to the code and then other nodes can begin to connect to the testnet.

This issue is only for getting the origin node up and running and the genesis block created and mined.

ToDo

  • Generate new Hush genesis block
  • Mine new genesis block
  • Update testnet code with IP of new origin testnet node

The version of Hush you were using:

All

Adjust auto-senescence parameters

Since merging 1.0.9 updates from upstream, nodes have an auto-senescence feature that causes versions more than roughly 18 weeks old to not run without a flag to override this.

We need to adjust parameters to match HUSH block heights, and possibly make for a longer deprecation period or consider not enabling by default.

Original upstream issue is zcash/zcash#2274 and was implemented in zcash/zcash#2297

Hush Messenger Reference Implementation

Describe the issue

The Hush Messenger Protocol needs a reference implementation, hopefully written in a language that does not hate humans.

Bounty

= 1000Hush

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. No
  2. Implementation
  3. Exists

Expected behaviour

Hush messages shall fly freely, like birds in the wind.

Actual behaviour + errors

Hush messages dream of the day they will be let from their coops.

The version of Hush you were using:

All

incorrect size of solution

In my Hush pool i have tryed to change diff setting from 0.1 upto 128 and still same errors

could anyone tell me where i messed up ?

[Pool] [hush] (Thread 4) Share rejected: {"job":"cccd","ip":"::ffff:31.24.216.135","worker":"t1aPXQqsm9fFZzhFotsYeJyvve3SNgURCQH.Rig18","difficulty":2.4,"error":"incorrect size of solution"}

Linux wallet encryption problem

Describe the issue

Wallet encryption on Linux is not working

error code: -16
error message:
Error: wallet encryption is disabled.

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. Cannot
  2. Use an encrypted Wallet
  3. On Linux

Expected behaviour

Wallets should be able to be encrypted.

Actual behaviour + errors

Error above.

The version of Hush you were using:

“version”: 1000950,

Machine specs:

  • OS name + version: Ubuntu 16.04

Hush Stuck between online wallet and cryptopia

Hi Hust team,

I was transferring my hush from the web wallet to Cryptopia exchange. (last week)

Hush never arrived.

My friends having a same problem as well.

Help please to solve this problem.

Thanks,

Zsolt

Discord invite has expired

The discord invite in the github doc has expired

Please can you update the discord invite / make it a perm invite

Reproducible/Deterministic Builds

Describe the issue

No deterministic builds

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. Compile and observe,
  2. No
  3. Reproducibility

Bounty

500HUSH

Expected behaviour

Since Bitcoin Core and Zcash have reproducible builds, we should as well. It increases the security of our entire ecosystem.

Actual behaviour + errors

We do not have Gitian setup

The version of Hush you were using:

All

Any extra information that might be useful in the debugging process.

I like tuhtles

Releases needs prebuilt binaires

Describe the issue

No one likes building stuff that takes 10 minutes - 1 hour constantly. Including .debs and .zips of prebuilt binaries is always useful

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. go to https://github.com/MyHush/hush
  2. be disappointed you have to build
  3. wait 10 minutes

Expected behaviour

  1. go to https://github.com/MyHush/hush
  2. click releases
  3. download
  4. dpkg -i hush.deb

Any extra information that might be useful in the debugging process.

There's a script to automatically package binaries into a deb in zcutil
https://github.com/MyHush/hush/blob/master/zcutil/build-debian-package.sh

Can't build on Manjaro/Arch

Running ./zcutil/build.sh -j$(nproc) fails on Manjaro 64bit

checking for boostlib >= 1.20.0... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system-mt... no
configure: error: Could not link against boost_system-mt !

The zCash solution is to run build.sh w/ --disable-proton, but even though this is present in the configuration file, the script doesn't accept it, "invalid argument --disable-proton"
edit: I see that disable-proton is default on the build file.

I'm currently attempting to change PREFIX="/usr/" to see if that works
update: somehow didn't pick up on the db headers.

Tried now with setting --with-boost-libdir=/usr/lib64 still getting same error.

Large Hush transactions fail

Description

Getting an error when trying to send HUSH from my wallet to another address

Error 16: bad-txns-oversize

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. Send 300 Hush
  2. In One
  3. Transaction

Expected behaviour

Should send 300 Hush.

Actual behaviour + errors

Fails to send 300, gives error.

The version of Hush you were using:

All

Machine specs:

All

Problems with installation instructions

Describe the issue

Running "sudo echo 'deb https://dl.bintray.com/myhush/hush/ hush main' >> /etc/apt/sources.list" errors with "permission denied: /etc/apt/sources.list". Using "echo 'deb https://dl.bintray.com/myhush/hush/ hush main' | sudo tee --append /etc/apt/sources.list.d/hush.list" works as expected.

Also "apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 379CE192D401AB61" should be executed with sudo otherwise it fails to install the key.

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. Follow the installation instructions
  2. Observe the errors

Expected behaviour

The repository should be added to sources and the key should install correctly.

Generating custom OP_RETURN data

Describe the issue

The createrawtransaction RPC method in Hush does not support a data key to embed data into a raw transaction via OP_RETURN.

This makes it hard/impossible to port a tool such as https://github.com/coinspark/python-OP_RETURN to Hush, since there is no RPC access to raw transactions that gives us what we need.

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. Try to create custom data in a raw transaction
  2. Realize you can't
  3. Win/lose

Expected behaviour

A hush developer should be able to create custom raw transactions with data keys, so as to enable embedding data via OP_RETURN, like http://coinsecrets.org/

Actual behaviour + errors

No way to create custom OP_RETURN data

The version of Hush you were using:

All

Error building hush on ARM chromebook

Describe the issue

When trying to compile the latest hush.git from source:

g++: error: unrecognized command line option "-m64"

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. ./zcutil/build
  2. Error happens when building boost

Expected behaviour

hush should build correctly

Actual behaviour + errors

When boost is being compiled, it seems to compile for x86_64 when this is an ARM7vl system.

The version of Hush you were using:

hush.git master 875183b360f4

Machine specs:

  • OS name + version: Ubuntu 14.04.5 LTS (ChromeOS)
  • CPU: arm7vl
  • RAM: 2GB
  • Disk size:
  • Disk Type (HD/SDD):
  • Linux kernel version (uname -a): Linux 3.8.11
  • Compiler version (gcc -version): 4.8.4-2ubuntu~14.04.03

v1.0.9-mac branch

I generated a diff between the radis42/zcash v1.0.8-1-mac-gcc branch and the zcash v1.0.8 branch to pick up the mac specific differences for a build.

I've generated a v1.0.9-mac branch from the hush v1.0.9-lin branch in my hush fork here:

https://github.com/ianblenke/hush

The only real difference in my patched branch is that I don't have any of the client name changes from MagicBean to AppleSeed as with zcash4mac. There is a README-mac.md that should help building and using this branch.

As this is a new branch, I can't really generate a proper github PR for this.

Fix https://explorer.myhush.org

Describe the issue

Currently we are using a self-signed cert which has scary warnings.

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. Self
  2. Signed
  3. Cert

Expected behaviour

Proper cert

Actual behaviour + errors

Scary warnings to average people 😢

The version of Hush you were using:

All

Hush ec2 AMI

Problem

Not easy to spin up a Hush server on ec2.

Can you reliably reproduce the issue?

All the time.

If so, please list the steps to reproduce below:

  1. No
  2. ec2
  3. AMI

Mine a regtest Genesis Block for testing

Describe the issue

No regtest genblock

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

  1. No
  2. Regtest
  3. GenBlock

Bounty

100 Hush

Expected behaviour

Devs should be able to run RPC tests/other in regtest mode.

Actual behaviour + errors

Doesn't exist, can't run the tests

The version of Hush you were using:

All

"hush-cli help" references "zcashaddress"

When running "hush-cli help" command it references "zcashaddress" which could lead to confusion. For example, one line of the returned text shows:
sendtoaddress "zcashaddress" amount ( "comment" "comment-to" subtractfeefromamount )

To avoid confusions, it should return something like:
sendtoaddress "hushaddress" amount ( "comment" "comment-to" subtractfeefromamount )

I saw this on hushd version v1.0.9-9b5ced9

Hush Miner in JS #bounty

The cheklist

  • working js miner
  • hosting for miner
  • build widget code

Describe the issue

We need a miner in JS, prior art:

https://forum.z.cash/t/zcash-javascript-miner/17496/21

Bounty

100 Hush

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. We
  2. Have
  3. None

Expected behaviour

Mining Hush in the browser!

Actual behaviour + errors

Doesn't exist

The version of Hush you were using:

All

Make myhush.github.io awesome

Describe the issue

It's just a temporary README right now

Can you reliably reproduce the issue?

Yup

If so, please list the steps to reproduce below:

  1. It
  2. Looks
  3. Bad

Expected behaviour

Super snazzy developer-oriented website to be an "easy onramp" for Hush devs/miners/pool ops/etc..

Actual behaviour + errors

Ain't nothin' there

Document how to run a testnet node

Describe the issue

We need docs on how to run a testnet node, or else nobody will know how.

Can you reliably reproduce the issue?

Yes

If so, please list the steps to reproduce below:

  1. No
  2. Docs
  3. TO RTFM

Expected behaviour

To be able to RTFM

Actual behaviour + errors

No RTFMing possible

The version of Hush you were using:

ALL

Automatic deprecation shutdown feature. How do I get rid of it? If there is no upgrade?

This issue tracker is only for technical issues related to hushd, the Hush node daemon.

General Hush questions and/or support requests and are best directed to the Hush Forums or Slack Chat.

For reporting security vulnerabilities or for sensitive discussions with our security team, please contact your local nasal demon via ICMP.

Describe the issue

Automatic deprecation shutdown feature. How do I get rid of it? If there is no upgrade? Is there a quick upgrade ?

Messages:

  • Warning: This version will be deprecated at block height 193076, and will automatically shut down. You should upgrade to the latest version of
    Zcash. To disable deprecation for this version, set -disabledeprecation=1.0.9.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.