Allow ed25519 node and validator keys #2647

wilsonianb · 2018-08-06T18:15:19Z

This change enables rippled to handle peer messages, proposals and validations signed by ed25519 keys.
You can configure rippled to use an ed25519 validator key by including a validator token with a manifest whose signing public key is that type.
There is not currently a way to configure rippled to use an ed25519 node public key.

RIPD-1424

ripplelabs-jenkins · 2018-08-06T19:21:31Z

Jenkins Build Summary

Built from this commit

Built at 20190615 - 08:57:46

Test Results

Build Type	Log	Result	Status

codecov-io · 2018-08-06T19:21:57Z

Codecov Report

Merging #2647 into develop will increase coverage by 0.02%.
The diff coverage is 75%.

@@             Coverage Diff             @@
##           develop    #2647      +/-   ##
===========================================
+ Coverage    70.02%   70.04%   +0.02%     
===========================================
  Files          704      704              
  Lines        55262    55250      -12     
===========================================
+ Hits         38696    38699       +3     
+ Misses       16566    16551      -15

Impacted Files	Coverage Δ
src/ripple/protocol/SecretKey.h	`100% <ø> (ø)`	⬆️
src/ripple/consensus/DisputedTx.h	`97.26% <ø> (ø)`	⬆️
src/ripple/app/consensus/RCLCxPeerPos.h	`0% <ø> (ø)`	⬆️
src/ripple/protocol/impl/SecretKey.cpp	`84.68% <ø> (+0.94%)`	⬆️
src/ripple/protocol/STObject.h	`92.14% <ø> (ø)`	⬆️
src/ripple/consensus/ConsensusProposal.h	`100% <ø> (ø)`	⬆️
src/ripple/consensus/LedgerTrie.h	`91.34% <ø> (ø)`	⬆️
src/ripple/protocol/PublicKey.h	`100% <ø> (ø)`	⬆️
src/ripple/protocol/STTx.h	`66.66% <ø> (ø)`	⬆️
src/ripple/protocol/impl/PublicKey.cpp	`90% <ø> (+1.53%)`	⬆️
... and 17 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7b03677...56a9a17. Read the comment docs.

scottschurr

Looks pretty good. I haven't finished my review yet, but I want to pass these thoughts along to you now for your consideration.

scottschurr · 2018-08-09T20:36:41Z

src/ripple/app/consensus/RCLConsensus.cpp

+    s.add32(std::uint32_t(proposal.proposeSeq()));
+    s.add32(proposal.closeTime().time_since_epoch().count());
+    s.add256(proposal.prevLedger());
+    s.add256(proposal.position());


Not excited about the duplication of the serialization code here and in RCLCxPeerPos.cpp. Consider refactoring that code into ConsensusProposal.h. A cherry-pickable example is here: scottschurr@0c2f17f. I was initially worried that would lead to a levelization violation in ConsensusProposal.h, but it was already bringing in stuff from ripple/protocol, so it looks like it will be okay.

ca2e49a incorporates the changes from your commit, except I opted to replace RCLCxPeerPos::signingData() with a non-member function similar to the existing proposalUniqueId instead of including more ripple/ in the consensus code.

scottschurr · 2018-08-09T20:42:04Z

src/ripple/app/consensus/RCLCxPeerPos.h


-    //! Verify the signing hash of the proposal
+    //! Verify the signing data of the proposal
    bool
    checkSign() const;



I noticed that hash_append(), further down in this file, doesn't seem to be used any more. I don't know whether that's been true for a while or if it's due to changes in this branch. You might take a look around for other unused code. I wonder if there are some calls to getSigningHash() that are no longer used? Thanks.

scottschurr · 2018-08-09T20:49:46Z

src/ripple/app/misc/impl/ValidatorKeys.cpp

            auto const m = Manifest::make_Manifest(
                boost::beast::detail::base64_decode(token->manifest));
+            if (! m)
+            {
+                configInvalid_ = true;


The stuff inside these braces is not being hit by your unit tests. Consider adding a unit test for a config with a corrupt validator token.

scottschurr · 2018-08-09T20:52:56Z

src/ripple/app/consensus/RCLCxPeerPos.cpp

 }

 bool
 RCLCxPeerPos::checkSign() const
 {
-    return verifyDigest(
-        publicKey(), signingHash(), signature(), false);
+    return verify(


This method and the signingData() method above are not being hit by your unit tests. Would it be possible to exercise this code with a unit test? Thanks.

You might take a peek in your codecov.io results (https://codecov.io/gh/ripple/rippled/compare/09050a860be745c88a54fbcbce1e317c72f2f51e...6c7a1270996b0dcae68bf2b8ae233c9f987c5917/diff) for additional unit testing ideas.

scottschurr · 2018-08-09T21:12:44Z

src/test/app/ValidatorKeys_test.cpp

@@ -70,31 +70,29 @@ class ValidatorKeys_test : public beast::unit_test::suite
        "RFE9PSIsInZhbGlkYXRpb25fc2VjcmV0X2tleSI6IjkyRDhCNDBGMzYwMTc5MTkwMU\n",
        "MzQTUzMzI3NzBDMkUwMTA4MDI0NTZFOEM2QkI0NEQ0N0FFREQ0NzJGMDQ2RkYifQ==\n"};

+    const std::vector<std::string> tokenBlobEd25519 = {


Consider renaming the other tokenManifests and tokenBlobs in this test to include sepc256k in their names. That might make future maintenance easier.

scottschurr · 2018-08-09T21:19:23Z

src/test/protocol/STValidation_test.cpp

        {
            SerialIter sit{payload2, sizeof(payload2)};
            auto stx = std::make_shared<ripple::STValidation>(sit,
                [](PublicKey const& pk) {
                    return calcNodeID(pk);
                }, false);
-            fail("An exception should have been thrown");


Even though payload2 is now valid, it feels like it would be nice to have a different payload that causes an exception to be thrown.

@scottschurr payload3 still causes the exception

It might be worth adding another payload with a public key and a bad signature...

// Invalid signature constexpr unsigned char payload4[] = { 0x73, 0x21, 0xed, 0xff, 0x03, 0x1c, 0xbe, 0x65, 0x22, 0x61, 0x9c, 0x5e, 0x13, 0x12, 0x00, 0x3b, 0x43, 0x00, 0x00, 0x00, 0xf7, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x13, 0x13, 0x13, 0xaa, 0xaa, 0xaa}; try { SerialIter sit{payload4, sizeof(payload4)}; std::make_shared<ripple::STValidation>( sit, [](PublicKey const& pk) { return calcNodeID(pk); }, true); fail("An exception should have been thrown"); } catch (std::exception const& e) { BEAST_EXPECT( strcmp(e.what(), "Invalid signature in validation") == 0); }

miguelportilla · 2018-08-10T15:06:36Z

src/test/protocol/STValidation_test.cpp

+            0x75, 0x73, 0x74, 0x53, 0x65, 0x74, 0x65, 0x61, 0x74, 0x65, 0x88, 0x00, 0xe6, 0x88, 0x00, 0xe6,
+            0x73, 0x00, 0x72, 0x00, 0x8a, 0x00, 0x88, 0x00, 0xe6
+        };
+


Consider condensing into something like

std::vector<std::vector<unsigned char>> const payloads { // specifies a secp256k1 public key {0x72, 0x00, 0x73, 0x21, 0x03, 0x76, 0x08, 0x7D, 0x78, 0x33, 0x5F, 0xE2, 0x08, 0xEE, 0xE1, 0x5D, 0x30, 0x96, 0x50, 0xFA, 0xAE, 0x60, 0xF4, 0xC5, 0xB7, 0xF3, 0x62, 0xAF, 0x97, 0x43, 0xF1, 0x72, 0x01, 0x9C, 0xBB, 0x20, 0xC8, 0x76, 0x31, 0x30, 0x37, 0x5f, 0x5f, 0x63, 0x6c, 0x61, 0x73, 0x73, 0x5f, 0x74, 0x79, 0x70, 0x65, 0x5f, 0x69, 0x6e, 0x66, 0x6f, 0x45, 0x00, 0xe6, 0x88, 0x54, 0x72, 0x75, 0x73, 0x74, 0x53, 0x65, 0x74, 0x65, 0x61, 0x74, 0x65, 0x88, 0x00, 0xe6, 0x88, 0x00, 0xe6, 0x73, 0x00, 0x72, 0x00, 0x8a, 0x00, 0x88, 0x00, 0xe6}, // specifies an Ed25519 public key {0x72, 0x00, 0x73, 0x21, 0xed, 0x78, 0x00, 0xe6, 0x73, 0x00, 0x72, 0x00, 0x3c, 0x00, 0x00, 0x00, 0x88, 0x00, 0xe6, 0x73, 0x38, 0x00, 0x00, 0x8a, 0x00, 0x88, 0x4e, 0x31, 0x30, 0x5f, 0x5f, 0x63, 0x78, 0x78, 0x61, 0x62, 0x69, 0x76, 0x31, 0x30, 0x37, 0x5f, 0x5f, 0x63, 0x6c, 0x61, 0x73, 0x73, 0x5f, 0x74, 0x79, 0x70, 0x65, 0x5f, 0x69, 0x6e, 0x66, 0x6f, 0x45, 0x00, 0xe6, 0x88, 0x54, 0x72, 0x75, 0x73, 0x74, 0x53, 0x65, 0x74, 0x65, 0x61, 0x74, 0x65, 0x88, 0x00, 0xe6, 0x88, 0x00, 0xe6, 0x73, 0x00, 0x72, 0x00, 0x8a, 0x00, 0x88, 0x00, 0xe6}, // specifies an Ed25519 public key {0x73, 0x21, 0xed, 0xff, 0x03, 0x1c, 0xbe, 0x65, 0x22, 0x61, 0x9c, 0x5e, 0x13, 0x12, 0x00, 0x3b, 0x43, 0x00, 0x00, 0x00, 0xf7, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x3f, 0x13, 0x13, 0x13, 0x3a, 0x27, 0xff}, // Has no public key at all {0x72, 0x00, 0x76, 0x31, 0x30, 0x37, 0x5f, 0x5f, 0x63, 0x6c, 0x61, 0x73, 0x73, 0x5f, 0x74, 0x79, 0x70, 0x65, 0x5f, 0x69, 0x6e, 0x66, 0x6f, 0x45, 0x00, 0xe6, 0x88, 0x54, 0x72, 0x75, 0x73, 0x74, 0x53, 0x65, 0x74, 0x65, 0x61, 0x74, 0x65, 0x88, 0x00, 0xe6, 0x88, 0x00, 0xe6, 0x73, 0x00, 0x72, 0x00, 0x8a, 0x00, 0x88, 0x00, 0xe6} }; try { for (auto const& payload : payloads) { SerialIter sit{payload.data(), payload.size()}; std::make_shared<ripple::STValidation>( sit, [](PublicKey const& pk) {return calcNodeID(pk);}, false); } fail("An exception should have been thrown"); } catch (std::exception const& e) { BEAST_EXPECT( strcmp(e.what(), "Invalid public key in validation") == 0); }

miguelportilla · 2018-08-10T15:50:30Z

src/test/protocol/STValidation_test.cpp

+            KeyType::ed25519
+        }};
+
+        for (auto const& keyType : keyTypes)


Consider eliminating keyTypes and using for (auto const &keyType : {KeyType::secp256k1, KeyType::ed25519})

miguelportilla · 2018-08-10T18:49:25Z

src/test/app/ValidatorKeys_test.cpp

+            BEAST_EXPECT(k.manifest == tokenManifestEd25519);
+            BEAST_EXPECT(!k.configInvalid());
+        }
+


Consider condensing into...

auto validateToken = [&]( KeyType keyType, std::string tknManifest, std::vector<std::string> tknBlob) { auto const m {Manifest::make_Manifest( boost::beast::detail::base64_decode(tknManifest))}; BEAST_EXPECT(m); Config c; c.section(SECTION_VALIDATOR_TOKEN).append(tknBlob); ValidatorKeys k{c, j}; auto const tknPublicKey{derivePublicKey(keyType, tokenSecretKey)}; BEAST_EXPECT(k.publicKey == tknPublicKey); BEAST_EXPECT(k.secretKey == tokenSecretKey); auto const tknNodeID{calcNodeID(m->masterKey)}; BEAST_EXPECT(k.nodeID == tknNodeID); BEAST_EXPECT(k.manifest == tknManifest); BEAST_EXPECT(!k.configInvalid()); }; // validator token validateToken(KeyType::secp256k1, tokenManifest, tokenBlob); // validator token with ed25519 key validateToken(KeyType::ed25519, tokenManifestEd25519, tokenBlobEd25519);

Another option is to place the validations in a container of tuples (key type, manifest, blob) and use a range based loop.
eg.

std::vector<std::tuple<KeyType, std::string, std::vector<std::string>>> const valData { { KeyType::secp256k1, // token manifest "JAAAAAFxIe1FtwmimvGtH2iCcMJqC9gVFKilGfw1/vCxHXXLplc2GnMhAkE1agqXxBwD" "wDbID6OMSYuM0FDAlpAgNk8SKFn7MO2fdkcwRQIhAOngu9sAKqXYouJ+l2V0W+sAOkVB" "+ZRS6PShlJAfUsXfAiBsVJGesaadOJc/aAZokS1vymGmVrlHPKWX3Yywu6in8HASQKPu" "gBD67kMaRFGvmpATHlGKJdvDFlWPYy5AqDedFv5TJa2w0i21eq3MYywLVJZnFOr7C0kw" "2AiTzSCjIzditQ8=", // token blob {" " "eyJ2YWxpZGF0aW9uX3NlY3JldF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3ND" "diNT\n", " \tQzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYTlkYWY2Iiwib" "WFuaWZl " " \n", "\tc3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncx" "L3ZDeE" "\n", "\t " "hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4" "U0tG\t " "\t\n", "bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUz" "ZQU2\n", "hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZ" "eXd1\n", "NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZW" "RGdj\n", "VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0i" "fQ==\n"} } }; ... for (auto const& v : valData) { auto const m {Manifest::make_Manifest( boost::beast::detail::base64_decode(std::get<1>(v)))}; BEAST_EXPECT(m); Config c; c.section(SECTION_VALIDATOR_TOKEN).append(std::get<2>(v)); ValidatorKeys k{c, j}; auto const tknPublicKey{ derivePublicKey(std::get<0>(v), tokenSecretKey)}; BEAST_EXPECT(k.publicKey == tknPublicKey); BEAST_EXPECT(k.secretKey == tokenSecretKey); auto const tknNodeID{calcNodeID(m->masterKey)}; BEAST_EXPECT(k.nodeID == tknNodeID); BEAST_EXPECT(k.manifest == std::get<1>(v)); BEAST_EXPECT(!k.configInvalid()); };

Consider condensing all of the config checks into somehting like ...

auto configCheck = [&](std::vector< std::pair<std::string, std::vector<std::string>>> sections) { Config c; for (auto const& s : sections) c.section(s.first).append(s.second); ValidatorKeys k{c, j}; BEAST_EXPECT(k.configInvalid()); BEAST_EXPECT(k.publicKey.size() == 0); BEAST_EXPECT(k.manifest.empty()); }; // invalid validator token configCheck({{SECTION_VALIDATOR_TOKEN, {"badtoken"}}}); // Cannot specify both configCheck({ {SECTION_VALIDATION_SEED, {seed}}, {SECTION_VALIDATOR_TOKEN, tokenBlob}}); // Token manifest and private key must match configCheck({{SECTION_VALIDATOR_TOKEN, invalidTokenBlob}});

scottschurr · 2018-08-17T19:01:32Z

The most recent commits are not building for me in Nounity/Debug/Clang/MacOS. Adding #include <iomanip> to LedgerTrie.h fixed the problem.

scottschurr · 2018-08-17T19:33:38Z

src/ripple/app/consensus/RCLCxPeerPos.cpp

 bool
 RCLCxPeerPos::checkSign() const
 {
-    return verifyDigest(
-        publicKey(), signingHash(), signature(), false);
+    return verify(


It looks like, as a result of this change, the verifyDigest() free function no longer needs to be public. It can be an implementation detail of the PublicKey.cpp file. So I suggest removing the declaration of verifyDigest() from PublicKey.h and make the implementation of verifyDigest() in PublicKey.cpp static.

You'll need to fix up SecretKey_test.cpp if you choose to make this change.

scottschurr · 2018-08-17T19:49:10Z

src/ripple/app/consensus/RCLConsensus.cpp

-        proposal.prevLedger(),
-        proposal.position());
-
-    auto sig = signDigest(valPublic_, valSecret_, signingHash);


As a consequence of this change the two SignDigest() free functions in the code base are no longer used. Their declarations can be removed from SecretKey.h and the implementation can be removed from SecretKey.cpp.

If you choose to make this change you'll need to fix up SecretKey_test.cpp.

wilsonianb · 2018-08-24T00:44:21Z

Rebased to resolve conflicts with rc3

nbougalis

~~scratched~~

Looked at the wrong version of the code. Oops!

sublimator · 2018-08-25T23:08:31Z

“VETO” caught my eye @nbougalis I can’t quite make sense of your comment though. It looks like the hashing is moved to ‘sign()’ function where it can be optionally done? Ed25519 manages message hashing itself. https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp#L141-L148

sublimator · 2018-08-25T23:19:29Z

Aaaaah, I saw the email notification, oops!

scottschurr

A few thoughts on unit tests.

scottschurr · 2018-08-24T18:04:48Z

src/test/protocol/STValidation_test.cpp

        {
-            BEAST_EXPECT(strcmp(e.what(), "Invalid public key in validation") == 0);
+            // Invalid signature


This test exercises an invalid signature and hits this check: https://github.com/ripple/rippled/blob/56a9a170c29f9ec593e9f34b81c80d6a86ddd5cc/src/ripple/protocol/STValidation.h#L87

Would it be possible to make a similar test with a bad public key? Then you could hit this check, which is not currently exercised: https://github.com/ripple/rippled/blob/56a9a170c29f9ec593e9f34b81c80d6a86ddd5cc/src/ripple/protocol/STValidation.h#L80

I think that's happening in the test above
https://github.com/ripple/rippled/pull/2647/files/56a9a170c29f9ec593e9f34b81c80d6a86ddd5cc#diff-78fe179d4e58a29ba79c1d7a7b6a033fR107

Interesting. Wonder why the tests are not hitting here then: https://github.com/ripple/rippled/blob/56a9a170c29f9ec593e9f34b81c80d6a86ddd5cc/src/ripple/protocol/STValidation.h#L80. But we can't kit 100% coverage anyway, so it's probably not worth pushing hard on.

scottschurr · 2018-08-24T20:55:44Z

src/ripple/app/consensus/RCLCxPeerPos.cpp

-        proposal().prevLedger(),
-        proposal().position());
-}
-
 bool
 RCLCxPeerPos::checkSign() const


I noticed that RCLCxPeerPos::checkSign() doesn't appear to be exercised by the unit tests. Seems like it should be? But I'll admit that may be outside what you think is appropriate to include in this pull request. Your call.

scottschurr · 2018-08-27T20:31:33Z

src/test/app/ValidatorKeys_test.cpp

+                "NJtYpVLHRwGcBJAC5ijq2BUDGbuLoDfqfdBQZl0DPu83pIs49lQsG+29yvl"
+                "flAp8BV7wPOG+HX2Azwh3wqsmthuDeLCM3nVKXNfCw==";
+
+            testValidatorToken(KeyType::ed25519, tokenManifest, tokenBlob);


I like this test with a valid ed25519 key. I'm looking for a similar test in this file that uses an secp256k1 key but didn't spot one. If there isn't one it seems like that would be a good thing to add.

There's one with secp256k1 here
https://github.com/ripple/rippled/pull/2647/files/56a9a170c29f9ec593e9f34b81c80d6a86ddd5cc#diff-dd5c6143d81cd734271df4c5fc90e9ebR178

Thanks. Sorry I missed that one.

scottschurr

Good tests. As far as I can tell this looks good. 👍

scottschurr · 2018-08-27T20:58:07Z

src/test/app/ValidatorKeys_test.cpp

+                "NJtYpVLHRwGcBJAC5ijq2BUDGbuLoDfqfdBQZl0DPu83pIs49lQsG+29yvl"
+                "flAp8BV7wPOG+HX2Azwh3wqsmthuDeLCM3nVKXNfCw==";
+
+            testValidatorToken(KeyType::ed25519, tokenManifest, tokenBlob);


Thanks. Sorry I missed that one.

scottschurr · 2018-08-27T20:59:50Z

src/test/protocol/STValidation_test.cpp

        {
-            BEAST_EXPECT(strcmp(e.what(), "Invalid public key in validation") == 0);
+            // Invalid signature


Interesting. Wonder why the tests are not hitting here then: https://github.com/ripple/rippled/blob/56a9a170c29f9ec593e9f34b81c80d6a86ddd5cc/src/ripple/protocol/STValidation.h#L80. But we can't kit 100% coverage anyway, so it's probably not worth pushing hard on.

RIPD-1424

a la proposalUniqueId

nbougalis

Conditional approval.

I like this commit and would be happy to allow Ed25519 keys for validations and node identities, but deploying this is, at best, challenging.

We need to add support for such keys first, but not offer a way to configure such keys (absent users changing the code, of course, which is beyond our control) until the network, as a whole, understands such keys and how to verify signatures.

This might mean introducing version 1.3 of the protocol, but stick to talking 1.2. Once we're confident t that the servers understand this, we can then add another commit to allow using these keys.

miguelportilla

👍

nbougalis · 2020-04-15T21:09:20Z

I am closing this, because it has bit-rotted. We will look at reimplementing this in the future.

wilsonianb assigned miguelportilla and scottschurr Aug 6, 2018

wilsonianb requested review from miguelportilla and scottschurr August 6, 2018 18:15

scottschurr reviewed Aug 9, 2018

View reviewed changes

miguelportilla reviewed Aug 10, 2018

View reviewed changes

scottschurr reviewed Aug 18, 2018

View reviewed changes

wilsonianb force-pushed the ed25519-validations branch from bb67a9f to 56a9a17 Compare August 24, 2018 00:43

nbougalis previously requested changes Aug 25, 2018

View reviewed changes

scottschurr reviewed Aug 27, 2018

View reviewed changes

scottschurr approved these changes Aug 27, 2018

View reviewed changes

wilsonianb added 9 commits September 16, 2018 22:02

[FOLD] Replace getSigningHash with getSigningData

4bd875c

[FOLD] Do not hash peer shared value

790f93c

Allow ed25519 node and validator keys

80f32e5

RIPD-1424

[FOLD] Replace signingData() with non-member function:

ff178fb

a la proposalUniqueId

[FOLD] Improve tests

c23a215

[FOLD] Add include

b6f1994

[FOLD] Was base64_decode'ing non-base64 string causing builds to fail?

e178793

[FOLD] Remove signDigest, move verifyDigest

01c6ecb

[FOLD] Change for rebase

e014419

wilsonianb force-pushed the ed25519-validations branch from 56a9a17 to e014419 Compare September 17, 2018 03:31

nbougalis approved these changes Sep 30, 2018

View reviewed changes

miguelportilla approved these changes Sep 20, 2019

View reviewed changes

mDuo13 mentioned this pull request Oct 11, 2019

Improve Ed25519 Support #3105

Open

4 tasks

nbougalis closed this Apr 15, 2020

carlhua mentioned this pull request Jun 3, 2020

Allow validations signed by ed25519 validator keys (Version: 1.5.0) #3434

Open

sappenin mentioned this pull request Nov 3, 2023

[XRPL Performance]Add or change signing support for peer messaging from sepc256k1 to ED25519 #4795

Open

Allow ed25519 node and validator keys #2647

Allow ed25519 node and validator keys #2647

Conversation

wilsonianb commented Aug 6, 2018

ripplelabs-jenkins commented Aug 6, 2018 • edited Loading

Jenkins Build Summary

Test Results

codecov-io commented Aug 6, 2018 • edited Loading

Codecov Report

scottschurr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miguelportilla Aug 10, 2018 • edited Loading

Choose a reason for hiding this comment

miguelportilla Aug 10, 2018 • edited Loading

Choose a reason for hiding this comment

miguelportilla Aug 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miguelportilla Aug 10, 2018 • edited Loading

Choose a reason for hiding this comment

miguelportilla Aug 10, 2018 • edited Loading

Choose a reason for hiding this comment

scottschurr commented Aug 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wilsonianb commented Aug 24, 2018

nbougalis left a comment • edited Loading

Choose a reason for hiding this comment

sublimator commented Aug 25, 2018 via email

sublimator commented Aug 25, 2018

scottschurr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scottschurr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nbougalis left a comment

Choose a reason for hiding this comment

miguelportilla left a comment

Choose a reason for hiding this comment

nbougalis commented Apr 15, 2020

ripplelabs-jenkins commented Aug 6, 2018 •

edited

Loading

codecov-io commented Aug 6, 2018 •

edited

Loading

miguelportilla Aug 10, 2018 •

edited

Loading

miguelportilla Aug 10, 2018 •

edited

Loading

miguelportilla Aug 10, 2018 •

edited

Loading

miguelportilla Aug 10, 2018 •

edited

Loading

miguelportilla Aug 10, 2018 •

edited

Loading

nbougalis left a comment •

edited

Loading