Skip to content

Commit 32af098

Browse files
minor fixes
Co-authored-by: Rusty Russel <[email protected]>
1 parent 0ee067c commit 32af098

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

bip-reconcil.mediawiki

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -134,7 +134,7 @@ Its payload consists of:
134134
|-
135135
| bool || responder || Indicates whether the sender will respond to "reqreconcil" messages.
136136
|-
137-
| uint32 || version || Must be exactly 1 currently.
137+
| uint32 || version || Sender must set this to 1 currently, otherwise receiver should ignore the message.
138138
|-
139139
| uint64 || salt || The salt used in the short transaction ID computation.
140140
|}
@@ -149,7 +149,7 @@ The reqreconcil message initiates a reconciliation round.
149149
|-
150150
| uint16 || set_size || Size of the sender's reconciliation set, used to estimate set difference.
151151
|-
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.
153153
|}
154154
155155
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
235235
This BIP suggests a stateful protocol and it requires storing several variables at every node to operate properly.
236236
237237
====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.
239239
Incoming transactions are added to sets when those transactions are received (if they satisfy the policies such as minimum fee set by a peer).
240240
A reconciliation set is moved to the corresponding set snapshot after the transmission of the initial sketch.
241241
@@ -261,7 +261,7 @@ Clients which do not implement this protocol remain fully compatible after this
261261
262262
====Why using PinSketch for set reconciliation?====
263263
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.
265265
PinSketch is as bandwidth efficient as CPISync, but PinSketch has quadratic decoding complexity, while CPISync have cubic decoding complexity. This makes PinSketch significantly faster.
266266
267267
====Why using 32-bit short transaction IDs?====

0 commit comments

Comments
 (0)