Peter Todd [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 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
--
'peter'[:-1]@petertodd.org
0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140322/fad79c8c/attachment.sig>;
š Original message: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
--
'peter'[:-1]@petertodd.org
0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140322/fad79c8c/attachment.sig>;