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
|
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 <hozer@grid.coop>) id 1WRr1k-0004Xt-N8
for bitcoin-development@lists.sourceforge.net;
Sun, 23 Mar 2014 22:38:00 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WRr1j-0007s0-P5 for bitcoin-development@lists.sourceforge.net;
Sun, 23 Mar 2014 22:38:00 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Sun, 23 Mar 2014 17:37:52 -0500
id 000000000006A347.00000000532F6240.000012F4
Date: Sun, 23 Mar 2014 17:37:52 -0500
From: Troy Benjegerdes <hozer@hozed.org>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20140323223752.GL3180@nl.grid.coop>
References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop>
<20140322190825.GB6047@savin>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <20140322190825.GB6047@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WRr1j-0007s0-P5
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: Sun, 23 Mar 2014 22:38:00 -0000
On Sat, Mar 22, 2014 at 03:08:25PM -0400, Peter Todd wrote:
> 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.
> >
> > I've spend some time looking at the Datacoin code, and I've come to the
> > conclusion the next copycatcoin I release will have an explicit 'data'
> > field with something like 169 bytes (a bakers dozen squared), which will
> > 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.
> >
> > I think this will prove to be a much more reliable infrastructure for
> > proof of publication than various hacks to overcome 40 byte limits with
> > Bitcoin.
> >
> > 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
Soft-fork tree chains with reasonable data/memo/annotation storage would be
extremely interesting. The important question, however, is how does one
build a *business* around such a thing, including getting paid as a developer.
What I find extremely relevant to the **bitcoin-dev** list are discussions
about how to motivate the people who own the hashrate and bulk of the coins
(aka, the bitcoin 1%) to PAY DEVELOPERS, and thus it is good marketing FOR
BITCOIN DEVELOPERS to remind the people who profit from our efforts they need
to make it profitable for developers to work on bitcoin.
If it's more profitable for innovative developers to premine and release
$NEWCOIN-blockchain than it is to work on Bitcoin-blockchain, is that a valid
discussion for this list? Or do you just want to stick your heads in the sand
while VC's look to disrupt Bitcoin?
|
