public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
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 21:12:20 +0100	[thread overview]
Message-ID: <CAC1+kJNOuCpUPDiaBNR40T12W3MwUXpXp+PCTLhHyQwyc+8BqA@mail.gmail.com> (raw)
In-Reply-To: <20140322193435.GC6047@savin>

On 3/22/14, Peter Todd <pete@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.



  reply	other threads:[~2014-03-22 20:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22  8:47 [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Peter Todd
2014-03-22 13:53 ` Jorge Timón
2014-03-22 19:34   ` Peter Todd
2014-03-22 20:12     ` Jorge Timón [this message]
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=CAC1+kJNOuCpUPDiaBNR40T12W3MwUXpXp+PCTLhHyQwyc+8BqA@mail.gmail.com \
    --to=jtimon@monetize.io \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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