Dog Pack: A Proposal for Private In-Round Bark Transfers

Protocol Lightning on Ark
1

I have a new proposal on how refreshes can be made more private.

The core of my proposal focuses on breaking the link between input attestation and output declaration.

VTXO ATTESTATION

Attestation works by having the user generate keypairs to register with a denomination of the vtxo value being attested to. We call the public keys of these keypairs slot_pubkeys. The ASP knows which vtxo each slot_pubkey belongs to.

The ASP then coordinates with the participant to start a musig2 signing session for the forfeit and computes their partial signature. Unlike the normal Bark flow, this forfeit will omit its hashlock.

The ASP then publishes the public points corresponding to each partial signature scalar which is necessary for our output declaration mechanism.

OUTPUT DECLARATION

Output declaration works by having the user create a ring proof using the slot_pubkeys of all participants for the denomination of the output being declared. Each branch contains two public points, and the proof requires knowledge of both corresponding secrets.

The first public key in each branch is the slot_pubkey and the other is the desired output public key minus the forfeit point for that slot. Each branch therefore contains the tuple: (slot_pubkey[j], output_pubkey - forfeit_point[j]). The proof also includes a nullifier derived from the real slot to prevent using the same slot multiple times.

To construct their output, the user generates an offset keypair and sets output_pubkey = forfeit_point[j] + offset_pubkey, where j is the slot they own. This means they know the private key corresponding to output_pubkey - forfeit_point[j], allowing them to satisfy the second part of their real ring branch. They cannot yet sign for output_pubkey itself because they do not know the ASP’s partial-signature scalar corresponding to forfeit_point[j].

After every ring proof is submitted, the ASP creates the vtxo tree and the users submit their forfeits. If a user later exits and the ASP claims the forfeited vtxo, the completed forfeit signature reveals the ASP’s partial-signature scalar to that user. The user can add this scalar to their offset secret to recover the private key for their submitted output.

Additional details for the proposal can be found here:

It’s still a work in progress so feedback is welcome :smiley:

2

Thanks Randy, looks cool, we’ll take a closer look.

3

Hey Randy, cool to see people are thinking about this! My first thought: what is the benefit of this approach over the Wasabi approach? (I.e. user submits inputs and receives (round-exclusive) ecash tokens in denominations; user exchanges ecash tokens for outputs.)

4

The big difference between this proposal and what Wasabi is doing is that it tries to build anonymity across atomic swaps rather than having all participants live on a single transaction. To do that I had to include the forfeit as a trigger for atomicity which is one of the biggest challenges when working with atomic swaps in the bark model. The benefit of this approach is that it can mostly build on machinery Bark already needs rather than introducing a separate credentialing system.

I probably could have taken more from Wasabi’s credentialing system, but it would’ve made things more complicated since it would add more ways for things to go wrong in implementation. This proposal is a lot simpler imo, but maybe future iterations can incorporate their mechanism.

5

I think the research is pretty cool.

I do have some questions about DoS prevention.

The server has to ensure that rounds succeed at some point.
One problem is that a malicious client can sign up for a round and not follow through.
Our current approach is quite simple. If a round attempt fails we ban all bad participants and try again with only the good ones. We keep doing this until only good participants remain and the round succeeds.

A key challenge is that if the tie is broken between input and output.
How does the server know which participant it should ban?
One bad participant could just keep retrying rounds forever?

Is your proposal vulnerable to this?
How to approach that problem

6

In the current model, because vtxo tree signing uses keys that aren’t related to the round’s input vtxos, a malicious client can’t be identified at that stage. The only thing I could think of is penalizing each vtxo in that round by incrementing a potential_misbehavior score. Then trying to evenly split the participants in that round into 2 new rounds, potentially adding new participants to each.

If a malicious client keeps causing rounds to fail, then their potential_misbehavior score will keep rising until the coordinator eventually disallows that vtxo from trying to participate in new rounds.