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 7A0C3483 for ; Wed, 5 Apr 2017 16:24:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 59603E3 for ; Wed, 5 Apr 2017 16:24:22 +0000 (UTC) Received: by mail-pg0-f49.google.com with SMTP id g2so10350274pge.3 for ; Wed, 05 Apr 2017 09:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightning.network; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DqvmZqNIYAGyf/4XOUriRuTfZeXgAlgJS4LRqMKNRG0=; b=Nt9mcOiRWG4639Eqk6A+u9x/9JXwlTTLTTKYaW6uVs7rCI1iDOLd+5Vohk66Ytuvdh aKytuE5/hiEMTrTPuQj3PiWFCx89PwjGRmUQbiH+0WTdvXwiKwio/CXICjbh8jyDOns7 XRTx052dKQCuqIybVtukE56MoTuJ2UG7DTECA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DqvmZqNIYAGyf/4XOUriRuTfZeXgAlgJS4LRqMKNRG0=; b=tE4fLM+3Lf3dt5fejl/x3YiQaPajXroo5gTf/uEaMDR8dTfdU2gN4l4Iz7gcgGFcSB eUqBaMawFfKKV3Ii/kCazGxSQOmYDPc7sWxJls5kKv+g/BxjooBsqbcEOCrS8l/KqZPV S6JqDtZd3Pz2I2ny0mQsCXgv/TJX3IMvKwXEaoBqsXxYvZ4WGAmgDmR6Adv/FwrxCKLs QokCEupSztwKQxFSyb6/zOUDNNNh8HVfCtGQ/eon2i5thtcCqZ+4ATElwVnNcybjOTWU QJkx0VC3vO+sFjTiTaaPykZzLgbJ1rNWMwngN7DMUssJRnbEtbC6L68vZFZUQ0fxkaPs c3Aw== X-Gm-Message-State: AFeK/H0/h7jOUxtUEZXYKw711th3O59xlXX3ALUIXvwJBSBFnY9jebatcDqnAB2IF+BiOQ== X-Received: by 10.99.163.72 with SMTP id v8mr31701905pgn.115.1491409461876; Wed, 05 Apr 2017 09:24:21 -0700 (PDT) Received: from localhost ([205.185.122.187]) by smtp.gmail.com with ESMTPSA id 11sm38378491pgf.28.2017.04.05.09.24.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 09:24:20 -0700 (PDT) Date: Wed, 5 Apr 2017 09:25:31 -0700 From: Joseph Poon To: Greg Sanders , Bitcoin Protocol Discussion Message-ID: <20170405162531.GA16131@lightning.network> References: <201704041803.57409.luke@dashjr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al 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, 05 Apr 2017 16:24:23 -0000 On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote: > I'd appreciate the authors chiming in, but I read the PASDA differently: > > 1) If a transaction is mined with a certain bit set, it reserves 700 bytes > for that particular block. > 2) In that space, 2 transactions may happen: > a) First, a transaction penalizing the "parent" transaction for fraud by > spending the funds immediately > b) Second, a "free rider" transaction that penalizes fraud within a ~2 week > window > > This means during systematic flooding of closing transactions by > Goldfinger, vigilant watchers of their channels can immediately punish the > fraud in the same block using (a), and if they are unable to, need to find > space within two weeks in (b). > > This is really in the LN weeds however, so I'll refrain from evaluating the > efficacy of such a solution. Yes, that is correct. I haven't had a chance to review Laolu's summary yet, haven't had a chance to talk to him today since I was away from the keyboard for most of the day, would have been unable to review things. Section "b" above only allows for free riding on the first output of a transaction with the bit set within the past 2016 blocks. It does not allow free riding on outputs without that bit set in the transaction. Additionally, the presumption is that the attacker fills up the mempool with incorrect prior commitment transactions. The attack scenario is Mallory asks everyone to open a channel with her. Mallory only has 1 BTC. With sufficiently low tx fees, Mallory can use that one bitcoin to open many ~1 BTC channels. All of those channels had a prior state which Mallory had ~1 BTC, and a current state where she has none. She broadcasts these thousands of prior states where she has ~1 BTC. The presumption is the penalty transaction in many cases has a very small fee, since it is already covered by the commitment. This mitigates systemic goldfinger attacks since it is unlikely they can get enough transactions in. Additionally the transactions waiting on the mempool allows for many to be notified and fill up the first reserved space. The attacker would likely be attempting to fill up the mempool (longer block times help here with security!!!). It is presumed that there is some small amount in reserve so there is some fee reward covered for enforcing the penalty. This construction allows for the amount in reserve to be significantly smaller and much more resilient against even the largest of goldfinger attacks. (This isn't a full mitigation, as there are certain conditions related to miner-attacker coordination with high hashpower. Attacker-Miner coordination is presumed to be out-of-scope, especially in relation to 51% attacks, since it's sort of a moot point, if they have the funds to mount this attack so that it's profitable, it gets pretty close for them to have a very significant hashpower anyway.) I'll add a clarification to the specification on github soon. The intent of this is to reduce the cost of setting up LN channels with funds in reserve, with minimal code changes. Future changes which could be desired if this is usable would be use additional tx flag bits to select how many outputs in a transaction apply to enable a large payment of funds pending in-flight. -- Joseph Poon