summaryrefslogtreecommitdiff
path: root/46/4285c5c0369e785d58eece0417013085736051
blob: ce874ada28ed1920210f4984e050f42dfdd1ffbe (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@monetize.io>) id 1WYKmH-00075t-Ae
	for bitcoin-development@lists.sourceforge.net;
	Thu, 10 Apr 2014 19:36:49 +0000
Received: from mail-pd0-f175.google.com ([209.85.192.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WYKmG-000516-4X
	for bitcoin-development@lists.sourceforge.net;
	Thu, 10 Apr 2014 19:36:49 +0000
Received: by mail-pd0-f175.google.com with SMTP id x10so4277425pdj.20
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 10 Apr 2014 12:36:42 -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=ZVTsUkdeqD10ZHuJ26iavzF1qkprjGQmFtz3i+8RPVY=;
	b=Ywam8yOBcnyG6F90rI52H8mMMZcNFm9+mJXJj0WGMlc5i+5efj7/pXnD4mJGZixiHN
	S7US2NLSP+5U5D2wndPc7Egu3IvWiq1h1VZ8mLu6ERx6n/dynJKrahp5CfvozLytWobE
	HqPIX/3NN5ZLfRQp8kSyP0lrKRG0Dqx5IL8CsLz1SOB2OSDG17jbqJPzFqjM+FTCsspK
	VsHEgHQiRBvQSOpNFpdGaBpX61ei+dcsBW9BuVAnsfR0tOJpUhsW2Ly5id28YhF5pAAk
	yfg2cYRaYulV5CY1o3jkj3pm18hgMQ1kkkOPH79erbM8r1kD8c+cOPb7DK9Rj0iuAbKM
	9ScQ==
X-Gm-Message-State: ALoCoQmdUOI3vPeiD/x1FPaXOyxgV89egzCjdk+d/gmGaAIc4bBigmq0plK2Jr3R7C/SQotDyq7B
X-Received: by 10.67.14.98 with SMTP id ff2mr21814871pad.101.1397158602137;
	Thu, 10 Apr 2014 12:36:42 -0700 (PDT)
Received: from [192.168.127.226] (50-0-36-93.dsl.dynamic.sonic.net.
	[50.0.36.93]) by mx.google.com with ESMTPSA id
	om6sm10816796pbc.43.2014.04.10.12.36.40
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 10 Apr 2014 12:36:41 -0700 (PDT)
Message-ID: <5346F2C7.1050809@monetize.io>
Date: Thu, 10 Apr 2014 12:36:39 -0700
From: Mark Friedenbach <mark@monetize.io>
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: <CANEZrP04O7EqB=TqyTiC7O1K2A9R0nKJ_ssANHKg=Byum8-LtA@mail.gmail.com>	<CA+s+GJDbYjwhpsV15a+7kCO_vTstEewVrwvqbnB=a5zOSwFC6Q@mail.gmail.com>	<CAAS2fgStmEpiUV4Yh-qqu6sZ+VZ5SiQPwp+QA=3X5zR52ia3OA@mail.gmail.com>	<CA+s+GJBxEC2MifJQY5-vn2zSOHo-UOm8B1vYHHOfuxq26=VscQ@mail.gmail.com>	<CAADm4BDDJkS_xdjUn=2Yzs4B0RXTvpzpd5Z_kDRorzrn1HWSng@mail.gmail.com>	<CANEZrP1rPZYkTLmx5GOdj67oQAgFjeaF-LCKAXpg5XsEhXYFuQ@mail.gmail.com>	<CAADm4BB8y=k_f7CG3tyX6ruWF0w3+hU2Szv7ajLp1x7KhS56GA@mail.gmail.com>	<CAPg+sBg88Q1Ddwsvuk3-17wO=0DF7L1wtxx4mWUoiV1=cWKhEQ@mail.gmail.com>
	<CADu7o8PD4Wkgx_X_aOHXHe8UA-OE9v5YZ4boMrX7LDVu6agfpQ@mail.gmail.com>
In-Reply-To: <CADu7o8PD4Wkgx_X_aOHXHe8UA-OE9v5YZ4boMrX7LDVu6agfpQ@mail.gmail.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.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [209.85.192.175 listed in list.dnswl.org]
X-Headers-End: 1WYKmG-000516-4X
Subject: Re: [Bitcoin-development] Chain pruning
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 19:36:49 -0000

You took the quote out of context:

"a full node can copy the chain state from someone else, and check that
its hash matches what the block chain commits to. It's important to
note that this is a strict reduction in security: we're now trusting
that the longest chain (with most proof of work) commits to a valid
UTXO set (at some point in the past)."

The described synchronization mechanism would be to determine the
most-work block header (SPV level of security!), and then sync the UTXO
set committed to within that block. This is strictly less security than
building the UTXO set yourself because it is susceptible to a 51% attack
which violates protocol rules.

On 04/10/2014 11:19 AM, Paul Rabahy wrote:
> You say UTXO commitments is "a strict reduction in security". If UTXO
> commitments were rolled in as a soft fork, I do not see any new attacks
> that could happen to a person trusting the committed UTXO + any
> remaining blocks to catch up to the head.
> 
> I would imagine the soft fork to proceed similar to the following.
> 1. Miners begin including UTXO commitments.
> 2. Miners begin rejecting blocks with invalid UTXO commitments.
> 3. Miners begin rejecting blocks with no UTXO commitments.
> 
> To start up a fresh client it would follow the following.
> 1. Sync headers.
> 2. Pick a committed UTXO that is deep enough to not get orphaned.
> 3. Sync blocks from commitment to head.
> 
> I would argue that a client following this methodology is strictly more
> secure than SPV, and I don't see any attacks that make it less secure
> than a full client. It is obviously still susceptible to a 51% attack,
> but so is the traditional block chain. I also do not see any sybil
> attacks that are strengthened by this change because it is not modifying
> the networking code.
> 
> I guess if the soft fork happened, then miners began to not include the
> UTXO commitment anymore, it would lower the overall network hash rate,
> but this would be self-harming to the miners so they have an incentive
> to not do it.
> 
> Please let me know if I have missed something.