Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AA7CDC002D for ; Fri, 2 Dec 2022 06:34:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8C12981D34 for ; Fri, 2 Dec 2022 06:34:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8C12981D34 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=meH3X81r X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdwvHq_gC8la for ; Fri, 2 Dec 2022 06:34:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2B9AC81CDC Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) by smtp1.osuosl.org (Postfix) with ESMTPS id 2B9AC81CDC for ; Fri, 2 Dec 2022 06:34:20 +0000 (UTC) Received: by mail-vs1-xe36.google.com with SMTP id d185so3828209vsd.0 for ; Thu, 01 Dec 2022 22:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=W9Hoy72ru2d6Ap1SzzaqCysRA8lO8m39b+WWWU4qOzw=; b=meH3X81rQ8h6uo6mlPuApVg/8wblDIbQJnA+fXDErpi2m8ARIFs/nkuNTh7Y4AkcZG mJFvkcKHea34mWBWKxNo97Cl5kkxYWNnbMnaytC76DCziUPMjHBIfEl8CVpAoHo8L7SN 95WILN8H2QgmpQjaqVggJJKY4IsBdK5i9KMIZhI3AuNgzrA6dGpnSIQIWiKkkJ1RInfW A6cvGegPlGDkIlFKHbh2W8t5jPfUVNfxSt7PTwomjHLhEsxNa16ZEGCJ6QAA5VHczm1h S8VgvAdPXUjpB4YTbyBeO28ttI9jXOQbZZWFGy4BiurNhluQg8EuvCDgZcjJt3b+ZJdD Ljdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=W9Hoy72ru2d6Ap1SzzaqCysRA8lO8m39b+WWWU4qOzw=; b=zgGoDUf4eSIi3frljGtvmdOVhFsWXVuPf9dQVp7qqLenzDxxrmptU5UD6VtJq2mCh8 gV1EhEpYV9vr7WTYlUHK+DKS+ahAiOlJvOhNRnv+9YdKClQDBqPNum4vnsAvpjhQE0Z8 LsoX+fYADhjLrczuVF37HvmlsNfC7BlUx+nUW6zny2aEGQ4BMZiEZ3n7+ysBu28ed1FH jUnFUrx5IVLpBqTYZPWdy5Cr7MbiBV54GcM7VF5Ja/82qvbmbrFJTJy/q1mRWynEro9u z8wyjBRM+IyZw12/4T/awC02xNRf2nqn0E2aI+zqWTH4KDFdO4uTsr7YuauApCZk0WSv pbLw== X-Gm-Message-State: ANoB5pmZwt17kNn+bkB2ZjSA9ZK7U20nB7xX+0V8QB3jS3Mwve+kXlFv DEEYQiXSa5+ChY4q6OstrtIhOjbs1J9KfOFY8um11HPK4kTBYQ== X-Google-Smtp-Source: AA0mqf7/U9i301rQlXWGkVBDPVj72QCJEgI84xNF2WME5WqtaUj7H1iuJgjJoDpGVoXXUamjxAz5mA4S+BBxeKaCEqE= X-Received: by 2002:a67:6504:0:b0:3b0:b7dd:4d0a with SMTP id z4-20020a676504000000b003b0b7dd4d0amr10186107vsb.17.1669962858859; Thu, 01 Dec 2022 22:34:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Fri, 2 Dec 2022 08:34:07 +0200 Message-ID: To: Erik Aronesty Content-Type: multipart/alternative; boundary="000000000000fda77105eed2861c" X-Mailman-Approved-At: Sat, 03 Dec 2022 00:19:46 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2022 06:34:21 -0000 --000000000000fda77105eed2861c Content-Type: text/plain; charset="UTF-8" If fullRBF would become default and this would become dominant, zero-conf acceptance would become extremely difficult and would impact significantly this market share because its not the everyday users who would actually worry about it however the attackers would be all over it. As it is today the network has brief periods of stress when trxs are delayed but in general clears regularly and from time to time there is stress. Today actors' wallets and merchants etc already have the option of RBF. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Fri, Dec 2, 2022 at 12:04 AM Erik Aronesty wrote: > There has never been any enforcement of miner preferences. The > convention is changing quickly, since miners are squeezed for cash and want > to capture every nickel, plus there are bounties for full rbf being posted > every day. > > I would suggest considering to continue doing business, as usual, as if > full rbf is present. > > This means: > > - managing risk > - waiting for confirmations if the risk is too high > - using lightning if possible > > No other coin or chain offers a safer way to do business than lightning > over bitcoin. > > > > > On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshitz via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> HI All >> >> I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other >> crypto transactions, BTC is a primary part of our business. Our guarantee >> enables our customers to recognise zero-conf deposits. We reimburse our >> clients value of the trx should we get it wrong and a transaction we >> confirmed gets double spent. >> >> Should full RBF become default enabled and significantly adopted this >> would have a major impact on the capacity to accept zerof confs on mainnet. >> With the end result being this use case will be forced to move to a >> different chain, with lightning being just another option. >> >> I wanted to share some statistics about how significant this use case is. >> GAP600 clients are primarily payment processors and non custodial >> liquidity providers; you can see some of our clients on our site >> www.gap600.com. There are also merchants who have developed their own >> tools so GAP600 statistics are only a subset of the full use case. >> >> I do not know of any wallet, exchange or custodian who accepts zero conf >> without having some sort of solution in place. The market seems to be fully >> aware of the risks of zero-conf. The opt-RBF seems to be a solution which >> gives a clear free choice for actors. >> >> Statistics for consideration as a sample of the zero conf use case - >> >> >> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to >> circa 15M transactions >> 2. These transactions have a cumulative value of 2.3B USD value. >> 3. We currently are seeing circa 1.5M transactions queired per month. >> >> >> It's a sizable amount of trxs on mainet and we are by no means the full >> market of platforms accepting zero-conf. I realise there are other >> considerations which BTC has, I would urge you to take into account the >> major risk being placed on this significant market share when deciding to >> make this feature default enabled and encouraging full adoption. >> >> Thank you for your consideration >> Daniel >> ________________________________ >> >> Daniel Lipshitz >> GAP600| www.gap600.com >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000fda77105eed2861c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If fullRBF would become default and this would become domi= nant, zero-conf acceptance would become extremely difficult and would impac= t significantly this market share because its not the everyday users who wo= uld actually worry about it however the attackers would=C2=A0be all over it= .

As it is today the network has brief periods of stress= when trxs are delayed but in general clears regularly and from time to tim= e there is stress. Today actors' wallets and merchants=C2=A0etc already= have the option of RBF.
_____________________________= ___

Daniel Lipshitz
GAP600|=C2=A0www.ga= p600.com
<= font face=3D"tahoma, sans-serif">Phone:=C2=A0+44 113 4900 117
Twitter: @daniellipshitz


On Fri, Dec 2, 2022 at 12:= 04 AM Erik Aronesty <erik@q32.com>= ; wrote:
There has never been any enforcement of miner preferences.=C2=A0 = =C2=A0The convention is changing quickly, since miners are squeezed for cas= h and want to capture=C2=A0every nickel, plus there are bounties for full r= bf being posted every day.

I would suggest considering t= o continue doing business, as usual, as if full rbf is present.
<= br>
This means:

- managing risk
- waiting for co= nfirmations if the risk is too high
- using lightning if possible=

No other coin or chain offers=C2=A0a safer way to= do business than lightning over bitcoin.



On Thu, Dec 1, 2022 at 7:32 AM Daniel Lipshit= z via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<= br>
HI All

I am the CEO of GAP600. We guarantee zero confir= med Bitcoin and other crypto=C2=A0 transactions, BTC is a primary part of o= ur business. Our guarantee enables our customers to recognise zero-conf dep= osits. We reimburse our clients value of the trx should we get it wrong and= a transaction we confirmed gets double spent.

Sho= uld full RBF become default enabled and significantly adopted this would ha= ve a major impact on the capacity to accept zerof confs on mainnet. With th= e end result being this use case will be forced to move to a different chai= n, with lightning being just another=C2=A0option.

= I wanted to share some statistics about how significant this use case is.= =C2=A0
GAP600 clients are primarily payment processors and non cu= stodial liquidity=C2=A0providers; you can see some of our clients on our si= te www.gap600.com. = There are also merchants who have developed their own tools so GAP600 stati= stics are only a subset of the full use case.=C2=A0

I do not know of any wallet, exchange or custodian who accepts zero conf = without having some sort of solution=C2=A0in place. The market seems to be = fully aware of the risks of zero-conf. The opt-RBF seems to be a solution w= hich gives a clear free choice for actors.

Statist= ics for consideration as a sample of the zero conf use case -=C2=A0

  1. As of end of Nov 2022 - GAP600 has processed i.e = responded to circa 15M transactions
  2. These transactions have a cumul= ative value of 2.3B USD value.=C2=A0
  3. We currently are seeing circa = 1.5M transactions queired per month.=C2=A0

It's a sizable amount of trxs on mainet and we are by no means the f= ull market of platforms accepting zero-conf.=C2=A0=C2=A0I realise there are= other considerations which BTC has,=C2=A0 I would urge you to take into ac= count the major risk being placed on this significant market share when dec= iding to make this feature default enabled and encouraging=C2=A0full adopti= on.

Thank you for your consideration
Dan= iel
________________________________

Daniel Lipshitz
GAP600|=C2=A0www.gap600.com

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000fda77105eed2861c--