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 1747DEF0 for ; Mon, 4 Jan 2016 18:04:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56ECC183 for ; Mon, 4 Jan 2016 18:04:30 +0000 (UTC) Received: by mail-yk0-f175.google.com with SMTP id x67so255390840ykd.2 for ; Mon, 04 Jan 2016 10:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Zj1ysUqDH0FoeAAvttz73CIYZ5Am6WPmuEYR9ivgHDI=; b=JHv6Nzi0illdfIpRWOhpWQMSNlKfwsV+CsRJFjzbYjPV2G4e2PHQDTJwiWQTJqRfL5 pcq/LlHUWTQJTA76F4vENMxRf6FdqQdaZW1PhpCMibHBlvAvMHAycLBeznDc4PFx64sc KFRIxvYsfnP8U8iOvNsSQVYUaQtVq2RKJFOSuI9MFpxOzevgvJ/eg7m6mCPXkceQfyvr 30fszStbgt4lpGjLWc05rIMwwu6BLqekC5NDkgoYmb1F7lb8CCTpUtzdo3yFuV4+xs7f H9nwveULk1Uy5s7zkWhc0A7/NyWDnY8ZLatTXTd3SjMnPlVSBqjWUzIYmdgiO/j9b5Cb RelA== MIME-Version: 1.0 X-Received: by 10.129.50.12 with SMTP id y12mr62638668ywy.305.1451930669661; Mon, 04 Jan 2016 10:04:29 -0800 (PST) Received: by 10.129.32.86 with HTTP; Mon, 4 Jan 2016 10:04:29 -0800 (PST) In-Reply-To: <3b3d9102043577785d1b1679704eabfd@openmailbox.org> References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org> <814e1ba765445a4c3b7364c471299393@openmailbox.org> <3b3d9102043577785d1b1679704eabfd@openmailbox.org> Date: Mon, 4 Jan 2016 11:04:29 -0700 Message-ID: From: Nick ODell To: joe2015@openmailbox.org, bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Mon, 04 Jan 2016 18:08:00 +0000 Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork. 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: Mon, 04 Jan 2016 18:04:31 -0000 How are you collecting fees from the transactions in the block? On Sat, Jan 2, 2016 at 8:51 PM, joe2015--- via bitcoin-dev wrote: > On 2016-01-03 02:46, Marco Falke wrote: >> >> 2015-12-30 17:27 GMT+01:00 : >>> >>> On 2015-12-30 18:33, Marco Falke wrote: >>>> >>>> >>>> This is an interesting approach but I don't see how this is a soft >>>> fork. (Just because something is not a hard fork, doesn't make it a >>>> soft fork by definition) >>>> Softforks don't require any nodes to upgrade. [1] >>>> Nonetheless, as I understand your approach, it requires nodes to >>>> upgrade. Otherwise they are missing all transactions but the coinbase >>>> transactions. Thus, they cannot update their utxoset and are easily >>>> susceptible to double spends... >>>> >>>> Am I missing something obvious? >>>> >>>> -- Marco >>>> >>>> >>>> [1] https://en.bitcoin.it/wiki/Softfork#Implications >>> >>> >>> >>> It just depends how you define "softfork". In my original write-up I >>> called >>> it a "generalized" softfork, Peter suggested a "firm" fork, and there are >>> some suggestions for other names. Ultimately what you call it is not >>> very >>> important. >>> >>> --joe. >> >> >> joe, indeed it is not important how you call it, but please, let's not >> call it "soft fork". > > > This kind of fork (whatever it is called) has all the traditional properties > of a softfork except meaningful backwards compatibility for non-upgraded > clients. So I think it is reasonable to call it a softfork with some > qualification. > >> Besides my initial question about the coinbase >> tx, I was also wondering how non-updated nodes would verify the >> collected fees without the actual txs at hand. (They only have the >> coinbase tx, don't they?) > > > Yes this appears to be an oversight in my proof-of-concept implementation. > The unintended consequence being that all transactions would have to be > zero-fee... > > The simplest fix would be make the new rules add the fees implicitly. There > are other solutions. > >> Moreover, I can't see the benefits over a hard fork. A hard fork is >> much cleaner in regard to code changes. As one of the intends of >> "generalized soft forks" is to force user to update, at least a hard >> fork doesn't lie about the fact. Am I missing any obvious advantages >> of a "generalized soft fork" over a "clean" hard fork? > > > A "firm soft fork" also does not lie about that fact -- you must upgrade. I > don't see it dishonest if it was never claimed otherwise. > > I agree that hardforks can be "cleaner". > > However the obvious disadvantage of a hardfork is the risk of the network > splitting between upgraded and non-upgraded clients. This is not a problem > if there is 100% consensus behind the hardfork, but I am not sure if 100% is > realistically achievable for contentious issues such as the blocksize limit. > > If 100% consensus is never achieved, then the options are: > 1. Never upgrade and keep the blocksize limit unchanged forever. > 2. Use a firm softfork to resolve the deadlock. > 3. Hardfork anyway and split the network. > > My argument is simply that 2 is better than 3 and possibly 1. > > --joe > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev