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 1Vcmcl-0006om-QP for bitcoin-development@lists.sourceforge.net; Sun, 03 Nov 2013 01:37:07 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.169 as permitted sender) client-ip=209.85.212.169; envelope-from=allen.piscitello@gmail.com; helo=mail-wi0-f169.google.com; Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vcmck-0005Iw-02 for bitcoin-development@lists.sourceforge.net; Sun, 03 Nov 2013 01:37:07 +0000 Received: by mail-wi0-f169.google.com with SMTP id cb5so680817wib.0 for ; Sat, 02 Nov 2013 18:36:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.221.38 with SMTP id qb6mr6985953wic.8.1383442619794; Sat, 02 Nov 2013 18:36:59 -0700 (PDT) Received: by 10.194.85.112 with HTTP; Sat, 2 Nov 2013 18:36:59 -0700 (PDT) In-Reply-To: <201311030127.43010.luke@dashjr.org> References: <20131102050144.5850@gmx.com> <201311030033.56983.luke@dashjr.org> <201311030127.43010.luke@dashjr.org> Date: Sat, 2 Nov 2013 20:36:59 -0500 Message-ID: From: Allen Piscitello To: Luke-Jr Content-Type: multipart/alternative; boundary=001a1134d2daeb8c9204ea3bd5e5 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: dashjr.org] -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 (allen.piscitello[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 X-Headers-End: 1Vcmck-0005Iw-02 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Message Signing based authentication 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, 03 Nov 2013 01:37:08 -0000 --001a1134d2daeb8c9204ea3bd5e5 Content-Type: text/plain; charset=ISO-8859-1 Required vs. strongly recommended is an important distinction. Satoshi Dice reuses EC Keys for every single transaction. Exchanges will have the same address you deposit in over and over, which gets reused. This is a best practice argument rather than a protocol requirement. On Sat, Nov 2, 2013 at 8:27 PM, Luke-Jr wrote: > On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote: > > I actually had a use case in my case where it was possible, and that was > > the check I used to get around it, just configured it so that I always > > generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx. > > It was either that or making sure I had no unspent outputs. The use > case > > of doing it was laziness in just creating a single key. > > Use cases mean an actual use, not mere laziness. Bitcoin as a system has > always required a unique EC key (and address) for each transaction. > > Luke > --001a1134d2daeb8c9204ea3bd5e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Required vs. strongly recommended is an important distinct= ion. =A0Satoshi Dice reuses EC Keys for every single transaction. =A0Exchan= ges will have the same address you deposit in over and over, which gets reu= sed. =A0This is a best practice argument rather than a protocol requirement= .


On Sat, Nov 2= , 2013 at 8:27 PM, Luke-Jr <luke@dashjr.org> wrote:
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello = wrote:
> I actually had a use case in my case where it was possible, and that w= as
> the check I used to get around it, just configured it so that I always=
> generated a new key when I needed to set up a 2 of 2 Multisig Refund T= x.
> =A0It was either that or making sure I had no unspent outputs. =A0The = use case
> of doing it was laziness in just creating a single key.

Use cases mean an actual use, not mere laziness. Bitcoin as a system = has
always required a unique EC key (and address) for each transaction.

Luke

--001a1134d2daeb8c9204ea3bd5e5--