ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-25 📝 Original message: Good morning aj, and ...
📅 Original date posted:2019-09-25
📝 Original message:
Good morning aj, and list,
> > Solution: buy a place in a merkle tree "risk-free"
> >
> > 1. send hash x of my message (or the merkle root of another tree) to the
> > timstamping server
> >
> > 2. server calculates Pedersen commit: C = xH + rG, hashes it, builds merkle
> > tree with other commits in it and publishes a valid transaction containing the
> > merkle root to the Bitcoin blockchain
> >
> > 3. after a certain number of block confirmations and with the given proof I can
> > confirm that the commitment C is indeed part of the Bitcoin blockchain
> >
> > 4. I now have to send a lightning payment with C - xH = rG as the payment
> > point to the timestamping server and as a proof of payment the server must
> > reveal r to receive the money.
> >
>
> Nice.
I agree.
This is quite correct for its needs, and kudos to Konstantin for deriving this.
Do note that Lightning today does not yet support payment points / scalars, only payment hashes / preimages.
In particular the client might induce the server to "waste" a slot on committing some information onchain, but the client will still not be able to get a commitment "for free" as it cannot know the blinding key for the commitment.
That is, the client can DoS the server and have it make commitments without getting paid, wasting the server capacity, but the client would not be able to prove the commitment does commit to its message without paying.
This can be avoided with aj suggestion of "floating" and "subscriber" clients.
I would have personally used sign-to-contract onchain directly myself for such "rare" operations, but aggregation certainly has its efficiency benefits and this is still useful.
So far it seems, we can use EC magic (payment point / scalar) to:
* Prevent route correlation especially for multipath payments.
* Allow pay-for-signature.
* Allow pay-for-pedersen-commitment (this thread).
* Support multiple parallel payments ("stuckless").
* Support noncustodial Lightning escrow.
* Probably some other things I have forgotten.
>
> Since it's off chain, you could also provide R and C and a zero knowledge
> proof that you know an r such that:
>
> R = SHA256( r )
> C = SHA256( x || r )
>
> in which case you could do it with lightning as it exists today.
I can insist on paying only if the server reveals an `r` that matches some known `R` such that `R = SHA256(r)`, as currently in Lightning network.
However, how would I prove, knowing only `R` and `x`, and that there exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`?
I am curious about this operation, as this is beyond what little I know of cryptography.
Regards,
ZmnSCPxj
📝 Original message:
Good morning aj, and list,
> > Solution: buy a place in a merkle tree "risk-free"
> >
> > 1. send hash x of my message (or the merkle root of another tree) to the
> > timstamping server
> >
> > 2. server calculates Pedersen commit: C = xH + rG, hashes it, builds merkle
> > tree with other commits in it and publishes a valid transaction containing the
> > merkle root to the Bitcoin blockchain
> >
> > 3. after a certain number of block confirmations and with the given proof I can
> > confirm that the commitment C is indeed part of the Bitcoin blockchain
> >
> > 4. I now have to send a lightning payment with C - xH = rG as the payment
> > point to the timestamping server and as a proof of payment the server must
> > reveal r to receive the money.
> >
>
> Nice.
I agree.
This is quite correct for its needs, and kudos to Konstantin for deriving this.
Do note that Lightning today does not yet support payment points / scalars, only payment hashes / preimages.
In particular the client might induce the server to "waste" a slot on committing some information onchain, but the client will still not be able to get a commitment "for free" as it cannot know the blinding key for the commitment.
That is, the client can DoS the server and have it make commitments without getting paid, wasting the server capacity, but the client would not be able to prove the commitment does commit to its message without paying.
This can be avoided with aj suggestion of "floating" and "subscriber" clients.
I would have personally used sign-to-contract onchain directly myself for such "rare" operations, but aggregation certainly has its efficiency benefits and this is still useful.
So far it seems, we can use EC magic (payment point / scalar) to:
* Prevent route correlation especially for multipath payments.
* Allow pay-for-signature.
* Allow pay-for-pedersen-commitment (this thread).
* Support multiple parallel payments ("stuckless").
* Support noncustodial Lightning escrow.
* Probably some other things I have forgotten.
>
> Since it's off chain, you could also provide R and C and a zero knowledge
> proof that you know an r such that:
>
> R = SHA256( r )
> C = SHA256( x || r )
>
> in which case you could do it with lightning as it exists today.
I can insist on paying only if the server reveals an `r` that matches some known `R` such that `R = SHA256(r)`, as currently in Lightning network.
However, how would I prove, knowing only `R` and `x`, and that there exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`?
I am curious about this operation, as this is beyond what little I know of cryptography.
Regards,
ZmnSCPxj