mirror of
https://github.com/bitcoin/bips.git
synced 2025-05-12 12:03:29 +00:00
minor fixes
Co-authored-by: Rusty Russel <rusty@rustcorp.com.au>
This commit is contained in:
parent
0ee067c70e
commit
32af098957
@ -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?====
|
||||
|
Loading…
x
Reference in New Issue
Block a user