path: root/4c/1a7de966068a0a5f3bdb9d0c0be732969cee4a

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 9E67EDE1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Sep 2018 17:35:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com
	[209.85.221.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C88817E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Sep 2018 17:35:36 +0000 (UTC)
Received: by mail-wr1-f45.google.com with SMTP id v90-v6so12324433wrc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Sep 2018 10:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-transfer-encoding;
	bh=D5rQpqcNXCiqNdc3tESqKXCrnqxiKXuSiXjBTah7C6w=;
	b=NyIQfS2V57vkWBwGcTA0Ckp1ojKjAzDj1Hk94AJAQ6FVBbdaUy6Ny/vWmV9vdXLW95
	JtGDitZGb3eqSuSqxyWAwbu87ESr8i3IhmfEVtDEB9dg9qUe4ou52cMsdFebr6c/yUD1
	mhwZrdyeXilvPE2XbzRv/XqxUncQceHHhHy3R9M/8znC9ykzDdbU9D/wxhn0dcRjY0UT
	h4jIs8n2Bak/Zl73LHTW4oBvKQjnAcNcTnbzMHvTSs/Q+czuhRsml3X6qhzMAXHh+ph6
	17lMLYsZ37RglYzG0F+59tUTpCURE5bYH5zAe1JPsJn6aNjjw2BN8l4wLHJaBb+Iha72
	JvdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc:content-transfer-encoding;
	bh=D5rQpqcNXCiqNdc3tESqKXCrnqxiKXuSiXjBTah7C6w=;
	b=k/ULfmlYySEXDgUXc68xaqUDkDl/cTFyuCaAPnLoWOBPWJhrW6o8L62KI47j9KQUla
	OLvbxzPyjmtMFfkBCBnYiAE7V5W8qH2UvtPwWFz437J9JaKfrCA9m9GF5hJMf+yp1gYj
	UbnpwzWI3Tz9/GFooQ6fdzu7fFzvgB8YAoTEI+uelIR/KcEdf0HXSq5Iv2/75WTS4P7U
	e3TzpEnswedN1sZmrQyBuNcaNiLAilW9wdnFYNguNyPkRoqyJJU9xNw/E3SRMcqFgBLz
	AtVTFCHsk1vs41wuH0q3aMno5KNlRx7B4R2EGptA8x73aOEqIdxlNaIDRf9Cw7rHFBMY
	1KVQ==
X-Gm-Message-State: APzg51D6BuQSuTiOwFWOhwzHCWNbDOLBE3hwCx2d8CIO0Oq51UMln/xz
	mQ4QQMEUj5kQrcqX7KBL0918lFBAih5okgRGGsM=
X-Google-Smtp-Source: ANB0VdZkji0fVLySs04MSMxztlU0mnfOgornYkimKUVBQ7XgyxECUzE0LgMcVMiD29MYUKrZI8ijPeidT3PsxE0+g+o=
X-Received: by 2002:adf:e6c2:: with SMTP id y2-v6mr3332144wrm.35.1536255335459;
	Thu, 06 Sep 2018 10:35:35 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjbnsqHwW=Oj7n_WJFR4vp1ND78NgV0=Ftj5doNuKOxLCg@mail.gmail.com>
	<PS2P216MB0179E804329D495A4EE6F4EC9D010@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB0179E804329D495A4EE6F4EC9D010@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 7 Sep 2018 02:35:24 +0900
Message-ID: <CAPv7TjawW9Z0frbjzfWe3y04V7zM1hdmUeJYjNLOtJnWVhZZ0w@mail.gmail.com>
To: willtech@live.com.au
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: Thu, 06 Sep 2018 17:39:36 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [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: Thu, 06 Sep 2018 17:35:37 -0000

Hi Damian,

>Where you say "create transactions which are only valid if they are mined =
on top of a specific block." - in practice, does that usually means at any =
height above a specific block?

Those details aren't important for the point I was trying to make.
BIP115 allows the transaction to be mined at any height, which is
probably as far as you can take this, realistically. What I think
you'll find in practice, is that the more specific you are in how you
want your transaction to be mined, the higher the chance that your
transaction will inadvertently become unmineable.

A perhaps more general point that I realized after posting, is that
fee pressure towards censorship resistance happens naturally if the
system provides anonymity. If the target transaction that miners wish
to censor is indistinguishable from other anonymous transactions, then
miners will have no choice but to censor every anonymous transaction,
so the end result is very similar to what I imagined linking
transactions would do.

-- Ruben Somsen
On Thu, Sep 6, 2018 at 5:48 PM Damian Williamson <willtech@live.com.au> wro=
te:
>
> Humour me please,
>
>
> Where you say "create transactions which are only valid if they are mined=
 on top of a specific block." - in practice, does that usually means at any=
 height above a specific block?
>
> ________________________________
> From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@=
lists.linuxfoundation.org> on behalf of Ruben Somsen via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org>
> Sent: Sunday, 2 September 2018 3:26:54 AM
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Guiding transaction fees towards a more censorship=
 resistant outcome
>
> 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 get=
s
> added. To the network, there=E2=80=99s a shared benefit: all fees add to =
the
> 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://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A=
%2F%2Fgithub.com%2Fbitcoin%2Fbips%2Fblob%2Fmaster%2Fbip-0115.mediawiki&amp;=
data=3D02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435=
aaaaaaaaaaaa%7C1%7C0%7C636716143839246019&amp;sdata=3Dreq4KYOcztXLAG%2Fu4Rr=
mhLREGBF28JNTe45pO86kRd4%3D&amp;reserved=3D0
>
> ** Coinjoin: https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%=
3A%2F%2Fbitcointalk.org%2Findex.php%3Ftopic%3D279249.0&amp;data=3D02%7C01%7=
C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1=
%7C0%7C636716143839246019&amp;sdata=3Dd%2B06jxrKubWhLwoInFEgo8eHvI9f1j74QN8=
WH7xrVos%3D&amp;reserved=3D0
>
> *** Risk sharing principle:
> https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithu=
b.com%2Flibbitcoin%2Flibbitcoin%2Fwiki%2FRisk-Sharing-Principle&amp;data=3D=
02%7C01%7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaa=
aaaaa%7C1%7C0%7C636716143839246019&amp;sdata=3DNA3HxqI5PnuyaI9hyCaw0rcaFsrh=
D%2FXQB8biWJXej8g%3D&amp;reserved=3D0
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://apc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists=
.linuxfoundation.org%2Fmailman%2Flistinfo%2Fbitcoin-dev&amp;data=3D02%7C01%=
7C%7C48403f77efc14613e89b08d611f5980c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C=
1%7C0%7C636716143839246019&amp;sdata=3D9P7UetPmKWngjgjNPE0%2BAMgdzuL2DgqBLo=
Lti82f23M%3D&amp;reserved=3D0