1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
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 <jtimon@monetize.io>) 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 <bitcoin-development@lists.sourceforge.net>;
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>
<CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@mail.gmail.com>
<20140322193435.GC6047@savin>
Date: Sat, 22 Mar 2014 21:12:20 +0100
Message-ID: <CAC1+kJNOuCpUPDiaBNR40T12W3MwUXpXp+PCTLhHyQwyc+8BqA@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2014 20:12:29 -0000
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.
|
