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.

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

Add register-ownership command #43

Open
wants to merge 43 commits into
base: main
Choose a base branch
from
Open

Conversation

magecnion
Copy link
Contributor

magecnion and others added 30 commits March 4, 2025 13:02
Co-authored-by: magecnion <magecnion@gmail.com>
Co-authored-by: magecnion <magecnion@gmail.com>
Co-authored-by: magecnion <magecnion@gmail.com>
Co-authored-by: magecnion <magecnion@gmail.com>
Co-authored-by: magecnion <magecnion@gmail.com>
Co-authored-by: magecnion <magecnion@gmail.com>
Co-authored-by: magecnion <magecnion@gmail.com>
@magecnion magecnion marked this pull request as ready for review March 6, 2025 11:04
tsenovilla
tsenovilla previously approved these changes Mar 7, 2025
@magecnion magecnion changed the title Add register-collection command Add register-ownership command Mar 7, 2025
magecnion and others added 6 commits March 13, 2025 16:58
* Update log level configuration for Laos-BTC.

Update statefulset.yaml to use .Values.laosbtc.logLevel
Add logLever field in values-digitalocean.yaml
Add debug field in values-local.yaml
Correct logLever to info in values-prod-digitalocean.yaml
Correct logLever to info in values-prod-local.yaml

* Enhance BRC721 script validation and structure

Implement is_brc721_script function
Add tests for BRC721 script validation
Move BRC721_INIT_CODE to the main module
Update register_collection to use new checks
Refactor brc721_updater for new script logic

* fix debuf in chart

* fix clippy

* refactoring

* typo

* index utxo on brc721
tsenovilla
tsenovilla previously approved these changes Mar 14, 2025
@@ -63,6 +63,22 @@ impl Brc721CollectionId {
},
)
}

pub fn to_leb128(&self) -> Vec<u8> {
Copy link
Member

@asiniscalchi asiniscalchi Mar 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be missing something, but it seems that this implementation isn't leveraging LEB128's efficiency as intended. For instance, a CollectionId { 1, 1 } currently serializes to 5 bytes, while my understanding is that it should only take 2 bytes based on the LEB128 specification.

Could you clarify if there's a specific reason for this behavior? Perhaps I'm overlooking some design consideration.

The following implementation serializes to 2 bytes.

use std::io;
use leb128::write;

pub fn serialize<W: io::Write>(&self, mut writer: W) -> io::Result<()> {
    write::unsigned(&mut writer, self.block)?;
    write::unsigned(&mut writer, self.tx as u64)?;
    Ok(())
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're absolutely right about the inefficiency in the current implementation.
This packs both values into a single u128 before encoding. Even for small values like {1,1}, the packed value is positioned far in the number space due to the bit shifting, requiring more bytes.
I've updated the code. Now it encodes each value separately, allowing each to use the minimum number of bytes needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants