Braidpool
Replies: 11 comments 5 replies
|
No need to wait for SV2 to stabilize, meanwhile all else can be hashed out, and different p2p impl. can be tried ... As an example using a message.io (FramedTCP Transport The braidpool repo README.md says "For the moment, the braidpool node runs a simple p2p broadcast. " huh ... [braidcast] ing, should use streams ?. The [invite] to join and get access to [beacon]s [peer-dictionary] can be a invite-code.onion => response would be a beacon that in turn uses invite code as ID for new [node]. [invite] |
|
Right now the code makes a TCP connection to itself and sends a "hello" message. There's no peer discovery yet. But obviously we need that. |
|
1 GB same machine Compiling message-io v0.18.0 (/opt/message-io) message-io Udp: Throughput: 5.15 GB/s native Udp: Throughput: 4.66 GB/s ///! 1 MB same machine Sending 1048576 bytes in chunks of 65507 bytes: message-io Udp: Throughput: 2.81 GB/s native Udp: Throughput: 3.83 GB/s |
|
We're looking for sending messages of a few kb, with as low latency at possible. We're more interested in latency than throughput. Given that a FEC network library doesn't seem to exist, in the short term we should prioritize simplicity and upgradability. |
|
|
|
[Braidcast] = System Message |
|
|
|
Better ? if [node] can receive aggregated Hashrate in [Bead] format directly ? ... |
|
A bead is a single sha256d hash solution. The set of beads is the "aggregated" hashrate and all nodes receive all beads. They'll be a few kb in size. It seems to me that we don't need two types of messages (system/latency priority). We're probably never going to care about throughput so should always use a latency optimized solution. |
|
per [node][block][[num-shares-weight]][ts-start][ts-end] do You have gossip ... else fetch - verify ... could be a control struct message after new tip to ensure each has correct DAG of last tip in epoch ... |
|
"The Web Native File System (WNFS) is a distributed file system. It is versioned, logged, programmable, has strong-yet-flexible security, and is fully controlled by the end user. Service providers can validate writes without reading the contents of the file system, and minimal metadata is leaked." "Nodes need to be encoded as dag-cbor." |
|
"Hash chains are a simple way to generate pseudorandom data, but are inefficient in situations that require long chains. This can cause unnecessary overhead for use cases including logical clocks, synchronizing the heads of a pseudorandom stream, or non-interactive key agreement. This paper presents the “skip ratchet”, a novel pseudorandom function that can be efficiently incremented by arbitrary intervals." https://github.com/wnfs-wg/spec/blob/main/spec/skip-ratchet.md |
|
@s2dd can you give some context as to how you think your linked ideas can be used in braidpool? |
|
recall some snippet on matrix from @pool2win regarding distributed Filesystem and find it interesting |
|
Range-Based Set Reconciliation "Range-based set reconciliation is a simple approach to ef- |
Uh oh!
There was an error while loading. Please reload this page.
Since there's been several discussions about P2P technology choices including #57 #63 #64 I thought I'd try out this new GitHub Discussions page, since neither Issues nor Pull Requests are necessarily the right place to have such discussions, and it seems due to the lack of low-latency P2P libraries we will probably be discussing this for some time.
All reactions