From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4DFB0C0177 for ; Sun, 5 Apr 2020 18:24:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 49BBC86418 for ; Sun, 5 Apr 2020 18:24:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haQ3ogw3bxM3 for ; Sun, 5 Apr 2020 18:24:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by whitealder.osuosl.org (Postfix) with ESMTPS id 2BEAF863CC for ; Sun, 5 Apr 2020 18:24:43 +0000 (UTC) Date: Sun, 05 Apr 2020 18:24:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1586111080; bh=Z5K90NuDQFkHcYA7Uu7DLrwtxxrd5r6PCC6G6iskUnI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=YpwApIkBQEENOFREOAndHKt4mtB6Hs1aqwVpVGOeOD7mlKu3ITfXYB3fDR/AKY0Gz D9mOqQOEPgyaxdDZfUVHrIDFGgqP1oWUCNt2ZYcflYj9hd69oTt3B4YOjjgcb50OWA gsXz0MtgtAjz7tsuwlaZa9CfR6Rufx5FaC8sbCBI= To: Bob McElrath , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20200405141717.GN28113@mcelrath.org> References: <20200331103508.asvxujkhtifj6n7i@ganymede> <20200405141717.GN28113@mcelrath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tom Trevethan Subject: Re: [bitcoin-dev] Statechain implementations X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2020 18:24:45 -0000 Good morning Bob, > Note that this attack requires collaboration with the current UTXO owner. > Generally if there's some form of address/payment request, the current ho= lder is > trying to transfer the UXTO to some other (non-statechain) entity, and he= knows > the target of the transfer, and participates in the protocol to authorize= it. > The current holder must obtain the target pubkey for the transfer out-of-= band > with respect to the SE, or the SE can MITM that. > > It's a stated security assumption that the sender or receiver do not coll= ude > with the SE. If either do, then your attack is generally possible and all= bets > are off. So what you've described is simply the SE colluding with the rec= eiver. > The receiver will already receive the UTXO, so the receiver here is assis= ting > the SE in stealing his (the receiver's) funds, or the SE has done a MITM = on the > transfer. Various improvements including blind signing, a SE-federation, = etc > are valuable to consider to mitigate this. But the SE must be prevented, = one way > or another, from "buying the UTXO". The SE cannot be allowed to be both o= perator > of the SE and a customer of it, as this clearly violates the no-receiver > collusion principle. > > "Adding a new user key" doesn't change the situation. There's already a u= ser key > involved, and the user has already acquiesced to the transfer. Acquiescin= g with > two keys doesn't change anything. The point is not that acquiescing with two keys is possible. Instead, the point is that any past owner of the coin can collude with the = statechain authority (who, in the new scheme, must be trusted to delete old= keys), or anyone who manages to get backups of the statechain authority ke= ys (such as by digging for backups in a landfill), in order to steal the on= chain funds, regardless of who the current owner is, within the statechain. Thus an amount of trust must still be put in the statechain authority. So I think the security assumptions should be that: * The statechain authority really does delete keys and does not make backup= s. * No *past* or *current* owner of the coin colludes with the statechain aut= hority. * I think saying merely "sender" is not sufficient to capture the actual = security assumption here. Regards, ZmnSCPxj