You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-reconcil.mediawiki
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -134,7 +134,7 @@ Its payload consists of:
134
134
|-
135
135
| bool || responder || Indicates whether the sender will respond to "reqreconcil" messages.
136
136
|-
137
-
| uint32 || version || Must be exactly 1 currently.
137
+
| uint32 || version || Sender must set this to 1 currently, otherwise receiver should ignore the message.
138
138
|-
139
139
| uint64 || salt || The salt used in the short transaction ID computation.
140
140
|}
@@ -149,7 +149,7 @@ The reqreconcil message initiates a reconciliation round.
149
149
|-
150
150
| uint16 || set_size || Size of the sender's reconciliation set, used to estimate set difference.
151
151
|-
152
-
| uint8 || q || Coefficient used to estimate set difference.
152
+
| uint8 || q || Coefficient used to estimate set difference. Multiplied by PRECISION=2^6 and rounded up by the sender and divided by PRECISION by the receiver.
153
153
|}
154
154
155
155
Upon receipt of a "reqreconcil" message, the receiver:
@@ -235,7 +235,7 @@ Upon receipt a "gettx" message, a node sends "tx" messages for the requested tra
235
235
This BIP suggests a stateful protocol and it requires storing several variables at every node to operate properly.
236
236
237
237
====Reconciliation sets====
238
-
Every node stores sets of 128-bit truncated IDs per every peer, representing the transactions which would have been sent according to the regular flooding protocol.
238
+
Every node stores a set of 128-bit truncated IDs for every peer which supports transaction reconciliation, representing the transactions which would have been sent according to the regular flooding protocol.
239
239
Incoming transactions are added to sets when those transactions are received (if they satisfy the policies such as minimum fee set by a peer).
240
240
A reconciliation set is moved to the corresponding set snapshot after the transmission of the initial sketch.
241
241
@@ -261,7 +261,7 @@ Clients which do not implement this protocol remain fully compatible after this
261
261
262
262
====Why using PinSketch for set reconciliation?====
263
263
264
-
To the best of our knowledge, PinSketch is more bandwidth efficient than IBLT, especially for the small differences in sets we expect to operate over.
264
+
PinSketch is more bandwidth efficient than IBLT, especially for the small differences in sets we expect to operate over.
265
265
PinSketch is as bandwidth efficient as CPISync, but PinSketch has quadratic decoding complexity, while CPISync have cubic decoding complexity. This makes PinSketch significantly faster.
0 commit comments