summaryrefslogtreecommitdiff
path: root/42/17965e62f153b903ed1878f6f44b1f84230e17
blob: d4c2411e143f697ec1b47e4225aa0a03f2270781 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 08C9593E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Natanael <natanael.l@gmail.com>
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: <CAAt2M1_x8zbN-vmgDEUQQvzrtonEKydb+B-P53ibCimVfnd-CA@mail.gmail.com>
	<CAAt2M1-LZQ1yE1CezFA+hr+=de-RVJ7wzkq-t969BC7OL6dWwg@mail.gmail.com>
	<CAAt2M18Fx9LwKU385id0_gHunLa=uQUmCO+jGkvSqb_2uLeCyg@mail.gmail.com>
In-Reply-To: <CAAt2M18Fx9LwKU385id0_gHunLa=uQUmCO+jGkvSqb_2uLeCyg@mail.gmail.com>
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 <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: 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