path: root/16/d39d6f7c2e95f28ed7c55fd368869846164c1e

Return-Path: <m@ib.tc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C72F214AD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jul 2019 19:49:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com
	[209.85.128.66])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5ADE8AC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jul 2019 19:49:17 +0000 (UTC)
Received: by mail-wm1-f66.google.com with SMTP id f17so42645437wme.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jul 2019 12:49:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=Z0eUnniOeHraAxPwELqxnidHmGBBnN9MR8Kwm0hICZo=;
	b=QF86EljJPkaUTHbiri2H7XqT+8j/mk+5jHkLsnDt18EjMO9KKixZnom9gxH/uPuVsQ
	WTBwabYWEAbeQscfBol8oLklZvc/nfKRG4HfY1hxz2gxHNcGO+T543vOKRs/VYUkZ510
	4tB7/pVXmzKvcmvidJzhXs4uuZ2i9st0eDAtRZbegoHoQtwRKOZ7CdVKlGxM4XdHGpG9
	DD5z+/TLHTQrh3r/kZ+LUhFYe/WR4acWKsn6BmPI659twVNhMBw7RPK8eve4LdnGPUvc
	zl5hsGTVnI0lURPnonccSjfdbkMOwbsX30PAJVN+FfqnTritd4TqRREG3WTW8Ik6LDEi
	298Q==
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;
	bh=Z0eUnniOeHraAxPwELqxnidHmGBBnN9MR8Kwm0hICZo=;
	b=DBuvam9sQB0ZlVaygHyF5iAC3pdeEjVeNH5aqWMt9xJduVfWx1PEnGFtEViDO8esdW
	WaYUaa2hmhTAcFMIYe9NmKiqYa5VYHqTqbMeE4r9hqtPL87SjtbPnu67Ef9TyrNCMxEn
	BNEKVGBYE1CR+ZOD6bR/bQcs5PNUstJSqsfWtIe4+yfP5NbAh+N1Wr6hAh9csAloccn9
	c53TWTomvenzdtOLLzKBlfnBG68R9XoNnjwNGDl7S54SL8okIuK3M62xpwsKyVezUyK3
	EPmXDjsJseB0mVnY5mX+E29hX4YcDOVSKBfHxjPoYBNHm1ItsSFQM0n6OkJg/lCH2x5I
	rvHQ==
X-Gm-Message-State: APjAAAXAA6LwesLqSH9MFO3lIyPpJ2GVB/Fq5Da/BZcEe3+W0nfwXRky
	ZjIKzSp49OpPLX9n6ZhBiKBZ8nW2xWRrtxXxjK4=
X-Google-Smtp-Source: APXvYqwtLS/dg46EUMOhT1iwQJ2ts0R4lg2jyYiJjWVWvjJDrilqDRQ0fdaDFWtraIKmWA84/JnCrslZoKdF7j7jsQE=
X-Received: by 2002:a7b:ce8a:: with SMTP id q10mr71758558wmj.109.1563997756028;
	Wed, 24 Jul 2019 12:49:16 -0700 (PDT)
MIME-Version: 1.0
References: <CALFqKjQkQwuxjeYkGWO_Y_HhNQmJgrjqF3m04hbORV7FSbsi3Q@mail.gmail.com>
	<CAAQdECAyQB0E0PxwBOxXoEtQO_HU5b3JGQpsqp_OfB8dOKqiUQ@mail.gmail.com>
	<CALFqKjTHT7XaREK7ewwKKBjrZcty7ueNBMtSLEW7B-o9uwXgmw@mail.gmail.com>
	<CAAQdECAxdUvwSo2byukgevZF56gadMN1+P9cvH2wQMCVPrA38Q@mail.gmail.com>
In-Reply-To: <CAAQdECAxdUvwSo2byukgevZF56gadMN1+P9cvH2wQMCVPrA38Q@mail.gmail.com>
From: Mike Brooks <m@ib.tc>
Date: Wed, 24 Jul 2019 12:49:05 -0700
Message-ID: <CALFqKjQUWMjS7V0aj8E0zFdyf70mfnj26gfy40_Ec-o1N9tPPw@mail.gmail.com>
To: Yuval Kogman <nothingmuch@woobling.org>
Content-Type: multipart/alternative; boundary="000000000000ad9073058e729a5a"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	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, 25 Jul 2019 05:32:14 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References
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: Wed, 24 Jul 2019 19:49:18 -0000

--000000000000ad9073058e729a5a
Content-Type: text/plain; charset="UTF-8"

Fungibility is a good question for inductive reasoning.  After all, what is
a claim without some rigger?

There exists some set of wallets 'w' which contain a balance of satoshi too
small to recover because it doesn't meet the minimum transaction fee
required to confirm the transaction.  These wallets are un-spendable by
their very nature - and quantifying un-spendable wallets is one way to
measure the fungibility of Bitcoin.  The number of un-spendable wallets can
be quantified as follows:

   Let 'p' equal the current price/per-bit for a transaction
   Let 'n' equal the number of bits in the transaction
   Let '[a]' be the set of all wallets with a balance
   Let '[w]' be the set of un-spendable wallets
   [w0] = [a] > b*n

Now, let's introduce a savings measure 'k' which is a constant flat savings
per transaction.

   [w1] = [a] > b*(n - k0)

As the savings 'k' increase, the set of 'w' also increases in size.
   len([w0]) < len([w1]) ... < len([wk])

In this case 'k0' could be the savings from a P2PKH transaction to a 233
byte SegWit transaction, and 'k1' could be 148 byte SegWit+PubRef
transaction, and the same model can be used for some future transaction
type that is even smaller.   As the savings 'k' approaches infinity the set
of un-spendable wallets approaches zero.

If a user is privacy-aware, and chooses to use single-use p2sh for all
transactions, then these users can still gain from PubRef because
block-weight should be decreased for everyone. There are cases where a user
or merchant might want to reuse their p2sh hash - and PubRef can provide
savings.  Additionally, the resulting p2sh script could be a multi-sig
transaction which could still benefit from PubRef compression.  PubRef
improves fungibility of Bitcoin in two different ways - both reduced cost
of transaction and increasing the max number of transactions that are able
to be confirmed by a block. Which is pretty hot - QED.

On Fri, Jul 19, 2019 at 3:48 PM Yuval Kogman <nothingmuch@woobling.org>
wrote:

> Hi,
>
> On Fri, 19 Jul 2019 at 17:49, Mike Brooks <m@ib.tc> wrote:
>
>> Users will adopt whatever the client accepts - this feature would be
>> transparent.
>>
>
> My skepticism was based in an assumption on my part that most such data is
> produced by actors with a track record of neglecting transaction
> efficiency. I'd be happy to be proven wrong, but considering say usage
> rates of native witness outputs, or the fraction of transactions with more
> than 2 outputs so far I see little evidence in support of widespread
> adoption of cost saving measures. Assuming this is intended as a new script
> version, all fully validating nodes need to commit to keeping all data
> indefinitely before they can enforce the rules that make transactions
> benefiting from this opcode safe to broadcast.
>
> That said, if successful, the main concern is still that of address reuse
> - currently there is no incentive in the protocol to do that, and with
> BIP32 wallets fewer reasons to do it as well, but this proposal introduces
> such an incentive for users which would otherwise generate new addresses
> (disregarding the ones that already reuse addresses anyway), and this is
> problematic for privacy and fungibility.
>
> Since address reuse has privacy concerns, I think it's important to draw a
> distinction between clients accepting and producing such transactions, if
> the latter were done transparently that would be very concerning IMO, and
> even the former would not be transparent for users who run currently
> pruning nodes.
>
> I'm not sure how an O(1) time complexity leads to DoS, that seems like a
>> very creative jump.
>>
>
> For what it's worth, that was in reference to hypothetical deduplication
> only at the p2p layer, similar to compact blocks, but on further reflection
> I'd like to retract that, as since both scenarios which I had in mind seem
> easily mitigated.
>
>   Based on this response, it makes me want to calculate the savings, what
>> if it was a staggering reduction in the tree size?
>>
>
> Assuming past address reuse rates are predictive this only places an upper
> bound on the potential size savings, so personally I would not find that
> very compelling. Even if the realized size savings would be substantial,
> I'm not convinced the benefits outweigh the downsides (increased validation
> costs, monotonically growing unprunable data, and direct incentive for
> address reuse), especially when compared to other methods/proposals that
> can reduce on chain footprint generally improve privacy while reducing
> validation costs for others (e.g. batching, lightning, MAST for
> sufficiently large scripts, Schnorr signatures (musig, adaptor signatures),
> {tap,graft}root, ).
>
> Regards,
> Yuval
>

--000000000000ad9073058e729a5a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Fungibility is a good question for inductive reasonin=
g.=C2=A0 After all, what is a claim without some rigger?=C2=A0</div><div><b=
r></div><div>There exists some set of wallets &#39;w&#39; which contain a b=
alance of satoshi too small to recover because it doesn&#39;t meet the mini=
mum transaction fee required to confirm the transaction.=C2=A0 These wallet=
s are un-spendable by their very nature - and quantifying un-spendable wall=
ets is one way to measure the fungibility of Bitcoin.=C2=A0 The number of u=
n-spendable wallets can be quantified as follows:</div><div><br></div><div>=
=C2=A0 =C2=A0Let &#39;p&#39; equal the current price/per-bit for a transact=
ion</div><div>=C2=A0 =C2=A0Let &#39;n&#39; equal the number of bits in the =
transaction</div><div>=C2=A0 =C2=A0Let &#39;[a]&#39; be the set of all wall=
ets with a balance</div><div>=C2=A0 =C2=A0Let &#39;[w]&#39; be the set of u=
n-spendable wallets</div><div>=C2=A0 =C2=A0[w0] =3D [a] &gt; b*n</div><div>=
<br></div><div>Now, let&#39;s introduce a savings measure &#39;k&#39; which=
 is a constant flat savings per transaction.=C2=A0=C2=A0</div><div><br></di=
v><div>=C2=A0 =C2=A0[w1] =3D [a] &gt; b*(n - k0)</div><div><br></div><div>A=
s the savings &#39;k&#39; increase, the set of &#39;w&#39; also increases i=
n size.<br></div><div>=C2=A0 =C2=A0len([w0]) &lt; len([w1]) ... &lt; len([w=
k])<br></div><div><br></div><div>In this case &#39;k0&#39; could be the sav=
ings from a P2PKH transaction to a 233 byte SegWit transaction, and &#39;k1=
&#39; could be 148 byte SegWit+PubRef transaction, and the same model can b=
e used for some future transaction type that is even smaller.=C2=A0 =C2=A0A=
s the savings &#39;k&#39; approaches infinity the set of un-spendable walle=
ts approaches zero.</div><div><br></div><div>If a user is privacy-aware, an=
d chooses to use single-use p2sh for all transactions, then these users can=
 still gain from PubRef because block-weight should be decreased for everyo=
ne. There are cases where a user or merchant might want to reuse their p2sh=
 hash - and PubRef can provide savings.=C2=A0 Additionally, the resulting p=
2sh script could be a multi-sig transaction which could still benefit from =
PubRef compression.=C2=A0 PubRef improves fungibility of Bitcoin in two dif=
ferent ways - both reduced cost of transaction and increasing the max numbe=
r of transactions that are able to be confirmed by a block. Which is pretty=
 hot - QED.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Fri, Jul 19, 2019 at 3:48 PM Yuval Kogman &lt;<a href=
=3D"mailto:nothingmuch@woobling.org">nothingmuch@woobling.org</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div>Hi,</div><div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Fri, 19 Jul 2019 at 17:49, Mike Brooks &lt;<a href=
=3D"mailto:m@ib.tc" target=3D"_blank">m@ib.tc</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Users will ad=
opt whatever the client accepts - this feature would be transparent.=C2=A0<=
br></div></blockquote></div><div class=3D"gmail_quote"><br><div class=3D"gm=
ail_quote">My=20
skepticism was based in an assumption on my part that most such data is pro=
duced by actors with a track record of neglecting transaction efficiency. I=
&#39;d be happy to be proven wrong, but considering say usage rates of nati=
ve witness outputs, or the fraction of transactions with more than 2 output=
s so far I see little evidence in support of widespread adoption of cost sa=
ving measures. Assuming this is intended as a new script version, all fully=
 validating nodes need to commit to keeping all data indefinitely before th=
ey can enforce the rules that make transactions benefiting from this opcode=
 safe to broadcast.</div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote">That said, if successful, the main concern is still that of a=
ddress reuse - currently there is no incentive in the protocol to do that, =
and with BIP32 wallets fewer reasons to do it as well, but this proposal in=
troduces such an incentive for users which would otherwise generate new add=
resses (disregarding the ones that already reuse addresses anyway), and thi=
s is problematic for privacy and fungibility.<br></div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">Since address reuse has privacy=
 concerns, I think it&#39;s important to draw a distinction between clients=
 accepting and producing such transactions, if the latter were done transpa=
rently that would be very concerning IMO, and even the former would not be =
transparent for users who run currently pruning nodes.<br></div></div></div=
></div><div><div><br><div class=3D"gmail_quote"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I&#39;m =
not sure how an O(1) time complexity leads to DoS, that seems like a very c=
reative jump.</div></blockquote><div><br></div><div class=3D"gmail_quote">F=
or what it&#39;s worth, that was in reference to hypothetical deduplication=
 only at the p2p layer, similar to compact blocks, but on further reflectio=
n I&#39;d like to retract that, as since both scenarios which I had in mind=
 seem easily mitigated.<br></div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr">=C2=A0 Based on this response, it makes me want to calculate =
the savings, what if it was a staggering reduction in the tree size?</div><=
/blockquote></div></div></div></div><div><br><div class=3D"gmail_quote"><di=
v>Assuming past address reuse rates are predictive this only places an uppe=
r bound on the potential size savings, so personally I would not find that =
very compelling. Even if the realized size savings would be substantial, I&=
#39;m not convinced the benefits outweigh the downsides (increased validati=
on costs, monotonically growing unprunable data, and direct incentive for a=
ddress reuse), especially when compared to other methods/proposals that can=
 reduce on chain footprint generally improve privacy while reducing validat=
ion costs for others (e.g. batching, lightning, MAST for sufficiently large=
 scripts, Schnorr signatures (musig, adaptor signatures), {tap,graft}root, =
).</div><div><br></div><div>Regards,</div><div>Yuval<br></div></div></div><=
/div></div>
</blockquote></div>

--000000000000ad9073058e729a5a--