[ANN] RinCoin (RIN) | CPU & GPU Friendly | ASIC Resistant RinHash

[Aevust]

As promised in my status report above, Rincoin Core v1.1.0-rc2, the second release candidate for v1.1.0, is now published for testing. It supersedes rc1 and carries the wallet fix described in that report.

https://github.com/Rin-coin/rincoin/releases/tag/v1.1.0-rc2

Upgrade before block 840,000

v1.1.0 carries RIN3 transaction-version enforcement (RIP-0009), which activates at block 840,000. RIN3 is replay protection: from that height, an upgraded node requires ordinary transactions to carry the version marker 0x52494e33, so an ordinary transaction built for a chain that did not upgrade is not valid on the upgraded one. A node on v1.0.6 or earlier does not enforce the rule and can end up on a different chain, so every node must run v1.1.0 before block 840,000.

Test with rc2 now, and run the final v1.1.0 release through the fork; it will be announced here. The consensus rules rc2 enforces are the ones the final release will enforce, and any further code change will be published as another candidate first.

Emission does not change: the Customized Halving schedule that v1.0.6 already carries gives 6.25 RIN through block 839,999, 4.00 RIN from block 840,000, then 2, 1, and 0.6 RIN at the later phase boundaries.

What changed since rc1

One wallet fix, ported from Rincoin-Sim v1.1.0.2: CWallet::FundTransaction() now carries the wallet's transaction version into a transaction it funds, so fundrawtransaction, walletcreatefundedpsbt and send produce 0x52494e33 from one block before the fork height, as sendtoaddress already did in rc1. A version other than 2 that the caller set before funding is kept. The code change is 17 lines in src/wallet/wallet.cpp; the rest of the seven commits are two functional tests that pin this behaviour, the version bump, and documentation. src/validation.cpp and src/consensus/ are unchanged. Upgrading from rc1 needs no chain-data or wallet migration, and the project's seed nodes run rc2.

What was verified

• On regtest, a two-node script that crosses the fork height passes 24 of 24 checks against rc2. Run against the published rc1 binaries, the same script failed exactly the three checks in which a funding RPC has to set the version itself.
• On the project's private testnet chain, one transaction funded through each of fundrawtransaction, walletcreatefundedpsbt, and send carried 0x52494e33, and all three were accepted and mined in the next block.
• The five Linux x86_64 binaries were built from the tag in two environments, WSL2 and a VirtualBox VM, and are byte-identical. Both of the project's seed nodes were upgraded in place from rc1 with the signed Linux tarball; about seventeen hours later, each was still running the same process, and the two agreed at height 780,193 with matching best block hashes.
• On regtest past the fork height, with the Windows build and with the ARM64 (AArch64) build (run under QEMU user-mode emulation on an x86_64 host), sendtoaddress, fundrawtransaction, walletcreatefundedpsbt and send each produced a transaction with version 0x52494e33, and all four were mined in the next block. On mainnet, the Windows build caught up to the tip and reported the same block hash at height 770,000 as both Linux seed nodes.

The Linux x86_64 build is the verified one. The Windows and ARM64 builds are cross-built and remain experimental; the ARM64 binaries have not been run on ARM64 hardware. On testnet and regtest, where MWEB is active, read the MWEB item under Known limitations on the release page before using the funding RPCs; mainnet is not affected.

Transactions from block 840,000

• Ordinary transactions must carry nVersion = 0x52494e33; coinbase, HogEx and MWEB-only transactions are exempt. The bundled wallet sets it on every path that funds a transaction, from one block before the fork height.
• The createrawtransaction and createpsbt RPCs on their own still write version 2, and rincoin-tx cannot set the marker with nversion=. A transaction built with createrawtransaction and signed without passing through fundrawtransaction, or built by other software, needs the version set before signing: in the unsigned hex, replace the leading 02000000 with 334e4952. For a PSBT, use walletcreatefundedpsbt. The release page gives the rincoin-tx workaround.
• The version is fixed when the wallet builds or funds the transaction, not when it is signed or broadcast. A PSBT or raw transaction funded while the tip is at 839,998 or lower carries version 2 and is valid only if it is mined by block 839,999; fund it again once the tip has reached 839,999.
• The wallet takes the fork height from its own node's chain, not from the network. Around the fork, send only when getblockchaininfo reports blocks equal to headers on a node that has peers.
• A transaction without the marker cannot be mined from block 840,000 onward, however long before the fork it was signed. Re-create pre-signed and timelocked transactions, and transactions without the marker that are still unconfirmed at the fork, spending the same inputs, so that whichever is mined first makes the other invalid. Signing with 0x52494e33 before the fork is safe: rc2 accepts that version before block 840,000 as well. If an output can only be spent through such a transaction, such as a multisig or escrow output whose other signers may not be available later, have that transaction re-created, with the same lock times, and signed with 0x52494e33 while they are.
• Do not broadcast in the last few blocks before 840,000 unless the transaction will confirm before it. The release page's section for node operators, pools, and exchanges gives the full steps for a transaction caught across the fork.
• Pools: call getblocktemplate with {"rules": ["mweb", "segwit"]}. DNS seeder operators: whitelist the filter x3000009.

Verify before you run anything

Official Rincoin Core binaries are signed and published only through the Rin-coin organization on GitHub. The five distribution files are covered by one signed manifest. Fetch the signing key from keys.openpgp.org by its fingerprint, and check that the fingerprint gpg reports for it is this one:

Code:

ED20 B635 4EE4 526D 01F8 3B53 8B6E 3BF4 5C71 4ECA

The manifest is signed with the key's signing subkey, 0ED9 9C46 B219 2E37 5381 EF4A C5BE F8A9 FA06 C16F, so that is the key gpg --verify names first; the primary fingerprint above appears later in the same output. GitHub's own Source code archives are not covered by the manifest. The release page shows the commands.

Rincoin was founded by 七夕凛 (tanabatarin here, ysmreg on GitHub), who reviews the final release; this candidate was built, signed, and published by Aevust. Reports from testing rc2 are welcome on the issue tracker:

https://github.com/Rin-coin/rincoin/issues

Don't Trust, Verify.

[Aevust]

Rincoin Core v1.1.0-rc3, the third release candidate for v1.1.0, is now published for testing. It supersedes rc2 and changes how a node handles transactions with the old version when the fork arrives.

https://github.com/Rin-coin/rincoin/releases/tag/v1.1.0-rc3

Upgrade before block 840,000

v1.1.0 carries RIN3 transaction-version enforcement (RIP-0009), which activates at block 840,000. RIN3 is replay protection: from that height, an upgraded node requires ordinary transactions to carry the version marker 0x52494e33, so an ordinary transaction built for a chain that did not upgrade is not valid on the upgraded one. A node on v1.0.6 or earlier does not enforce the rule and can end up on a different chain, so every node must run v1.1.0 before block 840,000.

At the average block interval measured from 14 October to 2 November, about 65 seconds, block 840,000 falls around 30 November 2026; the date moves with the block rate, so go by the height, not the calendar. Test with rc3 now, and run the final release through the fork.

If the final release comes too late for you to deploy before block 840,000, run the latest release candidate through the fork instead, which today is rc3: it enforces the rule at that height exactly as the final release will. Do not stay on v1.0.6 waiting for the final. Nodes on rc2 or rc1 enforce the rule as well but should move to rc3: rc2 keeps old-version transactions it accepted before the fork in its mempool after block 839,999 until a restart, and rc1's fundrawtransaction, walletcreatefundedpsbt, and send leave transactions at version 2.

The consensus rules rc3 enforces are unchanged from rc1 and rc2 and are the ones the final release will enforce, and any further code change will be published as another candidate first.

Emission does not change: the Customized Halving schedule that v1.0.6 already carries gives 6.25 RIN through block 839,999, 4.00 RIN from block 840,000, then 2, 1, and 0.6 RIN at the later phase boundaries.

What changed since rc2

On rc2, a transaction with the old version that a node had accepted before the fork height stayed in its mempool after block 839,999 had connected: it could no longer be mined, could not be abandoned, and blocked its own re-creation until the node restarted. In rc3, when a node connects block 839,999, it removes every transaction in its mempool that lacks the RIN3 marker, other than MWEB-only ones, together with its descendants. The wallet treats the removal like a conflict: -walletnotify fires once per removed wallet transaction, its change is no longer trusted, and abandontransaction, bumpfee (for a transaction that signals BIP 125), and a re-creation from the same inputs work at once, without a restart. The clean-up runs each time that height is connected, including after a reorg.

The change is the port of Rincoin-Sim pull request #7 and implements RIP-0009 section 7, "Mempool Clean-up at Activation". Consensus, mempool admission (PreChecks()), the block assembler, and P2P are unchanged, and nothing under src/consensus/ changes. Upgrading from rc2 or rc1 needs no chain-data or wallet migration, and the project's seed nodes run rc3.

https://github.com/Aevust/rincoin-sim/pull/7
https://rips.rincoin.org

What was verified

• On regtest, three new functional tests cover the clean-up, including reorgs across the fork height and the MWEB-only exemption, and the rewritten rescue test follows a wallet across the fork in 12 subtests. All pass.
• A two-node script that crosses the fork height passes all 19 of its checks against rc3. With the second node on the published rc2 binaries, and again with Rincoin-Sim v1.1.0.2, all 29 mixed-mode checks pass: the older node keeps the old-version transaction, and its relay of it is rejected without the older node being disconnected. Against rc2 alone, the script fails exactly the four clean-up checks that rc3 adds.
• Removing 227,000 old-version transactions (285 MB) took 6.5 to 6.8 seconds on the machine measured, during which RPC calls that need the chain state or the mempool waited; about 20 MB took 0.16 seconds.
• The Linux x86_64 build was reproduced byte for byte in two environments, WSL2 and a VirtualBox VM: the five binaries, the Linux tarball and the source tarball.
• Both of the project's seed nodes were upgraded in place from rc2 with the signed Linux tarball; fifty-three and sixty-six minutes after their relaunches, neither had restarted, and both were at the same height with the same best block hash.
• On mainnet, the Windows build caught up to the tip from the data directory rc2 had left and reported the same block hash at height 770,000 as the Linux nodes, and the Linux and Windows GUI wallets each received a transaction sent from the other. The ARM64 (AArch64) build was run under QEMU user-mode emulation on an x86_64 host.

The Linux x86_64 build is the verified one. The Windows and ARM64 builds are cross-built and remain experimental; the ARM64 binaries have not been run on ARM64 hardware.

Around block 840,000

• Once block 839,999 has connected, ordinary transactions must carry nVersion = 0x52494e33; coinbase, HogEx and MWEB-only transactions are exempt. The bundled wallet switches once the last block it has processed is 839,999.
• At that block, almost every unconfirmed transaction leaves the mempool, including unconfirmed payments to receivers, because almost all of them carry version 2. Re-create anything that did not confirm, from the same inputs; the release page gives the steps.
• Transactions built or signed outside the wallet need the version set before signing: in the unsigned hex, replace the leading 02000000 with 334e4952.
• Pre-signed and timelocked transactions with the old version cannot be mined from block 840,000 onward, however long before the fork they were signed. If you hold any, have their re-creation, with the same lock times and spending the same inputs, signed with 0x52494e33 while every signer is available; signing with that version before the fork is safe.
• Around the fork, send only when getblockchaininfo reports blocks equal to headers on a node that has peers, and avoid sending or abandoning from the GUI for about a minute after block 839,999 connects.
• If you upgrade a node from rc2 or earlier after block 839,999 has connected on it, read item 4 under "For node operators" on the release page first.
• Pools: call getblocktemplate with {"rules": ["mweb", "segwit"]}. DNS seeder operators: whitelist the filter x3000009.

Verify before you run anything

Official Rincoin Core binaries are signed and published only through the Rin-coin organization on GitHub. The four distribution files are covered by one signed manifest. Fetch the signing key from keys.openpgp.org by its fingerprint, and check that the fingerprint gpg reports for it is this one:

Code:

ED20 B635 4EE4 526D 01F8 3B53 8B6E 3BF4 5C71 4ECA

The manifest is signed with the key's signing subkey, 0ED9 9C46 B219 2E37 5381 EF4A C5BE F8A9 FA06 C16F, so that is the key gpg --verify names first; the primary fingerprint above appears later in the same output. GitHub's own Source code archives are not covered by the manifest. The release page shows the commands.

Reports from testing rc3 are welcome on the issue tracker:

https://github.com/Rin-coin/rincoin/issues

Rincoin was founded by 七夕凛 (tanabatarin here, ysmreg on GitHub), who reviews the final release; this candidate was built, signed, and published by Aevust. Thanks also to the developers of Bitcoin Core and Litecoin Core, on whose work this tree is built.

Don't Trust, Verify.