From Mochimo Wiki
Revision as of 13:35, 19 March 2021 by Mochimowiki (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

MIP-0005 - TX_ID to Be Globally Unique Hash of Entire Transaction

Presented to the Core Contributor Team on March 19, 2021 by user sputnik


The following Core Contributors have "sponsored" this MIP.

Stackoverflo (talk · contribs) In the original conception of the codebase, we looked at TX_ID as a hash of the entire transaction. Later, reasoning that using the WOTS+ schema meant source addresses should not be signed more than once, it should be sufficient to hash just the source address. A few years later, and we noticed people (specifically miners) will sign the same WOTS+ address more than once, even though they've been explicitly made aware of the inherent security risks. Consequently, third part transaction processors and exchanges have taken note of the "duplicate TX_ID" on the network, and erroneously assumed that some double-spend hijinks were occuring. To avoid this ambuiguity, and cause the MCM network to perform more or less the way every other network performs, we will endeavor to make the TX_ID globally unique by virtue of hashing the entire transaction. Returning, in this case, to the original architecture of the the system.

NOTE: Sponsorship for these purposes means that these Core Contributors have committed to developing the code on behalf of the community if this MIP is adopted. Note: Core Contributor sponsorship is not required for a MIP to be implemented. It just makes things easier on the community.

Problem Definition

Some exchanges have taken issue with the idea of TX IDs not being globally unique, since they can be repeated if someone signs a WOTS+ address twice.

Solution Summary

The codebase will be updated with Mochimo v3.0 release to include TX_IDs which are a hash of the entire transaction rather than just the source address.

Hard Fork Required ?


Technical Details

The TX_ID is only computed two places in the code, there it will be changed from hashing from the TX Buffer starting at tx->src_address for TXADDRELEN bytes (2208 bytes) to hashing from the TX Buffer starting at tx->src_address for TRANLEN bytes (8832 bytes) instead. Changes are shown below:

In config.h:

>> #define V30TRIGGER 259328 /* Mochimo 3.0 Activation Block TestNet Value*/

In mirror.c[process_tx()]:

>> mirror.c:      static word32 v30trigger[2] = { V30TRIGGER, 0 };
<< mirror.c:      sha256(tx.src_addr, TXADDRLEN, tx_id);
>> mirror.c:
if(cmp64(Cblocknum, v30trigger) > 0) {
   sha256(tx->src_addr, TRANLEN, tx_id);
} else {
   sha256(tx->src_addr, TXADDRLEN, tx_id);

In bval.com:

>> bval.c:      static word32 v30trigger[2] = { V30TRIGGER, 0 };
<< bval.c:      sha256(tx.src_addr, TXADDRLEN, tx_id);
>> bval.c:
if(cmp64(bnum, v30trigger) > 0) {
   sha256(tx.src_addr, TRANLEN, tx_id);
} else {
   sha256(tx.src_addr, TXADDRLEN, tx_id);

Test Results

The above change is status CONFIRMED WORKING, following implementation and testing on the TestNet. Please note: If any TXs are present in the TXCLEAN.DAT or MIRROR.DAT at the time the block trigger is hit, the blocks created therefrom will fail BVAL, and hang the system. Therefore, a node restart is required using "gomochi" following the trigger block, as a node "resume" will otherwise break the system.