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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <rsomsen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E08986A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Sep 2018 17:27:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com
[209.85.221.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C065A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Sep 2018 17:27:07 +0000 (UTC)
Received: by mail-wr1-f50.google.com with SMTP id w11-v6so13957196wrc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Sep 2018 10:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=19GSTAHWdCM7c3jgKznFSGESgVZ4NhraOaFKVQTg/BY=;
b=EDPDPd2wehF2KQylrTM3H6xYCDl0lVClXpXrVRhCpiNBdMESVM/PT78rZmg67ygejc
EARIF/ZsLrxqXrTGv0NYRwzk0NsWQjB4v4hPKtCC6TFY1Agq1RqDGFwIKYjr6rsBRMB+
W4T/D0TEGGlyFmbCng+VAumH2o8CUlP+OfZxzUhFdW9OWCPYa9GlNQ+uhQWDbvlohkoT
KEUAYuyTP4Nck9NwQQHaeLtLzokZtOd24KNSSWV+foRUiG2xMkapDMajvw7s9upKWNaj
bPTxEqzl8zZ8t6wZcSVCQYdJe87+6vXR9/ZtxP9kLD1k69EG9VDnyJeOPoV3AffLRFIG
IuQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=19GSTAHWdCM7c3jgKznFSGESgVZ4NhraOaFKVQTg/BY=;
b=bJhSUNavGwk7KMTnWr81XXW5q75WE2TOntFZK3iJuyp0wGWgQFIdWzHLaM8jQOeoqj
fEA1JSiuXfz9uo8qDkt2kMrgLzzVEapWAf0miVbrE2LL0o+xuBQcjwwWrIFdOQ0iDdJU
baeH1JvfEIa6mVvMXjNErZlRwA6jogJ05bHH4uh6uHGA/HXBbrGkt647HYXpo6ptSRZV
4xh7SwSIaOicbynWx+DDB1SY1cin45F3i4fUGa7tAFPnnXpiUEkXL/VcLr9bdvYl/bX5
lMe6+NEiqEeZqYhJGvcRqI1PlNouiFuvzNVrS+V6hqApkYuTVGvYum1G9CY7E0b7F2r2
dF9w==
X-Gm-Message-State: APzg51AN0X+cubMJeno4cEgspQ1h4IWvlqmMs0Wn5Ku/+GDEkEE3USv+
+1X0pndVkpAB3TgGHZovz+8PK2nS8/p4QKNkH79VP5fX
X-Google-Smtp-Source: ANB0VdZkcaTodllno8eDK7J2aEpYj2xXllhwKHE07TuGolXL/YWy1ZejomCgQC9FfD6ZJhVS/+jZsVehqoiyUIYtYWk=
X-Received: by 2002:adf:e648:: with SMTP id
b8-v6mr14950454wrn.254.1535822826015;
Sat, 01 Sep 2018 10:27:06 -0700 (PDT)
MIME-Version: 1.0
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sun, 2 Sep 2018 02:26:54 +0900
Message-ID: <CAPv7TjbnsqHwW=Oj7n_WJFR4vp1ND78NgV0=Ftj5doNuKOxLCg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE 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, 03 Sep 2018 23:25:52 +0000
Subject: [bitcoin-dev] Guiding transaction fees towards a more censorship
resistant outcome
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: Sat, 01 Sep 2018 17:27:08 -0000
When a user creates a transaction with a fee attached, they are
incentivizing miners to add this transaction to the blockchain. The
task is usually not very specific -- as long as it ends up in a valid
chain with the most Proof-of-Work, miners get paid. The payment is an
incentive for miners to act in the way that users desire.
To the user, there=E2=80=99s an individual benefit: their transaction gets
added. To the network, there=E2=80=99s a shared benefit: all fees add to th=
e
security of other transactions in the chain. Miners can choose to
ignore the incentives, but they would be leaving money on the table
(and eventually get replaced by more competitive miners).
Transactions from Bitcoin Core are slightly more specific about what
they ask miners to do. Every transaction is only valid at a block
height that is one higher than the last block. This incentivizes
miners to build on top of the last block, instead of going back and
reorganizing the blockchain. This is especially important in a future
scenario where the fee reward is larger than the block reward.
BIP 115* by Luke-jr is even more specific. It enables users to create
transactions which are only valid if they are mined on top of a
specific block. While originally designed as a form of replay
protection, it actually serves as a deterrent for miners to reorganize
the blockchain. If they orphan a block, it will invalidate
transactions that demanded the inclusion of the orphaned block. This
increases the cost of intentionally reorganizing the blockchain.
Coinjoin**, the act of combining payments of multiple users into a
single transaction, can be seen as yet another method for users to be
more specific. The fate of their payments are now intertwined with
that of others. If miners wish to censor a single payment, they have
to reject the entire transaction, and the associated fee amount.
Techniques like mimblewimble simplify this process, by making coinjoin
non-interactive.
This brings us to a theoretical scenario where:
- every block contains only a single coinjoin transaction
- the validity of this transaction depends on the inclusion of a
specific previous block
- the block reward is negligible compared to transaction fees
In this scenario, if miners wish to undo a specific transaction that
happened two blocks ago, they would have to create three empty blocks
(receiving negligible compensation) in order to overtake the longest
chain. And even then, users can still refuse to let their new
transactions be mined on top of the empty blocks, disincentivizing
such behavior completely.
While not easy to achieve in practice (e.g. resolving natural forks
becomes more complicated), it demonstrates that users can become more
empowered than they are today, benefitting censorship resistance***.
It is this line of thinking that I wish to convey. Perhaps it may
inspire further ideas in this direction.
-- Ruben Somsen
* BIP 115: https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki
** Coinjoin: https://bitcointalk.org/index.php?topic=3D279249.0
*** Risk sharing principle:
https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle
|
