Peter Todd

What's the proposed use-case for pay-to-contract? I'm pretty skeptical about adding extra dependencies without a compelling reason; just saving a few bytes isn't enough given how efficient OpenTimestamps is already.

Keep in mind that OT is already uncensorable against anything less than full-on whitelists, as it doesn't need to use OP_RETURN. Frankly, I don't care about Mimblewimble until it catches...

First of all, append and prepend are both binary opcodes. Secondly, attestations are effectively non-unary opcodes too! Note how the attestations could have been implemented is to build the arguments...

So thinking about this more, I think we have a good argument for doing this: we'd be able to allow anyone to help timestamp the calendar merkle tips at zero...

@mcelrath It's still on the todo list, it's just that I've had more pressing issues to deal with first. Also, note that due to how segwit's commitment is designed, using...

No, it's not *purely* an efficiency problem, as there's a [maximum message size](https://github.com/opentimestamps/python-opentimestamps/blob/9b19286da519f9da0b5318b4ce30941022acb6bd/opentimestamps/core/op.py#L59) limit of 4096 bytes. This would be hit by blocks containing >4096byte coinbase transactions, making a segwit-using...

Re: noes pruning witness data and SPV, none of that should be an issue as a BitcoinAttestation verifies the block header, and nothing else; OTS deliberately omits support for creating...

@cloutier I'm talking about a different type of attack actually - nuisance attacks that make timestamps bigger than necessary, or try to exploit bugs in validation logic. But yes, when...

@cloutier For example, even though a merkle tree proof shouldn't be more than about 1KB of data, the current codebase will accept up to 10KB of data; remember that proof...

> I don't think it is required, requesting LN users and some miners to use full RBF would be enough. It's not enough. As @mzumsande notes, you need a significant...