Published on: 2015-08-01T11:04:58+00:00
In an email conversation between Rusty Russell and Eric Lombrozo, Eric expresses confusion over how to use OP_CAT. Rusty suggests that a merkle tree calculation can be open-coded using OP_CAT and OP_HASH256, eliminating the need for a new OP. However, Rusty also acknowledges that this discussion may not be relevant to the current list they were on and suggests finding a more appropriate forum.In a discussion thread, Eric Lombrozo seeks clarification on the use of OP_CAT. He suggests that it can be used to open-code a merkle tree calculation along with OP_HASH256, without requiring a new OP, which may be more efficient. However, he also notes that this discussion may not be specific to lightning technology. Rusty agrees that they may be getting off-topic for the list and bids farewell.The context discusses minor script corrections, with a focus on creating commitment transactions and scripts for Prover and Verifier parties. The Prover wants to receive one currency unit from the Verifier for an SPV proof, but due to its high cost, they need to negotiate how to split the risk. They create commitment transactions with different signatures, timeouts, and revocation possibilities. A script for [ProverSig + VerifierRevocation || ProverSig + SPV proof || VerifierSig + timeout] is introduced, which uses OP_IF and OP_ELSE statements. It checks if the hash of the public key equals a given value, then verifies the signature. Alternatively, it drops three stack items and verifies the signature or checks the locktime. To redeem this output using the SPV proof, the Prover uses OP_CHECKSPVPROOFVERIFY OP_DROP.Once the commitment transactions are created, the Verifier receives the SPV proof, and both parties negotiate settlement transactions and exchange revocations. Eric Lombrozo suggests using the OP_CHECKSPVPROOFVERIFY OP_DROP script command to incentivize nodes to construct SPV proofs, but Rusty Russell notes that OP_CAT is disabled, and the txlen limit may pose a problem.The article discusses how to incentivize nodes to construct SPV proofs. The author presents two parties, Prover and Verifier, with an open channel of 10 currency units each. The Verifier wants to pay the Prover one currency unit for an SPV proof. The commitment transactions are created, and the Prover gives the Verifier the SPV proof. However, since sending the proof on the blockchain is expensive, parties need to negotiate how they split the risk. Once revoked, the second outputs should be claimed using the revocation secret, not the SPV proof. The script for [ProverSig + VerifierRevocation || ProverSig + SPV proof || VerifierSig + timeout] has been provided in the article. To redeem this output using the SPV proof, the Prover uses OP_CHECKSPVPROOFVERIFY OP_DROP.Once the commitment transactions are created, the Prover gives the Verifier the SPV proof, then they negotiate settlement transactions and exchange revocations. Eric Lombrozo suggested OP_CHECKSPVPROOFVERIFY OP_DROP instead of OP_CAT. The author concludes that something like this could work.Eric Lombrozo had a query regarding the usage of OP_CAT. He was thinking about using it along with OP_CHECKSPVPROOFVERIFY and OP_DROP. Rusty Russell responded that incentivizing nodes to construct SPV proofs could almost be done via P2SH, but not quite due to disabled OP_CAT and txlen limit which requires further calculation.In a recent post by Eric Lombrozo, he raises concerns over incentivizing nodes to construct SPV (Simplified Payment Verification) proofs. Lombrozo is uncertain if any research or publications have been made on this matter. He notes that the issue can be partially solved through P2SH (Pay-to-Script-Hash), but there are still obstacles. For example, OP_CAT is currently disabled, and the txlen limit may pose problems. Lombrozo's concerns highlight the ongoing need for innovation and problem-solving within the Bitcoin community. As the cryptocurrency landscape continues to evolve, it is important for developers and researchers to address potential roadblocks in order to ensure the continued success and adoption of Bitcoin.On July 29, 2015, Eric Lombrozo forwarded a message to the group about outsourcing Simple Payment Verification (SPV) proofs over Lightning Network (LN). Although it might not offer significantly better security than current SPV proofs, outsourcing is desirable as it leads to quantifiable incentives for running nodes to serve SPV clients. This makes it possible to reason about the economic security model of the network. While there is no mention of a specific opcode for SPV proof, using OP_CHECKSPVPROOFVERIFY in crafting a contract requesting payment from the SPV client along with an enforcement mechanism could be practical.
Updated on: 2023-07-31T18:10:58.146024+00:00