[Rendezvous] Draft proof-of-work requirement #334
Conversation
rendezvous/README.md
Outdated
| Once the difficulty requirement is met, a rendezvous point will respond with a | ||
| status code of `OK`. | ||
|
|
||
| To vary the difficulty, a client can manipulate the `nonce` field. |
There was a problem hiding this comment.
Wouldn't the client satisfy the difficulty set by the rendezvous point? The client would vary or manipulate the nonce to produce a hash that satisfies the difficulty?
There was a problem hiding this comment.
In the current proposal, the rendezvous point never specifies a difficulty. Maybe it should but that is another field with need to include the message :)
It might be worth it because then the client doesn't need to "trial and error" in getting the difficulty right.
On the other hand, it doesn't really reduce complexity because we still need to cover the error case where a client ignores that field and sends a hash that doesn't satisfy the difficulty. Hence, the only benefit would be in less round-trips and less hashing on the client which sounds like a good idea.
The client would vary or manipulate the nonce to produce a hash that satisfies the difficulty?
Yep, that is exactly what the spec says, maybe in a sort of contrived way: The nonce is the only field that can be varied by the client to produce a different hash.
| @@ -206,6 +254,8 @@ message Message { | |||
| E_INVALID_SIGNED_PEER_RECORD = 101; | |||
| E_INVALID_TTL = 102; | |||
| E_INVALID_COOKIE = 103; | |||
| E_POW_REQUIRED = 104; | |||
| E_DIFFICULTY_TOO_LOW = 105; | |||
There was a problem hiding this comment.
Thinking of dropping this one because it is essentially the same message as E_POW_REQUIRED.
| It is worth noting that the `target_difficulty` can change between the initial `E_POW_REQUIRED` | ||
| and submitting the PoW. Henceforth, a client must be prepared to receive a `E_DIFFICULTY_TOO_LOW` | ||
| message even if they adhered to the previously sent `target_difficulty`. |
There was a problem hiding this comment.
Thinking that this is actually quite annoying and there isn't really a reason for the server to do this. Once they've requested a specific PoW, they SHOULD accept it if the client provides a legitimate PoW.
| - The contents of `challenge` | ||
| - The `ns` field | ||
| - The `signedPeerRecord` field | ||
| - The `PeerId` of the rendezvous point we are registering with |
There was a problem hiding this comment.
Given the addition of challenge, I am considering dropping this because PoW hashes are now unique to the rendezvous point already.
| message ProofOfWork { | ||
| optional bytes hash = 1; | ||
| optional int64 nonce = 2; | ||
| } | ||
|
|
||
| optional MessageType type = 1; |
There was a problem hiding this comment.
Needs to be extended with PROOF_OF_WORK variant.
|
Pinging author and interest group. Does one of you want to take a look at this proposal? Also see #337 for a general discussion on whether to introduce proof of work to the Rendezvous protocol. @vyzo, @daviddias, @whyrusleeping, @Stebalien, @jacobheun, @yusefnapora, @vasco-santos |
|
we have had on and off discussions about PoW and we are not convinced its
the right thing to do.
I think its much better to have many rendezvous points and use verified
randomness in picking the one to use.
…On Mon, Jun 21, 2021, 13:17 Max Inden ***@***.***> wrote:
Pinging author and interest group. Does one of you want to take a look at
this proposal? Also see #337 <#337>
for a general discussion on whether to introduce *proof of work* to the
*Rendezvous* protocol.
@vyzo <https://github.com/vyzo>, @daviddias <https://github.com/daviddias>,
@whyrusleeping <https://github.com/whyrusleeping>, @Stebalien
<https://github.com/Stebalien>, @jacobheun <https://github.com/jacobheun>,
@yusefnapora <https://github.com/yusefnapora>, @vasco-santos
<https://github.com/vasco-santos>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#334 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAI4SWA44FXKCVPX5U5563TT4GT7ANCNFSM46WLAE7A>
.
|
Right, thanks for clarifying! I'll close this then and send another PR that incorporates this knowledge into the spec. |
Relates to libp2p#334. Fixes libp2p#337.
Relates to libp2p#334. Fixes libp2p#337.
Opened a follow-up PR: #342. |
This is a draft for the proof of work requirement that is to be defined in the rendezvous protocol.
I've considered a number of designs and ended up with what is presented here. I am not sure how much people will like the additional messages but it solves an important problem: The PoW must be unique to a single registration and the best way to achieve that IMO is for the rendezvous point to hand out a challenge to the client. Given that
REGISTERis sent by the client, there isn't really any opportunity before the register response to send back a challenge which is why I opted to introduce a dedicated status code that requests proof of work from the client.The main consequence of this is that it allows rendezvous points to not require proof of work for the first few registrations for example or whilst they are under low load. I am not sure we need this flexibility but it is there with the current design.
If however we want proof of work with every registration anyway, then the additional message is a bit of a waste and it would be ideal if the client could just include the proof of work with the original
REGISTERmessage. Unfortunately, I could come up with a way of making the PoW unique to this registration.ttlis a relative value and therefore, a PoW that is calculated once could be reused over and over again at a later point in time.