Split Ticket Service & Client
This is a beta release of the split ticket buyer service and client. Please
read the instructions for joining the beta.
macOS version provided by @girino.
Changelog for vesion 0.7.0
Note: This version bumps the protocol version to 4 so it is incompatible to previous versions (see below for explanations).
User facing changes
- OpenBSD support (thanks @dajohi!)
- Send buyer errors back to service for easier debugging
- Various log improvements (now using the same log format as other decred tools)
- Reduce split tx overcommit requirement (from 0.3 DCR to ~0.01 DCR)
- Support for SPV clients by using dcrdata for utxo fetching
Internal Changes
- Add tests to prevent usage of too many inputs in split transaction
- Better report error when testing for funds in buyer
- Add tests to prevent users acting on the wrong stage of the session
- Continuously test for blockchain sync between buyer and matcher
- Ability to execute an arbitrary command on service after a session is successfully completed.
Session Token & Bump to Protocol V4
This version of the buyer and service adds a new return value to the FindMatches() grpc call: session_token.
This is an opaque blob of data that must be returned by the buyer to the service in the subsequent calls for building the split ticket session. If the values are different, then the service will drop the request from the buyer.
The main purpose of this change is to discourage attempts at disrupting the session by an impersonator guessing the session id of another participant.
While this couldn't allow stealing of funds, it could allow a service to mistakenly identify a buyer as disruptive and black list it.
Given that this is a new required field in all messages, the protocol version had to be bumped.
SPV Client Support
SPV client support has been added, with a few privacy caveats.
The main requirement for network connection on the buyer is to be able to fetch other participant's utxos, so that it can ensure the split transaction is being funded with the correct amount of coins and that the utxos haven't actually been spent (which would invalidate the whole session).
On SPV clients, given that the wallet does not actually have access to a full node daemon, we need a different way of fetching the utxos. For this version, spv clients will use dcrdata to fetch the outstanding utxo information.
While this shouldn't be a security issue, it is a privacy issue, since it is providing information to dcrdata operators of an upcoming split ticket being built with the given utxos. Users should evaluate the potential privacy implication of this when deciding whether to use the split service with spv wallets.
In the future, once header commitments include a utxo set commitment and we can check for inclusion via wallet grpc commands, this is likely to be dropped.