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 1WepNN-0006kJ-FJ for bitcoin-development@lists.sourceforge.net; Mon, 28 Apr 2014 17:29:57 +0000 Received: from mail-pa0-f43.google.com ([209.85.220.43]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WepNL-00080h-TZ for bitcoin-development@lists.sourceforge.net; Mon, 28 Apr 2014 17:29:57 +0000 Received: by mail-pa0-f43.google.com with SMTP id rd3so4199878pab.16 for ; Mon, 28 Apr 2014 10:29:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qX4k6KCcWpMzzBVRRwwS+q/4gmL445vieM9vgQAqH2w=; b=my962vA5lCCYwq4EoxpW2xokIygQiVmpVnSk96lTLjj98QUUh4u1tWDvF9THIo7rj8 IbEM+jV/uok4Fm3Pw/mbdaJSMHlkZT//Y1Y27qlrIw+TSx/a7jDfpAPb1vEGxNg58lv1 zrawXlOwrbuGUFjD+TPU445QG8MEiTIzPVEfqTwEqVpY8AiMIsu+CRl2EA1yMDT2duCb pXqq436GZYPtg8EI1UuywLkxztxsq8FLBzEoo49i0GubYl4y68elOCsiOvfNZq8c9FxW +7uPcpRHzaolasUYIPGuiHe1hWyqcmXN+7mBP3aZvQMI29KDdAyax08rQ3rqRatKorKv GB9g== X-Gm-Message-State: ALoCoQlAVBE+P+KEzI+7RpKpitlHSlkq0kkh+GuB4yWyFdGMmQVl+6a7h9D9qJxXiGh3n6DFMQOG X-Received: by 10.66.122.1 with SMTP id lo1mr27109582pab.118.1398706189840; Mon, 28 Apr 2014 10:29:49 -0700 (PDT) Received: from [192.168.127.213] (50-0-36-93.dsl.dynamic.sonic.net. [50.0.36.93]) by mx.google.com with ESMTPSA id kl1sm36237234pbd.73.2014.04.28.10.29.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 10:29:48 -0700 (PDT) Message-ID: <535E900A.90407@monetize.io> Date: Mon, 28 Apr 2014 10:29:46 -0700 From: Mark Friedenbach Organization: Monetize.io Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <535C587F.90005@certimix.com> <535C60C8.5030605@monetize.io> <535C6DEC.9040505@certimix.com> <535CA722.1000704@monetize.io> <535CF9BB.5010209@certimix.com> <535D38E9.60209@monetize.io> <535E6681.6000509@certimix.com> In-Reply-To: <535E6681.6000509@certimix.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WepNL-00080h-TZ Subject: Re: [Bitcoin-development] About Compact SPV proofs via block header commitments 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: Mon, 28 Apr 2014 17:29:57 -0000 On 04/28/2014 07:32 AM, Sergio Lerner wrote: > So you agree that: you need a periodic connection to a honest node, but > during an attack you may loose that connection. This is the assumption > we should be working on, and my use case (described in > http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/) > assumes that. No, that's sortof tangential. What you are solving is some higher level application on top of SPV proofs, compact or otherwise. SPV proofs have many broad applications, such as 2-way pegs where proof-of-work is used to reach consensus over the most-work side-chain header, and a non-51% attack is detectable from observed difficulty and interblock times. Do you need an honest peer to learn about the best chain? Yes. Do you need to *trust* that you have an honest peer? No, because a non-51% attack against you is probabilistically detectable with existing tools. Maybe SmartSPV is useful, maybe not. The application domain is not something I've been concerned with in the past. But what you describe is a higher-level protocol that uses block headers to determine which chain to trust. My simple point from the start has been that you can use back-link commitments and compact SPV proofs to accomplish what you want fewer messages, less bandwidth, and equal security. The two proposals are not in conflict with each other.