bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00
Code Issues Releases Wiki Activity

minor fixes

Browse Source 
Co-authored-by: Rusty Russel <rusty@rustcorp.com.au>
This commit is contained in:
Gleb Naumenko 2019-09-30 11:49:54 +03:00
parent 0ee067c70e
commit 32af098957
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
bip-reconcil.mediawiki
View File

@ -134,7 +134,7 @@ Its payload consists of:
|- |-
| bool || responder || Indicates whether the sender will respond to "reqreconcil" messages. | 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. | 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. | 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: 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. This BIP suggests a stateful protocol and it requires storing several variables at every node to operate properly.
====Reconciliation sets==== ====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). 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. 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?==== ====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. 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?==== ====Why using 32-bit short transaction IDs?====