From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WRSHN-0007sB-IO for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 20:12:29 +0000 Received: from mail-la0-f53.google.com ([209.85.215.53]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WRSHL-0001l2-V5 for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 20:12:29 +0000 Received: by mail-la0-f53.google.com with SMTP id b8so2571520lan.26 for ; Sat, 22 Mar 2014 13:12:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i0AFbL35I2qf3PomjJnHPfEjysDnyianwB0DkkMQgBQ=; b=mqcVGw6UWxUhS1oWlwqJBPkd6I/Bb5YrSU3YpxmyTmt7yf6an/Nx0VeaMZ4Gs0ns2B qGW3o/d6N3yCWRgRrZtVePBA8Q0zqdErD3TFCX5ejHUIrC2B/cDHp6ATOZwJyf9RPFvN pyDVzDmLo8Kt72Fz+vZg3ZL2PgONkMLVka6qLc4/52ZctKtUSRctiXUV6H0mrj9oWiI7 yw3rWnEgi48e/KWNFDKgEDr4f+xQHzf8IKjif9Tdmr4gcnl5yrhEfh50O1NR/X53wDci 5twolfBgVfHlbBDfAp6uuGIppaL4M3aoRuXEkv36dttv8w8VeCXef15ynM2Qy9Ml57iY y4aA== X-Gm-Message-State: ALoCoQnm8DFPPDbb0GJwVIQUWseMGad96REQLHtTcuX8wiOyIym4yUakt6Lbeqyqcf0cJcYpe9kM MIME-Version: 1.0 X-Received: by 10.112.241.73 with SMTP id wg9mr56364lbc.48.1395519141090; Sat, 22 Mar 2014 13:12:21 -0700 (PDT) Received: by 10.112.62.136 with HTTP; Sat, 22 Mar 2014 13:12:20 -0700 (PDT) X-Originating-IP: [85.59.137.255] In-Reply-To: <20140322193435.GC6047@savin> References: <20140322084702.GA13436@savin> <20140322193435.GC6047@savin> Date: Sat, 22 Mar 2014 21:12:20 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WRSHL-0001l2-V5 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 20:12:29 -0000 On 3/22/14, Peter Todd 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.