Troy Benjegerdes [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-22 📝 Original message:On Sat, Mar 22, 2014 at ...
📅 Original date posted:2014-03-22
📝 Original message: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.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
📝 Original message: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.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash