On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Timón wrote: > On 3/22/14, Peter Todd wrote: > > There's been a lot of recent hoopla over proof-of-publication, with the > > OP_RETURN length getting reduced to a rather useless 40 bytes at > > the last minute prior to the 0.9 release. > > > I'm not against about miners accepting transactions that have longer > data in non-utxo polluting OP_RETURN than whatever is specified as > standard by the reference implementation, maybe it should be risen in > standard but I think it was assumed that the most common case would be > to include the root hash of some "merklized" structure. > My only argument against non-validated proof of publication is that in > the long run it will be very expensive since they will have to compete > with transactions that actually use the utxo, a feature that is more > valuable. But that's mostly speculation and doesn't imply the need for 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. > any action against it. I would strongly opposed to against a > limitation on OP_RETURN at the protocol level (other than the block > size limit itself, that is) and wouldn't mind if they're removed from > isStandard. I didn't payed much attention to that and honestly I don't > care enough. > > Maybe this encourages miners to adopt their own policies, which could > be good for things like replace-by-fee, the rational policy for > miners, which I strongly support (combined with game theory can > provide "instant" transactions as you pointed out in another thread). > > Maybe the right approach to keep improving modularity and implement > different and configurable mining policies. 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. > > All these methods have some overhead compared to just using OP_RETURN > > and thus cost more. > > I thought the consensus was that op_return was the right way to put > non-validated data in the chain, but limiting it in standard policies > doesn't seem consistent with that. 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: 14-03-20.log:12:47 < gavinandresen> jgarzik: RE: mastercoin/OP_RETURN: what's the current thinking on Best Way To Do It? Seems if I was to do it I'd just embed 20-byte RIPEMD160 hashes in OP_RETURN, and fetch the real data from a DHT or website (or any-of-several websites). Blockchain as reference ledger, not as data storage. > Peter Todd, I don't think you're being responsible or wise saying > nonsense like "merged mined chains can be attacked for free" and I > suggest that you prove your claims by attacking namecoin "for free", > please, enlighten us, how that's done? 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. 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) -- 'peter'[:-1]@petertodd.org 0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91