[Lightning-dev] OP_CHECKSPVPROOFVERIFY

Eric Lombrozo elombrozo at gmail.com
Thu Jul 30 12:18:42 UTC 2015


Let me elaborate more on the way I see this working in practice. I’ll ignore fees for now. Given that sending the proof on the blockchain is expensive, the parties need to negotiate how they split the risk. Moreover, once revoked, we want to encourage the second outputs to be claimed using the revocation secret, not the SPV proof…but we’ll ignore this detail for now.

We have two parties, Prover and Verifier. Verifier wants to pay Prover one currency unit for an SPV proof. Assume they have an open channel with each party having 10 currency units.


Here are the commitment transactions:

Verifier Commitment Transaction
=========================
10	ProverSig
1	ProverSig + VerifierRevocation || ProverSig + SPV proof || VerifierSig + timeout
9	ProverSig + VerifierRevocation || VerifierSig + timeout

Prover Commitment Transaction
=========================
9	VerifierSig
1	VerifierSig + ProverRevocation || ProverSig + SPV proof || VerifierSig + timeout
10	VerifierSig + ProverRevocation || ProverSig + timeout


A script for [ProverSig + VerifierRevocation || ProverSig + SPV proof || VerifierSig + timeout] could look like:

OP_IF
	OP_IF
		OP_HASH160 <VerifierRevocation> OP_EQUALVERIFY
	OP_ELSE
		<transaction hash> OP_CHECKSPVPROOFVERIFY OP_DROP
	OP_ENDIF
	<ProverPubKey> OP_CHECKSIG
OP_ELSE
	<timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
	<VerifierPubKey> OP_CHECKSIG
OP_ENDIF


To redeem this output using the SPV proof, the Prover uses:

<ProverSig> <block hash> <partial merkle tree for transaction> <0> <1>


Once the commitment transactions are created, the Prover gives the Verifier the SPV proof, then they negotiate settlement transactions and exchange revocations.

Would something like this work?

> On Jul 29, 2015, at 11:38 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> 
> I’m not entirely clear on how you intended to use OP_CAT.
> 
> I was thinking something along the lines of
> 
> <block hash> <partial merkle tree for transaction> <transaction> OP_CHECKSPVPROOFVERIFY OP_DROP
> 
> 
> 
> - Eric
> 
> 
>> On Jul 29, 2015, at 6:19 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>> 
>> Eric Lombrozo <elombrozo at gmail.com> writes:
>>> I don’t know if anyone has done any research or published anything in
>>> this regard, but one of the major issues with bitcoin I’ve been trying
>>> to solve is how to properly incentivize nodes to construct SPV proofs.
>> 
>> This can almost be done via P2SH, but not quite:
>> 
>> 1) OP_CAT is disabled :(
>> 2) The txlen limit might bite, I'd have to do the maths.
>> 
>> Cheers,
>> Rusty.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150730/e29f03b1/attachment.sig>


More information about the Lightning-dev mailing list