[Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

[Jorge Timón]

On 3/22/14, Peter Todd <pete at petertodd.org> wrote:
> Well remember that my thinking re: UTXO is that we need to move to a
> system like TXO commitments where storing the entirety of the UTXO set
> for all eternity is *not* required. Of course, that doesn't necessarily
> mean you can't have the advantages of UTXO commitments, but they need to
> be limited in some reasonable way so that long-term storage requirements
> do not grow without bound unreasonably. For example, having TXO
> commitments with a bounded size committed UTXO set seems reasonable; old
> UTXO's can be dropped from the bounded sized set, but can still be spent
> via the underlying TXO commitment mechanism.

Although not having to download the whole blockchain to operate a
trust-less full node is theoretically possible it is not clear that
they will work in practice or would be accepted, and we certainly
don't have that now.
So I don't think future potential theoretical scalability improvements
are solid arguments in favor of supporting proof of publication now.

> Like I said the real issue is making it easy to get those !IsStandard()
> transactions to the miners who are interested in them. The service bit
> flag I proposed + preferential peering - reserve, say, 50% of your
> peering slots for nodes advertising non-std tx relaying - is simple
> enough, but it is vulnerable to sybil attacks if done naively.

My point is that this seems relevant to competing mining policies in general.

> Right, but there's also a lot of the community who thinks
> proof-of-publication applications are bad and should be discouraged. I
> argued before that the way OP_RETURN was being deployed didn't actually
> give any reason to use it vs. other data encoding methods.
>
> Unfortunately underlying all this is a real ignorance about how Bitcoin
> actually works and what proof-of-publication actually is:

I understand that proof of publication is not the same thing as
regular timestamping, but requiring permanent storage in the
blockchain is not the only way you can implement proof of publication.
Mark Friedenbach proposes this:

Store hashes, or a hash root, and soft-fork that blocks are only
accepted if (a) the data tree is provided, or (b) sufficient work is
built on it and/or sufficient time has passed

This way full nodes can ignore the published data until is sufficiently buried.

> I think we're just going to have to agree to disagree on our
> interpretations of the economics with regard to attacking merge-mined
> chains. Myself, I'm very, very wary of systems that have poor security
> against economically irrational attackers regardless of how good the
> security is, in theory, against economically rational ones.

The attacker was of course economically irrational in my previous
example for which you didn't have any complain. So I think we can
agree that a merged mined separated chain is more secure than a
non-merged mined separated chain and that attacking a merged mined
chain is not free.
By not being clear on this you're indirectly promoting non-merged
mined altchains as a better option than merged mined altchains, which
is what I don't think is responsible on your part.

> Again, what it comes down to in the end is that when I'm advising
> Mastercoin, Counterparty, Colored Coins, etc. on how they should design
> their systems I know that if they do proof-of-publication on the Bitcoin
> blockchain, it may cost a bit more money than possible alternatives per
> transaction, but the security is very well understood and robust. Fact
> is, these applications can certainly afford to pay the higher
> transaction fees - they're far from the least economically valuable use
> of Blockchain space. Meanwhile the alternatives have, at best, much more
> dubious security properties and at worse no security at all.
> (announce/commit sacrifices is a great example of this, and very easy to
> understand)

I agree that we disagree on additional non-validated data in the main
chain vs merged mined chains as the best way to implement additional
features.
But please, you don't need to spread and maintain existing myths about
merged mining to make your case. If you insist on doing it I will
start to think that the honesty of your arguments is not something
important to you, and you just prefer to try to get people on your
side by any means, which would be very disappointing.