Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: Time-Locked Coinbase #280

Closed
wants to merge 16 commits into from
Closed

feat: Time-Locked Coinbase #280

wants to merge 16 commits into from

Conversation

aszepieniec
Copy link
Contributor

In Neptune Cash, the coinbase is divided into two parts. The first is liquid immediately; the second is locked for 3 years. This PR applies the latter lock.

Note that the guesser reward is already split in two parts, one liquid immediately and the other locked for 3 years. This commit modifies the NativeCurrency type script so as to require that if the transaction has a coinbase, then half of it is locked -- however this amount is distributed across time-locked outputs and guesser fee.

aszepieniec and others added 15 commits December 6, 2024 16:33
@aszepieniec @Sword-Smith
feat(native-currency): Add time-lock check in rust source
27d4ad1
@aszepieniec @Sword-Smith
refactor!(PrimitiveWitness): Drop ArbitraryWith implementation
a540005 
Function `arbitrary_with` still exists but has been renamed to
`arbitrary_with_size_numbers`.

New name describes purpose of arguments, which are not unambiguous
otherwise. This change means that `PrimitiveWitness` does not any
longer implement trait `ArbitraryWith`, which only makes sense if
the arguments are unambiguous.
@aszepieniec @Sword-Smith
refactor(PrimitiveWitness): Time-lock half of coinbase
d97362f 
In the main code path for arbitrary instances of `PrimitiveWitness`,
the `num_inputs` now has type `Option<usize>` so that it either counts
the number of input UTXOs in the transaction, or else indicates that
the generated `PrimitiveWitness` is one for a coinbase transaction
(*i.e.*, one with a set coinbase amount). When a `PrimitiveWitness`
for a coinbase transaction is generated then there are 2x as many
output UTXOs and half of them are time-locked for 3 years.
@aszepieniec @Sword-Smith
fix(PrimitiveWitness/Arbitrary): Pick one: coinbase or inputs
3e72a15
@aszepieniec @Sword-Smith
test: Add negative tests
8c7ab6e 
 1. Transaction is invalid if not enough coinbase funds are
    time-locked.
 2. Transaction is invalid if time-lock does not extend far enough
    into the future.
@aszepieniec @Sword-Smith
feat(native-currency): Time-lock half of coinbase
d7a5f92 
The tokenomics of Neptune Cash stipulate that half of all mining
be time-locked for three years. This commit time-locks half of the
coinbase. Half of the guesser fee is already automatically
time-locked.

Specifically, this commit modifies the tasm code for consensus program
`NativeCurrency` to verify that across all outputs (and counting half
of the transaction fee), at least half of the coinbase is time-locked
for three years.

Co-authored-by: Thorkil Schmidiger <thor@neptune.cash>
@aszepieniec @Sword-Smith
style: Check sanity of size indicators
9368dd7 
Closes #276.

Co-authored-by: Thorkil Schmidiger <thor@neptune.cash>
@aszepieniec @Sword-Smith
refactor: Integrate time-locked coinbase into mine pipeline
14d0961 
Co-authored-by: Thorkil Schmidiger <thor@neptune.cash>
@aszepieniec @Sword-Smith
refactor: Specify proving capability
287c446 
Allow caller to specify proof quality of coinbase transaction. This
change has the benefit of allowing tests that do need coinbase
transactions but not necessarily with valid proofs.

This closes #242.

Co-authored-by: Thorkil Schmidiger <thor@neptune.cash>
@Sword-Smith @aszepieniec
test(mine_loop): Add test that coinbase tx has timelocked/liquid outputs
d29af9b 
Co-authored-by: Alan Szepieniec <alan@neptune.cash>
@Sword-Smith @aszepieniec
test(mine_loop): Account fox timelocked coinbase output in test
402e47e 
Co-authored-by: Alan Szepieniec <alan@neptune.cash>
@aszepieniec
test: Re-randomize former proptest
ff90573 
No reason for these proofs to be deterministic; no proofs are being
generated.
@aszepieniec
style: Add conversion method for NativeCurrencyWitness
20d45ba 
From `PrimitiveWitness`.
@aszepieniec
style: Rename for better descriptiveness
13e0ff2
@Sword-Smith
test(native_currency): Assert that expected asserts are hit
a7ee5c5 
Use the error IDs to assert that the expected assert-instructions are
hit in the various negative tests.
@Sword-Smith
test(primitive_witness): Fix test-case generators after timelocking cb
9a9d06b 
Multiple tests and test-case generators needed adjusting after adding
timelocks to minimum 1/2 of the coinbase amount.
@dan-da
Copy link
Collaborator

dan-da commented Dec 12, 2024

Can you describe (or link to a description) the purpose (game theory? security? economics? marketing?) of time-locking 50% for 3 years, and why those specific pararameters are chosen. thx.

@aszepieniec
Copy link
Contributor Author

The dynamic we are hoping to engineer is to align the incentives of miners with the long-term success of the cryptocurrency. Miners have an interest in the price now as well as in the price three years from now, which is affected by the quality of the protocol at that time. In particular:

  • It turns miners into cheerleaders for Neptune Cash in a way that alternative blockchains don't an analogue for.
  • In a proof-of-work blockchain, miners have some deciding power over proposed protocol changes, and in this context we want their incentives aligned with the long-term success of the blockchain.
  • We want to incentivize miners to support continued protocol development and maintenance.

As for the particular parameters:

  • Three years coincides with the halving period. This makes it easier to draw circulating supply graphs, for those that are interested in that sort of thing.
  • Half coincides with a right shift by one bit, which is the simplest possible non-trivial arithmetic for dividing amounts. Bear in mind that whatever alternative you might propose would need to be implemented robustly in Triton assembler, because otherwise you lose one of the main selling points of Neptune, which is the cheap verification of consensus.

We did consider alternative parameters. We had the following considerations:

  • Short term and early term price play should not affect architectural decisions.
  • Complex policies are a hurdle for spreading understanding. So simplicity and similarity to existing templates are good.
  • Bitcoin launched into a world where no-one knew about the potential of blockchain money; by contrast, the environment Neptune Cash is launching into is one where everyone knows about the potential of blockchain money. As a result, it is reasonable to expect faster adoption rates and as a consequence of that we can afford a faster approach to the steady state where transaction fees dominate over block subsidies without risking a lopsided distribution of money. This line of thought motivates having a 3-year rather than 4-year halving period.

@aszepieniec
Copy link
Contributor Author

This branch has been extended (asz/negative-fees) and then merged into master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Sword-Smith Sword-Smith Awaiting requested review from Sword-Smith

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@aszepieniec @dan-da @Sword-Smith