From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RrNER-0000K5-BK for bitcoin-development@lists.sourceforge.net; Sun, 29 Jan 2012 05:23:15 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.175 as permitted sender) client-ip=209.85.216.175; envelope-from=etotheipi@gmail.com; helo=mail-qy0-f175.google.com; Received: from mail-qy0-f175.google.com ([209.85.216.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76) id 1RrNEQ-0001qv-HF for bitcoin-development@lists.sourceforge.net; Sun, 29 Jan 2012 05:23:15 +0000 Received: by qcha6 with SMTP id a6so1745508qch.34 for ; Sat, 28 Jan 2012 21:23:09 -0800 (PST) Received: by 10.229.76.26 with SMTP id a26mr4841157qck.126.1327814587815; Sat, 28 Jan 2012 21:23:07 -0800 (PST) Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net. [76.111.108.35]) by mx.google.com with ESMTPS id m20sm26138856qaj.14.2012.01.28.21.23.06 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 21:23:06 -0800 (PST) Message-ID: <4F24D7C1.3070106@gmail.com> Date: Sun, 29 Jan 2012 00:23:13 -0500 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <1327812740.41242.YahooMailNeo@web121002.mail.ne1.yahoo.com> <1327813841.99379.YahooMailNeo@web121006.mail.ne1.yahoo.com> In-Reply-To: <1327813841.99379.YahooMailNeo@web121006.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) 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 (etotheipi[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.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RrNEQ-0001qv-HF 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:23:15 -0000 It certainly wouldn't hurt if there was a way to use OP_MULTICHECKSIG with hash160 values instead... I doubt that's workable, though. At the moment, I feel that the copy&paste size problem is much smaller than the risk we take implementing such a huge change to the network. I almost feel like, we should have multi-sig in place, thoroughly tested and available, as something to fall back on if something goes wrong with BIP 13/16/17 after implementation. After all, I've been promoting the idea of considering the "cost" to fixing an erroneous/insecure implementation, as consideration for the proposals at hand. But gmaxwell has expressed some compelling reasons why plain multi-sig might be abused, which maybe suggests we don't want it ever considered standard...? I guess I'm not really promoting one thing or another, but I feel like copy&pasting is not a big deal (after all, it exists to moving large amounts of data around). Then of course, I use home-shift-end all the time, and regular users may not be so adept at copying long strings. -Alan On 01/29/2012 12:10 AM, Amir Taaki wrote: > 2 compressed pubkeys > > > ----- Original Message ----- > From: Amir Taaki > To: "bitcoin-development@lists.sourceforge.net" > Cc: > Sent: Sunday, January 29, 2012 4:52 AM > Subject: [Bitcoin-development] Quote on BIP 16 > > Gavin said: > "Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr > (or possibly even longer) > > I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable." > > How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development