diff options
| author | Gleb Naumenko <naumenko.gs@gmail.com> | 2019-09-30 11:49:54 +0300 |
|---|---|---|
| committer | Gleb Naumenko <naumenko.gs@gmail.com> | 2019-09-30 11:49:54 +0300 |
| commit | 32af098957cce3845c02d199483adf4e3948eb57 (patch) | |
| tree | dfc364636585dd59c8e551f855874bedbaf46dee | |
| parent | 0ee067c70e23aafa8ba433179adabf37181ab13e (diff) | |
| download | bips-32af098957cce3845c02d199483adf4e3948eb57.tar.xz | |
minor fixes
Co-authored-by: Rusty Russel <rusty@rustcorp.com.au>
| -rw-r--r-- | bip-reconcil.mediawiki | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/bip-reconcil.mediawiki b/bip-reconcil.mediawiki index cf53776..61d3968 100644 --- a/bip-reconcil.mediawiki +++ b/bip-reconcil.mediawiki @@ -134,7 +134,7 @@ Its payload consists of: |- | bool || responder || Indicates whether the sender will respond to "reqreconcil" messages. |- -| uint32 || version || Must be exactly 1 currently. +| uint32 || version || Sender must set this to 1 currently, otherwise receiver should ignore the message. |- | uint64 || salt || The salt used in the short transaction ID computation. |} @@ -149,7 +149,7 @@ The reqreconcil message initiates a reconciliation round. |- | uint16 || set_size || Size of the sender's reconciliation set, used to estimate set difference. |- -| uint8 || q || Coefficient used to estimate set difference. +| 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. |} 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 This BIP suggests a stateful protocol and it requires storing several variables at every node to operate properly. ====Reconciliation sets==== -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. +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. Incoming transactions are added to sets when those transactions are received (if they satisfy the policies such as minimum fee set by a peer). A reconciliation set is moved to the corresponding set snapshot after the transmission of the initial sketch. @@ -261,7 +261,7 @@ Clients which do not implement this protocol remain fully compatible after this ====Why using PinSketch for set reconciliation?==== -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. +PinSketch is more bandwidth efficient than IBLT, especially for the small differences in sets we expect to operate over. PinSketch is as bandwidth efficient as CPISync, but PinSketch has quadratic decoding complexity, while CPISync have cubic decoding complexity. This makes PinSketch significantly faster. ====Why using 32-bit short transaction IDs?==== |