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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WSYVx-0001JX-M8 for bitcoin-development@lists.sourceforge.net; Tue, 25 Mar 2014 21:04:05 +0000 Received: from mail-pa0-f49.google.com ([209.85.220.49]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WSYVw-00074j-QD for bitcoin-development@lists.sourceforge.net; Tue, 25 Mar 2014 21:04:05 +0000 Received: by mail-pa0-f49.google.com with SMTP id lj1so966448pab.8 for ; Tue, 25 Mar 2014 14:03:59 -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:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pmOlTaFyAeBszPxq/zvtgNvEPPK80ro/OV2JFldRahQ=; b=EfMLYS9bdavbei/PXjHHPW7uFpQXBpX6rPfKcshpJncUsCFyx5+rWivHDs1xhKxC7w 12ZkM+g/BjhhUHIsq5QAtSdRwABYTXzWteiPs/tMnVEOjlSRT8XYe0ydgCTOH/aGtxDE hycb5SIF+F1M4QemEONBPLd6hy1e2M5vSuzTMCuAX6eUiCGVnnUmSS1HarAgJ7tDWltO 7RaFHLYSWyhyHgvXjqNtKeHVQv06l/V10lh9ZIPYZJrwFXHTQlQKdXgIrS7BlXFDB39J S+gXohQHVZpLM2WiukaqDn86omToBpS40EOjZVFnrWEkfkC8j8L1fb94p68lJTXIcFoj T+QA== X-Gm-Message-State: ALoCoQkhqPv+1Euk+nXJIgM/jojVMcfuGEs7KlifKfWPFlfbU8nDJwxlk2suTK+6dhiGKcHk32mJ X-Received: by 10.68.201.226 with SMTP id kd2mr13528960pbc.157.1395781438901; Tue, 25 Mar 2014 14:03:58 -0700 (PDT) Received: from [192.168.127.190] ([207.86.76.198]) by mx.google.com with ESMTPSA id ix6sm42478113pbd.66.2014.03.25.14.03.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 14:03:58 -0700 (PDT) Message-ID: <5331EF3D.4000504@monetize.io> Date: Tue, 25 Mar 2014 14:03:57 -0700 From: Mark Friedenbach Organization: Monetize.io Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Todd References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop> <20140322190825.GB6047@savin> <532DE7E6.4050304@monetize.io> <20140325122851.GA9818@savin> In-Reply-To: <20140325122851.GA9818@savin> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 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: 1WSYVw-00074j-QD Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Tree-chains preliminary summary 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: Tue, 25 Mar 2014 21:04:06 -0000 I'm afraid I'm going to be the jerk that requested more details and then only nitpicks seemingly minor points in your introduction. But its because I need more time to digest the contents of your proposal. Until then: > But moving value between chains is inconvenient; right now moving > value requires trusted third parties. Two-way atomic chain transfers > does help here, but as recent discussions on the topic showed there's > all sorts of edge cases with reorganizations that are tricky to > handle; at worst they could lead to inflation. This isn't true. The re-org issue is fairly handled in the 2-way pegging scheme that Greg Maxwell developed and Adam Back described a week ago on this list. Depending on the implementation it could even be configurable by the person performing the peg too - allowing the transfer to specify the confirmation depth required during the quieting period in order to protect against re-orgs up to a sufficient depth. I think this is worked out quite well with sufficient enumeration of edge cases, and I don't think they are particularly tricky to handle or lead to money-losing situations under the explicit security assumptions. More importantly, to your last point there is absolutely no way this scheme can lead to inflation. The worst that could happen is theft of coins willingly put into the pegging pool. But in no way is it possible to inflate the coin supply. I will look at your proposal in more depth. But I also think you should give 2-way pegging a fair shake as pegging to side chains and private accounting servers may eliminate the need.