From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 06 Sep 2024 13:39:17 -0700 Received: from mail-qv1-f61.google.com ([209.85.219.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1smfjg-0006IG-Ug for bitcoindev@gnusha.org; Fri, 06 Sep 2024 13:39:17 -0700 Received: by mail-qv1-f61.google.com with SMTP id 6a1803df08f44-6c35b3a220asf87222496d6.0 for ; Fri, 06 Sep 2024 13:39:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1725655151; cv=pass; d=google.com; s=arc-20240605; b=V32s82XclZdCkoYIRDaH/xYpG7wtQGmUmrN/M1ALTx5dVLRIdxGFZlSG/O+VfH3In2 iZ9P1cXwzEcqO+MAoN1eNj47DLzBEF1zquLYflIy6OlVMtSVXZqCkstGse8r7X/M37FT yGG8pRanjXDWBAkmPG/2LTPRThJUaZdan7afCpXmbWaI6s+GZwC/eBPPTr50lbPpczPL NT9V/YkZDY8Yo9W42h6ZeR6U1kSdx6wwkQyl3RHV9PzhKYUphjOyRqVCo1C5L/BAatFx TsYdRxYHSHg17+mwFrRllKc4Q9ko57PrZ42n7FpK3kedbDb6eyVHDl5u8MU2dO3NKJAs 3Rxw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=idya+iCQ28ymGVhN8ezTxNbV/SjbTL+kx+mvu2ziKIc=; fh=TQCUkdBylmzec1HZzL4m0ILmSc3R7uAoseIjh90CT+o=; b=ewBQqwfltkxMkzv/PGDwtVbGXZqSTnd15MaUKCrEypfZ5K5ZpXZ8KowVdzBcOFW6Q0 g3AdZEi4df0sTKNPIXA0BUnYtxyn5LahzwtTHXnObNdeewWmJnH1twvExnZVJUg+XB5M Y7xTX0eDF3zPXXwhtoblMYQqV0Y+equb1OhGOznjaGcIabBb3n/20rSalru8grrXuQQ2 8igpSmnSoT1ZsWza6WtAqTo6tup89GZxoxbzXlU4+GjPiI5z9m6Wu19Or11o3IZ3HWZN Qdw14bTXan5zKJdWrYGK4UcZQd55BUfTGmfjv2/fO2R9wk62ZQgN6l2PMU4B9TPVS4TT Y9vQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=M6qSIefk; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1725655151; x=1726259951; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=idya+iCQ28ymGVhN8ezTxNbV/SjbTL+kx+mvu2ziKIc=; b=RDkfY9+4S/Gef4ezaG/ttEd4xYQ0sg6MtmPuhG6ZMKU5wRH+N/IBLQp6VgWGnGj1qL aRnIG728CaSC9VooTVeRq3BUl8YA2LLgIf3xETCpUNt6TzJzLFSXlvRM8lRG2BUmBppX bnLTs6MYATXN9ugGOIZxWtFIfcgDiuWhVlSLUKIxbjErl34SdjDl0jETdwVo5jI3wHUA ZdBbfuh7HNfwoaonNpZkBcmPFy3bHvnd6YjUBIAmyCokw0LYPk3hfJnLyvj5dJjRuoYu l7257qKxHOsgALdo74n/LD5CpC+KYdWiMG+F7oWTpWnlWhwRTh/8wV8vfW+FyqOVWawv dnnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725655151; x=1726259951; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=idya+iCQ28ymGVhN8ezTxNbV/SjbTL+kx+mvu2ziKIc=; b=lTPMp8LYCOQ52TXZ+s++zVFyXQ/Ww3fMA4BH/Eb2MfK06iyOUu1B5y8xZJhhlvjx7v OnHqV9rnJedwjPmXsH+P4ztFB3W0io2qRAzrKhGp7kjbZZ/3dw4Q8JvfKKKmqzYiqFJf J2b8f0c0pDO20I4xVmDwZt22qVHtguztzyh9GxlKHrflzXRT3SAds2k1RFY++GduTa/t 84iDTUcEMCUZUjvrJxBb+uJ+aPAq3tVlr4jYQT1dr7XWQhLsqMuR1X2w/JEa20M0byUQ 65cRc+olOBzbsJ0WYEmS7GsEh6yN607ywqNU5SVYZkkjm3SVarNiBu3N30dn9lGfCgDw YJQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725655151; x=1726259951; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=idya+iCQ28ymGVhN8ezTxNbV/SjbTL+kx+mvu2ziKIc=; b=ljeSYhMK+oXTimDiObpGhrhN57nnC3PTa9cq1IpFIN+U3fxwjmEx1Vj9yF17yQWNGG sjQndpn8KQpv7tepDlzuRBIgbyUf0bjy9b1CcN+mFFfCbJkpEFVsFQFV7L1zc/VgTxmL W6V2YZDLW2+A05dteQauMp6VZPiubHLpjzz2a+Fm/W5X8338FXeYmlF2dIzzFe6kIFTM AZT3MVOGX+Pq6Dc+1rWwxgSN+4iEwVGNruSHAzsF69Kx8anvJYfSpVXEjo95MfV9Pk9D Vo+2mg8DcPIDmB796oTWox5SwzEHy8nOmQGcxnTesdw62iyqg+CVOa//yK7i7C2HnaJP Zerg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUba6ImJkzB4/GizgNZbmyCkijLm7WPUNcC29sMhgpX1FvvehI74mZCSgY/L6XVb93F3/1tgMJOkrZ7@gnusha.org X-Gm-Message-State: AOJu0YzGZGeR0wXcVhdAAo+3v8hGN2DLi8Diz3d1v3CHXIbusGuMU/q9 i1we1k6MKOi5lzEL5pJWIhtkKQjk8OlijUIUNhu6ltbs9kJlnsH9 X-Google-Smtp-Source: AGHT+IHPTmRRGigRKGPpeMJZ/oIPyl/3W+YEHBzxghF7TcHQ60dy2YCvBYdRZhWpmi5GInTtD1rrqQ== X-Received: by 2002:a05:6214:5d04:b0:6c3:6b35:ac73 with SMTP id 6a1803df08f44-6c5283fd154mr59426196d6.11.1725655150534; Fri, 06 Sep 2024 13:39:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:1c49:b0:6bf:550b:6bdd with SMTP id 6a1803df08f44-6c527d31f19ls26409906d6.2.-pod-prod-00-us; Fri, 06 Sep 2024 13:39:09 -0700 (PDT) X-Received: by 2002:a05:620a:40d6:b0:7a4:d56a:a928 with SMTP id af79cd13be357-7a9888f0d4fmr1941693585a.21.1725655149039; Fri, 06 Sep 2024 13:39:09 -0700 (PDT) Received: by 2002:a05:620a:4908:b0:7a8:f6bb:1076 with SMTP id af79cd13be357-7a996b80511ms85a; Fri, 6 Sep 2024 12:52:26 -0700 (PDT) X-Received: by 2002:a05:620a:458c:b0:795:e9cd:f5b8 with SMTP id af79cd13be357-7a9888f0d41mr1679087085a.23.1725652345556; Fri, 06 Sep 2024 12:52:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1725652345; cv=none; d=google.com; s=arc-20240605; b=Y8Ww/TUvXGi6lSpxN9k/ivc9cuTPmr7nixkhV1vlsXyVCXaF8HdGo14T43+VkrruGv GHt9BZ+IIBJlPO1vldV7XiYcPQcN5uqgwkTB7MQTT/N8zIwFnyNiOimBODmpl84J4b25 sKoqx4j9XY1NPn5BaapuMUY9rN47hGtTyZiDujtjrbkIR8fiPCATUbXwvl3OWOtF5YCT Tulv2KKigJv+ZJNP+2NUIHItgzVvpmrlsV898pAm0a2zA+hm5kPhPXatYi73m/o6t0kE kjO5vbs0II5nFY09F4CaSiVKiWGUMkwaF4QGQ/Ze6vM7iN5nTDAU7OTUCxP8zm/0fjuu V/4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=jer+1Bpoa3tQMbHZNG+cpBtod4NBMSmlrs2yKG+GX8I=; fh=yPd8HNyAt94w6+9mawPnFhKq8crEnOt8R5D/kg3m3ro=; b=A8ah4wtIIDcGvUzxpzA0yL1iSPnEZv4BsZ2lSbf668UqsCgjy0qqf+itU7wdPXG9tg UMAEMHE9sr6TfrjTFGB89FdzjvFNyQ9TfhRz3jdeBWR4kPYREQ+U9RD6pgWTcj3DuOty U3GgSn9VHTAiq7HVOtUh/6WTvQgGGQT8qTqA1oH3ZssGSaYXSCxJ6eaF9uW70u4JwgZ/ vBOJxPmm34zhGfOpXFGtQBlnLR60SD+mKSTJF3c4ilr6qMZLE18HtUAImukfzR/ztWXh vYATUDN5C7ww4/SMpPyKonkD3ymmRyEcNtSpTTK8nXUb885wkMQrl/xaKTApxVWVOpke c2dA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=M6qSIefk; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-il1-x134.google.com (mail-il1-x134.google.com. [2607:f8b0:4864:20::134]) by gmr-mx.google.com with ESMTPS id af79cd13be357-7a98efee233si25422885a.4.2024.09.06.12.52.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Sep 2024 12:52:25 -0700 (PDT) Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) client-ip=2607:f8b0:4864:20::134; Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-39f54079599so7254485ab.0 for ; Fri, 06 Sep 2024 12:52:25 -0700 (PDT) X-Received: by 2002:a92:cdad:0:b0:39f:72a3:31ab with SMTP id e9e14a558f8ab-39f7978bdb8mr105092595ab.7.1725652344795; Fri, 06 Sep 2024 12:52:24 -0700 (PDT) MIME-Version: 1.0 References: <3c384b8e-fc91-4c30-95de-6856721e3318n@googlegroups.com> In-Reply-To: From: Antoine Riard Date: Fri, 6 Sep 2024 20:52:14 +0100 Message-ID: Subject: Re: [bitcoindev] Proposal to upgrade the transaction relay protocol to a new version To: Peter Todd Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000004784a062178bfcb" X-Original-Sender: antoine.riard@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=M6qSIefk; spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --00000000000004784a062178bfcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, > Your BIP is really incomplete without a discussion of what clients make use of > unannounced tx messages, their goals for doing it, and how they are expected to > achieve those goals once all nodes discontinue unannounced tx messages. The BIP is only applying effects for _upgraded_ peers and for now there is no code implementation to activate the halting of unannounced transactions messages towards non _upgraded_ peers, so non-upgraded clients are expected to do nothing. If you have a more wiseful transaction relay protocol upgrading deployment in mind, you can detail it. Personally, it might be wise in the future to always let few inbound slots to non-upgraded peers...? One can have a look on what is done by bitcoinj, which is the oldest library used to build wallets in the bitcoin ecosystem, notably I think Bitcoin Wallet: https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bit= coinj/core/TransactionBroadcast.java#L182 > It seems to me that implementing wallets with good UX could become a lot more > difficult if this change results in it taking significantly longer for a tx to > be broadcast. I don't know if it will. But you need to address this issue= . No, this BIP should change nothing for non-upgraded wallets as their unannounced transaction messages should still be processed the same by upgraded peers. Never heard that bitcoin non-documented transaction-relay set of messages were making any reliability guarantee on transaction delivery, like TCP is doing so. If someone wishes to introduce such a reliability mechanism, after considering what is the best approach between point-to-point or end-to-end, I'll note that such BIP proposal about a new node service bit should make it easier to do so. Split the BIP in 2 proposals to dissociate the signaling mechanism from the transaction message processing mechanism, here following UNIX philosophy about modularity: - https://github.com/bitcoin/bips/pull/1663 - https://github.com/bitcoin/bips/pull/1664 Best, Antoine ots hash: 3ea684a09c2db91070296f082e78059946c5c1e987de2a590e2c9bd9fd139c02 Le ven. 6 sept. 2024 =C3=A0 11:49, Peter Todd a =C3=A9= crit : > On Thu, Sep 05, 2024 at 03:49:55PM -0700, Antoine Riard wrote: > > Hi list, > > > > Opened a BIP draft proposing to introduce an upgrade of the transaction > > relay protocol by introducing a new node bit service: > > https://github.com/bitcoin/bips/pull/1663 > > > > For the movitations, see this old email thread from 2021: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018= 391.html > > Your BIP is really incomplete without a discussion of what clients make > use of > unannounced tx messages, their goals for doing it, and how they are > expected to > achieve those goals once all nodes discontinue unannounced tx messages. > > It seems to me that implementing wallets with good UX could become a lot > more > difficult if this change results in it taking significantly longer for a > tx to > be broadcast. I don't know if it will. But you need to address this issue= . > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/CALZpt%2BFgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR8mxwAQ%40mail.gma= il.com. --00000000000004784a062178bfcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

> Your BIP is really incomplete withou= t a discussion of what clients make use of
> unannounced tx messages,= their goals for doing it, and how they are expected to
> achieve tho= se goals once all nodes discontinue unannounced tx messages.

The BIP= is only applying effects for _upgraded_ peers and for now there is no
c= ode implementation to activate the halting of unannounced transactions mess= ages
towards non _upgraded_ peers, so non-upgraded clients are expected = to do nothing.

If you have a more wiseful transaction relay protocol= upgrading deployment in mind,
you can detail it. Personally, it might b= e wise in the future to always let few inbound
slots to non-upgraded pee= rs...?

One can have a look on what is done by bitcoinj, which is the= oldest library used
to build wallets in the bitcoin ecosystem, notably = I think Bitcoin Wallet:
https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/o= rg/bitcoinj/core/TransactionBroadcast.java#L182

> It seems to= me that implementing wallets with good UX could become a lot more
> = difficult if this change results in it taking significantly longer for a tx= to
> be broadcast. I don't know if it will. But you need to addr= ess this issue.

No, this BIP should change nothing for non-upgraded = wallets as their unannounced
transaction messages should still be proces= sed the same by upgraded peers.

Never heard that bitcoin non-documen= ted transaction-relay set of messages were
making any reliability guaran= tee on transaction delivery, like TCP is doing so.

If someone wishes= to introduce such a reliability mechanism, after considering what
is th= e best approach between point-to-point or end-to-end, I'll note that su= ch
BIP proposal about a new node service bit should make it easier to do= so.

Split the BIP in 2 proposals to dissociate the signaling mechan= ism from the transaction
message processing mechanism, here following UN= IX philosophy about modularity:
- https://github.com/bitcoin/bips/pull/1663
- https://github.com/bitcoin/b= ips/pull/1664

Best,
Antoine
ots hash: 3ea684a09c2db9107029= 6f082e78059946c5c1e987de2a590e2c9bd9fd139c02

Le=C2=A0ven. 6 sept. 2024 = =C3=A0=C2=A011:49, Peter Todd <pet= e@petertodd.org> a =C3=A9crit=C2=A0:
On Th= u, Sep 05, 2024 at 03:49:55PM -0700, Antoine Riard wrote:
> Hi list,
>
> Opened a BIP draft proposing to introduce an upgrade of the transactio= n
> relay protocol by introducing a new node bit service:
> https://github.com/bitcoin/bips/pull/1663
>
> For the movitations, see this old email thread from 2021:
> https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018391.html

Your BIP is really incomplete without a discussion of what clients make use= of
unannounced tx messages, their goals for doing it, and how they are expecte= d to
achieve those goals once all nodes discontinue unannounced tx messages.

It seems to me that implementing wallets with good UX could become a lot mo= re
difficult if this change results in it taking significantly longer for a tx= to
be broadcast. I don't know if it will. But you need to address this iss= ue.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.go= ogle.com/d/msgid/bitcoindev/CALZpt%2BFgByqOrdJ4L_435ixMa-Ek4nKQha5cOu2eCyRR= 8mxwAQ%40mail.gmail.com.
--00000000000004784a062178bfcb--