Exposing last tip for external tx

[RCasatta]

In the context of allowing external actor to make the timestamp transaction the server must expose his last tip.
Simple proposed implementation could be something like this:
https://github.com/RCasatta/opentimestamps-server/compare/perf-fix-with-order...RCasatta:get-tip?expand=1

[petertodd]

I'm not sure we want to encourage people to do this in an automated way right now, because inevitably people will end up making multiple timestamps and wasting tx fees.

OTOH, this would be totally ok with secp256k1 commitments, opentimestamps/python-opentimestamps#14, but to support that we need to not only provide the tip, but also allow the submission of timestamps, as secp256k1 are impossible to find from the chain alone.

There's also potential issues with griefing txs where people use their txs to put "bad" data into timestamp proofs, e.g. virus signatures, although secp256k1 unavoidably has that problem due to how miners can control what's in coinbase txs. :/

[RCasatta]

I'm not sure we want to encourage people to do this in an automated way right now, because inevitably people will end up making multiple timestamps and wasting tx fees.

Fees should already disincetivize people from doing this, people are motivated only if their timestamp is in the queue and they are in hurry...
Not doing this incentivize companies who wants more frequent timestamps to boot their own calendars and wasting even more fees. Or individualts timestmaping just their own commitment. At least in this case we know calendars are grouping commitments for everybody since there is no disincetive to timestamp their own commitments grouped with others.
I believe there is also a "cheap donation" if you are already making a tx and just decide to add an op_return.
This also allow a third party who wants to grant a SLA of let's say a timestamp in a day, to pay for the fee for everybody if he see the calendar are not timestamping in the last 24 hours

OTOH, this would be totally ok with secp256k1 commitments, opentimestamps/python-opentimestamps#14, but to support that we need to not only provide the tip, but also allow the submission of timestamps, as secp256k1 are impossible to find from the chain alone.

We started thinking about this, @LeoComandini is working on electrum plugin to commit in the signature and we know we have to communicate to the server something to "see the commitment".
This information to "see the commitment" should be in a form of a timestamp tree, to allow a client to ask all three calendar the tip, make a merkle, create the tx and tell the calendar how to connect that digest to the previous tip.
This mechanism should include some way to prove the client made the transaction as anti-dos mechanism.

There's also potential issues with griefing txs where people use their txs to put "bad" data into timestamp proofs, e.g. virus signatures, although secp256k1 unavoidably has that problem due to how miners can control what's in coinbase txs. :/

I absolutely didn't thought about that, but, is the maximum tx size of 1000 bytes and the max_msg_lengt of 2096 already preventing/making difficult this attack?

[petertodd]

I think you make good points re: fees, so I'm now in agreement with you on adding the tip API.

I just took a look at the stamper code, and it looks like if anyone did this the result will be commitments having multiple, redundant, Bitcoin attestations. This is a minor DoS attack actually, as you can add an arbitrary number of them, which the server will end up providing to the client when they ask for the timestamps on the commitment. Because doing this is so expensive, I don't think it really matters for the calendar servers. However for the sake of clients, we probably want to normalize the timestamps the calendar server returns by stripping off all but the oldest attestations.

I absolutely didn't thought about that, but, is the maximum tx size of 1000 bytes and the max_msg_lengt of 2096 already preventing/making difficult this attack?

It makes the attack less bad, but it doesn't actually stop it. The problem is "bad data" can be really small - a virus signature like the EICAR test file can be just a few dozen bytes. There just might not be a good solution though at the timestamp level; at the timestamp file level we could obfuscate the timestamp data, e.g. by encrypting it, but it sucks how that solution makes debugging harder. :/

Along those lines, awesome to hear about the Electrum plugin!

I don't think we need to force clients to prove they created the transaction though. In fact, I think it'd be reasonable to just make a generic timestamp submission system, where anyone could submit a timestamp for any commitment. The for each attestation, the timestamp server would choose to either ignore the attestation, or add it to the database, based on criteria like attestation age and total proof size. So long as our criteria are sane - like a total size limit - I don't see any harm in accepting arbitrary timestamps.

[RCasatta]

About the electrum plugin there are two cases:
In the case the client write the tip directly in a tx (eg op_return) the server doesn't need anything else.
In the case of sign to contract some extra info is needed

[petertodd]

Closing as "won't fix" for now, as there's potential security issues in giving third-parties the ability to get data into OTS proofs via their transactions.

That'd probably be ok with semi-trusted third parties where we can be pretty confident they won't do anything weird. But fees just haven't been high enough to justify all that work and risk.