From: Peter Todd <pete@petertodd•org>
To: "Jorge Timón" <jtimon@monetize•io>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
Date: Sat, 22 Mar 2014 15:34:35 -0400 [thread overview]
Message-ID: <20140322193435.GC6047@savin> (raw)
In-Reply-To: <CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5103 bytes --]
On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Timón wrote:
> On 3/22/14, Peter Todd <pete@petertodd•org> wrote:
> > There's been a lot of recent hoopla over proof-of-publication, with the
> > OP_RETURN <data> 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-03-22 19:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-22 8:47 Peter Todd
2014-03-22 13:53 ` Jorge Timón
2014-03-22 19:34 ` Peter Todd [this message]
2014-03-22 20:12 ` Jorge Timón
2014-03-23 23:17 ` Troy Benjegerdes
2014-03-23 23:53 ` Mark Friedenbach
2014-03-24 20:34 ` Troy Benjegerdes
2014-03-24 20:57 ` Mark Friedenbach
2014-03-25 22:10 ` Troy Benjegerdes
2014-03-26 1:09 ` kjj
2014-03-22 15:08 ` Troy Benjegerdes
2014-03-22 17:04 ` Mark Friedenbach
2014-03-22 19:08 ` Peter Todd
2014-03-23 22:37 ` Troy Benjegerdes
[not found] ` <532DE7E6.4050304@monetize.io>
2014-03-25 12:28 ` [Bitcoin-development] Tree-chains preliminary summary Peter Todd
2014-03-25 12:45 ` Gavin Andresen
2014-03-25 13:49 ` Peter Todd
2014-03-25 15:20 ` Mike Hearn
2014-03-25 16:47 ` Peter Todd
2014-03-25 17:37 ` Jeff Garzik
2014-03-25 18:02 ` Alan Reiner
2014-03-25 18:13 ` slush
2014-03-25 19:47 ` Peter Todd
2014-03-25 21:41 ` Troy Benjegerdes
2014-03-25 20:40 ` Ricardo Filipe
2014-03-25 22:00 ` Troy Benjegerdes
2014-03-26 10:58 ` Peter Todd
2014-03-25 12:50 ` Peter Todd
2014-03-25 21:03 ` Mark Friedenbach
2014-03-25 22:34 ` Gregory Maxwell
2014-03-27 16:14 ` Jorge Timón
2014-03-28 15:10 ` Troy Benjegerdes
2014-04-17 21:41 ` Tier Nolan
2014-03-26 10:48 ` Peter Todd
2014-08-03 17:23 ` Gregory Sanders
2014-03-24 21:17 ` [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140322193435.GC6047@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jtimon@monetize$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox