rusty-kaspa
rusty-kaspa copied to clipboard
Rewrite wish list
An issue for gathering any possible feature wished to be implemented during the rewrite of Kaspa to Rust. This might help guiding the developers to design things in a specific way, even if the actual feature is yet to be implemented.
The option to let getting UTXOs being spent from "all addresses except this this and this".
Ditch gRPC on RPC and using JSON-HTTP as main provider.
Planned RPC endpoints, not a chaos like go-kaspad.
txindex
- eUTXO model.
- base58 encoded addresses
- benchmark msgpack alternative to gRPC in both p2p and rpc perhaps for future switch, if indeed more preformant. (both in compaction and serialization / deserialization)
- developer wallet mode, which unlocks among potentially other things, payloads and custom signing operations.
Archival subnetwork:
- Allow the concept of partial archival nodes:
-
allow for a random section of the blockdag to be stored by nodes (for example with a
--archival 3), which allows the network to distribute the archival functionality among various kaspads offering diskspace, without commiting to the full blockDAG ledger. I guess the number should reffer to the number of randomized prunning periods that the kaspad will store. -
allow for partial archival nodes with a certain lookback period (for example with a
--archival-lookback 3) which will store 3 extra pruning points beyond the current minimum.
This is like a side note - even though Coinbase Rosetta is a separate entity, it may be wise if its not too difficult to provide mechanisms to answer the calls it makes etc.
https://www.rosetta-api.org/docs/Reference.html
- eUTXO model.
Payloads in outputs*.
Compare(benchmark) ed25519(blake2b) with secp256k1 for a possible support in future.
Better call names (on RPC)?
No crashes whatsoever.
Compare(benchmark) ed25519(blake2b) with secp256k1 for a possible switch in future.
I don't think this would be a switch though, since need backward compatibility, but can support ed25519 ontop.
- certificates, proxies and support tor addresses.
Native pagination of the UTXO data to avoid timeouts on a mega-multi-UTXO addresses
simple ui display ports for kaspad and kaspawalletd.
Stratum implementation on node level.
This can really come in varying degrees / with suboptions:
-
- Var diff so miners can display hashrate and better mining stats.
-
- Seperate Api for stats
Better automatic utxo selection scheme in wallet: perhaps dynamic based on utxostate size?
Stratum implementation on node level.
This can really come in varying degrees / with suboptions:
- Var diff so miners can display hashrate and better mining stats.
- Seperate Api for stats
Cant it be based on https://github.com/fungibilly/kaspad-stratum, given that it is written in rust @D-Stacks ?
Stratum implementation on node level. This can really come in varying degrees / with suboptions:
- Var diff so miners can display hashrate and better mining stats.
- Seperate Api for stats
Cant it be based on https://github.com/fungibilly/kaspad-stratum, given that it is written in rust @D-Stacks ?
based probably, but i know it has some issues, so no miner is actually using it. Also it would need to be expanded / altered to allow for multiple solo mining participants.
Currently adapters get told on start-up to which address they should mine too. In the case of a stratum on the node it should be inferred by mining.authorize method, and map the building of blocktemplates to corresponding connections.
Beyond this I would think about implementing Var diff for hashrate stat collection, one of he main reasons the adapters aren't used is
- extra installation steps - I suppose having it built into the node completely negates this
- miners mine to pools to receive information about their mining statistics
If the idea is to decentralize mining power as much as possible towards node mining, this would greatly help. currently we have over 56%+ of miners pool mining, (most of he rest consists of custom miners, probably fpgas), despite having 3 open source stratum adapters available. Ideally i'd even add a ui port where miners can see data, but so far this seems beyond the scope of the node.
I would expect @tmrlvi to also have an implementation of the stratum protocol as well as var diff in rust.
- Adopt bitcoin cash op codes standard.
Node RPC subsystem stats request
Fast and optimized client wallet that can be scaled for high transactional rates, and automated usages i.e. pools, exchanges and others.
- multiple to-addresses in wallet
send(mirrored in transaction outputs). - async requests
- ...
benchmark sustainable max. gas limit per block in accordance with min. requirements to run a node.