Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-01 📝 Original message: Minor script corrections: ...

📅 Original date posted:2015-08-01
📝 Original message:
Minor script corrections:

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


> On Jul 30, 2015, at 5:18 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> 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/20150731/5cfa2cc0/attachment.sig>;