From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E09BA279 for ; Wed, 10 Aug 2016 04:31:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f196.google.com (mail-qt0-f196.google.com [209.85.216.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79257263 for ; Wed, 10 Aug 2016 04:31:23 +0000 (UTC) Received: by mail-qt0-f196.google.com with SMTP id u25so1273370qtb.3 for ; Tue, 09 Aug 2016 21:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LKJ112x0LIaZYWBT0RdA/kJ1vAkxQLH5HuacvUhQhSU=; b=fYFh7+NJrMJwC/bGN+io/zoXNzuJIApaOZWmPJPXRE7F3CZXGdWqqzPuAkMh6NeOti uBvl+UhiyyoJdmAphn7Hr7cfYvXYUhb4kGXodcY141NdgGsAJlTQWenKvUdy0P8aeXQQ ZfJni4VdLgHW1pQQY0iPvusT2nVNtLB2TIDcpOtd5WoyBt9NM/z31nJXsYHTuiTc0xu6 mOf2IyyNFnPxkwpHNwGmQ1o9VJmxUEMLXLxIt+MEnYvqt2nFNKj+4hbaZqLluzuAdIWe jUcedpTg8aK71YOpzN0xhVm1rmozYnlxglrxtYw2RRv34trOIy3msNpxr0Dxr0xJTUQh aVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LKJ112x0LIaZYWBT0RdA/kJ1vAkxQLH5HuacvUhQhSU=; b=XbgYZYKhgfOGTbhFuJR5iLMkQ8j0Mf59oowYJem6FjrUjm6pVhaNzl+mBLwpRdgzbP IFFoKCItamFozNF+tcO+JDO0c+6foxTud6CDGCrtHlgrTeiSzA2L+/4d0gEVcHZTdztf YS2zQsFsSeKSvEqI94Rx2jKmS93TJsMC1JKNlJGcnWsH7WWrJO8d0zhOXO4xfgzswkyS 7G9m4HF9bZMjJgn6UUXaygRSXmkdXwk33cUTedLwjR6+e+w8qxN1JSpw6RFBW/L+lPXf DtGQ2rB69DTodxp/Tx9g6OVkRZn+TqJq1G9g0flAvoUuh5cViNav4+lZdpJlNV8kvvhw weTg== X-Gm-Message-State: AEkoousiqzxfNH2TDOi8j0nRxvEpr4/y5db6dAFDHo/TxTHhav/hfomIO6bAW5SdzROykeQYIsLon0aT/je2Yg== X-Received: by 10.200.39.61 with SMTP id g58mr2080281qtg.129.1470803482638; Tue, 09 Aug 2016 21:31:22 -0700 (PDT) MIME-Version: 1.0 References: <20160808154707.GB2196@banane.informatik.uni-ulm.de> In-Reply-To: From: James MacWhyte Date: Wed, 10 Aug 2016 04:31:11 +0000 Message-ID: To: tony.991@gmail.com Content-Type: multipart/alternative; boundary=001a1135aa2a1e00950539b01fc7 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Hiding entire content of on-chain transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 04:31:24 -0000 --001a1135aa2a1e00950539b01fc7 Content-Type: text/plain; charset=UTF-8 Signed by the key pair that was referenced in the output of the on-chain transaction? (Bob in my example, actually) Doesn't that mean it's easy to follow who is paying whom, you just can't see how much is going to reach recipient? On Tue, Aug 9, 2016, 04:40 Tony Churyumoff wrote: > This troll is harmless. A duplicate spend proof should also be signed > by the same user (Alice, in your example) to be considered a double > spend. > > 2016-08-09 3:18 GMT+03:00 James MacWhyte : > > One more thought about why verification by miners may be needed. > > > > Let's say Alice sends Bob a transaction, generating output C. > > > > A troll, named Timothy, broadcasts a transaction with a random hash, > > referencing C's output as its spend proof. The miners can't tell if it's > > valid or not, and so they include the transaction in a block. Now Bob's > > money is useless, because everyone can see the spend proof referenced and > > thinks it has already been spent, even though the transaction that > claims it > > isn't valid. > > > > Did I miss something that protects against this? > > > --001a1135aa2a1e00950539b01fc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Signed by the key pair that was referenced in the output o= f the on-chain transaction? (Bob in my example, actually) Doesn't that = mean it's easy to follow who is paying whom, you just can't see how= much is going to reach recipient?

On Tue, Aug 9, 2016,= 04:40 Tony Churyumoff <tony991@gmail.com> wrote:
This troll is harmless.=C2=A0 A duplicate spend proof should also be s= igned
by the same user (Alice, in your example) to be considered a double
spend.

2016-08-09 3:18 GMT+03:00 James MacWhyte <macwhyte@gmail.com>:
> One more thought about why verification by miners may be needed.
>
> Let's say Alice sends Bob a transaction, generating output C.
>
> A troll, named Timothy, broadcasts a transaction with a random hash, > referencing C's output as its spend proof. The miners can't te= ll if it's
> valid or not, and so they include the transaction in a block. Now Bob&= #39;s
> money is useless, because everyone can see the spend proof referenced = and
> thinks it has already been spent, even though the transaction that cla= ims it
> isn't valid.
>
> Did I miss something that protects against this?
>
--001a1135aa2a1e00950539b01fc7--