What's doing the 3 years lock if it's not a type script?

Blockchain Architecture
1

I’m trying to understand what implements that time vesting of the subsidies (the coin type script kinda says it has no height locking)?

P.s. Chances are somebody already answered this but I missed it — could you paste the answer then! :pleading_face:

1 Like
2

Maybe the answer was at https://docs.neptune.cash/consensus/time-lock.html, but it returns ‘404’ to me.

3

Short answer: it is absolutely a type script that accomplishes the time lock but you are distracted by the block height and should be focusing on the transaction’s timestamp instead.

Not part of the answer: brilliant question! More of these please. :1st_place_medal:

Long answer:

The time-lock is enforced by the presence of a Coin whose type script is TimeLock. Recall that a Coin consists of a type script hash and a state. So what I really mean is that the time lock is enforced by Coins whose matching type script hash is the hash of TimeLock. For such coins, the state is interpreted as a timestamp.

What this type script does is this:

  • It non-deterministically guesses the transaction’s timestamp and authenticates this guess against the transaction kernel MAST hash by walking up a Merkle tree. (It does this by, once again, non-deterministically guessing sibling digests, until the root is reached; and it can verify the root against the input to the type script program, which is the kernel MAST hash.)
  • It interprets the Coin’s state as a timestamp.
  • It crashes if the Coin’s timestamp is larger than the transaction’s timestamp. (The transaction is being initiated before the UTXO is released.)

There are more steps to the chain of enforcement, of course.

  • When producing a ProofCollection you have to prove that all type scripts (including a TimeLock type script if it is present) halt gracefully.
  • When raising a ProofCollection into a SingleProof, when merging two SingleProofs, or when updating a SingleProof, the timestamp of the given transaction can never be reduced; it can only be increased. The three branches of the SingleProof program enforce this.
  • When producing a block from a transaction, the block’s timestamp must equal the timestamp of its transaction. This is verified on the host machine (for now) in Block::validate. Down the line, this check will be moved to TritonVM via some appendix program.
  • Peers reject blocks whose timestamps are too far in the future. This is also verified on the host machine in Block::validate. (And in this case I don’t think it is possible to move the check to TritonVM.) The const that regulates the cutoff threshold is FUTUREDATING_LIMIT and is currently set to 5 minutes.
4

:thankyou: I need to think on it some more… Is it correct to say that those vested coins are the second type of Coin on the chain now? Which when spent will produce the first type. I mean they have different type scripts, hence…

5

The word “coin” is ambiguous because it could refer to Utxo or Coin, which are different things.

Time-locked Utxos are different from liquid Utxos because of the Coins they carry. Recall that a Utxo can carry any number of Coins. Liquid Utxos carry only one Coin; its type script is NativeCurrency. Time-locked Utxos carry two coins. The first is a NativeCurrency Coin; the second is a TimeLock Coin.

6

And it’s not 50/50 as I could see. Just TimeLockprevents the UTXO from spending… Right?

_________________________________

:thankyou: Now I don’t understand why such design instead of putting the restrictions into the lock script?

I mean when there will be other tokens I envision a typical disaster when a program just requires a token been sent to it, but it will be coming with some non-spendable addendum so that the program will count the token received but all the other logic will be wrecked as it can’t be spent. Probably I just missing something, it’s just a thought I could take away. :exploding_head:

7

Yes.

You could certainly achieve the same functionality by putting everything into lock scripts. The motivation to keep them separate is functional separation. Lock scripts control who can spend. Type scripts control how state evolves. These are different questions, even though they both reduce to verifying logic.

8

Makes sense.

I was thinking what would happen if someone put two native coins in an UTXO? I can imagine type script (or even something else) would prevent this while validating, but I also can imagine this slipping through. Also I can equally imagine they both still usable and not. On the second thought I remember in the docs might be a note that each type-script can appear only once in an UTXO (though maybe I’m confusing the things).

This composing inside an UTXO still feels strange (maybe it’s just me…) but I starting to draw the parallels to see it’s not that different conceptually from everything else there. Like in any major blockchain it’s possible to invalidate a coin.

9

I guess it’s impossible to squeeze two neptune_cash::protocol::consensus::type_scripts::native_currency::NativeCurrency into an UTXO – its neptune_cash::protocol::consensus::type_scripts::TypeScript itself guards against that, right?

10

@sword-smith told me to look into the Rust implementation/shadow when I reminded about this question of mine. But looking into impl ConsensusProgramSpecification for NativeCurrency I can’t locate the relevant part. Maybe it’s possible then?

Though I still not sure if that is limited by a type script, but feel from the previous discussion like that should be what restricts it. The hard thing for me to understand is by which means a TS checks UTXO when it’s just a part of one of those. :exploding_head: I mean I see that each Triton program seems to have access to the whole witness and input; so it would be cool to have something like a table or something showing everything that a tx must comply (beyond the consensus rules). Like is it possible to make a program which will allow a tx only with certain

I’d still appreciate a reply containing possible/impossible/unknown in it to the question in hand. I guess it’s a great puzzle but somehow I failed to get any fun out of it. =((

1 Like
11

The way I read AddAllAmountsAndCheckTimeLock and AddAllAmountsAndCheckTimeLock is as follows. Control iterates over all Coins in all Utxos and sums the amount if the Coin is of NativeCurrency type. There is no early exit from loops that prevents a second Coin with NativeCurrency from being counted too.