New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mixing: Add mixpool package. #3082
base: master
Are you sure you want to change the base?
Conversation
2d0d3c6
to
36b835e
Compare
5c698ec
to
18f2b89
Compare
cfa0c3d
to
c19fc08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think almost all of this should be an internal package, just like mempool
. Since mixing
is a development module for the time being, it's fine, but ultimately I really don't want to go back to having a huge surface of exposed code that really is specifically for the server itself.
I expect that some of it the code should be shared, akin to how blockchain/standalone
does it, but pretty much everything in mixpool.go
, mixpool_test.go
, and log.go
, at least, should be internal.
Not possible with current design.
This is because the mixclient package expects the wallet interface to provide an accessor function for the mixpool. |
8120f7b
to
65c2a80
Compare
The mixpool package implements a memory pool of recently observed mix messages. Similar to the transaction mempool, the mixpool allows these messages to be temporarily stored in memory to be relayed through the P2P network. It handles message acceptance, expiry, UTXO ownership proof checks, and that previously referenced messages have also been accepted to the mixpool. The mixpool is designed with both full-node and wallet usage in mind, providing all of these same acceptance rules to mixing wallets with the exception of UTXO proof checks. For wallets, it also implements query functions for messages matching compatible pairings and messages belong to ongoing sessions.
The
mixpool
package implements a memory pool of recently observed mix messages. Similar to the transactionmempool
, themixpool
allows these messages to be temporarily stored in memory to be relayed through the P2P network. It handles message acceptance, expiry, UTXO ownership proof checks, and that previously referenced messages have also been accepted to themixpool
.The
mixpool
is designed with both full-node and wallet usage in mind, providing all of these same acceptance rules to mixing wallets with the exception of UTXO proof checks. For wallets, it also implements query functions for messages matching compatible pairings and messages belong to ongoing sessions.Requires #3207.