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_lengthis used for fixed lengths of fields, whether string, bytes, lists or other types.bsor_typecan be provided for fields withfloatannotation, and may be eitherFieldType.FLOATorFieldType.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_typevalues are not actually tested in the test data, and it is possible that decoding ofFieldType.DOUBLEvalues does not work. Encoding does not check this metadata field yet.bsor_lengthlikely 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)
| 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)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| 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.