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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RrSoV-0000cC-1O for bitcoin-development@lists.sourceforge.net; Sun, 29 Jan 2012 11:20:51 +0000 X-ACL-Warn: Received: from nm40.bullet.mail.ne1.yahoo.com ([98.138.229.33]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1RrSoU-0006j1-Ab for bitcoin-development@lists.sourceforge.net; Sun, 29 Jan 2012 11:20:50 +0000 Received: from [98.138.90.55] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2012 11:20:44 -0000 Received: from [98.138.87.10] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jan 2012 11:19:44 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 29 Jan 2012 11:19:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 548274.40284.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 18461 invoked by uid 60001); 29 Jan 2012 11:19:44 -0000 X-YMail-OSG: oZ3jxjkVM1mDi2cU6oVAlvRAmWQuo0DgNL3VULcGjb2rmQQ EAY2nr4r_6y3NcuNwCqwMPPjWFcRGqvtKsdh7uqAuMeMegav3n67vkm30f7i TUUIy4XhZrvbdx2YFI5apR8JgLP7lMeTTIOKhQeZRZZd.1ir9UJeXbp1r6q5 3.NiPvP1_qLXn54cXh0PTbk2WVOXYQmoY11q27_SrDggfDetpPurDDyO_rYk b.gynrCArz_K3pzQl9BhbowrFSLUfsGOMsU6jKTvqsPebpDFXQFR6gr3JlMy iS0G2n5LOIgA9cYstnUq2TNJXtqh0k69f47BVXpSpwPs1sbYWZXof6r10Q3t 4GsgWTpfNADrnINmFI0i6FofWTRRCl8m35sBGIjBH_HSnlmtTbUxL72hNhRA rnPXjK5Ccliz6Pu.w76M_ Received: from [92.20.138.208] by web121002.mail.ne1.yahoo.com via HTTP; Sun, 29 Jan 2012 03:19:44 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com> <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com> Message-ID: <1327835984.12365.YahooMailNeo@web121002.mail.ne1.yahoo.com> Date: Sun, 29 Jan 2012 03:19:44 -0800 (PST) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.229.33 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.4 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RrSoU-0006j1-Ab Subject: [Bitcoin-development] Fw: Quote on BIP 16 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 11:20:51 -0000 (oops sorry greg- replied to you by mistake)=0A=0AThat 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.=0A=0AThat is the example quoted on the f= orums:=0A57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7= vVhaPaBE7Hr=0A=0A=0ACould it be a mistake?=0A=0A=0A----- Original Message -= ----=0AFrom: Gregory Maxwell =0ATo: Amir Taaki =0ACc: "bitcoin-development@lists.sourceforge.net" =0ASent: Sunday, January 29, 2012 5:19 AM=0AS= ubject: Re: [Bitcoin-development] Quote on BIP 16=0A=0AOn Sat, Jan 28, 2012= at 11:52 PM, Amir Taaki wrote:=0A> How could you have = a 70 byte long address without a P2SH scheme? Is this a mistake?=0A=0A...= =A0 No it's not a mistake.=A0 P2SH _prevents_ needing long addresses.=0A=0A= Lets unpack the acronym "pay to script _hash_".=A0 Hashes only need to=0Abe= 128-256 bits in size or so to have acceptable security, so you=0Adon't nee= d something longer than that for paying to a hash.=0A=0ANote that gavin is = saying 70 characters, not bytes.=0A=0AWithout some form of P2SH then only w= ay for you to make a personal=0Achoice of asking people to pay to a two-fac= tor protected account or=0Atwo a multiparty trust that manages the finances= of an organization=0Ais using some form of "P2S", pay-to-script.=0A=0AIn o= ther words, you'd have to have an address that encodes a full=0Ascript spec= ification for the sender to pay to,=A0 instead of just=0Aencoding its hash.= =A0 As a result these addresses would be much longer=0A(and potentially ver= y long).=0A=0AThe minimum size of a two address involving encoded script wo= uld be on=0Athat order, but they get bigger quite quickly if you add more o= ptions=0Ato the script (actually 70 sounds quite small, it should be more l= ike=0A100 for a minimum two pubkey script).=0A=0AIn addition to the unworka= bility of very long addresses as described=0Aby gavin (amusingly I am unabl= e to copy and paste the quoted example=0Ain one go) a P2S solution has seve= ral problems which you might=0Aconsider more or less important:=0A=0A=0A(1)= They are highly vulnerable to invisible substitution.=A0 E.g. I can=0Atriv= ially take a P2S address, change one or two characters and get a=0Ascript w= hich is redeemable by anyone.=A0 With P2SH you have to do=0Acomputation whi= ch is exponential in the number of unchanged digits to=0Aget a look alike a= ddress.=0A=0A(2) The sender is fully responsible for fees related to the en= larged=0Atransactions. Even if _you're_ willing to take the txn-processing = time=0Aand fee burden of a 30 person joint trust address,=A0 random e-comme= rce=0Asites will not be and will randomly reject your addresses.=0A=0A(3) T= hey create another input vector for non-trivial data which must=0Abe inspec= ted and validated, potentially presenting an attack surface.=0A=0A(4) They = leave the complicated (long) release rules in the transaction=0Aoutputs.=A0= When a transaction is mined we can't be sure if it will ever=0Abe redeemed= . The outputs are unprunable.=A0=A0 In a future world where=0Amany nodes pr= une output space is far more important than input space=0Aand it would make= sense to require more fees for it because we're=0Anever sure how long it w= ould need to be stored (making it an=0Aattractive target for someone who wa= nts to make Bitcoin unusable by=0Aspamming it with worthless data).=A0 P2SH= reduces output sizes to the=0Aabsolute minimum without inflating the total= data size.