diff options
| author | Nick ODell <nickodell@gmail.com> | 2016-01-04 11:04:29 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-01-04 18:04:31 +0000 |
| commit | 7e831762830d5fc8e6ec6f8b484e8c78933e8700 (patch) | |
| tree | 506fd726dd24de0f290be8fceb4d169aa8809763 | |
| parent | 3e9e6e6927306a7550becdc9f608d527afee4c5f (diff) | |
| download | pi-bitcoindev-7e831762830d5fc8e6ec6f8b484e8c78933e8700.tar.gz pi-bitcoindev-7e831762830d5fc8e6ec6f8b484e8c78933e8700.zip | |
Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
| -rw-r--r-- | b8/53a2b0d26280944fd95610770a0474a06662ac | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/b8/53a2b0d26280944fd95610770a0474a06662ac b/b8/53a2b0d26280944fd95610770a0474a06662ac new file mode 100644 index 000000000..fb0210adb --- /dev/null +++ b/b8/53a2b0d26280944fd95610770a0474a06662ac @@ -0,0 +1,152 @@ +Return-Path: <nickodell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 1747DEF0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 4 Jan 2016 18:04:30 +0000 (UTC) +Received: by mail-yk0-f175.google.com with SMTP id x67so255390840ykd.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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> + <CAKJqnrGUKeUb7g4SrjnWNAcPZOuLDKB-kjP2+Jy8Rdk_MfWLyQ@mail.gmail.com> + <814e1ba765445a4c3b7364c471299393@openmailbox.org> + <CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com> + <3b3d9102043577785d1b1679704eabfd@openmailbox.org> +Date: Mon, 4 Jan 2016 11:04:29 -0700 +Message-ID: <CANN4kme78DzknfOY_kOG0Bo+v16O1McxznCi4VPq5p9HxgzuKw@mail.gmail.com> +From: Nick ODell <nickodell@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 +<bitcoin-dev@lists.linuxfoundation.org> wrote: +> On 2016-01-03 02:46, Marco Falke wrote: +>> +>> 2015-12-30 17:27 GMT+01:00 <joe2015@openmailbox.org>: +>>> +>>> 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 + |