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 <p...@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 >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
