I don't have time to read this thread, so I don't know if this has been pointed out already. In our upthread discussion about Cryptonite and the MBC (mini blockchain), I failed to point out that the unscalable (without centralized mining) Bitcoin blockchain (and worse for Monero) can never be pruned because it relies on GUIDs to prevent double-spend replay transactions (or am I unaware that Bitcoin's tx GUID somehow incorporates the block hash?). If anyone is aware of a solution for that please let me know. Because I think it is major vulnerability of the MBC. Has Cryptonite addressed it in some way?
Their white paper says this:
In order to make sure the same signed transaction isn't processed by the network more than once, the block header must also contain a “lockheight” field. The transaction becomes invalid once the lockheight is outside the range of blocks which nodes are required to keep (lets call this the blocks “in view”), and same txid cannot be included twice in any of the blocks which are in view. This makes it impossible to use the same txid twice. However this solution requires that the txid is not malleable.
I think block header there is a typo...should that be transaction header?
Definitely should be 'transaction header'.
Okay so Crypton
ite retains GUIDs for at least the 'lockheight' (a blockchain length) allowance so the replay attack can't occur within that allowance. Off the top of my head, I assume one side-effect of this slightly kludgy design decision if your transaction isn't included in a block before the allowance, then it is invalid and you will need to resend it. However, I assume they are keeping weeks or months of transaction history “in view” so shouldn't be an issue.
Edit: Pruning Bitcoin's txids won't require that transactions include this block chain length expiration field, because address reuse
can't create a duplicate txid. The txid in Bitcoin is not a nonce rather the hash of the transaction which contains the output being spent, i.e. there is no way to reload an address with a duplicate txid, because all transactions are iterative hashes of hashes of hashes (etc) of the historical tree of preceding transactions history feeding the input.
Thus it is appears I was incorrect originally and Crypton
ite's 'lockheight' field is unnecessary if they've implemented txids the same as for Bitcoin. Apparently for space efficiency they may have implemented txids as nonces instead of hash of the transaction?
one feature lost is the ability to sign a transaction and hold it indefinitely before sending to the blockchain network. I can't think of any practical need for such a feature, can you? Silly me, then the balance being spent could be double-spent before you could send to blockchain, so there is no use for the lost feature.
I suppose multi-sig is not adversely affected, because for one reason they need to complete within the retained transaction history. And for another reason I suppose multiple signatures are multiple layered transactions. But I guess it can affect multi-sig in that if you want to retain the tx history indefinitely until all the dependent sigs complete, then 'lockheight' can't be known a priori. However, setting 'lockheight' to weeks or a month is probably sufficient since a block doesn't have to be pruned once its 'lockheight' expires.
