Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-26 📝 Original message: On Wed, Sep 25, 2019 at ...
📅 Original date posted:2019-09-26
📝 Original message:
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190926/c197098f/attachment-0001.sig>;
📝 Original message:
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190926/c197098f/attachment-0001.sig>;