Recording from last R&D Meeting:
https://us02web.zoom.us/rec/share/IkalJgToJ3s4_-_v3WJP9TVKyo7JrWhtXsQfSsQRXeRalXz-q4SzAm-Eznprz8Nj.CyM7fijsCVxifU5M Passcode: #79?#jGl
Zoom Video Communications
Topic: [ANN] KASPA (KAS) - CPU PoW - ghostDAG - page 8. (Read 9565 times)
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.
someone235 — 03/25/2022
Unfortunately, @Stas, the maintainer of KGI and kasboard, is no longer taking part in this project (see his message here https://discord.com/channels/599153230659846165/755890250643144788/956850666096197692 ).
But this can be a great opportunity for any developer here to step in and replace him in one of those projects. The projects require relatively small understanding of the Kaspa ecosystem (if you'll compare it to core development and mining), so I believe anyone with experience with React (for KGI) or Grafana (for kasboard) will be able to do the job.
So if anyone is interested let me know and I'll try to help him with the onboarding process.
P.S.
Not sure how yet, but I also think that the devfund should incentivize such activity. But I think I wanna see who's interested in taking the job before we discuss the details.
13
March 27, 2022
Unfortunately, @Stas, the maintainer of KGI and kasboard, is no longer taking part in this project (see his message here https://discord.com/channels/599153230659846165/755890250643144788/956850666096197692 ).
But this can be a great opportunity for any developer here to step in and replace him in one of those projects. The projects require relatively small understanding of the Kaspa ecosystem (if you'll compare it to core development and mining), so I believe anyone with experience with React (for KGI) or Grafana (for kasboard) will be able to do the job.
So if anyone is interested let me know and I'll try to help him with the onboarding process.
P.S.
Not sure how yet, but I also think that the devfund should incentivize such activity. But I think I wanna see who's interested in taking the job before we discuss the details.
13
March 27, 2022
Intresting project, i'll definetely be following it and seeing what it becomes over time
Hi Everyone!
kaspad v0.11.14 is out: https://github.com/kaspanet/kaspad/releases/tag/v0.11.14
This release has no major updates, but it includes an important bug fix to the new IBD flow introduced at v0.11.13. So it is highly recommended to upgrade. Keep the same DB etc. and simply rerun kaspad with the new version.
Our roadmap for the coming week or two includes a few large features:
* The much anticipated core wallet auto-compound feature by @svarog
* Reachability DB migration by @someone235 -- an internal migration and optimization which improves performance (of both header processing and storage) noticeably
* Optimizations for "pruning point anticone" processing (effects fresh-syncing nodes)
GitHub
Release v0.11.14 · kaspanet/kaspad
Fixed a bug in the new IBD chain negotiation protocol (#1981)
Release v0.11.14 · kaspanet/kaspad
kaspad v0.11.14 is out: https://github.com/kaspanet/kaspad/releases/tag/v0.11.14
This release has no major updates, but it includes an important bug fix to the new IBD flow introduced at v0.11.13. So it is highly recommended to upgrade. Keep the same DB etc. and simply rerun kaspad with the new version.
Our roadmap for the coming week or two includes a few large features:
* The much anticipated core wallet auto-compound feature by @svarog
* Reachability DB migration by @someone235 -- an internal migration and optimization which improves performance (of both header processing and storage) noticeably
* Optimizations for "pruning point anticone" processing (effects fresh-syncing nodes)
GitHub
Release v0.11.14 · kaspanet/kaspad
Fixed a bug in the new IBD chain negotiation protocol (#1981)
Release v0.11.14 · kaspanet/kaspad
First of all, it checks all the standard boxes:
pure POW
no PREMINE
NO ICO
Plus, it originated from DEVS who it was THEIR OWN IDEA . . they are not HIRED by someone else or a corporation
In my experience, the best projects are made by DEVS with a vision, and they are into the coin WAY MORE than anyone you could ever PAY to work on it
Its their BABY . . in other words
Otherwise - when the money runs out, the DEVS disappear, OR . . there is a problem,
and they expand the time it takes to solve because they dont really care about the chain or the coin, they just want their pay until the next opportunity comes around
DEVS who have their own project and its their baby, will stay up 4 days in a row geeking out until something is fixed, etc.
NOW - there are all grades of developers out there - from hack cut and paste QT wallet, change supply and block time and name and logo, create a genesis block and POOOF! nEw cOiNzorZ!!!!!!!!!!!
Then you got guys with network backgrounds and programming that can do better than that, they make some decent changes and find a niche for their coin and they do OK
THEN . . you got these guys here from $KASPA, the rare mathematic genius level , not only that, but HIGHly educated . . they dedicated their "young man years" to school . . PERIOD . . i mean these guys have been going to school non stop for 30 years +
and its a GROUP - not just a solitary wizard behind the curtain
so guys like THIS . . not only make subtle changes to bitcoin based tech, they realllly reallllllly understand and see what the completely NEXT thing should be , AND they are capable of turning it into a reality
pure POW
no PREMINE
NO ICO
Plus, it originated from DEVS who it was THEIR OWN IDEA . . they are not HIRED by someone else or a corporation
In my experience, the best projects are made by DEVS with a vision, and they are into the coin WAY MORE than anyone you could ever PAY to work on it
Its their BABY . . in other words
Otherwise - when the money runs out, the DEVS disappear, OR . . there is a problem,
and they expand the time it takes to solve because they dont really care about the chain or the coin, they just want their pay until the next opportunity comes around
DEVS who have their own project and its their baby, will stay up 4 days in a row geeking out until something is fixed, etc.
NOW - there are all grades of developers out there - from hack cut and paste QT wallet, change supply and block time and name and logo, create a genesis block and POOOF! nEw cOiNzorZ!!!!!!!!!!!
Then you got guys with network backgrounds and programming that can do better than that, they make some decent changes and find a niche for their coin and they do OK
THEN . . you got these guys here from $KASPA, the rare mathematic genius level , not only that, but HIGHly educated . . they dedicated their "young man years" to school . . PERIOD . . i mean these guys have been going to school non stop for 30 years +
and its a GROUP - not just a solitary wizard behind the curtain
so guys like THIS . . not only make subtle changes to bitcoin based tech, they realllly reallllllly understand and see what the completely NEXT thing should be , AND they are capable of turning it into a reality
Jump to: