Computing Blinding Factors in a PTLC and Trampoline World



Summary:

In this discussion, ZmnSCPxj presents a mathematical demonstration of a method to compute blinding factors for onion routing. The objective is to achieve certain properties such as non-Trampoline intermediate nodes only needing to know one blinding factor and the receiver only needing to know one blinding factor. Additionally, Trampoline nodes should be able to provide blinding factors without revealing that they are part of a trampoline route.The demonstration starts with the ultimate receiver having a secret value 'r' and providing the point 'R' to the ultimate sender, where 'R = r * G' (G being a generator point). In the simplest case where there are no intermediate nodes, the ultimate sender chooses a random scalar 'e' as the error blinding factor and constructs an onion that can be decrypted by the ultimate receiver. The ultimate sender also offers a PTLC (Point-Time Lock Contract) with the point 'e * G + R'. The ultimate receiver can claim the PTLC by revealing 'e + r', as it knows 'e' from the onion and the contract requires giving 'r' in exchange for payment.Next, the scenario is extended to include an intermediate node named Carol. The ultimate sender still chooses a random scalar 'e' as the final error blinding factor but now needs to generate two scalars 'c' and 'd' such that 'c + d = e'. This can be done by selecting a random 'd' and computing 'c = e - d'. The ultimate sender encrypts the onion with 'e' encrypted to the ultimate receiver and the above ciphertext along with 'd' encrypted to Carol. The PTLC sent to Carol is 'c * G + R'.For each intermediate non-Trampoline node like Carol, it adds its per-hop blinding factor times 'G' to the input point and uses the result as the output point to the next hop. Carol receives 'c * G + R', adds 'd * G' (the 'd' error from the onion), and sends a PTLC with the point 'c * G + R + d * G'. It is important to note that 'e = c + d', so the PTLC sent by Carol can be rearranged as '(c + d) * G + R', which is equal to 'e * G + R'.In the case where Carol is a Trampoline node and the ultimate sender does not provide a detailed route from Carol to the next Trampoline hop, additional steps are followed. The ultimate sender learns 'R' and selects a random 'e'. It also selects 'c' and 'd' such that 'c + d = e'. The ultimate sender then computes a Trampoline-level onion with 'e' encrypted to the ultimate receiver and the above ciphertext, 'd', and the next Trampoline hop encrypted to Carol. The PTLC sent to Carol is 'c * G + R'.Carol decrypts the onion and obtains 'd'. It then searches for a route from Carol to the ultimate receiver (the next Trampoline hop). Assuming it finds a route Carol -> Alice -> ultimate receiver, Carol needs to make 'c * G + d * G + R' reach the ultimate receiver. To achieve this, Carol selects two scalars 'a' and 'b' such that 'a + b = d'. It creates an onion with the copied ciphertext from the ultimate sender (with 'e' encrypted to the ultimate receiver), the above ciphertext, and 'b' encrypted to Alice. The PTLC sent to Alice is 'c * G + R + a * G'.Alice decrypts the onion and learns 'b'. She forwards the PTLC with the point 'c * G + R + a * G + b * G' to the next hop, the ultimate receiver. By construction, 'a + b = d' and 'c + d = e', so the ultimate receiver gets the same 'e * G + R' regardless of whether it was reached via a Trampoline or directly.On claiming, every intermediate node, both Trampoline and non-Trampoline, has enough data to claim its incoming PTLC. Only the ultimate sender knows 'c', which allows it to recover the 'r'.The demonstration shows how blinding factors can be computed in onion routing scenarios with different configurations of intermediate nodes, ensuring that certain properties are maintained without compromising the privacy of the ultimate receiver.


Updated on: 2023-07-14T03:09:19.839433+00:00