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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WRRHe-0005o1-TY
for bitcoin-development@lists.sourceforge.net;
Sat, 22 Mar 2014 19:08:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.100 as permitted sender)
client-ip=62.13.148.100; envelope-from=pete@petertodd.org;
helo=outmail148100.authsmtp.co.uk;
Received: from outmail148100.authsmtp.co.uk ([62.13.148.100])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WRRHd-0001OZ-N4 for bitcoin-development@lists.sourceforge.net;
Sat, 22 Mar 2014 19:08:42 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2MJ81FT047219;
Sat, 22 Mar 2014 19:08:01 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2MJ7uU2023704
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sat, 22 Mar 2014 19:07:58 GMT
Date: Sat, 22 Mar 2014 15:08:25 -0400
From: Peter Todd <pete@petertodd.org>
To: Troy Benjegerdes <hozer@hozed.org>
Message-ID: <20140322190825.GB6047@savin>
References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf"
Content-Disposition: inline
In-Reply-To: <20140322150836.GG3180@nl.grid.coop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 4850dce2-b1f5-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAAUFVQGAgsB AmIbWl1eUFp7XGs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrA2F7 AVt7UBlwdAJGfDBx ZEJiWD5fVEF6IRUo
QFMGFDsDeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4rFzgw QxEEEn0qHEsIXW06
Ixs+Nl8bGg4eKEw5 PFU8XVYJexEVEG8W EkRHDSNVKlVJTC0t
Fg5cRlMFWCZMWjtR BwZgPB5BSjBVRyBc CQ5eUxwJByJDX25S
RS5ZWyYgSVI4Ykwn P0zM
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WRRHd-0001OZ-N4
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 19:08:43 -0000
--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote:
> On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd 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. Secondly I noticed a
> > overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
> > into account, making it possible to broadcast unminable transactions and
> > bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG
> > outputs given that the sigops limit and the way they use up a fixed 20
> > sigops per op makes them hard to do fee calculations for. They also make
> > it easy to bloat the UTXO set, potentially a bad thing. This would of
> > course require things using them to change. Currently that's just
> > Counterparty, so I gave them the heads up in my email.
>=20
> I've spend some time looking at the Datacoin code, and I've come to the=
=20
> conclusion the next copycatcoin I release will have an explicit 'data'=20
> field with something like 169 bytes (a bakers dozen squared), which will=
=20
> add 1 byte to each transaction if unused, and provide a small, but usable
> data field for proof of publication. As a new coin, I can also do a
> hardfork that increases the data size limit much easier if there is a
> compelling reason to make it bigger.
>=20
> I think this will prove to be a much more reliable infrastructure for=20
> proof of publication than various hacks to overcome 40 byte limits with
> Bitcoin.
>=20
> I am disclosing this here so the bitcoin 1% has plenty of time to evaluate
> the market risk they face from the 40 byte limit, and put some pressure to
> implement some of the alternatives Todd proposes.
Lol! Granted, I guess I should "disclose" that I'm working on tree
chains, which just improve the scalability of blockchains directly. I'm
think tree-chains could be implemented as a soft-fork; if applied to
Bitcoin the datacoin 1% might face market risk. :P
--=20
'peter'[:-1]@petertodd.org
0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91
--wq9mPyueHGvFACwf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTLd+lXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDBiYmNjNTMxZDQ4YmVhOGQ2NzU5N2UyNzViNWFiY2ZmMThl
MThmNDYyNjY3MjNlOTEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuR+wgAjq/dl/mF245u3CEvN6zbeuKb
sOZC/wSb5p2T2az0nXPHpkYsThiCTlCgczNo63bIRHfsHhxvILOunFpe7ZO9pTuL
XOvjOoagXi1RSfQCQZTOG9bCVKPiDXIy8LCbZ95VukmWjVHoikSbOTfzNs2qQJPR
q7XUj3ashnbSKvEsVc1B9DVRVmnpdLWAshxIXa5xp015WVDDMaIOI3+W4LxbkXg3
pD1PqsnjW/S66Y0LPIOu+MdPfJKKHQoIsnMAnarNw9kbuaOOM5VNAYnIpH5MbPEc
09OAzIAh3sFENRsuHyGj61cbzoTY4naE+Bwj5wlNsKu9t1rB+AIH7bQn8D1rIw==
=7rM+
-----END PGP SIGNATURE-----
--wq9mPyueHGvFACwf--
|
