summaryrefslogtreecommitdiff
path: root/68/16428c5404e281a502d4cf374316fb8498ab80
blob: b1ca7e440efee6f095f9ae44f7f37df0450a2292 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 51DDCC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 02:35:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 21BC883883
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 02:35:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.505
X-Spam-Level: 
X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_DOTEDU=0.001]
 autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 d3RcTdz-wHtx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 02:35:24 +0000 (UTC)
X-Greylist: delayed 03:29:37 by SQLgrey-1.8.0
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com
 [IPv6:2a00:1450:4864:20::332])
 by smtp1.osuosl.org (Postfix) with ESMTPS id EDC1B83843
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 02:35:23 +0000 (UTC)
Received: by mail-wm1-x332.google.com with SMTP id o2so4176688wme.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 02 Mar 2021 18:35:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=eo+yrz21z/F5J2XjUHFnxAGSgSGsPspjPifScFPRds0=;
 b=jILFRzmjeQ8p8ljisRGUMxQThRFA79j7Zd+bHwyV95IYX4xGgUyYdV4Qp4K8Z+Zjju
 XTHDtzFtMzsXeQjkc8wJOpdUF1BuM8VeupE24Efq1sfubTb4rjUoA/Fhjtw//rkoinRv
 wv1af0WttWLK4oZqTnA+AJUR1oP3elD3jaWholnqshrg/wzenYVGMdlAHUOAljLyqk75
 gq+/VAYCNChcpM4Kv90PLLwGcCSrqL27ShzTupkaQBoILDoJnP0nu21JifWgwFc4YzfT
 p3bIbAnYe9aq43baZIH9Pje0PsSLbErDe18GQiyjjVb6RQw7e4XA+zuhC+Sr7e1908Fk
 GOJw==
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;
 bh=eo+yrz21z/F5J2XjUHFnxAGSgSGsPspjPifScFPRds0=;
 b=DC0QQT8nCYVWL1UMYMLMEh81P4EQG8boxyUgXvmXCITj2zaQk2UReDPhVrzNsQ0WzG
 WuJgpRXTHQ+cHlmDUimjVoFErJOBiyMzGkD4GSlK8b6rO5weoAYdpxe8QAwv4NGdBwiB
 SIaAskfFKn8ayFGs30INCV3X6lTyJ/4Pa8R2PtPwTQJh2Y1bSB80yEQqxSkKaPbde1YF
 A2VxMzRgf0iKDukN7ghY01Td3pC/uOUgOk7s/A0whdNJsCmnklUPNZEfoicu4Dye7QkI
 p+FBHOwieQ74KoQH33q1muxAtkDncBdhgPUoGbkiksPnoFtKSEPvAklfRRzwJ5TfBge7
 3INw==
X-Gm-Message-State: AOAM533b1WlSdudYrC41F5XnP04lACi8r6z3ynG2HEBxk8jxdJIDxwWn
 PEN4UVEaJJu9b+Olv9DIkMGjH00K+faNw/GsYc4XRgfjmRM=
X-Google-Smtp-Source: ABdhPJxwPRFxRKWLdki38aLjbxTmHyglSax/G8aUwM7pcfItHSkciq0WGKXzjyPBN8ciuSoCk4vly5iPTCGA69jXxuM=
X-Received: by 2002:a05:600c:22d1:: with SMTP id
 17mr6080227wmg.168.1614724946778; 
 Tue, 02 Mar 2021 14:42:26 -0800 (PST)
MIME-Version: 1.0
References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
 <CAFmfg2sT0sVVHOe5ZbDo5iDwE1Tk2oOXJiCKhNZv_hZVOVLbRw@mail.gmail.com>
 <CALZpt+HF0NwB=arz_buW1bzk7iT3s_Ytj+ZkEhT+iXpuRgmy2Q@mail.gmail.com>
 <CAFmfg2ubukd4QTRGpB2-aczuiJ94T60xa-Fs1Kn843iQiEfKiQ@mail.gmail.com>
In-Reply-To: <CAFmfg2ubukd4QTRGpB2-aczuiJ94T60xa-Fs1Kn843iQiEfKiQ@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 2 Mar 2021 17:42:14 -0500
Message-ID: <CALZpt+H_+aWfKdxDwbhrkx=7nz8Q_1V8taUx6_Qxq=i-CuwN6g@mail.gmail.com>
To: John Newbery <john@johnnewbery.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dcdff005bc9572c6"
X-Mailman-Approved-At: Wed, 03 Mar 2021 10:02:05 +0000
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 03 Mar 2021 02:35:28 -0000

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

> I believe this is what BIP 60 does, or did you have something else in
> mind?

Right, it achieves the first goal of dissociating `fRelay` from BIP37 but
it doesn't document Core specific behavior of disconnecting peers for raw
TX messages reception
from outbound block-relay-only peers, as implemented by PR 15759. I think
BIP 60 is as much unclear as BIP37 "Whether the remote peer should announce
relayed transactions or not, see BIP 0037, since version >=3D 70001". A fir=
st
interpretation could be that all tx-relay messages are disabled. A second
interpretation could be that only _tx-announcement_ messages (e.g INV(TX))
are disabled.

It could be argued that #15759 introduced incompatible changes between a
Bitcon Core 0.19.0 node and a BIP37 compliant peer on the p2p network.
Post-15759, the message space allowed to a BIP37 peer has been
reduced...Note that BIP60 isn't listed as implemented in
bitcoin/doc/bips.md.

I believe that BIP338 has the merit of making those subjects clear and easy
to follow by any Bitcoin software. Instead of spawning discussion around
old, lightclient-related BIPs or Core undocumented disabling transaction
relay mechanism being de facto part of the p2p protocol.

> Sorry - I meant that Bitcoin Core should allow a certain number of
> inbound peers that do not relay txs. This would be in addition to the
> full-relay inbound peers.

Yes, I agree on the purpose. But I don't think we need to "allow" further
disabled-tx peers by our inbound connection selection or eviction logics.
Turning a few bits in a protocol message sounds a too-cheap burden on
potential attackers contrary to most of our current eviction heuristics,
forcing some work ("announce transaction fast, "be located in some subnet",
"announce block fast"). Though better to discuss this later, not the main
point of your proposal.

Antoine

Le mar. 2 mars 2021 =C3=A0 07:22, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> Antoine,
>
> Nothing in my proposal below precludes introducing a more comprehensive
> feature negotiation mechanism at some later date. The only changes I'm
> proposing are to Bitcoin Core's policy for how it treats its peer
> connections.
>
> > If we don't want to introduce a new message and
> > corresponding code changes, it would be wise at least to extract
> VERSION's
> > `fRelay` and how Core handles it in its own BIP.
>
> I believe this is what BIP 60 does, or did you have something else in
> mind?
>
> > Explicit addr-relay negotiation will offer more
> > flexibility
>
> I agree!
>
> > (and more hygienic code paths rather than triggering data
> > structures initialization in few different locations).
>
> Not sure what you mean by hygienic here. This seems like a code style
> preference.
>
> > Given inbound connections might be attacker-controlled and tx-relay
> opt-out
> > signaling is also attacker-controlled, wouldn't this give a bias toward
> an
> > attacker in occupying our inbound slots ? Compared to honest inbound
> peers,
> > which in average are going to be full-relay.
>
> Sorry - I meant that Bitcoin Core should allow a certain number of
> inbound peers that do not relay txs. This would be in addition to the
> full-relay inbound peers.
>
> John
>
> On Mon, Mar 1, 2021 at 11:11 PM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi John,
>>
>> > I think a good counter-argument against simply using `fRelay` for this
>> > purpose is that we shouldn't reuse a protocol feature designed for one
>> > function to achieve a totally different aim. However, we know that nod=
es
>> > on the network have been using `fRelay` to disable transaction relay
>> > since Bitcoin Core version 0.12 (when `-blocksonly` was added), and th=
at
>> > usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>> > later (when block-relay-only connections were introduced), so using
>> > `fRelay` to disable transaction relay is now de facto part of the p2p
>> > protocol.
>>
>>
>> I don't think this is good practice ecosystem-wise. To understand
>> tx-relay opt-out from peers correctly, a _non_ Bitcoin Core client has t=
o
>> implement the `fRelay` subset of BIP37, but ignore the wider part around
>> FILTER* messages. Or implement those messages, only to disconnect peers
>> sending them, thus following BIP111 requirements.
>>
>> Thus, future developers of bitcoin software have the choice between
>> implementing a standard in a non-compliant way or implementing p2p messa=
ges
>> for a light client protocol in a way of deprecation ? Even further, an
>> interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
>> the filter is set prevents a client being flooded with traffic in the br=
ief
>> window of time") would make it okay to send TX messages to your inbound
>> block-relay-only peers. And that your client shouldn't be disconnected f=
or
>> such behavior.
>>
>> On the long-term, IMHO, better to have a well-defined standard with a
>> clean negotiation mechanism rather than relying on code specifics of a
>> given Bitcoin client. If we don't want to introduce a new message and
>> corresponding code changes, it would be wise at least to extract VERSION=
's
>> `fRelay` and how Core handles it in its own BIP.
>>
>> > I think a better approach would be for Bitcoin Core to only relay addr
>> > records to an inbound peer if it has previously received an `addr` or
>> > `addrv2` message from that peer, since that indicates definitively tha=
t
>> > the peer actively gossips `addr` records. This approach was first
>> > suggested by AJ in the original block-relay-only PR[15].
>>
>> If a node is willingly to opt-out from addr-relay from one of its inboun=
d
>> peers, how is it supposed to do ? Of course, you can drop such messages =
on
>> the floor, your peer is just going to waste bandwidth for nothing. IIRC
>> from past irc p2p meetings, we're really unclear about what a
>> good-propagation-and-privacy-preserving addr-relay strategy should look
>> like. Note, that distrusting your inbound peers with your addr-relay mig=
ht
>> be a sane direction. Explicit addr-relay negotiation will offer more
>> flexibility (and more hygienic code paths rather than triggering data
>> structures initialization in few different locations).
>>
>> > - update the inbound eviction logic to protect more inbound peers whic=
h
>> > do not have transaction relay data structures.
>>
>> Given inbound connections might be attacker-controlled and tx-relay
>> opt-out signaling is also attacker-controlled, wouldn't this give a bias
>> toward an attacker in occupying our inbound slots ? Compared to honest
>> inbound peers, which in average are going to be full-relay.
>>
>> Cheers,
>> Antoine
>>
>>
>>
>> Le lun. 1 mars 2021 =C3=A0 16:07, John Newbery via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>>
>>> Hi Suhas,
>>>
>>> Thank you for this proposal. I agree with your aims, but I think a new
>>> P2P message isn't necessary to achieve them.
>>>
>>> # Motivation
>>>
>>> There are two distinct (but interacting) motivations:
>>>
>>> 1. Allow a node to accept more incoming connections which will only be
>>>    used for block propagation (no transaction relay or addr gossip),
>>>    while minimizing resource requirements.
>>>
>>> 2. Prevent `addr` gossip messages from being sent to peers which will
>>>    'black hole' those addrs (i.e. not relay them further).
>>>
>>> These motivations interact because if we simply increase the number of
>>> block-relay-only connections that nodes make without making any
>>> allowance for the fact those connections won't gossip addr records, the=
n
>>> we'll increase the number of addr black holes and worsen addr gossip.
>>>
>>> # Using fRelay=3Dfalse to signal no transaction relay.
>>>
>>> `fRelay` is an optional field in the `version` message. There are three
>>> BIPs concerned with `fRelay`:
>>>
>>> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient
>>>   that they must not relay transactions over the connection until a
>>>   `filteradd` message has been received.
>>>
>>> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
>>>   how widely this BIP has been adopted by implementations.
>>>
>>> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
>>>   bloom filters are served by this node. According to this BIP, "If a
>>>   node does not support bloom filters but receives a "filterload",
>>>   "filteradd", or "filterclear" message from a peer the node should
>>>   disconnect that peer immediately."
>>>
>>> Within Bitcoin Core:
>>>
>>> - PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
>>>   filters.
>>>
>>> - Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
>>>   include the `fRelay` flag in `version` messages that it sends. Bitcoi=
n
>>>   Core will tolerate the `fRelay` field being present or absent in any
>>>   `version` message that it receives[6].
>>>
>>> - PR 6579[7] (merged in August 2015) implemented BIP 111. From that
>>>   point on, a Bitcoin Core node would disconnect peers that sent it
>>>   `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
>>>   peer's version was >=3D 70011. In PR 7708[8] (merged in March 2016) t=
his
>>>   was extended to disconnect any peer that sends a `filter*` message,
>>>   regardless of its version (in general, a 'polite disconnect' for any
>>>   peer that requests an unsupported service is probably the best
>>>   behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
>>>   filters was disabled by default, due to potential denial-of-service
>>>   attacks being possible against nodes which serve bloom filters on
>>>   public connections.
>>>
>>> - PR 6993[10] (merged in November 2015) started reusing the `fRelay`
>>>   field for the new `-blocksonly` mode. If Bitcoin Core is started with
>>>   `-blocksonly` configured, then it includes `fRelay=3Dfalse` in all of
>>>   the `version` messages it sends. In PR 15759[11] (merged  in Septembe=
r
>>>   2019), this usage of `fRelay` to permanently disable tx relay was
>>>   extended for use by the new block-relay only connection type.
>>>
>>> The net effect is that `fRelay` is already being used to indicate that
>>> transactions should not be relayed over a connection. In the motivation
>>> for your BIP, you write:
>>>
>>> > The low-bandwidth / minimal-resource nature of these connections is
>>> > currently known only by the initiator of the connection; this is
>>> > because the transaction relay field in the version message is not a
>>> > permanent setting for the lifetime of the connection.  Consequently, =
a
>>> > node receiving an inbound connection with transaction relay disabled
>>> > cannot distinguish between a peer that will never enable transaction
>>> > relay (as described in BIP 37) and one that will...
>>>
>>> However, as AJ points out in his response [12], the Bitcoin Core node
>>> _does_ know whether transaction relay can be supported as soon as the
>>> `version` message is received:
>>>
>>> > [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
>>> > message (either explicitly or by not setting fRelay), or you enable i=
t
>>> > later with FILTERLOAD or FILTERCLEAR, both of which will cause a
>>> > disconnect if bloom filters aren't supported. Bloom filter support is
>>> > (optionally?) indicated via a service bit (BIP 111), so you could
>>> > assume you know whether they're supported as soon as you receive the
>>> > VERSION line.
>>>
>>> i.e. if Bitcoin Core node is running under normal configuration with
>>> bloom filters disabled for public connections (which is both the defaul=
t
>>> setting and highly recommended due to DoS concerns), then as soon as it
>>> receives a `version` message with `fRelay=3Dfalse`, it can be sure that
>>> there will never be any transaction relay with that peer. If the peer
>>> later tries to enable transaction relay by sending a `filterload`
>>> message, then the node will disconnect that peer immediately.
>>>
>>> In summary, we can continue using the `fRelay` field to indicate that
>>> no transaction relay can happen for the entire lifetime of the
>>> connection.  Bitcoin Core can postpone allocating resources for
>>> transaction relay data structures until after the version message has
>>> been received to minimize resource usage for incoming block-relay-only
>>> connections. A rough implementation is here[13]. Obviously, a node that
>>> has been configured to serve bloom filters on public connections would
>>> not be able to take advantage of this and accept additional incoming
>>> block-relay-only peers, but I think that's fine - we already discourage
>>> that configuration.
>>>
>>> I think a good counter-argument against simply using `fRelay` for this
>>> purpose is that we shouldn't reuse a protocol feature designed for one
>>> function to achieve a totally different aim. However, we know that node=
s
>>> on the network have been using `fRelay` to disable transaction relay
>>> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and tha=
t
>>> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
>>> later (when block-relay-only connections were introduced), so using
>>> `fRelay` to disable transaction relay is now de facto part of the p2p
>>> protocol.
>>>
>>> # Preventing addr black holes
>>>
>>> Addresses of potential peers are gossiped around the p2p network using
>>> `addr` messages. When a Bitcoin Core node learns of a new `addr` record=
,
>>> it will relay that record to one or two of its peers, chosen at
>>> random[14]. The idea is that eventually the `addr` record will reach
>>> most of the nodes on the network.
>>>
>>> If there are too many nodes on the network that receive `addr` records
>>> and do not relay those records on to their peers (termed _addr black
>>> hole_ nodes), then propagation of those `addr` records suffers -- any
>>> individual `addr` record is unlikely to reach a large proportion of
>>> nodes on the network.
>>>
>>> Since a motivation for block-relay-only connections is to protect
>>> against eclipse attacks and thwart network topology analysis, Bitcoin
>>> Core will not relay `addr` records on those connections, and will ignor=
e
>>> any `addr` record received over those connections. Therefore, increasin=
g
>>> the number of block-relay-only connections without changing the `addr`
>>> gossip logic is likely to increase the prevalence of addr black holes,
>>> and negatively impact addr propagation. This is why BIP 338 includes:
>>>
>>> > It is RECOMMENDED that a node that has sent or received a disabletx
>>> > message to/from a peer not send any of these messages to the peer:
>>> >
>>> > - addr/getaddr
>>> > - addrv2 (BIP 155)
>>>
>>> I think a better approach would be for Bitcoin Core to only relay addr
>>> records to an inbound peer if it has previously received an `addr` or
>>> `addrv2` message from that peer, since that indicates definitively that
>>> the peer actively gossips `addr` records. This approach was first
>>> suggested by AJ in the original block-relay-only PR[15].
>>>
>>> An advantage of this approach is that it will improve addr propagation
>>> immediately and without any change to the P2P protocol, and will preven=
t
>>> sending `addr` records to all addr black holes (such as light clients),
>>> not just incoming block-relay-only connections.
>>>
>>> # Conclusion
>>>
>>> We can increase the permitted number of inbound block-relay-only peers
>>> while minimizing resource requirement _and_ improving addr record
>>> propagation, without any changes to the p2p protocol required.
>>>
>>> I propose that for Bitcoin Core version 22.0:
>>>
>>> - only initialize the transaction relay data structures after the
>>>   `version` message is received, and only if fRelay=3Dtrue and
>>>   `NODE_BLOOM` is not offered on this connection.
>>> - only initialize the addr data structures for inbound connections when
>>>   an `addr`, `addrv2` or `getaddr` message is received on the
>>>   connection, and only consider a connection for addr relay if its addr
>>>   data structures are initialized.
>>> - update the inbound eviction logic to protect more inbound peers which
>>>   do not have transaction relay data structures.
>>>
>>> Then, in version 23.0:
>>>
>>> - modestly increase the number of outbound block-relay-only connections=
.
>>>
>>> John
>>>
>>> [1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
>>> [2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki
>>> [3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
>>> [4] https://github.com/bitcoin/bitcoin/pull/1795
>>> [5] https://github.com/bitcoin/bitcoin/pull/2763
>>> [6]
>>> https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba1=
63c6e304d/src/net_processing.cpp#L2582-L2583
>>> [7] https://github.com/bitcoin/bitcoin/pull/6579
>>> [8] https://github.com/bitcoin/bitcoin/pull/7708
>>> [9] https://github.com/bitcoin/bitcoin/pull/16152
>>> [10] https://github.com/bitcoin/bitcoin/pull/6993
>>> [11] https://github.com/bitcoin/bitcoin/pull/15759
>>> [12]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/01=
8347.html
>>> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
>>> [14]
>>> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d76=
03e241d63/src/net_processing.cpp#L1696-L1700
>>> [15]
>>> https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757
>>>
>>> > Hi,
>>> >
>>> > I'm proposing the addition of a new, optional p2p message to allow
>>> peers to communicate that they do not want to send or receive (loose)
>>> transactions for the lifetime of a connection.
>>> >
>>> > The goal of this message is to help facilitate connections on the
>>> network over which only block-related data (blocks/headers/compact
>>> blocks/etc) are relayed, to create low-resource connections that help
>>> protect against partition attacks on the network.  In particular, by ad=
ding
>>> a network message that communicates that transactions will not be relay=
ed
>>> for the life of the connection, we ease the implementation of software =
that
>>> could have increased inbound connection limits for such peers, which in
>>> turn will make it easier to add additional persistent block-relay-only
>>> connections on the network -- strengthening network security for little
>>> additional bandwidth.
>>> >
>>> > Software has been deployed for over a year now which makes such
>>> connections, using the BIP37/BIP60 "fRelay" field in the version messag=
e to
>>> signal that transactions should not be sent initially.  However, BIP37
>>> allows for transaction relay to be enabled later in the connection's
>>> lifetime, complicating software that would try to distinguish inbound p=
eers
>>> that will never relay transactions from those that might.
>>> >
>>> > This proposal would add a single new p2p message, "disabletx", which
>>> (if used at all) must be sent between version and verack.  I propose th=
at
>>> this message is valid for peers advertising protocol version 70017 or
>>> higher.  Software is free to implement this BIP or ignore this message =
and
>>> remain compatible with software that does implement it.
>>> >
>>> > Full text of the proposed BIP is below.
>>> >
>>> > Thanks,
>>> > Suhas
>>> >
>>> > ---------------------------------------------------
>>> >
>>> > <pre>
>>> >   BIP: XXX
>>> >   Layer: Peer Services
>>> >   Title: Disable transaction relay message
>>> >   Author: Suhas Daftuar <sdaftuar@chaincode.com>
>>> >   Comments-Summary: No comments yet.
>>> >   Comments-URI:
>>> >   Status: Draft
>>> >   Type: Standards Track
>>> >   Created: 2020-09-03
>>> >   License: BSD-2-Clause
>>> > </pre>
>>> >
>>> > =3D=3DAbstract=3D=3D
>>> >
>>> > This BIP describes a change to the p2p protocol to allow a node to
>>> tell a peer
>>> > that a connection will not be used for transaction relay, to support
>>> > block-relay-only connections that are currently in use on the network=
.
>>> >
>>> > =3D=3DMotivation=3D=3D
>>> >
>>> > For nearly the past year, software has been deployed[1] which initiat=
es
>>> > connections on the Bitcoin network and sets the transaction relay fie=
ld
>>> > (introduced by BIP 37 and also defined in BIP 60) to false, to preven=
t
>>> > transaction relay from occurring on the connection. Additionally, add=
r
>>> messages
>>> > received from the peer are ignored by this software.
>>> >
>>> > The purpose of these connections is two-fold: by making additional
>>> > low-bandwidth connections on which blocks can propagate, the
>>> robustness of a
>>> > node to network partitioning attacks is strengthened.  Additionally,
>>> by not
>>> > relaying transactions and ignoring received addresses, the ability of
>>> an
>>> > adversary to learn the complete network graph (or a subgraph) is
>>> reduced[2],
>>> > which in turn increases the cost or difficulty to an attacker seeking
>>> to carry
>>> > out a network partitioning attack (when compared with having such
>>> knowledge).
>>> >
>>> > The low-bandwidth / minimal-resource nature of these connections is
>>> currently
>>> > known only by the initiator of the connection; this is because the
>>> transaction
>>> > relay field in the version message is not a permanent setting for the
>>> lifetime
>>> > of the connection.  Consequently, a node receiving an inbound
>>> connection with
>>> > transaction relay disabled cannot distinguish between a peer that wil=
l
>>> never
>>> > enable transaction relay (as described in BIP 37) and one that will.
>>> Moreover,
>>> > the node also cannot determine that the incoming connection will
>>> ignore relayed
>>> > addresses; with that knowledge a node would likely choose other peers
>>> to
>>> > receive announced addresses instead.
>>> >
>>> > This proposal adds a new, optional message that a node can send a pee=
r
>>> when
>>> > initiating a connection to that peer, to indicate that connection
>>> should not be
>>> > used for transaction-relay for the connection's lifetime. In addition=
,
>>> without
>>> > a current mechanism to negotiate whether addresses should be relayed
>>> on a
>>> > connection, this BIP suggests that address messages not be sent on
>>> links where
>>> > tx-relay has been disabled.
>>> >
>>> > =3D=3DSpecification=3D=3D
>>> >
>>> > # A new disabletx message is added, which is defined as an empty
>>> message where pchCommand =3D=3D "disabletx".
>>> > # The protocol version of nodes implementing this BIP must be set to
>>> 70017 or higher.
>>> > # If a node sets the transaction relay field in the version message t=
o
>>> a peer to false, then the disabletx message MAY also be sent in respons=
e to
>>> a version message from that peer if the peer's protocol version is >=3D
>>> 70017. If sent, the disabletx message MUST be sent prior to sending a
>>> verack.
>>> > # A node that has sent or received a disabletx message to/from a peer
>>> MUST NOT send any of these messages to the peer:
>>> > ## inv messages for transactions
>>> > ## getdata messages for transactions
>>> > ## getdata messages for merkleblock (BIP 37)
>>> > ## filteradd/filterload/filterclear (BIP 37)
>>> > ## mempool (BIP 35)
>>> > # It is RECOMMENDED that a node that has sent or received a disabletx
>>> message to/from a peer not send any of these messages to the peer:
>>> > ## addr/getaddr
>>> > ## addrv2 (BIP 155)
>>> > # The behavior regarding sending or processing other message types is
>>> not specified by this BIP.
>>> > # Nodes MAY decide to not remain connected to peers that send this
>>> message (for example, if trying to find a peer that will relay
>>> transactions).
>>> >
>>> > =3D=3DCompatibility=3D=3D
>>> >
>>> > Nodes with protocol version >=3D 70017 that do not implement this BIP=
,
>>> and nodes
>>> > with protocol version < 70017, will continue to remain compatible wit=
h
>>> > implementing software: transactions would not be relayed to peers
>>> sending the
>>> > disabletx message (provided that BIP 37 or BIP 60 has been
>>> implemented), and while
>>> > periodic address relay may still take place, software implementing
>>> this BIP
>>> > should not be disconnecting such peers solely for that reason.
>>> >
>>> > Disabling address relay is suggested but not required by this BIP, to
>>> allow for
>>> > future protocol extensions that might specify more carefully how
>>> address relay
>>> > is to be negotiated. This BIP's recommendations for software to not
>>> relay
>>> > addresses is intended to be interpreted as guidance in the absence of
>>> any such
>>> > future protocol extension, to accommodate existing software behavior.
>>> >
>>> > Note that all messages specified in BIP 152, including blocktxn and
>>> > getblocktxn, are permitted between peers that have sent/received a
>>> disabletx
>>> > message, subject to the feature negotiation of BIP 152.
>>> >
>>> > =3D=3DImplementation=3D=3D
>>> >
>>> > TBD
>>> >
>>> > =3D=3DReferences=3D=3D
>>> >
>>> > # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759
>>> implemented this functionality] since version 0.19.0.1, released in
>>> November 2019.
>>> > # For example, see
>>> https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and
>>> https://arxiv.org/pdf/1812.00942.pdf.
>>> >
>>> > =3D=3DCopyright=3D=3D
>>> >
>>> > This BIP is licensed under the 2-clause BSD license.
>>>
>>> On Wed, Jan 6, 2021 at 4:35 PM Suhas Daftuar via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm proposing the addition of a new, optional p2p message to allow
>>>> peers to communicate that they do not want to send or receive (loose)
>>>> transactions for the lifetime of a connection.
>>>>
>>>> The goal of this message is to help facilitate connections on the
>>>> network over which only block-related data (blocks/headers/compact
>>>> blocks/etc) are relayed, to create low-resource connections that help
>>>> protect against partition attacks on the network.  In particular, by a=
dding
>>>> a network message that communicates that transactions will not be rela=
yed
>>>> for the life of the connection, we ease the implementation of software=
 that
>>>> could have increased inbound connection limits for such peers, which i=
n
>>>> turn will make it easier to add additional persistent block-relay-only
>>>> connections on the network -- strengthening network security for littl=
e
>>>> additional bandwidth.
>>>>
>>>> Software has been deployed for over a year now which makes such
>>>> connections, using the BIP37/BIP60 "fRelay" field in the version messa=
ge to
>>>> signal that transactions should not be sent initially.  However, BIP37
>>>> allows for transaction relay to be enabled later in the connection's
>>>> lifetime, complicating software that would try to distinguish inbound =
peers
>>>> that will never relay transactions from those that might.
>>>>
>>>> This proposal would add a single new p2p message, "disabletx", which
>>>> (if used at all) must be sent between version and verack.  I propose t=
hat
>>>> this message is valid for peers advertising protocol version 70017 or
>>>> higher.  Software is free to implement this BIP or ignore this message=
 and
>>>> remain compatible with software that does implement it.
>>>>
>>>> Full text of the proposed BIP is below.
>>>>
>>>> Thanks,
>>>> Suhas
>>>>
>>>> ---------------------------------------------------
>>>>
>>>> <pre>
>>>>   BIP: XXX
>>>>   Layer: Peer Services
>>>>   Title: Disable transaction relay message
>>>>   Author: Suhas Daftuar <sdaftuar@chaincode.com>
>>>>   Comments-Summary: No comments yet.
>>>>   Comments-URI:
>>>>   Status: Draft
>>>>   Type: Standards Track
>>>>   Created: 2020-09-03
>>>>   License: BSD-2-Clause
>>>> </pre>
>>>>
>>>> =3D=3DAbstract=3D=3D
>>>>
>>>> This BIP describes a change to the p2p protocol to allow a node to tel=
l a peer
>>>> that a connection will not be used for transaction relay, to support
>>>> block-relay-only connections that are currently in use on the network.
>>>>
>>>> =3D=3DMotivation=3D=3D
>>>>
>>>> For nearly the past year, software has been deployed[1] which initiate=
s
>>>> connections on the Bitcoin network and sets the transaction relay fiel=
d
>>>> (introduced by BIP 37 and also defined in BIP 60) to false, to prevent
>>>> transaction relay from occurring on the connection. Additionally, addr=
 messages
>>>> received from the peer are ignored by this software.
>>>>
>>>> The purpose of these connections is two-fold: by making additional
>>>> low-bandwidth connections on which blocks can propagate, the robustnes=
s of a
>>>> node to network partitioning attacks is strengthened.  Additionally, b=
y not
>>>> relaying transactions and ignoring received addresses, the ability of =
an
>>>> adversary to learn the complete network graph (or a subgraph) is reduc=
ed[2],
>>>> which in turn increases the cost or difficulty to an attacker seeking =
to carry
>>>> out a network partitioning attack (when compared with having such know=
ledge).
>>>>
>>>> The low-bandwidth / minimal-resource nature of these connections is cu=
rrently
>>>> known only by the initiator of the connection; this is because the tra=
nsaction
>>>> relay field in the version message is not a permanent setting for the =
lifetime
>>>> of the connection.  Consequently, a node receiving an inbound connecti=
on with
>>>> transaction relay disabled cannot distinguish between a peer that will=
 never
>>>> enable transaction relay (as described in BIP 37) and one that will.  =
Moreover,
>>>> the node also cannot determine that the incoming connection will ignor=
e relayed
>>>> addresses; with that knowledge a node would likely choose other peers =
to
>>>> receive announced addresses instead.
>>>>
>>>> This proposal adds a new, optional message that a node can send a peer=
 when
>>>> initiating a connection to that peer, to indicate that connection shou=
ld not be
>>>> used for transaction-relay for the connection's lifetime. In addition,=
 without
>>>> a current mechanism to negotiate whether addresses should be relayed o=
n a
>>>> connection, this BIP suggests that address messages not be sent on lin=
ks where
>>>> tx-relay has been disabled.
>>>>
>>>> =3D=3DSpecification=3D=3D
>>>>
>>>> # A new disabletx message is added, which is defined as an empty messa=
ge where pchCommand =3D=3D "disabletx".
>>>> # The protocol version of nodes implementing this BIP must be set to 7=
0017 or higher.
>>>> # If a node sets the transaction relay field in the version message to=
 a peer to false, then the disabletx message MAY also be sent in response t=
o a version message from that peer if the peer's protocol version is >=3D 7=
0017. If sent, the disabletx message MUST be sent prior to sending a verack=
.
>>>> # A node that has sent or received a disabletx message to/from a peer =
MUST NOT send any of these messages to the peer:
>>>> ## inv messages for transactions
>>>> ## getdata messages for transactions
>>>> ## getdata messages for merkleblock (BIP 37)
>>>> ## filteradd/filterload/filterclear (BIP 37)
>>>> ## mempool (BIP 35)
>>>> # It is RECOMMENDED that a node that has sent or received a disabletx =
message to/from a peer not send any of these messages to the peer:
>>>> ## addr/getaddr
>>>> ## addrv2 (BIP 155)
>>>> # The behavior regarding sending or processing other message types is =
not specified by this BIP.
>>>> # Nodes MAY decide to not remain connected to peers that send this mes=
sage (for example, if trying to find a peer that will relay transactions).
>>>>
>>>> =3D=3DCompatibility=3D=3D
>>>>
>>>> Nodes with protocol version >=3D 70017 that do not implement this BIP,=
 and nodes
>>>> with protocol version < 70017, will continue to remain compatible with
>>>> implementing software: transactions would not be relayed to peers send=
ing the
>>>> disabletx message (provided that BIP 37 or BIP 60 has been implemented=
), and while
>>>> periodic address relay may still take place, software implementing thi=
s BIP
>>>> should not be disconnecting such peers solely for that reason.
>>>>
>>>> Disabling address relay is suggested but not required by this BIP, to =
allow for
>>>> future protocol extensions that might specify more carefully how addre=
ss relay
>>>> is to be negotiated. This BIP's recommendations for software to not re=
lay
>>>> addresses is intended to be interpreted as guidance in the absence of =
any such
>>>> future protocol extension, to accommodate existing software behavior.
>>>>
>>>> Note that all messages specified in BIP 152, including blocktxn and
>>>> getblocktxn, are permitted between peers that have sent/received a dis=
abletx
>>>> message, subject to the feature negotiation of BIP 152.
>>>>
>>>> =3D=3DImplementation=3D=3D
>>>>
>>>> TBD
>>>>
>>>> =3D=3DReferences=3D=3D
>>>>
>>>> # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 impl=
emented this functionality] since version 0.19.0.1, released in November 20=
19.
>>>> # For example, see https://www.cs.umd.edu/projects/coinscope/coinscope=
.pdf and https://arxiv.org/pdf/1812.00942.pdf.
>>>>
>>>> =3D=3DCopyright=3D=3D
>>>>
>>>> This BIP is licensed under the 2-clause BSD license.
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>&gt; I believe this is what BIP 60 does, or did you h=
ave something else in<br>&gt; mind?<br><br>Right, it achieves the first goa=
l of dissociating `fRelay` from BIP37 but it doesn&#39;t document Core spec=
ific behavior of disconnecting peers for raw TX messages reception<br>from =
outbound block-relay-only peers, as implemented by PR 15759. I think BIP 60=
 is as much unclear as BIP37 &quot;Whether the remote peer should announce =
relayed transactions or not, see BIP 0037, since version &gt;=3D 70001&quot=
;. A first interpretation could be that all tx-relay messages are disabled.=
 A second interpretation could be that only _tx-announcement_ messages (e.g=
 INV(TX)) are disabled.<br><br>It could be argued that #15759 introduced in=
compatible changes between a Bitcon Core 0.19.0 node and a BIP37 compliant =
peer on the p2p network. Post-15759, the message space allowed to a BIP37 p=
eer has been reduced...Note that BIP60 isn&#39;t listed as implemented in b=
itcoin/doc/bips.md.<br><br>I believe that BIP338 has the merit of making th=
ose subjects clear and easy to follow by any Bitcoin software. Instead of s=
pawning discussion around old, lightclient-related BIPs or Core undocumente=
d disabling transaction relay mechanism being de facto part of the p2p prot=
ocol.<br><br>&gt; Sorry - I meant that Bitcoin Core should allow a certain =
number of<br>&gt; inbound peers that do not relay txs. This would be in add=
ition to the<br>&gt; full-relay inbound peers.<br><br>Yes, I agree on the p=
urpose. But I don&#39;t think we need to &quot;allow&quot; further disabled=
-tx peers by our inbound connection selection or eviction logics. Turning a=
 few bits in a protocol message sounds a too-cheap burden on potential atta=
ckers contrary to most of our current eviction heuristics, forcing some wor=
k (&quot;announce transaction fast, &quot;be located in some subnet&quot;, =
&quot;announce block fast&quot;). Though better to discuss this later, not =
the main point of your proposal.<br><br></div>Antoine<br></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 2 mar=
s 2021 =C3=A0=C2=A007:22, John Newbery via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Antoine,<br><br>Nothing i=
n my proposal below precludes introducing a more comprehensive<br>feature n=
egotiation mechanism at some later date. The only changes I&#39;m<br>propos=
ing are to Bitcoin Core&#39;s policy for how it treats its peer<br>connecti=
ons.<br><br>&gt; If we don&#39;t want to introduce a new message and<br>&gt=
; corresponding code changes, it would be wise at least to extract VERSION&=
#39;s<br>&gt; `fRelay` and how Core handles it in its own BIP.<br><br>I bel=
ieve this is what BIP 60 does, or did you have something else in<br>mind?<b=
r><br>&gt; Explicit addr-relay negotiation will offer more<br>&gt; flexibil=
ity<br><br>I agree!<br><br>&gt; (and more hygienic code paths rather than t=
riggering data<br>&gt; structures initialization in few different locations=
).<br><br>Not sure what you mean by hygienic here. This seems like a code s=
tyle<br>preference.<br><br>&gt; Given inbound connections might be attacker=
-controlled and tx-relay opt-out<br>&gt; signaling is also attacker-control=
led, wouldn&#39;t this give a bias toward an<br>&gt; attacker in occupying =
our inbound slots ? Compared to honest inbound peers,<br>&gt; which in aver=
age are going to be full-relay.<br><br>Sorry - I meant that Bitcoin Core sh=
ould allow a certain number of<br>inbound peers that do not relay txs. This=
 would be in addition to the<br>full-relay inbound peers.<br><br>John<br></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Mon, Mar 1, 2021 at 11:11 PM Antoine Riard &lt;<a href=3D"mailto:antoine.r=
iard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</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"ltr"><=
div><div>Hi John,<br></div><div><br>&gt; I think a good counter-argument ag=
ainst simply using `fRelay` for this<br>&gt; purpose is that we shouldn&#39=
;t reuse a protocol feature designed for one<br>&gt; function to achieve a =
totally different aim. However, we know that nodes<br>&gt; on the network h=
ave been using `fRelay` to disable transaction relay<br>&gt; since Bitcoin =
Core version 0.12 (when `-blocksonly` was added), and that<br>&gt; usage wa=
s expanded to _all_ nodes running Bitcoin Core version 0.19 or<br>&gt; late=
r (when block-relay-only connections were introduced), so using<br>&gt; `fR=
elay` to disable transaction relay is now de facto part of the p2p<br>&gt; =
protocol.<br><br><br>I don&#39;t think this is good practice ecosystem-wise=
. To understand tx-relay opt-out from peers correctly, a _non_ Bitcoin Core=
 client has to implement the `fRelay` subset of BIP37, but ignore the wider=
 part around FILTER* messages. Or implement those messages, only to disconn=
ect peers sending them, thus following BIP111 requirements.<br><br>Thus, fu=
ture developers of bitcoin software have the choice between implementing a =
standard in a non-compliant way or implementing p2p messages for a light cl=
ient protocol in a way of deprecation ? Even further, an interpretation of =
BIP 37 (&quot;Being able to opt-out of _inv_ messages until the filter is s=
et prevents a client being flooded with traffic in the brief window of time=
&quot;) would make it okay to send TX messages to your inbound block-relay-=
only peers. And that your client shouldn&#39;t be disconnected for such beh=
avior.<br><br>On the long-term, IMHO, better to have a well-defined standar=
d with a clean negotiation mechanism rather than relying on code specifics =
of a given Bitcoin client. If we don&#39;t want to introduce a new message =
and corresponding code changes, it would be wise at least to extract VERSIO=
N&#39;s `fRelay` and how Core handles it in its own BIP.<br><br>&gt; I thin=
k a better approach would be for Bitcoin Core to only relay addr<br>&gt; re=
cords to an inbound peer if it has previously received an `addr` or<br>&gt;=
 `addrv2` message from that peer, since that indicates definitively that<br=
>&gt; the peer actively gossips `addr` records. This approach was first<br>=
&gt; suggested by AJ in the original block-relay-only PR[15].<br><br></div>=
<div>If a node is willingly to opt-out from addr-relay from one of its inbo=
und peers, how is it supposed to do ? Of course, you can drop such messages=
 on the floor, your peer is just going to waste bandwidth for nothing. IIRC=
 from past irc p2p meetings, we&#39;re really unclear about what a good-pro=
pagation-and-privacy-preserving addr-relay strategy should look like. Note,=
 that distrusting your inbound peers with your addr-relay might be a sane d=
irection. Explicit addr-relay negotiation will offer more flexibility (and =
more hygienic code paths rather than triggering data structures initializat=
ion in few different locations).<br></div><div><br>&gt; - update the inboun=
d eviction logic to protect more inbound peers which<br>&gt; do not have tr=
ansaction relay data structures.<br><br></div><div>Given inbound connection=
s might be attacker-controlled and tx-relay opt-out signaling is also attac=
ker-controlled, wouldn&#39;t this give a bias toward an attacker in occupyi=
ng our inbound slots ? Compared to honest inbound peers, which in average a=
re going to be full-relay.<br></div><div><br></div>Cheers,<br></div>Antoine=
<br><div><div><br><br></div></div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 1 mars 2021 =C3=A0=C2=A016:0=
7, John Newbery via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; a =C3=A9crit=C2=A0:<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"ltr">Hi Suhas,<br><br>Thank you for this proposal. I=
 agree with your aims, but I think a new<br>P2P message isn&#39;t necessary=
 to achieve them.<br><br># Motivation<br><br>There are two distinct (but in=
teracting) motivations:<br><br>1. Allow a node to accept more incoming conn=
ections which will only be<br>=C2=A0 =C2=A0used for block propagation (no t=
ransaction relay or addr gossip),<br>=C2=A0 =C2=A0while minimizing resource=
 requirements.<br><br>2. Prevent `addr` gossip messages from being sent to =
peers which will<br>=C2=A0 =C2=A0&#39;black hole&#39; those addrs (i.e. not=
 relay them further).<br><br>These motivations interact because if we simpl=
y increase the number of<br>block-relay-only connections that nodes make wi=
thout making any<br>allowance for the fact those connections won&#39;t goss=
ip addr records, then<br>we&#39;ll increase the number of addr black holes =
and worsen addr gossip.<br><br># Using fRelay=3Dfalse to signal no transact=
ion relay.<br><br>`fRelay` is an optional field in the `version` message. T=
here are three<br>BIPs concerned with `fRelay`:<br><br>- BIP 37[1] introduc=
ed the `fRelay` field to indicate to the recipient<br>=C2=A0 that they must=
 not relay transactions over the connection until a<br>=C2=A0 `filteradd` m=
essage has been received.<br><br>- BIP 60[2] aimed to make the `fRelay` fie=
ld mandatory. It is not clear<br>=C2=A0 how widely this BIP has been adopte=
d by implementations.<br><br>- BIP 111[3] introduced a `NODE_BLOOM` service=
 bit to indicate that<br>=C2=A0 bloom filters are served by this node. Acco=
rding to this BIP, &quot;If a<br>=C2=A0 node does not support bloom filters=
 but receives a &quot;filterload&quot;,<br>=C2=A0 &quot;filteradd&quot;, or=
 &quot;filterclear&quot; message from a peer the node should<br>=C2=A0 disc=
onnect that peer immediately.&quot;<br><br>Within Bitcoin Core:<br><br>- PR=
 1795[4] (merged in January 2013) added support for BIP 37 Bloom<br>=C2=A0 =
filters.<br><br>- Since PR 2763[5] (merged in June 2013), Bitcoin Core will=
 _always_<br>=C2=A0 include the `fRelay` flag in `version` messages that it=
 sends. Bitcoin<br>=C2=A0 Core will tolerate the `fRelay` field being prese=
nt or absent in any<br>=C2=A0 `version` message that it receives[6].<br><br=
>- PR 6579[7] (merged in August 2015) implemented BIP 111. From that<br>=C2=
=A0 point on, a Bitcoin Core node would disconnect peers that sent it<br>=
=C2=A0 `filter*` messages if it hadn&#39;t enabled `NODE_BLOOM`, provided t=
he<br>=C2=A0 peer&#39;s version was &gt;=3D 70011. In PR 7708[8] (merged in=
 March 2016) this<br>=C2=A0 was extended to disconnect any peer that sends =
a `filter*` message,<br>=C2=A0 regardless of its version (in general, a &#3=
9;polite disconnect&#39; for any<br>=C2=A0 peer that requests an unsupporte=
d service is probably the best<br>=C2=A0 behaviour). In PR 16152[9] (merged=
 in July 2019), serving Bloom<br>=C2=A0 filters was disabled by default, du=
e to potential denial-of-service<br>=C2=A0 attacks being possible against n=
odes which serve bloom filters on<br>=C2=A0 public connections.<br><br>- PR=
 6993[10] (merged in November 2015) started reusing the `fRelay`<br>=C2=A0 =
field for the new `-blocksonly` mode. If Bitcoin Core is started with<br>=
=C2=A0 `-blocksonly` configured, then it includes `fRelay=3Dfalse` in all o=
f<br>=C2=A0 the `version` messages it sends. In PR 15759[11] (merged =C2=A0=
in September<br>=C2=A0 2019), this usage of `fRelay` to permanently disable=
 tx relay was<br>=C2=A0 extended for use by the new block-relay only connec=
tion type.<br><br>The net effect is that `fRelay` is already being used to =
indicate that<br>transactions should not be relayed over a connection. In t=
he motivation<br>for your BIP, you write:<br><br>&gt; The low-bandwidth / m=
inimal-resource nature of these connections is<br>&gt; currently known only=
 by the initiator of the connection; this is<br>&gt; because the transactio=
n relay field in the version message is not a<br>&gt; permanent setting for=
 the lifetime of the connection.=C2=A0 Consequently, a<br>&gt; node receivi=
ng an inbound connection with transaction relay disabled<br>&gt; cannot dis=
tinguish between a peer that will never enable transaction<br>&gt; relay (a=
s described in BIP 37) and one that will...<br><br>However, as AJ points ou=
t in his response [12], the Bitcoin Core node<br>_does_ know whether transa=
ction relay can be supported as soon as the<br>`version` message is receive=
d:<br><br>&gt; [...] you either set m_tx_relay-&gt;fRelayTxes to true via t=
he VERSION<br>&gt; message (either explicitly or by not setting fRelay), or=
 you enable it<br>&gt; later with FILTERLOAD or FILTERCLEAR, both of which =
will cause a<br>&gt; disconnect if bloom filters aren&#39;t supported. Bloo=
m filter support is<br>&gt; (optionally?) indicated via a service bit (BIP =
111), so you could<br>&gt; assume you know whether they&#39;re supported as=
 soon as you receive the<br>&gt; VERSION line.<br><br>i.e. if Bitcoin Core =
node is running under normal configuration with<br>bloom filters disabled f=
or public connections (which is both the default<br>setting and highly reco=
mmended due to DoS concerns), then as soon as it<br>receives a `version` me=
ssage with `fRelay=3Dfalse`, it can be sure that<br>there will never be any=
 transaction relay with that peer. If the peer<br>later tries to enable tra=
nsaction relay by sending a `filterload`<br>message, then the node will dis=
connect that peer immediately.<br><br>In summary, we can continue using the=
 `fRelay` field to indicate that<br>no transaction relay can happen for the=
 entire lifetime of the<br>connection.=C2=A0 Bitcoin Core can postpone allo=
cating resources for<br>transaction relay data structures until after the v=
ersion message has<br>been received to minimize resource usage for incoming=
 block-relay-only<br>connections. A rough implementation is here[13]. Obvio=
usly, a node that<br>has been configured to serve bloom filters on public c=
onnections would<br>not be able to take advantage of this and accept additi=
onal incoming<br>block-relay-only peers, but I think that&#39;s fine - we a=
lready discourage<br>that configuration.<br><br>I think a good counter-argu=
ment against simply using `fRelay` for this<br>purpose is that we shouldn&#=
39;t reuse a protocol feature designed for one<br>function to achieve a tot=
ally different aim. However, we know that nodes<br>on the network have been=
 using `fRelay` to disable transaction relay<br>since Bitcoin Core version =
0.12 (when `-blocksonly` was added), and that<br>usage was expanded to _all=
_ nodes running Bitcoin Core version 0.19 or<br>later (when block-relay-onl=
y connections were introduced), so using<br>`fRelay` to disable transaction=
 relay is now de facto part of the p2p<br>protocol.<br><br># Preventing add=
r black holes<br><br>Addresses of potential peers are gossiped around the p=
2p network using<br>`addr` messages. When a Bitcoin Core node learns of a n=
ew `addr` record,<br>it will relay that record to one or two of its peers, =
chosen at<br>random[14]. The idea is that eventually the `addr` record will=
 reach<br>most of the nodes on the network.<br><br>If there are too many no=
des on the network that receive `addr` records<br>and do not relay those re=
cords on to their peers (termed _addr black<br>hole_ nodes), then propagati=
on of those `addr` records suffers -- any<br>individual `addr` record is un=
likely to reach a large proportion of<br>nodes on the network.<br><br>Since=
 a motivation for block-relay-only connections is to protect<br>against ecl=
ipse attacks and thwart network topology analysis, Bitcoin<br>Core will not=
 relay `addr` records on those connections, and will ignore<br>any `addr` r=
ecord received over those connections. Therefore, increasing<br>the number =
of block-relay-only connections without changing the `addr`<br>gossip logic=
 is likely to increase the prevalence of addr black holes,<br>and negativel=
y impact addr propagation. This is why BIP 338 includes:<br><br>&gt; It is =
RECOMMENDED that a node that has sent or received a disabletx<br>&gt; messa=
ge to/from a peer not send any of these messages to the peer:<br>&gt; <br>&=
gt; - addr/getaddr<br>&gt; - addrv2 (BIP 155)<br><br>I think a better appro=
ach would be for Bitcoin Core to only relay addr<br>records to an inbound p=
eer if it has previously received an `addr` or<br>`addrv2` message from tha=
t peer, since that indicates definitively that<br>the peer actively gossips=
 `addr` records. This approach was first<br>suggested by AJ in the original=
 block-relay-only PR[15].<br><br>An advantage of this approach is that it w=
ill improve addr propagation<br>immediately and without any change to the P=
2P protocol, and will prevent<br>sending `addr` records to all addr black h=
oles (such as light clients),<br>not just incoming block-relay-only connect=
ions.<br><br># Conclusion<br><br>We can increase the permitted number of in=
bound block-relay-only peers<br>while minimizing resource requirement _and_=
 improving addr record<br>propagation, without any changes to the p2p proto=
col required.<br><br>I propose that for Bitcoin Core version 22.0:<br><br>-=
 only initialize the transaction relay data structures after the<br>=C2=A0 =
`version` message is received, and only if fRelay=3Dtrue and<br>=C2=A0 `NOD=
E_BLOOM` is not offered on this connection.<br>- only initialize the addr d=
ata structures for inbound connections when<br>=C2=A0 an `addr`, `addrv2` o=
r `getaddr` message is received on the<br>=C2=A0 connection, and only consi=
der a connection for addr relay if its addr<br>=C2=A0 data structures are i=
nitialized.<br>- update the inbound eviction logic to protect more inbound =
peers which<br>=C2=A0 do not have transaction relay data structures.<br><br=
>Then, in version 23.0:<br><br>- modestly increase the number of outbound b=
lock-relay-only connections.<br><br>John<br><br>[1] <a href=3D"https://gith=
ub.com/bitcoin/bips/blob/master/bip-0037.mediawiki" target=3D"_blank">https=
://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki</a><br>[2] <a hre=
f=3D"https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki" target=
=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki<=
/a><br>[3] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0111.=
mediawiki" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bi=
p-0111.mediawiki</a><br>[4] <a href=3D"https://github.com/bitcoin/bitcoin/p=
ull/1795" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/1795</a=
><br>[5] <a href=3D"https://github.com/bitcoin/bitcoin/pull/2763" target=3D=
"_blank">https://github.com/bitcoin/bitcoin/pull/2763</a><br>[6] <a href=3D=
"https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c=
6e304d/src/net_processing.cpp#L2582-L2583" target=3D"_blank">https://github=
.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba163c6e304d/src/net_=
processing.cpp#L2582-L2583</a><br>[7] <a href=3D"https://github.com/bitcoin=
/bitcoin/pull/6579" target=3D"_blank">https://github.com/bitcoin/bitcoin/pu=
ll/6579</a><br>[8] <a href=3D"https://github.com/bitcoin/bitcoin/pull/7708"=
 target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/7708</a><br>[9] =
<a href=3D"https://github.com/bitcoin/bitcoin/pull/16152" target=3D"_blank"=
>https://github.com/bitcoin/bitcoin/pull/16152</a><br>[10] <a href=3D"https=
://github.com/bitcoin/bitcoin/pull/6993" target=3D"_blank">https://github.c=
om/bitcoin/bitcoin/pull/6993</a><br>[11] <a href=3D"https://github.com/bitc=
oin/bitcoin/pull/15759" target=3D"_blank">https://github.com/bitcoin/bitcoi=
n/pull/15759</a><br>[12] <a href=3D"https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2021-January/018347.html" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018347.html</a><br>[=
13] <a href=3D"https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-p=
eer" target=3D"_blank">https://github.com/jnewbery/bitcoin/tree/2021-02-laz=
y-init-peer</a><br>[14] <a href=3D"https://github.com/bitcoin/bitcoin/blob/=
e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700=
" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3c=
f3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700</a><br>[15] <a=
 href=3D"https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-5270127=
57" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/15759#issueco=
mment-527012757</a><br><br>&gt; Hi,<br>&gt; <br>&gt; I&#39;m proposing the =
addition of a new, optional p2p message to allow peers to communicate that =
they do not want to send or receive (loose) transactions for the lifetime o=
f a connection. <br>&gt; <br>&gt; The goal of this message is to help facil=
itate connections on the network over which only block-related data (blocks=
/headers/compact blocks/etc) are relayed, to create low-resource connection=
s that help protect against partition attacks on the network.=C2=A0 In part=
icular, by adding a network message that communicates that transactions wil=
l not be relayed for the life of the connection, we ease the implementation=
 of software that could have increased inbound connection limits for such p=
eers, which in turn will make it easier to add additional persistent block-=
relay-only connections on the network -- strengthening network security for=
 little additional bandwidth.<br>&gt; <br>&gt; Software has been deployed f=
or over a year now which makes such connections, using the BIP37/BIP60 &quo=
t;fRelay&quot; field in the version message to signal that transactions sho=
uld not be sent initially.=C2=A0 However, BIP37 allows for transaction rela=
y to be enabled later in the connection&#39;s lifetime, complicating softwa=
re that would try to distinguish inbound peers that will never relay transa=
ctions from those that might.<br>&gt; <br>&gt; This proposal would add a si=
ngle new p2p message, &quot;disabletx&quot;, which (if used at all) must be=
 sent between version and verack.=C2=A0 I propose that this message is vali=
d for peers advertising protocol version 70017 or higher.=C2=A0 Software is=
 free to implement this BIP or ignore this message and remain compatible wi=
th software that does implement it.<br>&gt; <br>&gt; Full text of the propo=
sed BIP is below.<br>&gt; <br>&gt; Thanks,<br>&gt; Suhas<br>&gt; <br>&gt; -=
--------------------------------------------------<br>&gt; <br>&gt; &lt;pre=
&gt;<br>&gt; =C2=A0 BIP: XXX<br>&gt; =C2=A0 Layer: Peer Services<br>&gt; =
=C2=A0 Title: Disable transaction relay message<br>&gt; =C2=A0 Author: Suha=
s Daftuar &lt;<a href=3D"mailto:sdaftuar@chaincode.com" target=3D"_blank">s=
daftuar@chaincode.com</a>&gt;<br>&gt; =C2=A0 Comments-Summary: No comments =
yet.<br>&gt; =C2=A0 Comments-URI:<br>&gt; =C2=A0 Status: Draft<br>&gt; =C2=
=A0 Type: Standards Track<br>&gt; =C2=A0 Created: 2020-09-03<br>&gt; =C2=A0=
 License: BSD-2-Clause<br>&gt; &lt;/pre&gt;<br>&gt; <br>&gt; =3D=3DAbstract=
=3D=3D<br>&gt; <br>&gt; This BIP describes a change to the p2p protocol to =
allow a node to tell a peer<br>&gt; that a connection will not be used for =
transaction relay, to support<br>&gt; block-relay-only connections that are=
 currently in use on the network.<br>&gt; <br>&gt; =3D=3DMotivation=3D=3D<b=
r>&gt; <br>&gt; For nearly the past year, software has been deployed[1] whi=
ch initiates<br>&gt; connections on the Bitcoin network and sets the transa=
ction relay field<br>&gt; (introduced by BIP 37 and also defined in BIP 60)=
 to false, to prevent<br>&gt; transaction relay from occurring on the conne=
ction. Additionally, addr messages<br>&gt; received from the peer are ignor=
ed by this software.<br>&gt; <br>&gt; The purpose of these connections is t=
wo-fold: by making additional<br>&gt; low-bandwidth connections on which bl=
ocks can propagate, the robustness of a<br>&gt; node to network partitionin=
g attacks is strengthened.=C2=A0 Additionally, by not<br>&gt; relaying tran=
sactions and ignoring received addresses, the ability of an<br>&gt; adversa=
ry to learn the complete network graph (or a subgraph) is reduced[2],<br>&g=
t; which in turn increases the cost or difficulty to an attacker seeking to=
 carry<br>&gt; out a network partitioning attack (when compared with having=
 such knowledge).<br>&gt; <br>&gt; The low-bandwidth / minimal-resource nat=
ure of these connections is currently<br>&gt; known only by the initiator o=
f the connection; this is because the transaction<br>&gt; relay field in th=
e version message is not a permanent setting for the lifetime<br>&gt; of th=
e connection.=C2=A0 Consequently, a node receiving an inbound connection wi=
th<br>&gt; transaction relay disabled cannot distinguish between a peer tha=
t will never<br>&gt; enable transaction relay (as described in BIP 37) and =
one that will.=C2=A0 Moreover,<br>&gt; the node also cannot determine that =
the incoming connection will ignore relayed<br>&gt; addresses; with that kn=
owledge a node would likely choose other peers to<br>&gt; receive announced=
 addresses instead.<br>&gt; <br>&gt; This proposal adds a new, optional mes=
sage that a node can send a peer when<br>&gt; initiating a connection to th=
at peer, to indicate that connection should not be<br>&gt; used for transac=
tion-relay for the connection&#39;s lifetime. In addition, without<br>&gt; =
a current mechanism to negotiate whether addresses should be relayed on a<b=
r>&gt; connection, this BIP suggests that address messages not be sent on l=
inks where<br>&gt; tx-relay has been disabled.<br>&gt; <br>&gt; =3D=3DSpeci=
fication=3D=3D<br>&gt; <br>&gt; # A new disabletx message is added, which i=
s defined as an empty message where pchCommand =3D=3D &quot;disabletx&quot;=
.<br>&gt; # The protocol version of nodes implementing this BIP must be set=
 to 70017 or higher.<br>&gt; # If a node sets the transaction relay field i=
n the version message to a peer to false, then the disabletx message MAY al=
so be sent in response to a version message from that peer if the peer&#39;=
s protocol version is &gt;=3D 70017. If sent, the disabletx message MUST be=
 sent prior to sending a verack.<br>&gt; # A node that has sent or received=
 a disabletx message to/from a peer MUST NOT send any of these messages to =
the peer:<br>&gt; ## inv messages for transactions<br>&gt; ## getdata messa=
ges for transactions<br>&gt; ## getdata messages for merkleblock (BIP 37)<b=
r>&gt; ## filteradd/filterload/filterclear (BIP 37)<br>&gt; ## mempool (BIP=
 35)<br>&gt; # It is RECOMMENDED that a node that has sent or received a di=
sabletx message to/from a peer not send any of these messages to the peer:<=
br>&gt; ## addr/getaddr<br>&gt; ## addrv2 (BIP 155)<br>&gt; # The behavior =
regarding sending or processing other message types is not specified by thi=
s BIP.<br>&gt; # Nodes MAY decide to not remain connected to peers that sen=
d this message (for example, if trying to find a peer that will relay trans=
actions).<br>&gt; <br>&gt; =3D=3DCompatibility=3D=3D<br>&gt; <br>&gt; Nodes=
 with protocol version &gt;=3D 70017 that do not implement this BIP, and no=
des<br>&gt; with protocol version &lt; 70017, will continue to remain compa=
tible with<br>&gt; implementing software: transactions would not be relayed=
 to peers sending the<br>&gt; disabletx message (provided that BIP 37 or BI=
P 60 has been implemented), and while<br>&gt; periodic address relay may st=
ill take place, software implementing this BIP<br>&gt; should not be discon=
necting such peers solely for that reason.<br>&gt; <br>&gt; Disabling addre=
ss relay is suggested but not required by this BIP, to allow for<br>&gt; fu=
ture protocol extensions that might specify more carefully how address rela=
y<br>&gt; is to be negotiated. This BIP&#39;s recommendations for software =
to not relay<br>&gt; addresses is intended to be interpreted as guidance in=
 the absence of any such<br>&gt; future protocol extension, to accommodate =
existing software behavior.<br>&gt; <br>&gt; Note that all messages specifi=
ed in BIP 152, including blocktxn and<br>&gt; getblocktxn, are permitted be=
tween peers that have sent/received a disabletx<br>&gt; message, subject to=
 the feature negotiation of BIP 152.<br>&gt; <br>&gt; =3D=3DImplementation=
=3D=3D<br>&gt; <br>&gt; TBD<br>&gt; <br>&gt; =3D=3DReferences=3D=3D<br>&gt;=
 <br>&gt; # Bitcoin Core has [<a href=3D"https://github.com/bitcoin/bitcoin=
/pull/15759" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/1575=
9</a> implemented this functionality] since version 0.19.0.1, released in N=
ovember 2019.<br>&gt; # For example, see <a href=3D"https://www.cs.umd.edu/=
projects/coinscope/coinscope.pdf" target=3D"_blank">https://www.cs.umd.edu/=
projects/coinscope/coinscope.pdf</a> and <a href=3D"https://arxiv.org/pdf/1=
812.00942.pdf" target=3D"_blank">https://arxiv.org/pdf/1812.00942.pdf</a>.<=
br>&gt; <br>&gt; =3D=3DCopyright=3D=3D<br>&gt; <br>&gt; This BIP is license=
d under the 2-clause BSD license.<br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 6, 2021 at 4:35 PM Suhas D=
aftuar via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<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=
"ltr">Hi,<div><br></div><div>I&#39;m proposing the addition of a new, optio=
nal p2p message to allow peers to communicate that they do not want to send=
 or receive (loose) transactions for the lifetime of a connection.=C2=A0</d=
iv><div><br></div><div>The goal of this message is to help facilitate=C2=A0=
connections on the network over which only block-related data (blocks/heade=
rs/compact blocks/etc) are relayed, to create low-resource connections that=
 help protect against partition attacks on the network.=C2=A0 In particular=
, by adding a network message that communicates that transactions will not =
be relayed for the life of the connection, we ease the implementation of so=
ftware that could have increased inbound connection limits for such peers, =
which in turn will make it easier to add additional persistent block-relay-=
only connections on the network -- strengthening network security for littl=
e additional bandwidth.</div><div><br></div><div>Software has been deployed=
 for over a year now which makes such connections, using the BIP37/BIP60 &q=
uot;fRelay&quot; field in the version message to signal that transactions s=
hould not be sent initially.=C2=A0 However, BIP37 allows for transaction re=
lay to be enabled=C2=A0later in the connection&#39;s lifetime, complicating=
 software that would try to distinguish inbound peers that will never relay=
 transactions from those that might.</div><div><br></div><div>This proposal=
 would add a single new p2p message, &quot;disabletx&quot;, which (if used =
at all) must be sent between version and verack.=C2=A0 I propose that this =
message is valid for peers advertising protocol version 70017 or higher.=C2=
=A0 Software=C2=A0is free to implement this BIP or ignore this message and =
remain compatible with software that does implement it.</div><div><br></div=
><div>Full text of the proposed BIP is below.</div><div><br></div><div>Than=
ks,<br></div><div>Suhas<br></div><div><br></div><div>----------------------=
-----------------------------</div><div><br></div><div><pre style=3D"color:=
rgb(0,0,0);white-space:pre-wrap">&lt;pre&gt;
  BIP: XXX
  Layer: Peer Services
  Title: Disable transaction relay message
  Author: Suhas Daftuar &lt;<a href=3D"mailto:sdaftuar@chaincode.com" targe=
t=3D"_blank">sdaftuar@chaincode.com</a>&gt;
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Draft
  Type: Standards Track
  Created: 2020-09-03
  License: BSD-2-Clause
&lt;/pre&gt;

=3D=3DAbstract=3D=3D

This BIP describes a change to the p2p protocol to allow a node to tell a p=
eer
that a connection will not be used for transaction relay, to support
block-relay-only connections that are currently in use on the network.

=3D=3DMotivation=3D=3D

For nearly the past year, software has been deployed[1] which initiates
connections on the Bitcoin network and sets the transaction relay field
(introduced by BIP 37 and also defined in BIP 60) to false, to prevent
transaction relay from occurring on the connection. Additionally, addr mess=
ages
received from the peer are ignored by this software.

The purpose of these connections is two-fold: by making additional
low-bandwidth connections on which blocks can propagate, the robustness of =
a
node to network partitioning attacks is strengthened.  Additionally, by not
relaying transactions and ignoring received addresses, the ability of an
adversary to learn the complete network graph (or a subgraph) is reduced[2]=
,
which in turn increases the cost or difficulty to an attacker seeking to ca=
rry
out a network partitioning attack (when compared with having such knowledge=
).

The low-bandwidth / minimal-resource nature of these connections is current=
ly
known only by the initiator of the connection; this is because the transact=
ion
relay field in the version message is not a permanent setting for the lifet=
ime
of the connection.  Consequently, a node receiving an inbound connection wi=
th
transaction relay disabled cannot distinguish between a peer that will neve=
r
enable transaction relay (as described in BIP 37) and one that will.  Moreo=
ver,
the node also cannot determine that the incoming connection will ignore rel=
ayed
addresses; with that knowledge a node would likely choose other peers to
receive announced addresses instead.

This proposal adds a new, optional message that a node can send a peer when
initiating a connection to that peer, to indicate that connection should no=
t be
used for transaction-relay for the connection&#39;s lifetime. In addition, =
without
a current mechanism to negotiate whether addresses should be relayed on a
connection, this BIP suggests that address messages not be sent on links wh=
ere
tx-relay has been disabled.

=3D=3DSpecification=3D=3D

# A new disabletx message is added, which is defined as an empty message wh=
ere pchCommand =3D=3D &quot;disabletx&quot;.
# The protocol version of nodes implementing this BIP must be set to 70017 =
or higher.
# If a node sets the transaction relay field in the version message to a pe=
er to false, then the disabletx message MAY also be sent in response to a v=
ersion message from that peer if the peer&#39;s protocol version is &gt;=3D=
 70017. If sent, the disabletx message MUST be sent prior to sending a vera=
ck.
# A node that has sent or received a disabletx message to/from a peer MUST =
NOT send any of these messages to the peer:
## inv messages for transactions
## getdata messages for transactions
## getdata messages for merkleblock (BIP 37)
## filteradd/filterload/filterclear (BIP 37)
## mempool (BIP 35)
# It is RECOMMENDED that a node that has sent or received a disabletx messa=
ge to/from a peer not send any of these messages to the peer:
## addr/getaddr
## addrv2 (BIP 155)
# The behavior regarding sending or processing other message types is not s=
pecified by this BIP.
# Nodes MAY decide to not remain connected to peers that send this message =
(for example, if trying to find a peer that will relay transactions).

=3D=3DCompatibility=3D=3D

Nodes with protocol version &gt;=3D 70017 that do not implement this BIP, a=
nd nodes
with protocol version &lt; 70017, will continue to remain compatible with
implementing software: transactions would not be relayed to peers sending t=
he
disabletx message (provided that BIP 37 or BIP 60 has been implemented), an=
d while
periodic address relay may still take place, software implementing this BIP
should not be disconnecting such peers solely for that reason.

Disabling address relay is suggested but not required by this BIP, to allow=
 for
future protocol extensions that might specify more carefully how address re=
lay
is to be negotiated. This BIP&#39;s recommendations for software to not rel=
ay
addresses is intended to be interpreted as guidance in the absence of any s=
uch
future protocol extension, to accommodate existing software behavior.

Note that all messages specified in BIP 152, including blocktxn and
getblocktxn, are permitted between peers that have sent/received a disablet=
x
message, subject to the feature negotiation of BIP 152.

=3D=3DImplementation=3D=3D

TBD

=3D=3DReferences=3D=3D

# Bitcoin Core has [<a href=3D"https://github.com/bitcoin/bitcoin/pull/1575=
9" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/15759</a> impl=
emented this functionality] since version 0.19.0.1, released in November 20=
19.
# For example, see <a href=3D"https://www.cs.umd.edu/projects/coinscope/coi=
nscope.pdf" target=3D"_blank">https://www.cs.umd.edu/projects/coinscope/coi=
nscope.pdf</a> and <a href=3D"https://arxiv.org/pdf/1812.00942.pdf" target=
=3D"_blank">https://arxiv.org/pdf/1812.00942.pdf</a>.

=3D=3DCopyright=3D=3D

This BIP is licensed under the 2-clause BSD license.</pre></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000dcdff005bc9572c6--