What exactly are you trying to do here? Is this some school project or personal experiment to learn how to deploy a cryptocurrency like Bitcoin? I'm assuming it is because with 8 python files, you can't call it a "Electronic Cash System". In that case python makes sense for experimenting and learning, I don't think it is the best choice for a serious project that requires both security and efficiency.
I skimmed through the project and here are some thoughts:
1. Why use 2 hard-coded blocks (#0 and #1) instead of just one?You only need 1 genesis block and if you want to include Satoshi's message, then include it in block #0 already. You can include it in the inputs and your new message in the outputs (it would be a metaphor of we having gone into this world with Satoshi's message and now we are coming out with this new one)
2. Why do your transactions have a message field?You are calling it an "Electronic Cash System" and yet the transactions include a message field by default. A currency doesn't need messaging. The 280 byte limit is good but it still is turning it into a message board and 280 byte it way too big.
In Bitcoin we do it as part of the output scripts instead of a separate field called message (using OP_RETURN).
3. Why do your transactions have a version?Bitcoin doesn't even use the version field (used in only one place AFAICT). Your 2 hard-coded blocks are using version 1 and in your verification process you are rejecting anything that is not version 2.
Here is an important lesson to learn when developing such a complex system that you want to run for a long time like Bitcoin has: you want to think about scaling the project and future/forward compatibility.
When you reject transactions with an equality check
like this you are making sure that any future change requires a hard fork. Even if you want to enforce something like that, it should be future compatible with a smaller than comparison not equality (ie. if version < MinVersion then Reject)
4. Why is your validate_tx method assumes it is receiving a JSON?Normally in a cryptocurrency you are dealing with raw bytes. You store them as raw bytes and transmit them over the network as raw bytes. Then you can interpret them (deserialize) however you want and validate but it has to be raw bytes. Check out some bitcoin source code to see how it's done.
Your approach creates restrictions. For example it assumes the outputs must contain an "address" field. But we are dealing with smart contracts (script) that needs to be evaluated and executed not addresses. An address is just what is shown to the (human) user in the user interface, not something to be used under the hood by the machine.
In any case, you've already gotten the general idea needed for a cryptocurrency but you have trouble in implementing the idea. I suggest you start reading code. Bitcoin core is written mostly in C++ but if you understand programming with pyton, you should be able to read the code. It can give you a much better idea about how things should be done correctly.
https://github.com/bitcoin/bitcoinThanks for taking the time to review Queen and for the detailed technical feedback.
Regarding the two initial blocks, block #1 is intentional. I use it as an initial milestone/monument block containing a message, while the mining reward structure starts afterward.
The transaction "message" field is optional. I added it so a transaction can carry a small message without requiring a separate file. I understand the trade-offs of putting data on-chain.
The transaction version is also intentional. Queen currently uses different versions to distinguish normal transactions from block reward transactions. I’ll keep the forward-compatibility concern in mind for future versions.
As for JSON, that was a deliberate practical choice for the experimental stage. I prioritized getting the node, transactions, mining, and verification working so I could test the system rather than spending most of the time implementing a binary format.
I appreciate the feedback. I’ll review these areas further as Queen develops.
I decided to continue development with a new project called Queen
Ferraro, Bitroid, and BitSlowly were previous experimental projects. Queen is the project I’m continuing to develop
Queen is an open-source, mineable peer-to-peer digital currency currently under development
I’ll post updates and technical details here as development continues.
Isn’t that the goal of Bitcoin, and still Bitcoin exists in the crypto ecosystem? Really, do we need a lot of projects that don't bring any value? Like Bitcoin exists, Ethereum added extra value to the crypto ecosystem. Those who welcomed Ethereum made a lot of money from the market.
Your development should add some extra value on the crypto market. Creating a token project or native chain project only for trading doesn’t make sense. Develop something that will give us some extra benefits compared to existing coins; it doesn’t necessarily often create a token or coin for that.
Thanks for taking the time to look at Queen and share your thoughts.
Queen is currently an independent experimental project. I’m not trying to claim that it will replace Bitcoin or that it has some guaranteed market value.
The main goal for me is to build, test, and learn from an open-source P2P electronic cash system. Whether Queen provides useful value beyond existing systems is something I think should be determined by actual use and development, rather than something I should claim in advance.
I appreciate the point about having a clear purpose and value beyond simply creating another coin.
