jiucai2008
Newbie
Offline
Activity: 35
Merit: 0
|
|
November 27, 2021, 02:32:23 PM Last edit: November 28, 2021, 02:41:08 PM by mprep |
|
-
Their discord server is very active. If you want to get a quick answer, you need to join their discord server link
The computing power of the whole network has exceeded 12G/s, incredible! It's only a few days [moderator's note: consecutive posts merged]
|
|
|
|
wannabej0
Newbie
Offline
Activity: 3
Merit: 0
|
|
November 29, 2021, 01:32:15 AM |
|
Need more CPU miners, come on over and get in on this coin!
|
|
|
|
neguinho1
Newbie
Offline
Activity: 151
Merit: 0
|
|
November 29, 2021, 08:47:19 PM |
|
kaspa-miner.exe -t 10 --mining-address kaspa: qrug9kefug0tj62k789kv067dw8fh6e50f0vsacmuwnznxz9ratc62hxlzr46 how do i configure
|
|
|
|
wannabej0
Newbie
Offline
Activity: 3
Merit: 0
|
|
November 30, 2021, 01:02:38 AM |
|
kaspa-miner.exe -t 10 --mining-address kaspa: qrug9kefug0tj62k789kv067dw8fh6e50f0vsacmuwnznxz9ratc62hxlzr46 how do i configure kaspa-miner.exe -t 10 --mining-address kaspa:qrug9kefug0tj62k789kv067dw8fh6e50f0vsacmuwnznxz9ratc62hxlzr46 Get rid of the space between kaspa: and the rest of the address
|
|
|
|
jiucai2008
Newbie
Offline
Activity: 35
Merit: 0
|
|
November 30, 2021, 05:05:50 AM |
|
kaspa-miner.exe -t 10 --mining-address kaspa: qrug9kefug0tj62k789kv067dw8fh6e50f0vsacmuwnznxz9ratc62hxlzr46 how do i configure Kaspa's discord server is quite active. If you ask mining related questions or tutorials there, you will get a reply faster!
|
|
|
|
cryptomaxsun
Legendary
Offline
Activity: 2744
Merit: 1387
Ukrainians will resist
|
|
November 30, 2021, 05:34:52 AM |
|
kaspa-miner.exe -t 10 --mining-address kaspa: qrug9kefug0tj62k789kv067dw8fh6e50f0vsacmuwnznxz9ratc62hxlzr46 how do i configure Download the miner from here - https://github.com/elichai/kaspa-miner/releasesHere's an example of a bat file: kaspa-miner-v0.1.3-win64-amd64 --mining-address your address --threads 10 pause The network has just started and the size of the folder with blocks is already 2.64 GB. This is a lot. Will there be any work to optimize the size of stored blocks?
|
❘|❘ Cлaвa Укpaинe! ❘|❘ Glory to Ukraine! ❘|❘ ❘|❘ КaPФaгeн дoлжeн быть paзpyшeн ❘|❘
|
|
|
Wolfie
|
|
November 30, 2021, 05:54:05 PM |
|
The network has just started and the size of the folder with blocks is already 2.64 GB. This is a lot. Will there be any work to optimize the size of stored blocks?
They have a concept in place, it will be explained here shortly https://eprint.iacr.org/2021/623.pdf
|
@XVG_HypeMan
|
|
|
shaideshe
Newbie
Offline
Activity: 12
Merit: 1
|
|
November 30, 2021, 08:00:54 PM Last edit: November 30, 2021, 10:03:31 PM by Mr. Big Merited by cryptomaxsun (1) |
|
The network has just started and the size of the folder with blocks is already 2.64 GB. This is a lot. Will there be any work to optimize the size of stored blocks?
Hi, I am from the Kaspa research team. All and all we store three components: full header data above the pruning block, the UTXO set of the pruning block, and a proof of correctness for the UTXO set. We have a fancy pruning mechanism (cf. https://research.kas.pa/t/some-of-the-intuition-behind-the-design-of-the-invalidation-rules-for-pruning/95) that allows us to remove old block data. At full capacity the size of a block payload is bound by 100kB and the size of a block header is bound by (100 +32*log_2(past size))B. In the distant future where we have a trillion blocks in the network (this will take about 30 thousand years of one block per second) we will have that log_2(past size) = 40, so let us assume that log_2(past size) <= 40. This means that the header size is bound by (100+32*40)B which is just below 1.5kB. For simplicity assume for now that he entire block size is 100kB. We store three days worth of full block data which, at a rate of one block/second, accumulates to about 26GB (note that this bound assumes that all blocks are at maximum capacity, no assumptions on average number of txns per block). The UTXO correctness proof (cf. https://github.com/kaspanet/research/issues/3) requires that we keep additional log_2(number of blocks in the network) headers (not full blocks). Using again the assumption log_2(past size) <= 40 this adds about 60kB of data, which is completely negligible. Currently we store all block headers, as it requires some care to remove them without accidentally removing headers required for the proof and our dev team hasn't got around to this yet, this is a completely technical issue which will be resolved in the near future. (There is another detail I swept under the rug, which is that we also have to store the headers of all pruning blocks. This means one header per day. While this technically grows at a rate O(n*logn) the constant is ridiculously small: it is bound by 1.5kB/day, which are about 570kB a year). The only thing that grows linearly is the pruning block UTXO set itself. It currently requires a field of a fixed size for every unspent output in the network. It is hard to predict how fast this set grows as this heavily depends on user behavior. We will resolve this in the future by means of cryptographic accumulators (cf. https://en.wikipedia.org/wiki/Accumulator_(cryptography)). An accumulator is a way to represent a large set succinctly such that it is impossible to recover the set itself (due to information theoretic compression bounds), but it is possible to verify that an element is in the set given a proof. This means that every user will only need to store the (proofs of) their own unspent outputs, and the nodes will only have to verify this proof against the accumulator, which is much smaller than the actual number of unspent outputs. The sizes of the accumulator and the proofs depends on the exact solution we will choose.
Holding back from making announcements or keeping info back - like the telegram bot which gives network hashrate, didn't sit right with me and the coin is no longer restricted to a few people on discord.
I feel that I should clarify: the bot in question was written by a community member which is not a member of the core team and who does not want to share their code, and I am sure they have their reasons. This has nothing to do with Kaspa. All the bot does is to issue a couple of commands to our (completely open source and publicly available) node and print the result to a Telegram channel. Seems a bit unfair to me to conclude from this that the core team is holding back on anything. We strongly believe in openness, which is why we made the network publicly available and invited the community to get involved as soon as possible, and in particular, without any premining whatsoever. The reason we wanted to delay the announcement is because we wanted the coin to be more well tested, and the ecosphere more well developed, before using our one chance to garner attention off the BCT board. But since this is a community coin, we can't (and don't want to) prevent anyone from making announcements. Anyway, now that the cat is out of the bag feel free to ask me anything.
|
|
|
|
jiucai2008
Newbie
Offline
Activity: 35
Merit: 0
|
|
December 01, 2021, 08:55:34 AM |
|
It is announced on the discord server that the accurate monetary policy will be released soon. I hope to release it soon. I have been looking forward to this policy for nearly a week!
|
|
|
|
cryptomaxsun
Legendary
Offline
Activity: 2744
Merit: 1387
Ukrainians will resist
|
|
December 01, 2021, 03:08:32 PM |
|
Thanks for the detailed answer. I have more questions: is there a GUI wallet planned? and how much total supply?
|
❘|❘ Cлaвa Укpaинe! ❘|❘ Glory to Ukraine! ❘|❘ ❘|❘ КaPФaгeн дoлжeн быть paзpyшeн ❘|❘
|
|
|
Wolfie
|
|
December 02, 2021, 03:17:49 AM |
|
The network has just started and the size of the folder with blocks is already 2.64 GB. This is a lot. Will there be any work to optimize the size of stored blocks?
Hi, I am from the Kaspa research team. All and all we store three components: full header data above the pruning block, the UTXO set of the pruning block, and a proof of correctness for the UTXO set. We have a fancy pruning mechanism (cf. https://research.kas.pa/t/some-of-the-intuition-behind-the-design-of-the-invalidation-rules-for-pruning/95) that allows us to remove old block data. At full capacity the size of a block payload is bound by 100kB and the size of a block header is bound by (100 +32*log_2(past size))B. In the distant future where we have a trillion blocks in the network (this will take about 30 thousand years of one block per second) we will have that log_2(past size) = 40, so let us assume that log_2(past size) <= 40. This means that the header size is bound by (100+32*40)B which is just below 1.5kB. For simplicity assume for now that he entire block size is 100kB. We store three days worth of full block data which, at a rate of one block/second, accumulates to about 26GB (note that this bound assumes that all blocks are at maximum capacity, no assumptions on average number of txns per block). The UTXO correctness proof (cf. https://github.com/kaspanet/research/issues/3) requires that we keep additional log_2(number of blocks in the network) headers (not full blocks). Using again the assumption log_2(past size) <= 40 this adds about 60kB of data, which is completely negligible. Currently we store all block headers, as it requires some care to remove them without accidentally removing headers required for the proof and our dev team hasn't got around to this yet, this is a completely technical issue which will be resolved in the near future. (There is another detail I swept under the rug, which is that we also have to store the headers of all pruning blocks. This means one header per day. While this technically grows at a rate O(n*logn) the constant is ridiculously small: it is bound by 1.5kB/day, which are about 570kB a year). The only thing that grows linearly is the pruning block UTXO set itself. It currently requires a field of a fixed size for every unspent output in the network. It is hard to predict how fast this set grows as this heavily depends on user behavior. We will resolve this in the future by means of cryptographic accumulators (cf. https://en.wikipedia.org/wiki/Accumulator_(cryptography)). An accumulator is a way to represent a large set succinctly such that it is impossible to recover the set itself (due to information theoretic compression bounds), but it is possible to verify that an element is in the set given a proof. This means that every user will only need to store the (proofs of) their own unspent outputs, and the nodes will only have to verify this proof against the accumulator, which is much smaller than the actual number of unspent outputs. The sizes of the accumulator and the proofs depends on the exact solution we will choose.
Holding back from making announcements or keeping info back - like the telegram bot which gives network hashrate, didn't sit right with me and the coin is no longer restricted to a few people on discord.
I feel that I should clarify: the bot in question was written by a community member which is not a member of the core team and who does not want to share their code, and I am sure they have their reasons. This has nothing to do with Kaspa. All the bot does is to issue a couple of commands to our (completely open source and publicly available) node and print the result to a Telegram channel. Seems a bit unfair to me to conclude from this that the core team is holding back on anything. We strongly believe in openness, which is why we made the network publicly available and invited the community to get involved as soon as possible, and in particular, without any premining whatsoever. The reason we wanted to delay the announcement is because we wanted the coin to be more well tested, and the ecosphere more well developed, before using our one chance to garner attention off the BCT board. But since this is a community coin, we can't (and don't want to) prevent anyone from making announcements. Anyway, now that the cat is out of the bag feel free to ask me anything. Hey Deshe, you beast me to it with your own answer Thxx! Wolfie
|
@XVG_HypeMan
|
|
|
jiucai2008
Newbie
Offline
Activity: 35
Merit: 0
|
|
December 02, 2021, 09:51:08 AM |
|
That's crazy! Why does the computing power of the whole network suddenly rise so much? I'm only 24M/s, and now I can only dig 30000 kaspa a day
|
|
|
|
minerja
|
|
December 02, 2021, 11:56:02 AM Last edit: December 02, 2021, 05:42:20 PM by mprep |
|
What is going on with this coin
when i launch ./kaspad i get this
2021-12-02 11:51:35.711 [INF] KASD: Version 0.11.6 2021-12-02 11:51:35.712 [INF] KASD: Loading database from '/home/miner2/.kaspad/kaspa-mainnet/datadir2' 2021-12-02 11:51:35.966 [INF] ADXR: Loaded 3067 addresses and 0 banned addresses 2021-12-02 11:51:35.967 [INF] TXMP: P2P Server listening on [::]:16111 2021-12-02 11:51:35.967 [INF] TXMP: RPC Server listening on [::]:16110 2021-12-02 11:51:35.967 [INF] CMGR: Connecting to [2600:1700:d78:1cf0::46]:16111 2021-12-02 11:51:36.968 [INF] CMGR: Connecting to 65.108.46.85:16111 2021-12-02 11:51:37.060 [INF] TXMP: P2P Connected to 65.108.46.85:16111 2021-12-02 11:51:37.060 [INF] CMGR: Connecting to [2001:14ba:3fe:9600:500d:cd4a:b440:5453]:16111 2021-12-02 11:51:37.252 [INF] PROT: IBD started 2021-12-02 11:51:37.304 [INF] PROT: Downloading headers from <39b2560a869fc42bddeff257167b09cb: 65.108.46.85:16111> 2021-12-02 11:51:38.061 [INF] CMGR: Connecting to [240e:3b5:34e0:f191:8e63:f401:cd10:62cd]:16111 2021-12-02 11:51:39.061 [INF] CMGR: Connecting to [2409:8a30:22f:e180:24c3:4fe7:1b6b:2d8a]:16111 2021-12-02 11:51:40.062 [INF] CMGR: Connecting to 140.250.146.11:16111 2021-12-02 11:51:40.458 [INF] TXMP: P2P Connected to 140.250.146.11:16111 2021-12-02 11:51:40.458 [INF] CMGR: Connecting to [2a01:4f9:6b:431d::2]:16111 2021-12-02 11:51:41.459 [INF] CMGR: Connecting to [2a10:800e:218d:0:c06:5a86:6163:4d71]:16111 2021-12-02 11:51:49.743 [INF] BDAG: Processed 1 block and 315 header in the last 13.78s (1 transaction, 2021-12-02 11:46:31.638 +0000 GMT) 2021-12-02 11:51:50.338 [INF] BDAG: Resolving virtual. This may take some time... 2021-12-02 11:51:50.682 [INF] BDAG: Resolved virtual 2021-12-02 11:51:50.682 [INF] PROT: IBD finished successfully 2021-12-02 11:51:51.294 [INF] PROT: IBD started 2021-12-02 11:51:51.340 [INF] PROT: Downloading headers from <39b2560a869fc42bddeff257167b09cb: 65.108.46.85:16111> 2021-12-02 11:51:51.899 [INF] BDAG: Resolving virtual. This may take some time... 2021-12-02 11:51:51.921 [INF] BDAG: Resolved virtual 2021-12-02 11:51:51.921 [INF] PROT: IBD finished successfully 2021-12-02 11:51:52.194 [INF] PROT: Accepted block d29174246d50f8d6b1393f318aa7f075e274971ac49806e96a31a4b407eccfcd via relay 2021-12-02 11:51:53.740 [INF] PROT: Received a block with missing parents, adding to orphan pool: 2e46a2594395d705b7b8ee8883472b33e43aa726e91ee1799de669f4e0958cf0 2021-12-02 11:51:53.740 [INF] PROT: Block 2e46a2594395d705b7b8ee8883472b33e43aa726e91ee1799de669f4e0958cf0 has 1 missing ancestors. Adding them to the invs queue... 2021-12-02 11:51:53.829 [INF] PROT: Accepted block 495eef8d6f6f6a773b5fb2f9d1fe2742c77175d809da3d8ccfa481f08912bd6c via relay 2021-12-02 11:51:53.861 [INF] PROT: Unorphaned block 2e46a2594395d705b7b8ee8883472b33e43aa726e91ee1799de669f4e0958cf0 2021-12-02 11:51:54.118 [INF] PROT: Accepted block b6d5bd6032e664a28ec509863f79faa0fb42b083baddf1e90ad94d4ddd7f7806 via relay 2021-12-02 11:51:54.374 [INF] PROT: Received a block with missing parents, adding to orphan pool: 428eea9316bdbbe31a58a8b47aeece0a89c715e1c0754ec74a50fe5b93058d65 2021-12-02 11:51:54.374 [INF] PROT: Block 428eea9316bdbbe31a58a8b47aeece0a89c715e1c0754ec74a50fe5b93058d65 has 1 missing ancestors. Adding them to the invs queue... 2021-12-02 11:51:54.575 [INF] PROT: Accepted block aaf7ef4e98724d7a871ba4161e7e8935f34b037cffe103e53681be18899623ab via relay 2021-12-02 11:51:54.604 [INF] PROT: Unorphaned block 428eea9316bdbbe31a58a8b47aeece0a89c715e1c0754ec74a50fe5b93058d65 2021-12-02 11:51:54.828 [INF] PROT: Accepted block 77986eeff4025eb8416d94d71236fe1d7a6bc6a297b8f96e13dc78659acee815 via relay 2021-12-02 11:51:56.493 [INF] PROT: Accepted block be2512d9193c4ebe045e76ed7f3de6eda0306a7cc6733353d89bda4a8fd1c29e via relay 2021-12-02 11:51:58.201 [INF] PROT: Accepted block bcf78e914439d61bc18941bb77548ee75469e980c49f6f91e9c67788a234bebe via relay 2021-12-02 11:51:58.561 [INF] PROT: Accepted block 30fcfcb1eb59ed929c9573b7c618dd7af0cc556498727ab0a8de2e23fa458b85 via relay 2021-12-02 11:51:58.582 [INF] PROT: Accepted block ab167b0c738a03de76b733437024a385144438195827bc4399ea933bddd634d6 via relay 2021-12-02 11:51:59.594 [INF] PROT: Accepted block 41377d1c4b4d3a1044c1887602fa89c43101bd209519f19ae338bf181e3bfe1e via relay 2021-12-02 11:52:01.209 [INF] BDAG: Processed 343 blocks and 16 headers in the last 11.47s (349 transactions, 2021-12-02 11:51:59.988 +0000 GMT) 2021-12-02 11:52:01.209 [INF] PROT: Accepted block 77c9ced5e1c71aec4374013c73e1bf61f055e58744b56f885eacab8b88f11088 via relay
ok, does that mean the blockchain is synced???
if i type ./kaspawallet this happens./kaspawallet Please specify one command of: balance, broadcast, create, create-unsigned-transaction, dump-unencrypted-data, send, show-address, sign or start-daemon or miner2@Miner2:~/Downloads/kaspad/bin$ ./kaspawallet show-address kaspawallet daemon is not running, start it with `kaspawallet start-daemon` then miner2@Miner2:~/Downloads/kaspad/bin$ ./kaspawallet start-daemon 2021-12-02 11:54:38.069 [INF] KSWD: Listening on localhost:8082 rpc error github.com/kaspanet/kaspad/infrastructure/network/rpcclient.init /home/runner/work/kaspad/kaspad/infrastructure/network/rpcclient/rpcclient.go:174 runtime.doInit /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/proc.go:6315 runtime.doInit /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/proc.go:6292 runtime.doInit /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/proc.go:6292 runtime.main /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/proc.go:208 runtime.goexit /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/asm_amd64.s:1371 Method unavailable when kaspad is run without --utxoindex github.com/kaspanet/kaspad/infrastructure/network/rpcclient.(*RPCClient).convertRPCError /home/runner/work/kaspad/kaspad/infrastructure/network/rpcclient/rpcclient.go:177 github.com/kaspanet/kaspad/infrastructure/network/rpcclient.(*RPCClient).GetUTXOsByAddresses /home/runner/work/kaspad/kaspad/infrastructure/network/rpcclient/rpc_get_utxos_by_addresses.go:17 github.com/kaspanet/kaspad/cmd/kaspawallet/daemon/server.(*server).collectUTXOs /home/runner/work/kaspad/kaspad/cmd/kaspawallet/daemon/server/sync.go:136 github.com/kaspanet/kaspad/cmd/kaspawallet/daemon/server.(*server).collectUTXOsWithLock /home/runner/work/kaspad/kaspad/cmd/kaspawallet/daemon/server/sync.go:127 github.com/kaspanet/kaspad/cmd/kaspawallet/daemon/server.(*server).collectUTXOsFromRecentAddresses /home/runner/work/kaspad/kaspad/cmd/kaspawallet/daemon/server/sync.go:114 github.com/kaspanet/kaspad/cmd/kaspawallet/daemon/server.(*server).sync /home/runner/work/kaspad/kaspad/cmd/kaspawallet/daemon/server/sync.go:34 github.com/kaspanet/kaspad/cmd/kaspawallet/daemon/server.Start.func1 /home/runner/work/kaspad/kaspad/cmd/kaspawallet/daemon/server/server.go:68 github.com/kaspanet/kaspad/util/panics.handleSpawnedFunction /home/runner/work/kaspad/kaspad/util/panics/panics.go:83 github.com/kaspanet/kaspad/util/panics.GoroutineWrapperFunc.func1.1 /home/runner/work/kaspad/kaspad/util/panics/panics.go:32 runtime.goexit /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/asm_amd64.s:1371 error syncing the wallet github.com/kaspanet/kaspad/cmd/kaspawallet/daemon/server.Start.func1 /home/runner/work/kaspad/kaspad/cmd/kaspawallet/daemon/server/server.go:70 github.com/kaspanet/kaspad/util/panics.handleSpawnedFunction /home/runner/work/kaspad/kaspad/util/panics/panics.go:83 github.com/kaspanet/kaspad/util/panics.GoroutineWrapperFunc.func1.1 /home/runner/work/kaspad/kaspad/util/panics/panics.go:32 runtime.goexit /opt/hostedtoolcache/go/1.16.10/x64/src/runtime/asm_amd64.s:1371
what gives
How do you run this wallet? How do i get andress? How do i mine How do i check my balance?
Why are there not simple instructions in the ann....(do not ask me to go to discord, please post here so all can see)
Also, just tried mining using this test address
./kaspa-miner-v0.1.3-linux-amd64 --mining-address kaspa:qpyn6a3gudav4jzt0gway6tndj3tyw0uazehet5g0fvutmmnktg0zz2klk4dt cos mine says i have the wrong address...duh
Anyways, i get between 2-4 mhs, but the net hash is already 24GHs, so 1000 times higher...so ZERO point in solo mining. What a terrible launch, needs pools ready or no point even trying...fail
[moderator's note: consecutive posts merged]
|
|
|
|
rocketrunner442
Newbie
Offline
Activity: 11
Merit: 0
|
|
December 02, 2021, 12:14:09 PM |
|
Anyways, i get between 2-4 mhs, but the net hash is already 24GHs, so 1000 times higher...so ZERO point in solo mining. What a terrible launch, needs pools ready or no point even trying...fail
What are you talking about? With a fairly basic CPU, you can easily get a couple blocks a day.
|
|
|
|
minerja
|
|
December 02, 2021, 12:30:11 PM |
|
Anyways, i get between 2-4 mhs, but the net hash is already 24GHs, so 1000 times higher...so ZERO point in solo mining. What a terrible launch, needs pools ready or no point even trying...fail
What are you talking about? With a fairly basic CPU, you can easily get a couple blocks a day. Please guide me thru how to get the wallet working first
|
|
|
|
wannabej0
Newbie
Offline
Activity: 3
Merit: 0
|
|
December 02, 2021, 01:32:20 PM |
|
Anyways, i get between 2-4 mhs, but the net hash is already 24GHs, so 1000 times higher...so ZERO point in solo mining. What a terrible launch, needs pools ready or no point even trying...fail
What are you talking about? With a fairly basic CPU, you can easily get a couple blocks a day. Please guide me thru how to get the wallet working first I would recommend joining the Discord and there will be lots of folks available to help you live with wallet and mining issues.
|
|
|
|
minerja
|
|
December 02, 2021, 01:42:13 PM |
|
Anyways, i get between 2-4 mhs, but the net hash is already 24GHs, so 1000 times higher...so ZERO point in solo mining. What a terrible launch, needs pools ready or no point even trying...fail
What are you talking about? With a fairly basic CPU, you can easily get a couple blocks a day. Please guide me thru how to get the wallet working first I would recommend joining the Discord and there will be lots of folks available to help you live with wallet and mining issues. If you read my post above detailing all the errors u have you would see that i also asked the DEV to please post any help on this ANN. Why should people have to join DISCORD just to mine his coin. If you have managed to get your wallet working, please post the instructions here. Most people accessing this from a work, or public PC can't go to DISCORD
|
|
|
|
cryptomaxsun
Legendary
Offline
Activity: 2744
Merit: 1387
Ukrainians will resist
|
|
December 02, 2021, 02:42:32 PM |
|
I started mining using this guide, and everything works for me - https://steemit.com/crypto/@kaspa/kaspa-quick-start-guideBlock reward 500 coins. Be careful and you will succeed)
|
❘|❘ Cлaвa Укpaинe! ❘|❘ Glory to Ukraine! ❘|❘ ❘|❘ КaPФaгeн дoлжeн быть paзpyшeн ❘|❘
|
|
|
minerja
|
|
December 02, 2021, 05:01:31 PM |
|
Thankyou kindly Worked like a charm
|
|
|
|
MMOStars
Member
Offline
Activity: 285
Merit: 18
|
|
December 02, 2021, 05:25:31 PM |
|
Hashrate is increasing because the project is promising? Mystery solved.
|
|
|
|
|