Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60645910 for ; Sat, 30 Sep 2017 03:56:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6CF441E for ; Sat, 30 Sep 2017 03:56:00 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id w23so759582vkw.2 for ; Fri, 29 Sep 2017 20:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DRXioQnq0Whr1BEHutamoOChmpIQLt6KECo7Rq4/5oM=; b=RbP/qJH/jOmmSL7GOrYSRYEQ6jbSdooSfmp0LMYiVALqGIdkY1OiIwk7rh2tj/pi29 mE2DNdjG1JCsaO41SzRJhYc5/wwfwHYfQ0INOIpYs6OQLcoibEL2RV+B0vfgKaFucpma zPQnvgEKP/DaM6++5fyAsJ0aA1fYv4GPg/qzcGliwwH1lw8muS9G5eyBY+utKtDS2N4e IDIFEbZvOMhu74weOCbiXUhGj1w+fSgETcDiGebSSON22n7B0P73P4/E1fNLpsxxSXi8 GOvPGWEqD32vX5/j+OGCR8znmUsfKvWCiFhTSy4Lv1OtO6PXPyuCZE3MgJQsehVzV5Q1 P4vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DRXioQnq0Whr1BEHutamoOChmpIQLt6KECo7Rq4/5oM=; b=ENIfQsP2CKdMtmflwsmFo9cld04glIUbB0gTLSMWgo6x1YAno/8lGvzwHOAIw9QOaH fY1+cGWa0x5IA6PSNsVrjv6rXoTWsxr6PUsRsHXL67Han0sJKtcznRwkLoRcFYHdyGjW Nsb5cGXxjcKAqYhyHEFinU5gmjuCKBTGTZxngiCE3ylXCzdaQqgzcB+rOHCZXpwnteeA DpdUir+Bn+Sq5DH5jPTNpw8pj0bzu9e/ETk8ar4WLKKl7wlT71SX82NKh9tU2llVQn4W gXsVbaCFDjpajwZSeU4Zz2G1h0l9sSSfEC+r+1iAT/oNJg+g4QZPRoQBnlrmQdNYEzPp pTdA== X-Gm-Message-State: AHPjjUimXZEMwMdjqMVvx1sMQB1hthtFNo0kAfU8sIM0D4/VYxKhv0mx q/pNVZHXSMwg4h+nH3VRwgt55m0ureklZjxpw9tNdQ== X-Google-Smtp-Source: AOwi7QDtHC836duAWeKdq8RWEwvXia8n50hj6ieveIcbioQQ8qMeuq0aJLZXOABL8TfrMJKQU2lRsHi044CP9zZd1T8= X-Received: by 10.31.110.1 with SMTP id j1mr5162539vkc.156.1506743759780; Fri, 29 Sep 2017 20:55:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.79.199 with HTTP; Fri, 29 Sep 2017 20:55:58 -0700 (PDT) Received: by 10.31.79.199 with HTTP; Fri, 29 Sep 2017 20:55:58 -0700 (PDT) In-Reply-To: References: <5F7A4F74-B108-4E30-A3F4-4125BBD0F819@friedenbach.org> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Sat, 30 Sep 2017 05:55:58 +0200 Message-ID: To: Mark , Bitcoin Dev Content-Type: multipart/alternative; boundary="94eb2c14a38491edca055a601eb5" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Daniele Pinna Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets 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: Sat, 30 Sep 2017 03:56:01 -0000 --94eb2c14a38491edca055a601eb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gmaxwell I think what's new is that in this case, with a single tx you would take out all txs with fee below 1 btc. With current rules, you would only remove enoguh txs for that one to fit, not empty the whole block and mine only a block with that single tx. On 30 Sep 2017 5:53 am, "Jorge Tim=C3=B3n" wrote: > I really don't see how this "outlier behaviour" can be prevented. I think > it would be the norm even with your proposed "fix". Perhaps I'm missing > something too. > > On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> This is correct. Under assumptions of a continuous mempool model however >> this should be considered the outlier behavior, other than a little bit = of >> empty space at the end, now and then. A maximum fee rate calculated as a >> filter over past block rates could constrain this outlier behavior from >> ever happening too. >> >> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna >> wrote: >> > >> > Maybe I'm getting this wrong but wouldn't this scheme imply that a >> miner is incentivized to limit the amount of transactions in a block to >> capture the maximum fee of the ones included? >> > >> > As an example, mined blocks currently carry ~0.8 btc in fees right now= . >> If I were to submit a transaction paying 1 btc in maximal money fees, th= en >> the miner would be incentivized to include my transaction alone to avoid >> that lower fee paying transactions reduce the amount of fees he can earn >> from my transaction alone. This would mean that I could literally clog t= he >> network by paying 1btc every ten minutes. >> > >> > Am I missing something? >> > >> > Daniele >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --94eb2c14a38491edca055a601eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gmaxwell I think what's new is that in this case, wit= h a single tx you would take out all txs with fee below 1 btc. With current= rules, you would only remove enoguh txs for that one to fit, not empty the= whole block and mine only a block with that single tx.

On 30 Sep 2017 5:53 am, "J= orge Tim=C3=B3n" <jtimon@jtimon.cc> wrote:
I really don't see = how this "outlier behaviour" can be prevented. I think it would b= e the norm even with your proposed "fix". Perhaps I'm missing= something too.

On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" &l= t;bitcoin-dev@lists.linuxfoundation.org> wrote:
This is correct. Under assumptions = of a continuous mempool model however this should be considered the outlier= behavior, other than a little bit of empty space at the end, now and then.= A maximum fee rate calculated as a filter over past block rates could cons= train this outlier behavior from ever happening too.

> On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna@gmail.com> wrote= :
>
> Maybe I'm getting this wrong but wouldn't this scheme imply th= at a miner is incentivized to limit the amount of transactions in a block t= o capture the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now= . If I were to submit a transaction paying 1 btc in maximal money fees, the= n the miner would be incentivized to include my transaction alone to avoid = that lower fee paying transactions reduce the amount of fees he can earn fr= om my transaction alone. This would mean that I could literally clog the ne= twork by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
--94eb2c14a38491edca055a601eb5--