- 2 Pull Requests for TxBit integration
9 PRs from mostly non-core devs as well!
Topic: [ANN] KASPA (KAS) - CPU PoW - ghostDAG - page 7. (Read 8705 times)
2 Pull Requests for TxBit integration
- 2 Pull Requests for TxBit integration
9 PRs from mostly non-core devs as well!
- 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
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
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
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...
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="
// Once synced, shutdown both nodes, move
// 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)
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
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?
*********************************************
*****************************************************
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
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
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).
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
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
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
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
******************************************************************
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
Freshman — Yesterday at 12:38 PM
Hello Kaspers!
I'm happy to announce that the community funding pool for the listing on txbit.io has been successfully filled!
The payment for the listing is already done. I shared the Transaction ID and the receiving confirmation from txbit in the #funding-pool-discussions channel
Thanks to everyone who helped reaching this goal in less than 24 hours!
I'll share all minor updates regarding the listing in the #funding-pool-discussions channel as well.
The listing itself will be announced through the official announcement channel.
Hello Kaspers!
I'm happy to announce that the community funding pool for the listing on txbit.io has been successfully filled!
The payment for the listing is already done. I shared the Transaction ID and the receiving confirmation from txbit in the #funding-pool-discussions channel
Thanks to everyone who helped reaching this goal in less than 24 hours!
I'll share all minor updates regarding the listing in the #funding-pool-discussions channel as well.
The listing itself will be announced through the official announcement channel.
Freshman — Today at 11:39 AM
@everyone Hello Kaspers!
Welcome to the first community funding pool!
The proposal behind this pool is to get $KAS listed on the crypto exchange txbit.io.
Txbit.io is fully integrated on the most important crypto listing pages such as Coinmarketcap, Coingecko and the portfolio tracking app FTX (former Blockfolio).
A listing on Txbit would bring us the opportunity to get listed on these crypto pages as well. It would also increase the chances to get listed on other exchanges.
As there is no other exchange listing yet, a listing on txbit.io would also provide a secured environment for buying/selling activities.
We got the following offer:
-2000$ to be paid in a stablecoin.
-They told us that Kaspa could be listed within two weeks after the payment has been made. (Please keep in mind that this is just an estimation. There could always be some unforeseen issues)
The goal for this pool has been set at 2100$ to cover all potencial fees. If there is some money from the additional 100$ left, we would use it to help filling another community funding pool in the future.
The duration for this pool is 2 weeks (Until April 10th, 8pm CET). If we miss the necessary cap, everyone would get refunded.
Supported Currencies: BUSD (BEP20) or USDT (BEP20) only
Thank you very much for your support!
Link to the pool: https://app.poolo.io/pool/ed4fd934-7280-4e37-b43d-bc3538175947
If you have any questions, feel free to ask in the #funding-pool-discussions channel
***UPDATE***
Funding for first listing now at 77% in less than 24 hours!!
$1617 of $2100 so far!!
https://app.poolo.io/pool/ed4fd934-7280-4e37-b43d-bc3538175947
@everyone Hello Kaspers!
Welcome to the first community funding pool!
The proposal behind this pool is to get $KAS listed on the crypto exchange txbit.io.
Txbit.io is fully integrated on the most important crypto listing pages such as Coinmarketcap, Coingecko and the portfolio tracking app FTX (former Blockfolio).
A listing on Txbit would bring us the opportunity to get listed on these crypto pages as well. It would also increase the chances to get listed on other exchanges.
As there is no other exchange listing yet, a listing on txbit.io would also provide a secured environment for buying/selling activities.
We got the following offer:
-2000$ to be paid in a stablecoin.
-They told us that Kaspa could be listed within two weeks after the payment has been made. (Please keep in mind that this is just an estimation. There could always be some unforeseen issues)
The goal for this pool has been set at 2100$ to cover all potencial fees. If there is some money from the additional 100$ left, we would use it to help filling another community funding pool in the future.
The duration for this pool is 2 weeks (Until April 10th, 8pm CET). If we miss the necessary cap, everyone would get refunded.
Supported Currencies: BUSD (BEP20) or USDT (BEP20) only
Thank you very much for your support!
Link to the pool: https://app.poolo.io/pool/ed4fd934-7280-4e37-b43d-bc3538175947
If you have any questions, feel free to ask in the #funding-pool-discussions channel
***UPDATE***
Funding for first listing now at 77% in less than 24 hours!!
$1617 of $2100 so far!!
https://app.poolo.io/pool/ed4fd934-7280-4e37-b43d-bc3538175947
svarog — Today at 12:02 PM
Hey all!
Go 1.18 has released, and we're very excited to finally start using Generics.
We will upgrade all kaspanet repositories to depend on go 1.18 starting in 3 days - Wednesday March 30th.
If you plan to compile any kaspanet repositories, including kaspad - please upgrade your Go toolchain by then.
Hey all!
Go 1.18 has released, and we're very excited to finally start using Generics.
We will upgrade all kaspanet repositories to depend on go 1.18 starting in 3 days - Wednesday March 30th.
If you plan to compile any kaspanet repositories, including kaspad - please upgrade your Go toolchain by then.
Jump to: