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 08C9593E for ; Thu, 30 Mar 2017 10:04:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A3BEF86 for ; Thu, 30 Mar 2017 10:04:16 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 9875438ABEA2; Thu, 30 Mar 2017 10:04:07 +0000 (UTC) X-Hashcash: 1:25:170330:bitcoin-dev@lists.linuxfoundation.org::beOGcagKM63+gZLH:/ZVj X-Hashcash: 1:25:170330:natanael.l@gmail.com::1KJ1YCnCIrmDC/lc:vGgS From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Natanael Date: Thu, 30 Mar 2017 10:04:05 +0000 User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201703301004.06489.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 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: Thu, 30 Mar 2017 10:04:17 -0000 On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote: > You want to really make sure your transaction gets processed quickly? > Transactions could have a second fee type, a specially labeled > anyone-can-spend output with an op_return value defining a "best-before" > block number and some function describing the decline of the fee value for > every future block, such that before block N the miners can claim the full > expedience fee + the standard fee (if any), between block N+1 and N+X the > miner can claim a reduced expedience fee + standard fee, afterwards only > the standard fee. Minor detail: OP_RETURN doesn't work like that. You'd need OP_DROP. > When a transaction is processed late such that not the full expedience fee > can be claimed, the remainder of the expedience fee output is returned to > the specified address among the inputs/outputs (could be something like > in#3 for the address used by the 3rd UTXO input). This would have to be > done for all remaining expedience fees within the last transaction in the > block, inserted there by the miner. Inputs don't have addresses, and addresses should only ever be used once. You might be able to fix this by increasing the value of the change, though. It would require a new signature-check opcode at the very least. I don't see a purpose to this proposal. Miners always mine as if it's their *only* chance to get the fee, because if they don't, another miner will. Ie, after 1 block, the fee effectively drops to 0 already. > --- > > Fee pool. Softfork compatible. The standard problem with these is that miners are incentivised to publish their own "out of band fee" address so they get all the fee directly. Luke