From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RrNB8-0007SL-PL for bitcoin-development@lists.sourceforge.net; Sun, 29 Jan 2012 05:19:50 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.175 as permitted sender) client-ip=209.85.220.175; envelope-from=gmaxwell@gmail.com; helo=mail-vx0-f175.google.com; Received: from mail-vx0-f175.google.com ([209.85.220.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RrNB8-0004n2-3a for bitcoin-development@lists.sourceforge.net; Sun, 29 Jan 2012 05:19:50 +0000 Received: by vcbfk26 with SMTP id fk26so2873901vcb.34 for ; Sat, 28 Jan 2012 21:19:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.150.206 with SMTP id z14mr6692859vcv.5.1327814384679; Sat, 28 Jan 2012 21:19:44 -0800 (PST) Received: by 10.220.141.211 with HTTP; Sat, 28 Jan 2012 21:19:44 -0800 (PST) In-Reply-To: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com> References: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com> Date: Sun, 29 Jan 2012 00:19:44 -0500 Message-ID: From: Gregory Maxwell To: Amir Taaki Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.0 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.6 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RrNB8-0004n2-3a Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Quote on BIP 16 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 05:19:50 -0000 On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki 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.