summaryrefslogtreecommitdiff
path: root/a8/4dbd657fb02dd1d45b81295fe39cfa7b97ae20
blob: 10dd54bdebf2fae26e846dc14cd4161ee37082ca (plain)
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
143
144
145
146
147
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jtimon@monetize.io>) id 1WRMMv-0007kS-I8
	for bitcoin-development@lists.sourceforge.net;
	Sat, 22 Mar 2014 13:53:49 +0000
Received: from mail-la0-f43.google.com ([209.85.215.43])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WRMMu-0007p5-8K
	for bitcoin-development@lists.sourceforge.net;
	Sat, 22 Mar 2014 13:53:49 +0000
Received: by mail-la0-f43.google.com with SMTP id e16so2446275lan.2
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 22 Mar 2014 06:53:41 -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
	:content-transfer-encoding;
	bh=kSultoXzLzhI/QePDS/D7K6biZRqiMugh9vJ9Erme5M=;
	b=h3sZg4RRzVw1P2+uYUrvzwVG4AT9yjmFHgLHW6LEtZbrWL6sxHcrl8FnONMjY+dDLY
	lppFPUTsQyX2kWqMWvPpe8a9n7kTGF2csdomURPUfV1QhXaTpvJE15x5FbH1R+rx89hi
	vuy8brZYHidAwXY+rhHKjajiTNZGKSN7iGvd7gZqkhsfVidQF2wWciHTcsAJdKP4CW07
	IdlfCcz5A9Z3xvIDV7FPz5V9W7hffJFK3i5Emhs1Z6iWB30mlUtuO5i6ei1joccYnkmG
	XAKa0o9UTLPGwoHmxJMkLZN102M6FDzEpViSNdarEQSyS+m56vEJkYp9X6O2Dafa2Cxk
	PLKA==
X-Gm-Message-State: ALoCoQl7igwviBsMM7M8RB7GKOqejTaygQh9l3vodY0SIz00bPFTyxYGWJJcZPh2ERcSEtY+MPaC
MIME-Version: 1.0
X-Received: by 10.152.19.7 with SMTP id a7mr38190527lae.16.1395496421249; Sat,
	22 Mar 2014 06:53:41 -0700 (PDT)
Received: by 10.112.62.136 with HTTP; Sat, 22 Mar 2014 06:53:41 -0700 (PDT)
X-Originating-IP: [85.59.137.255]
In-Reply-To: <20140322084702.GA13436@savin>
References: <20140322084702.GA13436@savin>
Date: Sat, 22 Mar 2014 14:53:41 +0100
Message-ID: <CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@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
Content-Transfer-Encoding: quoted-printable
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: 1WRMMu-0007p5-8K
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 13:53:49 -0000

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
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.

> 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.

> Finally I'll be writing something more detailed soon about why
> proof-of-publication is essential and miners would be smart to support
> it. But the tl;dr: of it is if you need proof-of-publication for what
> your system does you're much more secure if you're embedded within
> Bitcoin rather than alongside of it. There's a lot of very bad advise
> getting thrown around lately for things like Mastercoin, Counterparty,
> and for that matter, Colored Coins, to use a separate PoW blockchain or
> a merge-mined one. The fact is if you go with pure PoW, you risk getting
> attacked while your still growing, and if you go for merge-mined PoW,
> the attacker can do so for free. We've got a real-world example of the
> former with Twister, among many others, usually resulting in a switch to
> a centralized checkpointing scheme. For the latter we have Coiledcoin,
> an alt that made the mistake of using SHA256 merge-mining and got killed
> off early at birth with a zero-cost 51% attack. There is of course a
> censorship risk to going the embedded route, but at least we know that
> for the forseeable future doing so will require explicit blacklists,
> something most people here are against.

The "proof of publication vs separate chain" discussion is orthogonal
to the "merged mining vs independent chain" one.
If I remember correctly, last time you admitted after my example that
merged mining was comparatively better than a separate chain, that it
was economically harder to attack. I guess ecological arguments won't
help here, but you're confusing people developing independent chains
and thus pushing them to a less secure (apart from more wasteful
setup) system design.
Coiledcoin just proofs that merged mining may not be the best way to
bootstrap a currency, but you can also start separated and then switch
to merged mining once you have sufficient independent support.
As far as I can tell twister doesn't have a realistic reward mechanism
for miners so the incentives are broken before considering merged
mining.
Proof of work is irreversible and it's a good thing to share it.
Thanks Satoshi for proposing this great idea of merged mining and
thanks vinced for a first implementation with a data structure that
can be improved.

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?
It should be easier with the scamcoin ixcoin, with a much lower
subsidy to miners so I don't feel bad about the suggestion if your
"free attack" somehow works (certainly using some magic I don't know
about).

--=20
Jorge Tim=F3n

http://freico.in/