Topic: [ANN] KASPA (KAS) - CPU PoW - ghostDAG - page 7. (Read 9274 times)

This is exactly why there's a limit and probably why it will be removed altogether in the future.
in short this is why we cant have nice things.

Use a vpn and change your ip. Login again and reclaim the faucet. Can do it lot of time. I’ve done it 20 time before  getting bored

At least from the wallet, the daily faucet limit is 5 KAS.

Hi. Is there a faucet claim limit? There seems to be that limit.

Your best bet is to head on over to the Discord (link on https://kaspa.org) and talk to people about it there.

Any guide to engineer a FPGA miner for this?
I'm already running my own node on GPU and wish to expand with FPGA

Thank you and keep up the good work!

Really great algo. Thank you devs. More pools in the future hopefully.

KASPA coin is good for GPU mining, but there is a little bit hot algo for summer. There is a review of KAS here: https://www.cryptoprofi.info/?p=11997. Taking into account activity of developers, this crypto may have good future.

Kaspa in now listed on two exchanges, https://www.exbitron.com/ and https://txbit.io/

My reff links if someone would like to register:
https://www.exbitron.com/signup?refid=IDF3B9B52D60
https://txbit.io/?r=24eb6

Good Luck

As of this moment the net is at 14,483,141 DAA score, with the target HF time being 14,687,583.

This leaves us with ~56=(14687583 - 14483141)/3600 hours to the countdown, which is pretty much on schedule



^This was 8 hours ago from RIGHT MEOW!!!

So that means 2 days even until the Hard Fork!!

The Hard Fork introduces these new features:

Breaking changes:

Hard-fork at DAA score 14687583 (estimated to be on 28/04 16:38 UTC) which includes:
* Using separate depth than finality depth for merge set calculations (#2013)
* Not counting the header size as part of the block mass (#2013)
* Increasing block version to 1 (#2013)
* Removing the limit on amount of KAS that can be sent in one transaction (#2013)

hauntedcook [kaspa-miner-GPU] — Today at 1:47 PM


Kaspa-Miner version 0.2.1-GPU-0.6 was released, continuing our tradition of making file names really long.

This is a stability release, which fixes issues with miner not working for certain drivers and installations. Also, we finally report hashrates per device (this isn't implemented in hiveos scripts yet), and lower the miner memory footprint for CUDA.

The overclock capability is included only in overclock release, since we require newer nvidia drivers (495+) for it.


https://github.com/tmrlvi/kaspa-miner/releases/tag/v0.2.1-GPU-0.6

2 Pull Requests for TxBit integration


 - 2 Pull Requests for TxBit integration


9 PRs from mostly non-core devs as well!

@everyone


Kaspad v0.12.0 is out: https://github.com/kaspanet/kaspad/releases/tag/v0.12.0
This upgrade is mandatory. It contains a hard fork at DAA score 14687583 (estimated to be on 28/04 16:38 UTC). Everyone who doesn't upgrade will be split off the network.
The main focus of the hard fork is to address the issue of deep side chains that spam the network. After the hard fork is activated such side chains will be ignored unless they win the block race and have more blue work than the rest of the network. The hard fork also removes the previous limit on transactions to send less than 21M KAS.
Note: whoever who's upgrading directly from v0.11.14 might experience a very long DB migration process, so in that case I would recommend to just delete the old data directory and resync from scratch.

P.S.
We contacted @aspect and he said that a new corresponding KDX version will be released in the next two days.


GitHub


This version contains a hard fork at DAA score 14687583 (estimated to be on 28/04 16:38 UTC). Upgrade is mandatory, and everyone who doesn't upgrade will be split off the network.
The main focus of the hard fork is to address the issue of deep side chains that spam the network. After the hard fork is activated such side chains will be ignored unless they win the block race and have more blue work than the rest of the network.

Changelog
Breaking changes:
Hard-fork at DAA score 14687583 (estimated to be on 28/04 16:38 UTC) which includes:
* Using separate depth than finality depth for merge set calculations (#2013)
* Not counting the header size as part of the block mass (#2013)
* Increasing block version to 1 (#2013)
* Removing the limit on amount of KAS that can be sent in one transaction (#2013)

Bug fixes:

Making a workaround for the UTXO diff child bug (#2020)
Use cosigner index 0 for read only wallets (#2014)
Non-breaking changes:

Adding a "sweep" command to kaspawallet (#2018)
Use blue work heuristic to skip irrelevant relay blocks
Kaspawallet daemon: Add Send and Sign commands (#2016)
New Contributors
@D-Stacks made their first contribution in #2018
Full Changelog: v0.11.17...v0.12.0

奇怪啊，昨天的回帖没了，回档了？

Devs geeking out to add commands to KASPA WALLET for TxBit - our first exchange!!


Kaspawallet daemon: Add Send and Sign commands by svarogg · Pull Re...
This PR adds the Send and Sign commands to the kaspawallet daemon, to be used by external wallets and APIs.
Requested by TxBit exchange.



https://github.com/kaspanet/kaspad/pull/2016

Recording from last R&D Meeting:


https://us02web.zoom.us/rec/share/IkalJgToJ3s4_-_v3WJP9TVKyo7JrWhtXsQfSsQRXeRalXz-q4SzAm-Eznprz8Nj.CyM7fijsCVxifU5M Passcode: #79?#jGl


Zoom Video Communications

Hi @everyone


kaspad v0.11.15 is out: https://github.com/kaspanet/kaspad/releases/tag/v0.11.15

TL;DR
Auto-compound wallet feature, improved miner-node flow, big performance improvement in header processing (requires a DB upgrade, read instructions below).

Full details:
* Add auto-compound support for Kaspawallet: if a transaction's mass is too-high, kaspawallet will split the transaction into multiple smaller transactions.
* Unite reachability data to a single storage entity: improves performance of header processing and saves DB space. Requires a DB migration or a fresh sync.
* Improved miner-node flow, including: (i) new new template event, dedicated for miners (both community and bz miner already support this), (ii) cache for block templates to support many miners over a single kaspad more efficiently, and (iii) fixed definition of "out of sync" to keep the network up and mining also during side-chain IBDs
* Upgrade to go 1.18 and removal of v4 p2p version
* Many more small bug fixes and improvements

Upgrade instructions:
* The fastest is to sync from fresh into a new DB, and then switch. This option is also faster and also avoids down-time of your node. Do the following:
// Run the new v0.11.15 kaspad with a new DB directory and non-default ports:
kaspad --utxoindex --appdir="" --listen=0.0.0.0:26111 --rpclisten=0.0.0.0:26110
// Once synced, shutdown both nodes, move to replace the content of and rerun the usual node.
// Make sure you use the new binary here too
kaspad --utxoindex

* The other option is to simply rerun your usual command with the new version. This will start an in-place DB migration process that takes longer than fresh sync depending on the size of your DB.
NOTE: if you maintain an archival node, this will delete the history, so backup the archive DB before.
GitHub
Release v0.11.15 · kaspanet/kaspad
What's Changed

Add support for auto-compound in kaspawallet send (#1951)
Unite reachability stores (#1963, #1993, #2001)
Add names to nameless routes (#1986)
Optimize the miner-kaspad flow and...

msutton — Today at 3:00 PM

Kaspad11.15 -

it's pre-released under my kaspad fork. Tomorrow morning I'll release an official version + upgrade instructions (it's not a simple upgrade this time)

msutton — Today at 1:37 PM


Hey everyone @here , let's have a live experiment. We have a nice-size sidechain now. We also have an RC version (RC=release candidate) running for a few days by our dear @Validators , which remains synced despite side chains. So if your node is going in and out of IBD, please redirect your miner to one of the following IPs, provided generously by @Tiram

144.76.19.91:30510
23.88.70.20:30510
116.202.130.71:30510
135.181.177.189:30510


this will be a nice test for the new version in terms of both, staying synced and mining, and stretching the load over these nodes.

Edit: ideally you should use the new miner version for this because it communicates with kaspad better at such times

https://github.com/tmrlvi/kaspa-miner/releases/tag/v0.2.1-GPU-0.5

Here's some integration status with TxBit - since KASPA is a brand new tech, the integration team from TxBit has some questions and the KASPA Devs contemplating possible solutions:

*****************************************************

Got some requests from TxBit, will appreciate your take on things:


Hi Mike! Thank you for writing these examples. We have a couple of questions about the API:

- GetUTXOsByAddressExample
The 'GetUTXOsByAddressExample' call seems to require one or more addresses in the 'GetUtxosByAddressesRequestMessage'. The method returns all possible UTXOs for that (array of) address(es). This method would not work very well on a larger scale, like our exchange. Say that we have 10k addresses and 100k transactions. It would be really inefficient if we call this method for each address and get back all UTXOs. Our questions are:
1) Would it be possible to provide us with an API endpoint that:
a) returns transactions instead of UTXOs?
b) returns only an incremental list of transactions?
c) does not require us to specify an address but instead returns the data for all addresses in that wallet that have UTXOs?
For example, the Bitcoin API call "listtransactions" does precisely that.

- CreateUnsignedTransactionExample, BroadcastTransaction, and transaction signing
Our questions are:
1) Would it be possible to provide us with an API endpoint that:
a) works like the Bitcoin API method "sendtoaddress"?

We can not work with manual signing. Our workflow is completely automated.
About CreateUnsignedTransactions:
 I think about providing a mode of operation in daemon that will ask for password on start / cli, and than will enable Send and Sign requests.

Another option is to add a Sign and Send commands to kaspawallet that will take a password. <- this is easier.
About GetUTXOsByAddress:
a. We can't provide transactions, that's fine by them.
b+c.  I guess we can add a GetUTXOs to daemon that will get UTXOs for all registered addresses.
Then we'll also need to add to GetUTXOs both in kaspad and in daemon a parameter of "startingFromDAAScore", that will filter out UTXOs above certain DAAScore.
I'm not very sure we want this functionality in kaspad. Does maybe Katnip support such things?

*********************************************