From: Mark Friedenbach <mark@monetize•io>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
Date: Sat, 22 Mar 2014 10:04:30 -0700 [thread overview]
Message-ID: <532DC29E.4080304@monetize.io> (raw)
In-Reply-To: <20140322150836.GG3180@nl.grid.coop>
Please, by all means: ignore our well-reasoned arguments about
externalized storage and validation cost and alternative solutions.
Please re-discover how proof of publication doesn't require burdening
the network with silly extra data that must be transmitted, kept, and
validated from now until the heat death of the universe. Your failure
will make my meager bitcoin holdings all the more valuable! As despite
persistent assertions to the contrary, making quality software freely
available at zero cost does not pay well, even in finance. You will not
find core developers in the Bitcoin 1%.
Please feel free to flame me back, but off-list. This is for *bitcoin*
development.
On 03/22/2014 08:08 AM, 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.
>
next prev parent reply other threads:[~2014-03-22 17:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-22 8:47 Peter Todd
2014-03-22 13:53 ` Jorge Timón
2014-03-22 19:34 ` Peter Todd
2014-03-22 20:12 ` Jorge Timón
2014-03-23 23:17 ` Troy Benjegerdes
2014-03-23 23:53 ` Mark Friedenbach
2014-03-24 20:34 ` Troy Benjegerdes
2014-03-24 20:57 ` Mark Friedenbach
2014-03-25 22:10 ` Troy Benjegerdes
2014-03-26 1:09 ` kjj
2014-03-22 15:08 ` Troy Benjegerdes
2014-03-22 17:04 ` Mark Friedenbach [this message]
2014-03-22 19:08 ` Peter Todd
2014-03-23 22:37 ` Troy Benjegerdes
[not found] ` <532DE7E6.4050304@monetize.io>
2014-03-25 12:28 ` [Bitcoin-development] Tree-chains preliminary summary Peter Todd
2014-03-25 12:45 ` Gavin Andresen
2014-03-25 13:49 ` Peter Todd
2014-03-25 15:20 ` Mike Hearn
2014-03-25 16:47 ` Peter Todd
2014-03-25 17:37 ` Jeff Garzik
2014-03-25 18:02 ` Alan Reiner
2014-03-25 18:13 ` slush
2014-03-25 19:47 ` Peter Todd
2014-03-25 21:41 ` Troy Benjegerdes
2014-03-25 20:40 ` Ricardo Filipe
2014-03-25 22:00 ` Troy Benjegerdes
2014-03-26 10:58 ` Peter Todd
2014-03-25 12:50 ` Peter Todd
2014-03-25 21:03 ` Mark Friedenbach
2014-03-25 22:34 ` Gregory Maxwell
2014-03-27 16:14 ` Jorge Timón
2014-03-28 15:10 ` Troy Benjegerdes
2014-04-17 21:41 ` Tier Nolan
2014-03-26 10:48 ` Peter Todd
2014-08-03 17:23 ` Gregory Sanders
2014-03-24 21:17 ` [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=532DC29E.4080304@monetize.io \
--to=mark@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox