{"type":"rich","version":"1.0","author_name":"npub1t97ak5ltnq0v72nv4jssnhw0fr09axwqvc20623jfdnvrajae7nqufg2yy","author_url":"https://nostr.ae/npub1t97ak5ltnq0v72nv4jssnhw0fr09axwqvc20623jfdnvrajae7nqufg2yy","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-12-02\n📝 Original message:HI Antoine\n\nThank you for all the references - I agree with Sergej\nstatement \"opportunity makes the thief\"\n\nThe 1.5M trxs are all BTC which our clients query, I dont have specifics\nfor those trxs i.e. reasons for not being confirmed. However we target to\nachieve +90% confirmation of trxs for our clients. Fee rates the\ntransactions generally follow standard fee/rate policy similar to all\nindustry recommendations, we recommend higher priority fee rate but approve\ntrxs well below that level. I would say we havent seen a trx with medium\nfee rate be double spend - this is excluding race attacks or as you\nmentioned ancestral unconfirmed attacks.\n\nOpt in RBF is used in many ways to try to do double spends - i.e with\nancestral attacks inputs which are not confirmed, and also publishing the\nRBF first and then the straight trxs later. In general double spends excl\nOptin RBF does not occur alot at all - but the presence of a potential risk\ncauses everyone to wait back for confirmations.\n\nLooking at a sample of latest 4.3M trxs, I can see crica 11k trxs which\nseem to be double spent vast majority of these will be RBF, also on trx\nthat are high risk and we dont confirm the attacker has no incentive to\nfollow through with the second trxs.\n\nI see quite a bit of reference to the benefit to miners for RBF - I would\nthink this cash flow benefit is not significant but I would suggest getting\ninput from a miner themselves.\n\nBest\nDaniel\n\n________________________________\n\nDaniel Lipshitz\nGAP600| www.gap600.com\nPhone: +44 113 4900 117\nSkype: daniellipshitz123\nTwitter: @daniellipshitz\n\n\nOn Fri, Dec 2, 2022 at 3:52 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e Hi Daniel,\n\u003e\n\u003e From my understanding of GAP600, you're operating a zero-conf risk\n\u003e analysis business, which is integrated and leveraged by payment\n\u003e processors/liquidity providers and merchants. A deployment of fullrbf by\n\u003e enough full-node operators and a subset of the mining hashrate would lower\n\u003e the cost of double-spend attack by lamda users, therefore increasing the\n\u003e risk exposure of your users. This increased risk exposure could lead you to\n\u003e alter the acceptance of incoming zero-conf transactions, AFAICT in a\n\u003e similar reasoning as exposed by Bitrefill earlier this year [0].\n\u003e\n\u003e About the statistics you're asking for considerations, few further\n\u003e questions, on those 1.5M transactions per month, a) how many are\n\u003e Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many\n\u003e are excluded from zeroconf due to factors like RBF, long-chain of\n\u003e unconfirmed ancestors or too high-value and c) what has been the average\n\u003e feerate (assuming a standard size of 200 bytes) ?\n\u003e\n\u003e My personal position on fullrbf is still the same as expressed in #26525\n\u003e [1]. As a community, I think we still don't have conceptual consensus on\n\u003e deploying full-rbf, neither to remove it. In the direction of removing the\n\u003e current option from Bitcoin Core, I think the prerequisite to address are\n\u003e the qualification of enough economic flows at risk and the presence of a\n\u003e sizable loss in miners income. Beyond that, I think there is still the open\n\u003e question if we (we, as the Bitcoin protocol development community, with all\n\u003e its stakeholders) should restrain user choice in policy settings in the\n\u003e name of preserving mining income and established use-case stability.\n\u003e\n\u003e To recall, the original technical motivation of this option, and the wider\n\u003e smoother deployment was to address a DoS vector affecting another class of\n\u003e use-case: multi-party transactions like coinjoin and contracting protocols\n\u003e like Lightning [2] [3]. All of them expect to generate economic flows and\n\u003e corresponding mining income. Since then, alternative paths to solve this\n\u003e DoS vector have been devised, all with their own trade-offs and conceptual\n\u003e issues [4] [5].\n\u003e\n\u003e Best,\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021070.html\n\u003e [1] https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319499006\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e [4]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html\n\u003e [5]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html\n\u003e\n\u003e Le jeu. 1 déc. 2022 à 07:32, Daniel Lipshitz via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\u003e\n\u003e\u003e HI All\n\u003e\u003e\n\u003e\u003e I am the CEO of GAP600. We guarantee zero confirmed Bitcoin and other\n\u003e\u003e crypto  transactions, BTC is a primary part of our business. Our guarantee\n\u003e\u003e enables our customers to recognise zero-conf deposits. We reimburse our\n\u003e\u003e clients value of the trx should we get it wrong and a transaction we\n\u003e\u003e confirmed gets double spent.\n\u003e\u003e\n\u003e\u003e Should full RBF become default enabled and significantly adopted this\n\u003e\u003e would have a major impact on the capacity to accept zerof confs on mainnet.\n\u003e\u003e With the end result being this use case will be forced to move to a\n\u003e\u003e different chain, with lightning being just another option.\n\u003e\u003e\n\u003e\u003e I wanted to share some statistics about how significant this use case is.\n\u003e\u003e GAP600 clients are primarily payment processors and non custodial\n\u003e\u003e liquidity providers; you can see some of our clients on our site\n\u003e\u003e www.gap600.com. There are also merchants who have developed their own\n\u003e\u003e tools so GAP600 statistics are only a subset of the full use case.\n\u003e\u003e\n\u003e\u003e I do not know of any wallet, exchange or custodian who accepts zero conf\n\u003e\u003e without having some sort of solution in place. The market seems to be fully\n\u003e\u003e aware of the risks of zero-conf. The opt-RBF seems to be a solution which\n\u003e\u003e gives a clear free choice for actors.\n\u003e\u003e\n\u003e\u003e Statistics for consideration as a sample of the zero conf use case -\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e    1. As of end of Nov 2022 - GAP600 has processed i.e responded to\n\u003e\u003e    circa 15M transactions\n\u003e\u003e    2. These transactions have a cumulative value of 2.3B USD value.\n\u003e\u003e    3. We currently are seeing circa 1.5M transactions queired per month.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e It's a sizable amount of trxs on mainet and we are by no means the full\n\u003e\u003e market of platforms accepting zero-conf.  I realise there are other\n\u003e\u003e considerations which BTC has,  I would urge you to take into account the\n\u003e\u003e major risk being placed on this significant market share when deciding to\n\u003e\u003e make this feature default enabled and encouraging full adoption.\n\u003e\u003e\n\u003e\u003e Thank you for your consideration\n\u003e\u003e Daniel\n\u003e\u003e ________________________________\n\u003e\u003e\n\u003e\u003e Daniel Lipshitz\n\u003e\u003e GAP600| www.gap600.com\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221202/9b026be3/attachment-0001.html\u003e"}