public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Amir Taaki <zgenjix@yahoo•com>
To: "bitcoin-development@lists•sourceforge.net"
	<bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Fw:  Quote on BIP 16
Date: Sun, 29 Jan 2012 03:19:44 -0800 (PST)	[thread overview]
Message-ID: <1327835984.12365.YahooMailNeo@web121002.mail.ne1.yahoo.com> (raw)
In-Reply-To: <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com>

(oops sorry greg- replied to you by mistake)

That address he gives is 77 characters/bytes (same thing). What I'm asking is how can it be so small. I know that it's encoding a script, but then I started trying to imagine what kind of script and to me it seems that 2 public keys are too large for those 77 characters when encoded.

That is the example quoted on the forums:
57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr


Could it be a mistake?


----- Original Message -----
From: Gregory Maxwell <gmaxwell@gmail•com>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Sunday, January 29, 2012 5:19 AM
Subject: Re: [Bitcoin-development] Quote on BIP 16

On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki <zgenjix@yahoo•com> wrote:
> How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?

...  No it's not a mistake.  P2SH _prevents_ needing long addresses.

Lets unpack the acronym "pay to script _hash_".  Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.

Note that gavin is saying 70 characters, not bytes.

Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of "P2S", pay-to-script.

In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to,  instead of just
encoding its hash.  As a result these addresses would be much longer
(and potentially very long).

The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).

In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:


(1) They are highly vulnerable to invisible substitution.  E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone.  With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.

(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address,  random e-commerce
sites will not be and will randomly reject your addresses.

(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.

(4) They leave the complicated (long) release rules in the transaction
outputs.  When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable.   In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data).  P2SH reduces output sizes to the
absolute minimum without inflating the total data size.



  parent reply	other threads:[~2012-01-29 11:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-29  4:52 [Bitcoin-development] " Amir Taaki
2012-01-29  5:10 ` Amir Taaki
2012-01-29  5:15   ` Luke-Jr
2012-01-29  5:23   ` Alan Reiner
2012-01-29  8:14     ` Gregory Maxwell
2012-01-29  5:19 ` Gregory Maxwell
     [not found]   ` <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com>
2012-01-29 11:19     ` Amir Taaki [this message]
2012-01-29 14:30       ` [Bitcoin-development] Fw: " Gavin Andresen
2012-01-29 14:40         ` 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=1327835984.12365.YahooMailNeo@web121002.mail.ne1.yahoo.com \
    --to=zgenjix@yahoo$(echo .)com \
    --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