by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:46
    jaspervdm synchronize #3433
  • Sep 17 14:01
    lehnberg opened #3447
  • Sep 16 17:10
    quentinlesceller synchronize #3431
  • Sep 16 17:03

    quentinlesceller on master

    cleanup mining stats (#3439) *… (compare)

  • Sep 16 17:03
    quentinlesceller closed #3439
  • Sep 16 14:28

    antiochp on 4.1.x

    bump current/4.1.x to 4.1.1-alp… (compare)

  • Sep 16 14:28
    antiochp closed #3446
  • Sep 16 13:58
    antiochp opened #3446
  • Sep 16 13:40

    antiochp on v4.1.0

    (compare)

  • Sep 16 13:38

    antiochp on 4.1.x

    bump version to 4.1.0 final for… (compare)

  • Sep 16 13:38
    antiochp closed #3444
  • Sep 16 13:31
    antiochp milestoned #3445
  • Sep 16 13:31
    antiochp opened #3445
  • Sep 16 13:13
    antiochp opened #3444
  • Sep 16 13:11
    jaspervdm commented #3433
  • Sep 16 13:01
    jaspervdm synchronize #3433
  • Sep 15 16:26

    antiochp on master

    bump working version on master … (compare)

  • Sep 15 16:26
    antiochp closed #3443
  • Sep 15 16:20

    antiochp on v4.1.0-beta.1

    (compare)

  • Sep 15 16:15

    antiochp on 4.1.x

    bump new 4.1.0 branch to 4.1.0-… (compare)

John Tromp
@tromp
in cuckoo-miner/src/cuckoo_sys/plugins/CMakeLists.txt, can you comment out line 104 for building cuckatoo_mean_cuda_19 ?
and let me know if that causes problems?
rostfrei
@rostfrei
@tromp This solved the compilation problem. Thank you! Now I have runtime problem
[root@localhost grin-miner]# ./target/debug/grin-miner
Starting Grin-Miner from config file at: /root/Developement/grin-miner/grin-miner.toml
Jan 10 23:32:28.048 INFO This is Grin-Miner version 3.0.0-beta.1 (git v3.0.0-beta.1), built for x86_64-unknown-linux-gnu by rustc 1.40.0.
Jan 10 23:32:28.354 ERRO
thread 'unnamed' panicked at 'called `Option::unwrap()` on a `None` value': src/libcore/option.rs:378stack backtrace:
   0: grin_miner_util::logger::send_panic_to_log::{{closure}}
             at util/src/logger.rs:120
   1: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:468
   2: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
   3: rust_begin_unwind
             at src/libstd/panicking.rs:302
   4: core::panicking::panic_fmt
             at src/libcore/panicking.rs:139
   5: core::panicking::panic
             at src/libcore/panicking.rs:70
   6: core::option::Option<T>::unwrap
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libcore/macros.rs:41
   7: cuckoo_miner::miner::miner::CuckooMiner::solver_thread
             at cuckoo-miner/src/miner/miner.rs:95
   8: cuckoo_miner::miner::miner::CuckooMiner::start_solvers::{{closure}}
             at cuckoo-miner/src/miner/miner.rs:228
   9: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/sys_common/backtrace.rs:129
  10: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/thread/mod.rs:469
  11: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/panic.rs:317
  12: std::panicking::try::do_call
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/panicking.rs:287
  13: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  14: std::panicking::try
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/panicking.rs:265
  15: std::panic::catch_unwind
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/panic.rs:396
  16: std::thread::Builder::spawn_unchecked::{{closure}}
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libstd/thread/mod.rs:468
  17: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /builddir/build/BUILD/rustc-1.40.0-src/src/libcore/ops/function.rs:227
  18: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /builddir/build/BUILD/rustc-1.40.0-src/src/liballoc/boxed.rs:942
  19: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /builddir/build/BUILD/rustc-1.40.0-src/src/liballoc/boxed.rs:942
      std::sys_common::thread::start_thread
             at src/libstd/sys_common/thread.rs:13
      std::sys::unix::thread::Thread::new::thread_start
             at src/libstd/sys/unix/thread.rs:79
  20: start_thread
  21: clone



Thread 'unnamed' panicked with message:
"called `Option::unwrap()` on a `None` value"
See grin.log for further details.
Jan 10 23:32:29.238 WARN Connection Status: Connected to Grin server at floonet-stratum.grinmint.com:13416.
Jan 10 23:32:30.010 INFO Got a job at height 320801 and difficulty 4
Jan 10 23:32:31.062 INFO Mining: Cucka*oo* at 0 gps (graphs per second)
Jan 10 23:32:32.003 INFO Got a new job: JobTemplate { height: 320801, job_id: 11, difficulty: 4, pre_pow: "0003000000000004e521000000005e18fb7e30d1db9bb92d3292ee0d8117b21e680200922b7de30a0a87d05aba2592699829e82d09d41b05beabf18f1456be7c7e4d2ac8ce48105a6bde63af1222f6082a8dd402118737bcb53a87e6bf9bee9c50d61a0030b8b7a4d0a348669a561419812280f2986b2b01775a5461c749547f6f60e5ad5ce5360363002ba279e6b0dad60096809fa98f4d7625c0711317ac9bfa499b8b6dd1a615fd9d8b564d6caa484050bcd38d9698f4f8cfbe7e3f643ddf6db159ce69da8c9646270b0c02a5bd37ae4c00000000000c97aa00000000000a9ada000000fe14829e330000000d" }
John Tromp
@tromp
i'm afraid i can't help with that
it somehow failed to create a solver context
John Tromp
@tromp
perhaps you can file an issue at https://github.com/mimblewimble/grin-miner/issues
rostfrei
@rostfrei

Thank you @tromp You helped me a lot. Maybe somebody else will be able to help me with this one. I have these graphics cards

[root@localhost grin-miner]# nvidia-smi
Fri Jan 10 23:37:32 2020
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 435.21       Driver Version: 435.21       CUDA Version: 10.1     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 106...  Off  | 00000000:0A:00.0  On |                  N/A |
| 33%   30C    P8     6W / 130W |     23MiB /  3016MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce RTX 2080    Off  | 00000000:0B:00.0 Off |                  N/A |
|  0%   35C    P8     1W / 225W |      1MiB /  7982MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1835      G   /usr/bin/X                                    21MiB |
+-----------------------------------------------------------------------------+

and this miner configuration

# currently requires 6GB GPU memory
[[mining.miner_plugin_config]]
plugin_name = "cuckaroom_cuda_29"
#plugin_name = "cuckarood_cuda_29"
# or, prior to 2nd hardfork: plugin_name = "cuckarood_cuda_29"
#[mining.miner_plugin_config.parameters]
device = 1
cpuload = 1
ntrims = 399
#ntrims = 31
# or, prior to 2nd hardfork: ntrims = 31
genablocks = 1024
recoverblocks = 2048
recovertpb = 256
I am trying to mine with cuckaroom pow on
# whether to run the tui
run_tui = false

# listening grin stratum server url
#stratum_server_addr = "127.0.0.1:3416"
#stratum_server_addr = "eu-west-stratum.grinmint.com:3416"
stratum_server_addr = "floonet-stratum.grinmint.com:13416"

# login for the stratum server (if required)
stratum_server_login = "5647+test@gmail.com/rig1"

# password for the stratum server (if required)
#stratum_server_password = "x"
rostfrei
@rostfrei
I'm trying to prepare for the upcoming Grin fork in 2 days for the cuckaroom algorithm. I'm not able to make grin-miner work and I have not managed to get any closed sourced miner that support cuckaroom algo. None of the recommended miners on https://floonet.grinmint.com/help.html support it currently. What miner will people use when the fork actually happen? Does anybody know any miner that currently support cuckaroom algorithm and is able to communicate with stratum pool protocol?
Quentin Le Sceller
@quentinlesceller
@rostfrei currently there is:
佘奕敏
@elvinsophus
Hello guys, I need some help. What is the "token" param in the Grin wallet API v3?
(https://docs.rs/grin_wallet_api/3.0.0/grin_wallet_api/trait.OwnerRpcS.html#) I succeeded in generating the shared public key as well as encrypting the request and decrypting the response, but could not figure out where to find the "token".
SW van Heerden
@SWvheerden
Hi, I have a question regarding the header field "total_kernel_offset". Is there a reason why the total accumulated offset is stored in the header and not just the offset per block?
The only pro of doing it this way is that you can have the total when doing a complete chain validation. You dont have to look at every header and sum it.
But if you store it per block you can validate a block on its own and not in the chain, eg an orphan block that you dont yet have the parent for.
John Tromp
@tromp
without parent you cannot check proof of work. checking PoW is first step before spending time on sig validation
Antioch Peverell
@antiochp
Hi @SWvheerden this is also to keep the data in the block header consistent - with the focus on full chain state per header (see various MMR root and size fields). Each header represents a full block of data that is appended to the existing full chain state. MMR are appended to and roots (and sizes) calculated. The kernel offset is added to in the same way.
SW van Heerden
@SWvheerden
thanks
Antioch Peverell
@antiochp
In the future we may implement "flyclient" and allow nodes to quickly sync without necessarily having validated all previous headers - the total offset comes in very useful in this scenario.
Photis Phudge
@photis

Anyone else ran across this while compiling cuckoo_miner v3.0.0-beta.1?

CMake Error at /usr/share/cmake-3.10/Modules/FindCUDA.cmake:1801 (add_library):
Cannot find source file:  cuckoo/src/cuckaroom/kernel.cuh

(using CUDA Toolkit v9.2)

Photis Phudge
@photis

Found it!

git submodule update --remote —recursive
cargo clean
cargo buildrelease

did the trick.

Mark Renten
@rentenmark
i see the igno persona is alive and well https://github.com/mimblewimble/grin-wallet/releases is igno back to active?
or is it someone else?
Quentin Le Sceller
@quentinlesceller
It’s just that the release automated process uses its github token :).
Mark Renten
@rentenmark
aww :/ nvm then lol
aleqx
@aleqx
Just spoke to Poloniex, who recently (12h before the fork) disabled GRIN deposit and withdrawals. They just replied to say that the "GRIN wallet is not working properly at the moment" and that they have no timeline for re-enabling it. I wanted to mention it in case any one of you wants to reach out to help them ... I presume they wanted to upgrade to 3.0 and ran into issues.
Quentin Le Sceller
@quentinlesceller
aleqx
@aleqx
good to know, it seems their support is not (always) aware of what the dev team and marketing team is doing, as their reply to me saying it's not working and no ETA was after that tweet
lehnberg
@lehnberg
Bi-weekly dev meeting taking place right now in grincoin#dev on Keybase
Jacks
@JakobAbf_twitter
Does anybody know the guy who has created the npm bindings for secp256k1-zkp mimblewimble fork? https://github.com/DaniloShan/secp256k1-zkp
Ghost
@ghost~5a84a8dfd73408ce4f8d2d24

I'm attempting to build grin targeting aarch64-unknown-linux-gnu to run on my raspberry pi.

I'm getting an error

= note: /usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lncursesw
          collect2: error: ld returned 1 exit status

When I run sudo apt-get install libncursesw5-dev it says I already have that library installed. Where should I go from here?

Blade Doyle
@bladedoyle
@tenthousandlakesmn I believe this chat group is defunct. Everybody moved to keybase.
Re, building grin libcurses requirement: Please try: sudo apt-get install libncurses5 libncursesw5
you will also need libssl-dev clang libclang-dev llvm-dev
johndavies24
@johndavies24
@tenthousandlakesmn i built on my rapsberry pi with no issues, just followed the grin wiki build instructions and it worked
Ghost
@ghost~5a84a8dfd73408ce4f8d2d24
@johndavies24 @bladedoyle thank you for your replies
johndavies24
@johndavies24
i didnt change anything, built the same way as i did on ubuntu and debian, just sudo apt install all the dependencies, install rust with the script and git pull and cargo build. I was surprised it worked so well on arm
i have a pi4 though, i know the beam raspberry pi instructions mentions making swap space if you dont have enough ram
Ghost
@ghost~5a84a8dfd73408ce4f8d2d24
@johndavies24 I over came the memory issue using the -p flag to build regex, syn, serde_derive etc. the regular cargo build --release command seems to be working excellent. fingers crossed.
Quentin Le Sceller
@quentinlesceller
Nice @tenthousandlakesmn
Ghost
@ghost~5a84a8dfd73408ce4f8d2d24
@johndavies24 @quentinlesceller I ended up building most of the grin_* crates one at a time. with that being said my pi grin node is syncing! no cross compilation needed.
佘奕敏
@elvinsophus
How do I validate an income with "retrieve_txs"? I received a transaction whose "tx_type" is "TxReceived" and "confirmed" is"true", but the balance of my wallet (through "retrieve_summary_info") didn't increase. The version of my wallet is "v3.0.0". Can any one help? Thanks.
aleqx
@aleqx
@quentinlesceller above we spoke about Poloniex ... their wallet is down again and so is at some other exchanges (Bibox, TradeOgre are two, haven't looked at all of them). TradeOgre on Twitter said they keep having issues with the new node/wallet in that transactions wait to finalize but the chain explorer shows the already mature. Are there known issues with v3?
Quentin Le Sceller
@quentinlesceller
Link to tweet @aleqx ?
aleqx
@aleqx
was a PM to me ... i'll screenshot it for you
@quentinlesceller see PM
aleqx
@aleqx
my question still stands though - are there any known issues with v3 (or at least reported by multiple folks)?
BLOCKCHAINSMOKER
@BLOCKCHAINSMOKER
@aleqx maybe it is because they are sending with tradeogre v3 wallet to their own personal wallet that is still v2?
I used tradeogre yesterday no problems
invertedcrosss
@invertedcrosss_twitter
I've had a withdrawal with Poloniex awaiting finalization for 4 days now. Do I have to keep my wallet listening or will the transaction simply confirm when their wallet is back online and the broadcast the transaction to the grin blockchain? Thanks.
invertedcrosss
@invertedcrosss_twitter
I know this is not dev talk, but it's a continuation of the comment made by @quentinlesceller about Poloniex and their wallet being down again.
energyburn
@energyburn
@invertedcrosss_twitter Your wallet must be online listening during the withdrawal process