Skip to main content

The electrumsv-bsor package

Tokenized have developed a serialisation format that encodes in Bitcoin script object representation, or BSOR for short. This package uses the test files from Tokenized's project in order to verify that it can both convert a binary representation to a decoded object, and to convert that decoded object back to the same binary representation.

This package loosely follows the standard dump/dumps/load/loads API that standard library modules like json and pickle provide, although there are some extra requirements for this package due to the need to the way data structures are defined.

The package API

  • electrumsv_bsor.dump(object, stream, structure_metadata)
  • data: bytes = electrumsv_bsor.dump(object, structure_metadata)
  • object = electrumsv_bsor.load(stream, definition, class_reference)
  • object = electrumsv_bsor.loads(data, definition, class_reference)

For now, the nuances of how to use this are best observed in the test files.

Structure markup in Python

The structure_metadata is how the encoder and decoder works out how to encode or decode different types of objects. For non-structures like PublicKey they generally already provide encoding and decoding methods directly to and from the desired encoding data type. For structures like XTestSubStruct these must meet the definition requirements and considered a special serialisation OBJECT data type.

    structure_metadata: dict[str, tuple[Any, Any, FieldType]] = {
        "PublicKey": (PublicKey.from_bytes, lambda instance: instance.to_bytes, FieldType.BYTES),
        "XTestSubStruct": (XTestSubStruct, None, FieldType.OBJECT),
    }

Structures define their own BSOR encoding format and this is done using the standard library dataclasses module.

@dataclass
class XTestStructSimple:
    IntField: int = field(metadata={ "bsor_id": 1 })
    StringField: str = field(metadata={ "bsor_id": 2 })
    IntZeroField: int = field(metadata={ "bsor_id": 3 })
    SubStruct: XTestSubStruct = field(metadata={ "bsor_id": 4     })
    BinaryField: bytes = field(metadata={ "bsor_id": 5 })
    IntPointerField1: int | None = field(metadata={ "bsor_id": 6 })
    IntPointerField2: int | None = field(metadata={ "bsor_id": 7 })
    PublicKeyField: PublicKey = field(metadata={ "bsor_id": 8  })
    ArrayStringPtrField: list[str|None] = field(metadata={ "bsor_id": 25 })

Each defined field in the structure must have a field identifier (bsor_id in the data classes metadata) that matches the same value in any other definitions of the same structure in other projects. The type of the field is drawn from the Python typing annotations, for example, in the case of the IntField field it is int.

Other supported metadata entries are:

  • bsor_length is used for fixed lengths of fields, whether string, bytes, lists or other types.
  • bsor_type can be provided for fields with float annotation, and may be either FieldType.FLOAT or FieldType.DOUBLE.

Go pointer equivalence is considered to represented by Optional Python values and are indicated with use of the | None Python type annotation.

Warning

Any use of this package is best preceded with test data that exercises the structures to be used for all variations.

Implementation notes

There are various things that need testing and further work and are not hit by the test files borrowed from the Tokenized project:

  • bsor_type values are not actually tested in the test data, and it is possible that decoding of FieldType.DOUBLE values does not work. Encoding does not check this metadata field yet.
  • bsor_length likely has a lot of edge cases that are not covered and may not even be representable in the current structures (lists of fixed length strings for instance).

The Python dataclasses standard module keeps type names in string format, which means there is no way of matching the type names to the classes being referred to. This is what the structure_metadata dictionary provides coverage of, both structures and encoded data types can be declared by the given dataclasses type name in this dictionary.

Metadata

Release files for electrumsv-bsor 0.9

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for electrumsv-bsor 0.9
File Size Uploaded Provenance Actions
electrumsv-bsor-0.9.tar.gz 8.3 kB Without provenance Details for electrumsv-bsor-0.9.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for electrumsv-bsor 0.9
File Interpreter ABI Platform Actions
electrumsv_bsor-0.9-py3-none-any.whl Python 3 none any Details for electrumsv_bsor-0.9-py3-none-any.whl

Total release size: 17.0 kB

Release files / electrumsv-bsor-0.9.tar.gz

Download URL electrumsv-bsor-0.9.tar.gz
Size 8.3 kB
Tags Source
SHA-256 checksum
How to use checksums
a18a6ebbd2b3d1bcb8346924d6b4c66d157a0ffe90aaf5e4f97a52266987ce14
BLAKE2b-256 checksum
How to use checksums
902e251b67ab34724376866a559a932ad6f788a0787008cec910bfc25ca45896
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/3.8.0 pkginfo/1.8.2 readme-renderer/32.0 requests/2.27.1 requests-toolbelt/0.9.1 urllib3/1.26.9 tqdm/4.62.3 importlib-metadata/4.11.1 keyring/23.5.0 rfc3986/2.0.0 colorama/0.4.5 CPython/3.10.2

Release files / electrumsv_bsor-0.9-py3-none-any.whl

Download URL electrumsv_bsor-0.9-py3-none-any.whl
Size 8.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
061abcb622195a22065802439cdcfbba9b5cd822a65647f5c979b0e76704da55
BLAKE2b-256 checksum
How to use checksums
c9b19c3eaee6421b6b1c5ce46134ca50a658c7f07083e40ce1e1fbe0547e99be
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/3.8.0 pkginfo/1.8.2 readme-renderer/32.0 requests/2.27.1 requests-toolbelt/0.9.1 urllib3/1.26.9 tqdm/4.62.3 importlib-metadata/4.11.1 keyring/23.5.0 rfc3986/2.0.0 colorama/0.4.5 CPython/3.10.2

Security for electrumsv-bsor 0.9

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

0.9 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page