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 A85797F for ; Thu, 13 Aug 2015 23:42:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4D54B31 for ; Thu, 13 Aug 2015 23:42:18 +0000 (UTC) Received: by pdrh1 with SMTP id h1so24819510pdr.0 for ; Thu, 13 Aug 2015 16:42:18 -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-type:content-disposition:in-reply-to; bh=D+LbEQdClBVfSQJUZ1VKwUrcv22POjzyXc/PHdy/xxU=; b=UmwoSG/1jXYHDcwTRtFhz4SmvewxKNckfAX86NHzsMZ4Vhj82z0O4eTVLE3G2UuXBI DuYRJCwjApjDbiQebWmpzUHxR7fERC4mOCw2/HP4PMP9M5KTIedsacRIvw9Fz7o9HGmq st2zbU5zC3lUWZ13+MQOAsQXc+P6CSBnICi3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=D+LbEQdClBVfSQJUZ1VKwUrcv22POjzyXc/PHdy/xxU=; b=HcQuGfhJ+ZKB11VDSZqviczf0uqncWXhWN02zU5oKnMtHdpbLdT+Brgd28g1bpI3lJ /cVmko7oXtG16rF8IPNO2TPm8W8yMeyCiuGjo+hZidWKTdEpDmBJ8bSpTqExkjPY669N WvM67TZ2QhK5G0BrUhh6D0er5gb4IihwvjSnYqGS5lhv693Ks+xyXcuyws6/UpNjVCH4 yOjNFJxeHIiR8ABWFK7nA3mVuD5qtR5N8bOGknoC8mT3eiDvkzYMcpCh/qEc390ax0Y+ t2WTiOQbPJ2Cn8nfRAncy8btXHCtKefXBwLQPLVKZ9QJlbGSXgfpkrQyUg39VR4oXgc4 h5Wg== X-Gm-Message-State: ALoCoQnmbRz5t1UrS9R8sPyG69T0kwOJhGiE0c4R9pmcXJZT8aXn7czxeYtGQdgw/+32p7BmD293 X-Received: by 10.70.20.5 with SMTP id j5mr82343843pde.40.1439509338052; Thu, 13 Aug 2015 16:42:18 -0700 (PDT) Received: from localhost (70-36-197-138.dsl.dynamic.fusionbroadband.com. [70.36.197.138]) by smtp.gmail.com with ESMTPSA id mb10sm3875118pdb.91.2015.08.13.16.42.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2015 16:42:17 -0700 (PDT) Date: Thu, 13 Aug 2015 16:42:13 -0700 From: Joseph Poon To: Btc Drak Message-ID: <20150813234213.GH2123@lightning.network> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 23:42:18 -0000 Very cool! This will certainly help make Lightning Network testable on the main-chain and permit channels to remain open indefinitely. I'm looking forward to it. On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote: > // Note that unlike CHECKLOCKTIMEVERIFY we do not need to > // accept 5-byte bignums since any value greater than or > // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected > // anyway. This limitation just happens to coincide with > // CScriptNum's default 4-byte limit with an explicit sign > // bit. I haven't tested the details of this, but is there another bit available for use in the future for the relative blockheight? I strongly believe that Lightning needs mitigations for a systemic supervillan attack which attemps to flood the network with transactions, which can hypothetically be mitigated with something like a timestop bit (as originally suggested by gmaxwell). Summary: If a block is flagged as timestopped (whether automatically or by vote or other mechanism), then an auxillary blockheigh is frozen and does not increment. This auxillary blockheight is only used for accounting in timestopped height computation (and isn't used for anything else). So as the real blockheight increments, the auxillary blockheight can sometimes stop and stay the same. If a transaction has a timestop bit enabled, then the transaction's OP_CSV relative height is dependent upon the auxillary height, not the real block height. This allows for a large backlog of transactions which must occur before a particular (relative) block height to enter into the blockchain. I'm not sure if it's out of scope, but it could make sense to consider the possibility for additional state(s) with relative height computation today. Ideally, there'd be some kind of "version" byte which can be recontextualized into something later, but I don't know how that could cleanly fit into the data structure/code. -- Joseph Poon