[Lightning-dev] Selling timestamps (via payment points and scalars + Pedersen commitments ) [try2]

[Konstantin Ketterer]

First of all, thanks for everybodys feedback. I'm happy that it works.

Adopting a standard like OpenTimestamps should be a no brainer because it
would save on development work and people are already familiar with it.

I looked into secp256k1 commitments/ sign-to-contract (
https://pdfs.semanticscholar.org/21ac/217d10de3ece8d29dcd1d75305b7385985a5.pdf)
and love how they basically enable free timestamps at no additional cost by
tweaking the signature of a normal transaction. I imagine that in the
future nodes such as public lightning routing nodes or submarineswap
providers who have to do some transactions like opening new channels or
performing swaps anyways will try to subsidise their transaction fees by
selling timestamps. Because they have no additional risk/cost they only
need to charge a fee upfront or require some Hashcash like proof of work
protection in case of spam.

*Removing the discrete logarithm security assumption*
If we include a hash h( x || r ) of x and r in the hash of the commitment
--> h( x*H + r*G | | h( x | | r) ) , the timestamp will still remain secure
and valid incase secp256k1 breaks. We can't enforce it with payment points
and scalars but if the server doesn't include a valid hash we'll never use
his services again and can even prove to other peers that he cheated us. If
the system is resistant against sybil attacks with something like
JoinMarkets time-locked Bitcoins proposal  this should work fine.

Regards
Konstantin

Am Do., 26. Sept. 2019 um 11:08 Uhr schrieb Peter Todd <pete at petertodd.org>:

> On Wed, Sep 25, 2019 at 11:01:28AM +0200, Konstantin Ketterer wrote:
> > *Disclaimer*: I have just finished Highschool and I'm only learning a bit
> > in my free time.This may be fundamentally broken ;)
> >
> > *Motivation*: If I had to timestamp multiple messages I could simply
> > aggregate them in a merkle tree and pay relatively low fees per message.
> > However, if I only need to timestamp something once in a while I need to
> > rely on free services or pay high fees.
> >
> > *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 = x*H + r*G, 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 - x*H = r*G as the
> payment
> > point  to the timestamping server and as a proof of payment the server
> must
> > reveal r to receive the money.
> >
> > --> With both r and x I have a valid Pedersen commitment.
> >
> > This introduces an additional security assumption to Bitcoin timestamps
> but
> > if the discrete logarithm is broken Bitcoin has bigger problems than
> broken
> > timestamps.
> >
> > *Conclusion*
> > This scheme essentially shifts the risk of a timestamping service from
> the
> > buyer to the seller who now has to pay the onchain transaction fee
> upfront.
> > Hence, the seller will most likely charge a small fee upfront just like
> > some submarineswap providers do.
>
> This sounds like a clever idea. But because timestamping is so scalable I
> already run a much less clever service called OpenTimestamps that does
> timestamping for free. Basically, it uses giant merkle trees built every
> second
> in a scalable way to amortize the cost of the BTC transactions across the
> entire world's timestamps, so there's really no need to charge for them.
>
> Even if, say, every single Android phone in the world timestamped every
> single
> photo taken, all I'd have to do is partner with someone like Cloudflare to
> run
> OpenTimestamps aggregators and it'd still be using just a handful of
> bitcoin
> transactions every day.
>
> https://opentimestamps.org
>
> Also, note that Andrew Poelstra has a pull-req to add secp256k1
> commitments to
> OpenTimestamps, which may prove useful to you in implementing the above:
>
> https://github.com/opentimestamps/python-opentimestamps/pull/14
>
> After all, the OpenTimestamps *proof format* doesn't depend on the
> aggregation
> scheme, so if you actually build the above it'd be awesome if it produced
> OpenTimestamps proofs!
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190926/13ce2839/attachment.html>