Community News

• Block Producer: The Service Node responsible for generating a block.
• Block Leader: The Service Node at the top of the Service Node List queue. By default, the Block Leader serves as the Block Producer during Pulse round 0. If that round fails, the Block Producer is changed through multi-block seeding.
• Provide two signatures for signed block messages.

  Submitting only one signature creates a vulnerability: a quorum member that receives and relays the message could tamper with its contents—for example, by changing the round to an invalid value. This could cause other quorum members to reject the message, incorrectly record that the Service Node did not participate in the round, and bias the network toward decommissioning that node.

  Instead of taking the shortcut of providing only one signature, we use the same approach applied to other messages:

  1. The first signature covers the contents of the message. This proves that the message originated from the claimed Service Node and prevents its contents from being altered.
  2. The second signature signs the final block and is included in the block as it propagates through the network.
• Make active Service Node information available for Pulse to query, allowing Pulse quorums to be generated outside of the Service Node List.
• Add Service Node checkpointing for PoS.

• Palm Wallet has released Android version 1.5.9.
• IOS version 1.5.9 will be released in September. This release will not overwrite older versions; please back up your data before updating.

• A community-developed Judecoin mainnet blockchain explorer combining real-time access to on-chain data with interactive network visualization has been officially launched as Blockchain Explorer III.
• Its source code has been published in the designated repository.

The Windows GUI version v3.2.0 has been officially released.

The Linux version has entered the final testing stage and is expected to be released in September.

The upgrade of the Windows GUI wallet is nearing completion and is about to enter the final testing phase; it is expected to launch in August.

• A community-developed version of the blockchain explorer has been updated in the designated code repository.
• In the future, more community-developed versions of blockchain explorers, wallets, and other ecosystem applications will be updated.

• Fix service node winner incorrect error

If we are re-deriving states we still also need the historical quorums such that we can process incoming blocks with state changes. Without it, state changes will be ignored and skipped causing inconsistent state in the service node list.

This mandates a rescan and stores the most recent in state_ts, and only just quorums for states preceeding 10k intervals. We can no longer store the 1st most recent state in the DB as that will be missing quorums as well for similar reason when rederiving on start-up.

• Apple's system wallet and GUI wallet need to be redeveloped from the underlying code; for the system wallet, the Mac version needs to be completed first before the mobile version can be completed.

Andres Pavez

Greetings,

IANA has published a new Certificate Authority (CA) certificate used to validate the authenticity of the DNS root zone trust anchors file (root-anchors.xml).

The updated certificate bundle is available at:

https://data.iana.org/root-anchors/icannbundle.pem

This bundle currently contains both the existing certificate and its replacement certificate. Signatures chaining to the new certificate are expected to be published in 2028, at which point relying parties will need to validate using the new certificate.

Affected file(s):

• src/common/dns_utils.cpp

Please review whether the trust anchor validation material in this repository should be updated to include the current contents of icannbundle.pem.

Considerations for updating the trust anchor are described inDNSSEC Trust Anchor Publication for the Root Zone (RFC 9718).

Thank you.

jessicayang-judecoin

Thank you for the report.

I reviewed the DNSSEC trust anchor handling. The old ICANN CA certificate block was commented out and was not used by the current resolver path.

DNSSEC validation is initialized directly from the built-in DS trust anchors via get_builtin_ds(), which already includes the current root DS trust anchors.

I removed the stale commented-out certificate block and updated the comment to keep the trust anchor handling clear without changing resolver behavior.

• Our new website is https://www.judecoin.info, which is now integrated with GitHub. https://www.judecoin.io will cease service.
• The download addresses for CLI Wallet and Palm Wallet have been updated.
• New commands will be required for future node registration, node restarts, and node IP changes.

Cleanup on block adding failure.

If a block adding operation fails and triggers the following error message:

Block added hook signalled failure

the service node list does not get reset correctly. This can immediately lead to an incorrect service node winner, because the winner has already been incremented but not removed from the list.

This update fixes the issue by calling the blockchain detached hooks to perform the required cleanup.

The old version of the website will no longer be available. The new version will be gradually added to the information repository for community reference.

More APIs will be opened in the future, and more versions of blockchain explorers will be included.

Currently, some code repositories on GitHub and the website content are lagging behind the on-chain development progress.

In the future, the website will be restructured and integrated with GitHub. The website will be built around the theme of Proof of Stake, and its content can be directly updated and optimized on GitHub.

Kusama (KSM) Tripartite System

Kusama (KSM) uses a tripartite system:

• Referendum: all nodes
• Council: community governance organizers
• Technical Committee: development

Incentive Mechanism

Node incentives and voting are related to Service Nodes updating the community's latest CLI.

Rewards for community governance organizers are distributed from the total amount contributed to the Judecoin community since its launch.

Qualifications for Community Governance Organizers

1. Community governance organizers must hold at least 100,000 Judecoins.
2. They must have an independent GitHub account.
3. They must have the ability to identify simple code.
4. Community governance organizers must not be located in regions where cryptocurrency operations are prohibited.
5. They must be able to provide maintenance protocols and technical upgrade suggestions.
6. Malicious and illegal upgrades will be rejected.
7. Malicious proposals will be penalized, have their privileges revoked, or be blocked.
8. Community governance organizers must leave a message on GitHub and provide an email address.

Update your CLI wallet to version V3.1.1.

If you have already registered and started a Service Node, re-register and start it with the new wallet version to prevent block rewards from not being distributed.

In the future, the core nodes, iOS wallet, and GUI wallet versions will be upgraded to prepare for the next major upgrade.

The next wallet upgrade will add more nodes.

Please follow the official website's instructions to start the registration service.

quorum_cop: Fix Bug in Missing Node Detection and Add Logging

Fixed a bug in missing node detection and added logging.

Service Nodes: Add Quorum States to Database Storage

Added quorum states to database storage for Service Nodes.

Make Transaction Type and Version Scoped Enums

This converts the transaction type and version to scoped enums, giving type safety and making transaction type assignment less error-prone.

There is no implicit conversion or comparison with raw integers that needs to be considered.

This converts uses of:

cryptonote::transaction::type_xyz

to:

cryptonote::transaction::txtype::xyz

For versions, names such as:

transaction::version_v3

become:

cryptonote::txversion::v3_tx_types

This also allows and includes various other simplifications related to, or enabled by, this change:

• Handle is_standard_tx dynamically in serialization code, setting type::standard or type::state_change rather than using a version-determined union.
• get_type() is no longer needed with the above change. It is now much simpler to directly access type, which will always have the correct value, even for v2 or v3 transaction types.
• Although there was an assertion on the enum value, get_type() was only used sporadically, and many places accessed .type directly.
• The old unscoped enum did not have a type but was assumed castable to and from uint16_t, which technically meant there was potential undefined behavior when deserializing any type values greater than or equal to 8.
• Transaction type range checks were not being done in all serialization paths. They are now.
• Because get_type() was not used everywhere, and many places simply accessed .type directly, these issues might not have been caught before.
• set_type() is not needed. It was only being used in a single place, wallet2.cpp, and only for v3 transactions, so the version protection code was never doing anything.
• Added a std::ostream << operator for the enum types so that they can be output with:

  << tx_type <<

rather than needing to wrap it everywhere in:

  type_to_string(tx_type)

• For versions, the annotated version string is output, such as v3_tx_types, rather than just the number.

1. quorum_cop: added quorum cop and Service Node keys to judecoind.
2. Service Nodes: added quorum states to database storage.
3. quorum_cop: changed uptime proof prune timeout to 2 hours 10 minutes.
4. Added judecoin-sn-keys SN key management tool.

This allows inspecting, generating, and restoring Ed25519 secret key files as needed by judecoind.

Generate SN Key

$ ./judecoin-sn-keys generate key_ed25519

Generated SN Ed25519 secret key in key_ed25519

Public key:      08791467164b3f41681cb650385ffedeab96345f509e87a9852e4389643c5611
X25519 pubkey:   ea7b652f1d215674441775e5e42ceaef31cf3ffad6cc3f0321031abf0935b86c

Show SN Key

$ ./judecoin-sn-keys show key_ed25519

key_ed25519 (Ed25519 SN keypair)

==========

Secret key:      08016220970441955b29b1797f2c4bee0d3237e50bfafdb7999264caea163ecc
Public key:      08791467164b3f41681cb650385ffedeab96345f509e87a9852e4389643c5611
X25519 pubkey:   ea7b652f1d215674441775e5e42ceaef31cf3ffad6cc3f0321031abf0935b86c

Restore SN Key

$ ./judecoin-sn-keys restore key_ed25519-2

Enter the Ed25519 secret key:

08016220970441955b29b1797f2c4bee0d3237e50bfafdb7999264caea163ecc

Public key:      08791467164b3f41681cb650385ffedeab96345f509e87a9852e4389643c5611
X25519 pubkey:   ea7b652f1d215674441775e5e42ceaef31cf3ffad6cc3f0321031abf0935b86c

Is this correct? Press Enter to continue, Ctrl-C to cancel.

Saved secret key to key_ed25519-2

1. Version 3.0.1 of the CLI wallet will be re-released once the upgrade is complete.

Palm Wallet is an integrated wallet based on Judecoin mainnet version 3.0.0.

Future updates and upgrades to the wallet will primarily be based on version 3.0.0.

Cleaner Validation

This update provides cleaner validation that is faster and more reasonable.

There is no need to call check_key for every output public key in check_tx_outputs again.

The redundant call to check_key inside check_tx_outputs can be safely removed.

This change saves one unnecessary point decompression for every output public key since hard fork v14.

This provides a useful performance gain, in addition to the key image sanity check done for clarity and to prevent future mistakes.

Reject New Votes That Can Slip Through the Syncing Phase at Startup

If the daemon is not completely synced at startup, it can connect to peers that relay P2P votes from the tip of the chain before the daemon realizes it has blocks to sync.

This can cause the missing quorum state error to print erroneously.

This update rejects new votes that can slip through the syncing phase at startup.

Do Not Relay Expired Votes; Add Vote Tolerance Before Disconnection

This update changes the way votes are relayed to fix superfluous P2P disconnections.

The update includes:

• Checking that votes are not older than VOTE_LIFETIME before relaying.
• Adding a 5-block buffer to incoming vote tolerance handling.

Votes that are too new or too old should not be accepted.

However, a disconnection should not be triggered if the vote is within 5 blocks of the acceptable range, so that relays from slightly out-of-sync peers do not trigger P2P disconnections.

Use shared_ptr Storage for service_node_info

This converts the stored service_node_info value into a shared_ptr rather than a plain service_node_info.

This yields a huge performance benefit by significantly eliminating the vast majority of service_node_info construction, destruction, and copying.

Most of the time when a service_node_info is copied, nothing in it has changed, which means the same thing is being stored again.

This previously caused extra construction for every Service Node info on every block, and extra destruction when old stored history was culled.

By using a shared_ptr, the vast majority of those constructions and destructions are eliminated.

With the shared_ptr approach, a copy is only made when a change is actually needed, such as infrequent per-Service Node events including state_change, received reward, contribution, and similar changes.

The contained reference is deliberately const so that values are not changeable.

A new function performs an explicit copying duplication, returning the new non-const value and storing the const reference in the shared pointer.

Related to this is a small change and fix to how proof info and public_ip are stored.

Rather than storing the values in the service_node_info struct itself, they are now stored in a shared_ptr inside service_node_info, which is intentionally shared among all copies of the service_node_info.

In other words, a Service Node info copy deliberately copies the pointer rather than the values.

This also moves the IP values into the proof struct, since that is easier than maintaining a separate shared_ptr for each value.

Previously, because these values were stored directly in service_node_info, they would get rolled back in the event of a reorg.

That behavior is undesirable, because it could roll back to old values of the uptime proof and IP address.

Those values are not dependent on the blockchain and should not be affected by a reorg or rollback.

With this change, they are not affected, since there is only one actual proof stored.

Note that the shared storage here only applies to in-memory states.

States loaded from the database will still be duplicated.

Add Locks Around the Refresh Thread

Wallet API is really messy with threads.

The refresh thread can run at any time and change internal wallet state, which breaks almost everything.

This puts all non-trivial wallet access from wallet_api behind a lock of the refresh thread to lock it out from refresh while other operations are underway.

Do Not Relay Service Node Votes or Uptime Proof If Synchronising

When trying to sync the chain, nodes are constantly bombarded with voting information and uptime proofs.

Service Node votes and uptime proofs are not relayed during synchronization to reduce the bombardment of P2P data.

1. Core: submit uptime proof immediately after registering.
2. Incorporate the Service Node IP address into uptime proofs and validate the IP address when receiving uptime proof.
3. Add a message on receipt of your own uptime proof from the network.
4. Relay proofs back to the source, but do not relay your own proof again.

Otherwise, a ping-pong situation can occur as follows:

Node1 sends uptime ->

Node2 receives uptime and relays it back to Node1 for acknowledgement ->

Node1 receives it, handle_uptime_proof returns true to acknowledge ->

Node1 tries to resend to the same peers again

Instead, if we receive our own uptime proof, then acknowledge it but do not send it on.

If we are missing an uptime proof, it will have been submitted automatically by the daemon itself instead of using our own proof relayed by other nodes.

1. Add --service-node Option to Daemon

By using this option, Judecoin can run in Service Node mode.

2. Add New Interactive Daemon Command prepare_registration

A new interactive daemon command, prepare_registration, has been added to generate a registration command.

This also allows users to use:

judecoind prepare_registration

to generate a registration command via RPC commands to judecoind.

This is particularly useful when judecoind is running in non-interactive mode.

Example

judecoind prepare_registration

2025-07-09 11:49:17.879 I Judecoin 'Chamaeleo dilepis' (v3.0.0-391e7e6a8)

Judecoin Service Node Registration

------------------------------

Service Node Pubkey: 8dc0d93a5f9ce759448e38bf9bbbd1f439a09d0c853e0b91626e50f6f07390f3

Staking requirement: 23600.000000000 jude from up to 9 contributors

Enter the JUDE address of the Service Node operator (C/Cancel):

J6jRMfcZBUNCoc3iacrJgh79UiuoQgW4KDe4aLh5Dww2N6B8iWhuzB1StgCEWjpt4YNVzfrQLRB82XfgjcYgcnHWSf1LKxo

The operator must stake between 5900.000000000 jude and 23600.000000000 jude.

How much JUDE does the operator want to stake? (B/Back/C/Cancel/max/min) [max]: 8000

This Service Node requires an additional stake of 15600.000000000 jude.

To add a reserved contribution spot enter the contributor's JUDE address now.

Leave this blank to leave the remaining stake open to public contributors. (B/Back/C/Cancel):

JBAo6emU36qSJU12Mdp6Pc1ioAFyRUiHbDDqbuoPRgSn6z6tnnsUzEHgRZ4axJb73Neb7DJjnfEHrQdjgUTvD7ZhF8hZnDj

The next contributor must stake between 1950.000000000 jude and 15600.000000000 jude.

How much JUDE does contributor 1 want to stake? (B/Back/C/Cancel/max/min) [max]: 5000

This Service Node requires an additional stake of 10600.000000000 jude.

To add a reserved contribution spot enter the contributor's JUDE address now.

Leave this blank to leave the remaining stake open to public contributors. (B/Back/C/Cancel):

This Service Node has multiple contributors and thus requires an operator fee percentage. This percentage is removed from the block reward and assigned to the operator, then the remaining reward is split among contributors, including the operator, proportionally to their contribution.

Enter the operator fee as a percentage [0.00-100.00] (B/Back/C/Cancel): 5.67

Total reserved contributions: 13000.000000000 jude.

The total reserved amount (13000.000000000 jude) is less than the required full stake (23600.000000000 jude).

The remaining stake (10600.000000000 jude) will be open to contribution from 1-7 public contributors.

The Service Node will not activate until the entire stake has been contributed.

Is this acceptable? (Y/Yes/N/No/B/Back/C/Cancel): Y

Registration Summary:

Service Node Pubkey: 8dc0d93a5f9ce759448e38bf9bbbd1f439a09d0c853e0b91626e50f6f07390f3

Operator fee (as % of Service Node rewards): 5.67%

 Contributor        Address            Contribution                     Contr. %

_____________    _____________      _________________            ________

   Operator      J6jRMfcZB..xo       8000.000000000              33.90%

Contributor 1   JBAo6emU3..Dj       5000.000000000              21.19%

    (open)          (any)            >=1514.285714286            >=6.42%

    (open)          (any)

    (open)          (any)

    (open)          (any)

    (open)          (any)

    (open)          (any)

    (open)          (any)

Is the staking information above correct? (Y/Yes/N/No/B/Back/C/Cancel): Y

DRY Wallet Inactivity Timer

This replaces the callback wrapper that had to be called from each command callback to reset the inactivity timer.

The previous wrapper was randomly missing from some commands.

It is replaced with a generic one in the console_handler, allowing pre-callback and post-callback commands to be specified.

Significantly Reduce CLI Wallet Sweep RPC Request Count

When the CLI wallet sweeps, it processes the transaction to show output and ring information.

Previously, this was done by making a separate get_outputs.bin RPC request for each input being spent.

For a large sweep, this added a large amount of latency, making the entire request take much longer than necessary.

This update optimizes the process by batching output requests into 5000 outputs per request, which will typically mean just one request.

Judecoin Team

console_handler: Log Errors Properly and Gracefully Shut Down Wallet

• In simplewallet, invalid or missing commands were not reported to the CLI because errors were thrown and caught silently.
• Now errors are always logged to the user unless they are thrown by something other than the wallet.
• Added an invalid_command exception to distinguish between an error thrown by the console_handler, such as a missing or empty command, and an actual std::out_of_range thrown by wallet code.
• Previously, this could incorrectly report Unknown command ... even when it was a known command.
• Exceptions thrown through commands sent by RPC over the terminal are now caught, allowing the wallet to shut down properly.
• In console_handler, cmd_handler failure is no longer treated as an invalid command. Previously, if a command failed, it would assume an invalid command and log or try the next branch, which was detecting application exit.

Wallet and Simplewallet

Dropped support for the mine-to-use RPC system.

Add grace_blocks to is_synced()

Add a grace_blocks parameter, defaulting to 0, to is_synced().

This replaces the previous check for being fully in sync with a check for being close to synced.

The wallet can occasionally become out of sync when a new block is added, making it one block behind the chain height.

This can result in unnecessary wallet errors, because if the user immediately calls the function again after it fails, it will succeed.

Fix Fork Earliest Height Caching in node_rpc_proxy

There was a problem caused by combining two states, earliest_height and enabled, into a single cached value.

While earliest_height does not change on the fork, enabled does.

If the call is made when enabled = false, meaning before the fork, the wallet will never apply the rules for that fork until the wallet is restarted and the cache is cleared.

Mobile Wallet Optimization

The mobile wallet will optimize the desktop image, wallet full name, and shared node staking function.

Annotate and Split Up Ring Signature Code

generate_ring_signature and check_ring_signature were used somewhat inappropriately to sign and check a signature of a single key image.

While this works, the full ring signature algorithm adds quite a bit of complexity that is not needed, and does not run, for the key image proof included in stake transactions and exported key images from the wallet.

This update splits it up, makes the key image interface considerably simpler, and adds annotation comments throughout it.

It also adds comments into the main signature code.

This is a necessary step toward getting stake transactions and key image exports working with Ledger, without implementing the full ring signature, because that is quite involved and not needed for most of these cases.

Remove Macro and goto Code in wallet2::import_outputs

This replaces a confusing code section and replaces an odd macro / goto combination with a more reasonable if statement.