[5.0] Adapt to changes in bls12-381 lib and add tests #1882

yarkinwho · 2023-11-09T07:33:18Z

Removes host functions:

bls_g1_mul
bls_g2_mul
bls_g1_exp
bls_g2_exp

Adds host functions:

bls_g1_weighted_sum
bls_g2_weighted_sum
bls_fp_mul
bls_fp_exp

All bls host functions modified to accept and return affine non-montgomery little endian form.

Removes protocol feature: BLS_PRIMITIVES and adds protocol feature BLS_PRIMITIVES2.

Resolves #1701

libraries/chain/include/eosio/chain/webassembly/interface.hpp

serialization.

benchmark/bls.cpp

libraries/chain/include/eosio/chain/webassembly/interface.hpp

libraries/chain/webassembly/crypto.cpp

greg7mdp · 2023-11-16T13:29:04Z

in fp.cpp, it looks like we check isValid() only if the check flag is set, even though the comment says otherwise:

optional<fp> fp::fromBytesBE(const span<const uint8_t, 48> in, const bool check, const bool raw)
{
    // We decided to always validate the input here. But we reserve the flag.
    fp e = fp(scalar::fromBytesBE<6>(in));
    if(check && !e.isValid()) return {};
    if(raw) return e;
    else    return e.toMont();
}

optional<fp> fp::fromBytesLE(const span<const uint8_t, 48> in, const bool check, const bool raw)
{
    // We decided to always validate the input here. But we reserve the flag.
    fp e = fp(scalar::fromBytesLE<6>(in));
    if(check && !e.isValid()) return {};
    if(raw) return e;
    else    return e.toMont();
}

greg7mdp · 2023-11-16T13:36:46Z

I'm not quite understanding the logic of this function:

array<uint8_t, 48> fp::toBytesBE(const bool raw) const
{
    if(raw) return scalar::toBytesBE<6>(d);
    else    return scalar::toBytesBE<6>(fromMont().d);
}

In particular what does raw mean. Does it mean, as I understand, that *this is already in Montgomery form?

Is that is the case, when raw is false, and *this is not in Montgomery form, Why do we call fromMont()? Shouldn't it be toMont()?

greg7mdp · 2023-11-16T13:57:29Z

There are inconsistencies between the types used in the for various APIs.

Sometimes we use uint8_t (which translates to unsigned char, as in void g1::toAffineBytesBE(const span<uint8_t, 96> out, const bool raw) const.
Sometimes we use char, as in interface::bls_g1_add(span<const char> op1, span<const char> op2, span<char> result) const.

Can we use the same type throughout?

Also use std::array instead of std::vector when appropriate, as it converts implicitely to eosio::chain::span.

This would help making the code simpler and avoid unnecessary repetition of sizes, which can be error-prone.
For example, instead of:

void benchmark_bls_g1_add() {
   // prepare g1 operand in Jacobian LE format
   g1 p = random_g1();
   std::vector<char> buf(96);
   p.toAffineBytesLE(std::span<uint8_t, 96>((uint8_t*)buf.data(), 96), true);
   eosio::chain::span<const char> op1(buf.data(), buf.size());

   // prepare result operand
   std::vector<char> result_buf(96);
   eosio::chain::span<char> result(result_buf.data(), result_buf.size());

   // set up bls_g1_add to be benchmarked
   interface_in_benchmark interface;
   auto g1_add_func = [&]() {
      interface.interface->bls_g1_add(op1, op1, result);
   };

   benchmarking("bls_g1_add", g1_add_func);
}

we could have:

void benchmark_bls_g1_add() {
   // prepare g1 operand in Jacobian LE format
   g1 p = random_g1();
   std::array<unsigned char, 96> op1;
   p.toAffineBytesLE(op1, true);

   // prepare result operand
   std::array<char, 96> result;

   // set up bls_g1_add to be benchmarked
   interface_in_benchmark interface;
   auto g1_add_func = [&]() {
      interface.interface->bls_g1_add(op1, op1, result);
   };

   benchmarking("bls_g1_add", g1_add_func);
}

yarkinwho · 2023-11-16T14:15:46Z

I'm not quite understanding the logic of this function:
array<uint8_t, 48> fp::toBytesBE(const bool raw) const
{
    if(raw) return scalar::toBytesBE<6>(d);
    else    return scalar::toBytesBE<6>(fromMont().d);
}
In particular what does raw mean. Does it mean, as I understand, that *this is already in Montgomery form?

Is that is the case, when raw is false, and *this is not in Montgomery form, Why do we call fromMont()? Shouldn't it be toMont()?

raw here means whether the the output should be the "raw" form used for internal calculation, aka. Montgomery form.
*this is supposed to always be in Montgomery form. That's why we need extra caution when constructing fp.

.

yarkinwho · 2023-11-16T14:19:29Z

in fp.cpp, it looks like we check isValid() only if the check flag is set, even though the comment says otherwise:

optional<fp> fp::fromBytesBE(const span<const uint8_t, 48> in, const bool check, const bool raw)
{
    // We decided to always validate the input here. But we reserve the flag.
    fp e = fp(scalar::fromBytesBE<6>(in));
    if(check && !e.isValid()) return {};
    if(raw) return e;
    else    return e.toMont();
}

optional<fp> fp::fromBytesLE(const span<const uint8_t, 48> in, const bool check, const bool raw)
{
    // We decided to always validate the input here. But we reserve the flag.
    fp e = fp(scalar::fromBytesLE<6>(in));
    if(check && !e.isValid()) return {};
    if(raw) return e;
    else    return e.toMont();
}

Oh, that's the comment I forgot to delete...

yarkinwho · 2023-11-16T14:21:57Z

There are inconsistencies between the types used in the for various APIs.

Sometimes we use uint8_t (which translates to unsigned char, as in void g1::toAffineBytesBE(const span<uint8_t, 96> out, const bool raw) const.

Sometimes we use char, as in interface::bls_g1_add(span<const char> op1, span<const char> op2, span<char> result) const.

Can we use the same type throughout?

Also use std::array instead of std::vector when appropriate, as it converts implicitely to eosio::chain::span.

This would help making the code simpler and avoid unnecessary repetition of sizes, which can be error-prone. For example, instead of:
void benchmark_bls_g1_add() {
   // prepare g1 operand in Jacobian LE format
   g1 p = random_g1();
   std::vector<char> buf(96);
   p.toAffineBytesLE(std::span<uint8_t, 96>((uint8_t*)buf.data(), 96), true);
   eosio::chain::span<const char> op1(buf.data(), buf.size());

   // prepare result operand
   std::vector<char> result_buf(96);
   eosio::chain::span<char> result(result_buf.data(), result_buf.size());

   // set up bls_g1_add to be benchmarked
   interface_in_benchmark interface;
   auto g1_add_func = [&]() {
      interface.interface->bls_g1_add(op1, op1, result);
   };

   benchmarking("bls_g1_add", g1_add_func);
}
we could have:
void benchmark_bls_g1_add() {
   // prepare g1 operand in Jacobian LE format
   g1 p = random_g1();
   std::array<unsigned char, 96> op1;
   p.toAffineBytesLE(op1, true);

   // prepare result operand
   std::array<char, 96> result;

   // set up bls_g1_add to be benchmarked
   interface_in_benchmark interface;
   auto g1_add_func = [&]() {
      interface.interface->bls_g1_add(op1, op1, result);
   };

   benchmarking("bls_g1_add", g1_add_func);
}

good points. guess that's because that's code originally written by different people :)
Let me try if i can unify them

greg7mdp · 2023-11-16T14:24:44Z

I'm not quite understanding the logic of this function:

array<uint8_t, 48> fp::toBytesBE(const bool raw) const
{
    if(raw) return scalar::toBytesBE<6>(d);
    else    return scalar::toBytesBE<6>(fromMont().d);

raw here means whether the the output should be the "raw" form used for internal calculation, aka. Montgomery form. *this is supposed to always be in Montgomery form. That's why we need extra caution when constructing fp.

So when we call scalar::toBytesBE<6>(), would it not work if we used the Montgomery form as input?

…_benchmark

yarkinwho · 2023-11-16T14:52:06Z

I'm not quite understanding the logic of this function:
array<uint8_t, 48> fp::toBytesBE(const bool raw) const
{
    if(raw) return scalar::toBytesBE<6>(d);
    else    return scalar::toBytesBE<6>(fromMont().d);
raw here means whether the the output should be the "raw" form used for internal calculation, aka. Montgomery form. *this is supposed to always be in Montgomery form. That's why we need extra caution when constructing fp.

So when we call scalar::toBytesBE<6>(), would it not work if we used the Montgomery form as input?

scalar is defined as numbers that are not in GF(p) so there's no Montgomery form, it always views bytes as plain number.

And Montgomery form is pretty much just map the number to another value in the group, so no matter the fp is in Montgomery form or not, its bytes, viewed by scalar, are always valid number.

So:
if(raw) return scalar::toBytesBE<6>(d); <-we want to export the "raw" number, so treat it as scalar and export.
else return scalar::toBytesBE<6>(fromMont().d); <- we want to export the "not raw" number so it will need to be converted back "fromMont"

greg7mdp · 2023-11-16T15:03:56Z

A suggestion, do you think it might be better to define the sizes as members instead of having the hardcoded sizes everywhere. We could also define buffer types:

class g1
{

public:
    fp x;
    fp y;
    fp z;

    static constexpr size_t jacobian_sz   = 144;
    static constexpr size_t affine_sz     = 96;
    static constexpr size_t compressed_sz = 48;

    using jacobian_buf   = std::array<uint8_t, jacobian_sz>;
    using affine_buf     = std::array<uint8_t, affine_sz>;
    using compressed_buf = std::array<uint8_t, compressed_sz>;
    
    g1();
    explicit g1(const std::array<fp, 3>& e3);
    g1(const g1& e);
    static std::optional<g1> fromJacobianBytesBE(const std::span<const uint8_t, jacobian_sz> in, const bool check = false, const bool raw = false);
...

yarkinwho · 2023-11-16T15:22:21Z

A suggestion, do you think it might be better to define the sizes as members instead of having the hardcoded sizes everywhere. We could also define buffer types:

class g1
{

public:
    fp x;
    fp y;
    fp z;

    static constexpr size_t jacobian_sz   = 144;
    static constexpr size_t affine_sz     = 96;
    static constexpr size_t compressed_sz = 48;

    using jacobian_buf   = std::array<uint8_t, jacobian_sz>;
    using affine_buf     = std::array<uint8_t, affine_sz>;
    using compressed_buf = std::array<uint8_t, compressed_sz>;
    
    g1();
    explicit g1(const std::array<fp, 3>& e3);
    g1(const g1& e);
    static std::optional<g1> fromJacobianBytesBE(const std::span<const uint8_t, jacobian_sz> in, const bool check = false, const bool raw = false);
...

Not sure, usually it's not good to have magic numbers around, but in this case, maybe it's more clear to have those numbers in function declaration so that people don't need to click around to find the correct size.

greg7mdp · 2023-11-16T15:26:37Z

Not sure, usually it's not good to have magic numbers around, but in this case, maybe it's more clear to have those numbers in function declaration so that people don't need to click around to find the correct size.

Hum, I don't know, maybe @arhag can give his opinion.

I think I'd even define span types, so we'd have something like this:

class g1
{

public:
    fp x;
    fp y;
    fp z;

    static constexpr size_t jacobian_sz   = 144;
    static constexpr size_t affine_sz     = 96;
    static constexpr size_t compressed_sz = 48;

    using jacobian_buf   = std::array<uint8_t, jacobian_sz>;
    using affine_buf     = std::array<uint8_t, affine_sz>;
    using compressed_buf = std::array<uint8_t, compressed_sz>;

    using jacobian_in    = std::span<const uint8_t, jacobian_sz>;
    using jacobian_out   = std::span<uint8_t, jacobian_sz>;
    using affine_in      = std::span<const uint8_t, affine_sz>;
    using affine_out     = std::span<uint8_t, affine_sz>;
    using compressed_in  = std::span<const uint8_t, compressed_sz>;
    using compressed_out = std::span<uint8_t, compressed_sz>;
    
    
    g1();
    explicit g1(const std::array<fp, 3>& e3);
    g1(const g1& e);
    static std::optional<g1> fromJacobianBytesBE(const jacobian_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromJacobianBytesLE(const jacobian_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromAffineBytesBE(const affine_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromAffineBytesLE(const affine_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromCompressedBytesBE(const compressed_in in);
    void toJacobianBytesBE(const jacobian_out out, const bool raw = false) const;
    void toJacobianBytesLE(const jacobian_out out, const bool raw = false) const;
    void toAffineBytesBE(const affine_out out, const bool raw = false) const;
    void toAffineBytesLE(const affine_out out, const bool raw = false) const;
    void toCompressedBytesBE(const compressed_out out) const;
    jacobian_buf toJacobianBytesBE(const bool raw = false) const;
    jacobian_buf toJacobianBytesLE(const bool raw = false) const;
    affine_buf toAffineBytesBE(const bool raw = false) const;
    affine_buf toAffineBytesLE(const bool raw = false) const;
    compressed_buf toCompressedBytesBE() const;

In user code, I think this:

   g2::affine_buf buf;
   random_g2().toAffineBytesLE(buf, true);

is better than this:

   std::vector<char> buf(192);
   random_g2().toAffineBytesLE(std::span<uint8_t, 192>((uint8_t*)buf.data(), 192), true);

…chain::span

yarkinwho · 2023-11-16T16:18:29Z

Not sure, usually it's not good to have magic numbers around, but in this case, maybe it's more clear to have those numbers in function declaration so that people don't need to click around to find the correct size.

Hum, I don't know, maybe @arhag can give his opinion.

I think I'd even define span types, so we'd have something like this:

class g1
{

public:
    fp x;
    fp y;
    fp z;

    static constexpr size_t jacobian_sz   = 144;
    static constexpr size_t affine_sz     = 96;
    static constexpr size_t compressed_sz = 48;

    using jacobian_buf   = std::array<uint8_t, jacobian_sz>;
    using affine_buf     = std::array<uint8_t, affine_sz>;
    using compressed_buf = std::array<uint8_t, compressed_sz>;

    using jacobian_in    = std::span<const uint8_t, jacobian_sz>;
    using jacobian_out   = std::span<uint8_t, jacobian_sz>;
    using affine_in      = std::span<const uint8_t, affine_sz>;
    using affine_out     = std::span<uint8_t, affine_sz>;
    using compressed_in  = std::span<const uint8_t, compressed_sz>;
    using compressed_out = std::span<uint8_t, compressed_sz>;
    
    
    g1();
    explicit g1(const std::array<fp, 3>& e3);
    g1(const g1& e);
    static std::optional<g1> fromJacobianBytesBE(const jacobian_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromJacobianBytesLE(const jacobian_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromAffineBytesBE(const affine_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromAffineBytesLE(const affine_in in, const bool check = false, const bool raw = false);
    static std::optional<g1> fromCompressedBytesBE(const compressed_in in);
    void toJacobianBytesBE(const jacobian_out out, const bool raw = false) const;
    void toJacobianBytesLE(const jacobian_out out, const bool raw = false) const;
    void toAffineBytesBE(const affine_out out, const bool raw = false) const;
    void toAffineBytesLE(const affine_out out, const bool raw = false) const;
    void toCompressedBytesBE(const compressed_out out) const;
    jacobian_buf toJacobianBytesBE(const bool raw = false) const;
    jacobian_buf toJacobianBytesLE(const bool raw = false) const;
    affine_buf toAffineBytesBE(const bool raw = false) const;
    affine_buf toAffineBytesLE(const bool raw = false) const;
    compressed_buf toCompressedBytesBE() const;

In user code, I think this:

   g2::affine_buf buf;
   random_g2().toAffineBytesLE(buf, true);

is better than this:

   std::vector<char> buf(192);
   random_g2().toAffineBytesLE(std::span<uint8_t, 192>((uint8_t*)buf.data(), 192), true);

I guess if we are going to pick similar approaches, we will need some better design for hexToBytes and bytesToHex methods. With the current design, I think we will still need to put some hardcoded number to copy data to buf in some steps.

BLS: add benchmarking for Affine form host functions

heifner · 2023-11-21T14:16:42Z

libraries/chain/protocol_feature_manager.cpp

 Adds new cryptographic host functions
- Add, multiply, multi-exponentiation and pairing functions for the bls12-381 elliptic curve.
+- Add, weighted-sum, map, and pairing functions for the bls12-381 elliptic curve.


https://t.me/jungletestnet/87773

Test restarting a node that had the previous digest for BLS_PRIMITIVES. Consider renaming if it avoid the restart issue.

arhag

Also update bls12-381 library submodule to the commit https://github.com/AntelopeIO/bls12-381/commits/13888087ac9225b1f266fee8b149c4effe10fabb.

Otherwise, looks good to me.

libraries/chain/include/eosio/chain/webassembly/interface.hpp

greg7mdp · 2023-11-16T14:01:52Z

libraries/chain/include/eosio/chain/webassembly/interface.hpp

-          * @param[out] result - the result op1 + op2.
-          * @return -1 if there was an error 0 otherwise
+          * @param op1 - a span containing the affine coordingates of the first operand G1 point - 96 bytes little-endian.
+          * @param op2 - a span containing the affine coordingates of the second operand G1 point - 96 bytes little-endian.


Suggested change

* @param op2 - a span containing the affine coordingates of the second operand G1 point - 96 bytes little-endian.

* @param op2 - a span containing the affine coordinates of the second operand G1 point - 96 bytes little-endian.

Fixed in #1938

greg7mdp · 2023-11-16T14:02:07Z

libraries/chain/include/eosio/chain/webassembly/interface.hpp

-          * @param[out] result - the result op1 + op2.
-          * @return -1 if there was an error 0 otherwise
+          * @param op1 - a span containing the affine coordingates of the first operand G2 point - 192 bytes little-endian.
+          * @param op2 - a span containing the affine coordingates of the second operand G2 point - 192 bytes little-endian.


Suggested change

* @param op2 - a span containing the affine coordingates of the second operand G2 point - 192 bytes little-endian.

* @param op2 - a span containing the affine coordinates of the second operand G2 point - 192 bytes little-endian.

Fixed in #1938

yarkinwho added 2 commits November 9, 2023 11:14

Make code compile with refactored bls12-381.

71a9319

Refactor some interfaces, compiling, not tested yet.

eea0ea3

yarkinwho marked this pull request as draft November 9, 2023 07:33

Merge branch 'release/5.0' into yarkin/update_bls

3d188c7

greg7mdp reviewed Nov 9, 2023

View reviewed changes

libraries/chain/include/eosio/chain/webassembly/interface.hpp Outdated Show resolved Hide resolved

yarkinwho added 5 commits November 10, 2023 23:30

Refactor bls_gx calls.

fa59891

Add bls_fp_mod and bls_fp_exp

d8dc360

Update unit tests.

35f375c

Merge branch 'release/5.0' into yarkin/update_bls

77f2be4

Fix comile.

9c42d42

arhag linked an issue Nov 13, 2023 that may be closed by this pull request

Modify BLS host functions to fix failing tests on ARM builds #1701

Closed

yarkinwho added 3 commits November 14, 2023 15:55

Update to use affine form instead of jacobian form for data

49d17e3

serialization.

Merge branch 'release/5.0' into yarkin/update_bls

fa5f81e

Fix benchmark

4e40590

arhag self-requested a review November 14, 2023 17:56

yarkinwho marked this pull request as ready for review November 15, 2023 01:40

linh2931 and others added 3 commits November 14, 2023 20:43

add benchmarking for Montgomery form host functions

2a85796

Add tests for fp_mod, fp_exp, fp_mul

9d35e5a

Add more test case and update submodule (only contains test updates).

4255d62

greg7mdp reviewed Nov 15, 2023

View reviewed changes

linh2931 and others added 5 commits November 15, 2023 12:12

fix weighted sum montgomery form flag

8819030

add const& to std::string parameters in all _impl methods

f280d5e

Remove _mont functions.

dfb05c5

Update comments.

e1f67e9

Delete unused benchmark.

d9e59b8

linh2931 added 2 commits November 16, 2023 09:28

Merge remote-tracking branch 'origin/yarkin/update_bls' into more_bls…

36eafc7

…_benchmark

resolve merge conflicts

65b54ab

remove _mont* functions

c39e930

use std::array instead of std::vector to simply conversion to eosio::…

6a9a8b1

…chain::span

linh2931 and others added 2 commits November 16, 2023 19:09

Merge pull request #1904 from AntelopeIO/more_bls_benchmark

cc9bba8

BLS: add benchmarking for Affine form host functions

Update feature signature.

cb4ceaa

heifner reviewed Nov 21, 2023

View reviewed changes

yarkinwho added 2 commits November 30, 2023 01:51

Update feature manager, fix deep-mind.log accordinglly.

1269951

Update to latest bls lib.

11640bf

arhag mentioned this pull request Nov 29, 2023

Update BLS wrappers to support new/changes BLS host functions AntelopeIO/cdt#251

Closed

arhag reviewed Nov 29, 2023

View reviewed changes

libraries/chain/include/eosio/chain/webassembly/interface.hpp Outdated Show resolved Hide resolved

libraries/chain/include/eosio/chain/webassembly/interface.hpp Outdated Show resolved Hide resolved

Merge branch 'release/5.0' into yarkin/update_bls

3c5c566

arhag mentioned this pull request Nov 29, 2023

Benchmark for leap BLS Host Functions #1854

Closed

greg7mdp added 2 commits November 29, 2023 18:53

remove (multi-exponentiation) from comments.

87738aa

Update bls12 submodule to tip of main branch.

804e415

arhag approved these changes Nov 30, 2023

View reviewed changes

heifner added the consensus label Nov 30, 2023

heifner approved these changes Nov 30, 2023

View reviewed changes

greg7mdp approved these changes Nov 30, 2023

View reviewed changes

heifner merged commit c584cdb into release/5.0 Nov 30, 2023
29 checks passed

heifner deleted the yarkin/update_bls branch November 30, 2023 16:03

This was referenced Nov 30, 2023

[5.0 -> main] Adapt to changes in bls12-381 lib and add tests #1939

Merged

Add new BLS host function support and switch to affine AntelopeIO/cdt#252

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[5.0] Adapt to changes in bls12-381 lib and add tests #1882

[5.0] Adapt to changes in bls12-381 lib and add tests #1882

yarkinwho commented Nov 9, 2023 •

edited by heifner

Loading

greg7mdp commented Nov 16, 2023 •

edited

Loading

greg7mdp commented Nov 16, 2023

greg7mdp commented Nov 16, 2023 •

edited

Loading

yarkinwho commented Nov 16, 2023

yarkinwho commented Nov 16, 2023

yarkinwho commented Nov 16, 2023

greg7mdp commented Nov 16, 2023

yarkinwho commented Nov 16, 2023 •

edited

Loading

greg7mdp commented Nov 16, 2023 •

edited

Loading

yarkinwho commented Nov 16, 2023

greg7mdp commented Nov 16, 2023 •

edited

Loading

yarkinwho commented Nov 16, 2023

heifner Nov 21, 2023

yarkinwho Nov 29, 2023

arhag left a comment

greg7mdp Nov 16, 2023

heifner Nov 30, 2023

greg7mdp Nov 16, 2023

heifner Nov 30, 2023

	* @param op2 - a span containing the affine coordingates of the second operand G1 point - 96 bytes little-endian.
	* @param op2 - a span containing the affine coordinates of the second operand G1 point - 96 bytes little-endian.

[5.0] Adapt to changes in bls12-381 lib and add tests #1882

[5.0] Adapt to changes in bls12-381 lib and add tests #1882

Conversation

yarkinwho commented Nov 9, 2023 • edited by heifner Loading

greg7mdp commented Nov 16, 2023 • edited Loading

greg7mdp commented Nov 16, 2023

greg7mdp commented Nov 16, 2023 • edited Loading

yarkinwho commented Nov 16, 2023

yarkinwho commented Nov 16, 2023

yarkinwho commented Nov 16, 2023

greg7mdp commented Nov 16, 2023

yarkinwho commented Nov 16, 2023 • edited Loading

greg7mdp commented Nov 16, 2023 • edited Loading

yarkinwho commented Nov 16, 2023

greg7mdp commented Nov 16, 2023 • edited Loading

yarkinwho commented Nov 16, 2023

heifner Nov 21, 2023

Choose a reason for hiding this comment

yarkinwho Nov 29, 2023

Choose a reason for hiding this comment

arhag left a comment

Choose a reason for hiding this comment

greg7mdp Nov 16, 2023

Choose a reason for hiding this comment

heifner Nov 30, 2023

Choose a reason for hiding this comment

greg7mdp Nov 16, 2023

Choose a reason for hiding this comment

heifner Nov 30, 2023

Choose a reason for hiding this comment

yarkinwho commented Nov 9, 2023 •

edited by heifner

Loading

greg7mdp commented Nov 16, 2023 •

edited

Loading

greg7mdp commented Nov 16, 2023 •

edited

Loading

yarkinwho commented Nov 16, 2023 •

edited

Loading

greg7mdp commented Nov 16, 2023 •

edited

Loading

greg7mdp commented Nov 16, 2023 •

edited

Loading