Yes i STILL have all my CPUs on $EPIC . . its great in the summer also since they only run like 40% of the time or so - not straining the AC haha

Very nice, go go $EPIC


In case youre not aware, $EPIC is basically MimbleWimble "done right" . .

21 million MAX supply

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="<new dir>" --listen=0.0.0.0:26111 --rpclisten=0.0.0.0:26110
// Once synced, shutdown both nodes, move <new dir> to replace the content of <default dir> 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?

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

hauntedcook — Today at 11:17 AM


Hi all,
The long miner awaited version v0.2.1-GPU-0.5 is finally out. This version includes stratum support, Cuda OC settings, and most important - uses the new events from kaspad, allowing for smoother IBD, and less resyncing time.

This version include some changes to how the events are processed. If you see drop in performance, please report the details
https://github.com/tmrlvi/kaspa-miner/releases/tag/v0.2.1-GPU-0.5

$KAS mining calc!!


https://minerstat.com/coin/KAS

Thx to SonOfaTech (175k) for posting a $KASPA clip on Youtube !!!

https://t.co/VQu7QdTic2

aspect — Today at 10:53 AM


KDX 2.9.1 is out at https://kdx.app/   (next release we will start releasing on Github as well). This is an intermediate release - it fixes the KDX application exit bug when the application is set to a language other than English.  It also addresses some issues with i18n translations.  This version now properly handles translations and upon completion of KDX translations, they will be made available on the PWA as well (web app).

Yahooooooooooooooo!

Here we have Good Ol' SonofaTech (175k sub) YouTube with an very informative section on KASPA starting around 6:30



https://www.youtube.com/watch?v=xUjPnbH7jeA

Hey guys look at this great short on youtube from the Chinese KAS community:


https://youtu.be/YZz9OrY1e14

Announcement for miner developers:

The following PR (https://github.com/kaspanet/kaspad/pull/1988) added a new event type to the RPC API, dedicated for miners.
The event is named NewBlockTemplate. (https://github.com/kaspanet/kaspad/blob/dev/infrastructure/network/netadapter/server/grpcserver/protowire/rpc.md#notifynewblocktemplaterequestmessage)

Miner software should replace the current BlockAdded event with this event.
This event is called only when the real conditions for a block template update were met (for instance a block can be added to the DAG but is not always
added as parent of virtual due to various mining rules). Additionally, we avoid calling this event during IBD when thousands of blocks are added to the DAG
every second, and in the future we might trigger this event also as a result of mempool changes.

I'm implementing several more optimizations for the miner-kaspad communication cycle, including template caching, and modifying
"out of sync"/isSynced definition such that miners will mine under all possible circumstances.

Hence our recommendations for miners are the following:
- Register to the new event type (perhaps verify that kaspad version >= 0.11.15 or simply try and if you error fallback to prev event)
   -- As a reference, the registration was updated in the native go miner already https://github.com/kaspanet/kaspad/blob/dev/cmd/kaspaminer/client.go#L33
- If the template you get is marked isSynced=false, do not mine, we will indicate this only when the node is really behind (unlike now).
- If you do decide to mine even if isSynced=false, use the latest template you just received and not anything older

@someone235 @hauntedcook @demisrael @iedoc @elichai2  @Community Developer
GitHub
Optimize the miner-kaspad flow and latency by michaelsutton · Pull ...
This PR includes initial changes to improve the miner-to-kaspad communication cycle, including the following:

A dedicated "new block template" event for notifying miners only when necess...
Optimize the miner-kaspad flow and latency by michaelsutton · Pull ...
GitHub
kaspad/client.go at dev · kaspanet/kaspad
Kaspad is the reference full node Kaspa implementation written in Go (golang). - kaspad/client.go at dev · kaspanet/kaspad
kaspad/client.go at dev · kaspanet/kaspad

You need to ask yourself ONE question -  Can your other coins Lead Dev do this?


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

hashdag — Today at 5:47 AM

@someone235 IIRC we thought SPV design would be much more complicated in DAG than in chain due to double spends, but we can simply provide inclusion proof of the utxo in the merkle root of accepted txns (or utxos) by the merging block, and then the SPV needs either to (i) run GHOSTDAG to convince itself that this is indeed the merging block, or simpler yet (ii) require inclusion proof for a few candidate merging blocks, and if the utxo is accepted by all of them