From: Peter Todd <pete@petertodd•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution
Date: Tue, 9 Apr 2013 23:03:01 -0400 [thread overview]
Message-ID: <20130410030301.GA9921@savin> (raw)
In-Reply-To: <CAAS2fgSkiqfhJxHJNw8i8G5yd1XY6tUTDynQ+AekbwmHP_jZmw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]
On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote:
Note how we can already do this: P2SH uses Hash160, which is
RIPE160(SHA256(d)) We still need a new P2SH *address* type, that
provides the full 256 bits, but no-one uses P2SH addresses yet anyway.
This will restrict data stuffing to brute forcing hash collisions. It'd
be interesting working out the math for how effective that is, but it'll
certainely be expensive in terms of time hashing power that could solve
shares instead.
> (1) Define a new address type, P2SH^2 like P2SH but is instead
> H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is
> a hash of a P2SH address.
>
> (2) Make a relay rule so that to relay a P2SH^2 you must include
> along the inner P2SH address. All nodes can trivially verify it by
> hashing it.
>
> (2a) If we find that miners mine P2SH^2 addresses where the P2SH
> wasn't relayed (e.g. they want the fees) we introduce a block
> discouragement rule where a block is discouraged if you receive it
> without receiving the P2SH^2 pre-images for it.
>
> With this minor change there is _no_ non-prunable location for users
> to cram data into except values. (and the inefficiency of cramming
> data into values is a strong deterrent in any case)
>
> The same thing could also be done for OP_RETURN PUSH value outputs
> used to link transactions to data. Make the data be a hash, outside of
> the txn include the preimage of the hash.
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-04-10 3:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 2:53 Gregory Maxwell
2013-04-10 3:03 ` Peter Todd [this message]
2013-04-10 3:08 ` Peter Todd
2013-04-10 15:58 ` Jorge Timón
2013-04-11 11:27 ` Peter Todd
2013-04-10 6:53 ` Peter Todd
2013-04-10 7:15 ` Gregory Maxwell
2013-04-10 7:29 ` Peter Todd
2013-04-10 3:52 ` Robert Backhaus
2013-04-10 3:58 ` Gregory Maxwell
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=20130410030301.GA9921@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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