Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C72F214AD for ; 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 ; Wed, 24 Jul 2019 19:49:17 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id f17so42645437wme.2 for ; 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: In-Reply-To: From: Mike Brooks Date: Wed, 24 Jul 2019 12:49:05 -0700 Message-ID: To: Yuval Kogman 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > Hi, > > On Fri, 19 Jul 2019 at 17:49, Mike Brooks 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
Fungibility is a good question for inductive reasonin= g.=C2=A0 After all, what is a claim without some rigger?=C2=A0
There exists some set of wallets 'w' which contain a b= alance of satoshi too small to recover because it doesn'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:

= =C2=A0 =C2=A0Let 'p' equal the current price/per-bit for a transact= ion
=C2=A0 =C2=A0Let 'n' equal the number of bits in the = transaction
=C2=A0 =C2=A0Let '[a]' be the set of all wall= ets with a balance
=C2=A0 =C2=A0Let '[w]' be the set of u= n-spendable wallets
=C2=A0 =C2=A0[w0] =3D [a] > b*n
=
Now, let's introduce a savings measure 'k' which= is a constant flat savings per transaction.=C2=A0=C2=A0

=C2=A0 =C2=A0[w1] =3D [a] > b*(n - k0)

A= s the savings 'k' increase, the set of 'w' also increases i= n size.
=C2=A0 =C2=A0len([w0]) < len([w1]) ... < len([w= k])

In this case 'k0' could be the sav= ings from a P2PKH transaction to a 233 byte SegWit transaction, and 'k1= ' 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 'k' approaches infinity the set of un-spendable walle= ts approaches zero.

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.

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 ad= opt whatever the client accepts - this feature would be transparent.=C2=A0<= br>

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= '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.

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.

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 transpa= rently 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 c= reative jump.

F= or what it's worth, that was in reference to hypothetical deduplication= only at the p2p layer, similar to compact blocks, but on further reflectio= n I'd like to retract that, as since both scenarios which I had in mind= seem easily mitigated.

=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?
<= /blockquote>

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, = ).

Regards,
Yuval
<= /div> --000000000000ad9073058e729a5a--