snowball protocol (rough draft)

snowball.md

General Workflow

• Mobile wallet prepares a transaction in PSBT format
• Mobile wallet calls snowball.enroll(psbt)
  • Invites all connected peers to add equal-sized inputs and outputs to the PSBT
  • Asynchronous with timeout
  • This would take soem kind of settings object including:
    • Who pays the fees
    • TODO: what else
• Mobile wallet updates outputs to according to fee settings and desired fee rate
  • Snowball could also do this, but perhaps wallets don't want to outsource too heavily ...
• Mobile wallet signs their inputs
• Mobile wallet calls snowball.sign(psbt)
  • Sends the updated psbt to peers, and each peer sends it back with their inputs signed
  • Snowball combines the PSBT and returns a serialized bitcoin TX
  • Asynchronous with timeout
• Mobile wallet checks that transaction is legit, and broadcasts

Questions

• How should devices advertisse themselves "snowball-capable"?
  • I know bluetooth has some version bits
  • We don't want our phone to advertise that it has bitcoins on it. That would be bad.
  • Perhaps the payer could just ping every nearby device with a message asking "do you want to snowball?". This way we avoid broadcasting that we own bitcoin unnecessarily

If snowball takes care of adjusting fees (bullet point #3), then we could combine snowball.enroll with snowball.sign. The wallet would just call snowball and snowball would try its best to add some inputs/outputs. This would integrating snowball very easy ...

From the iOS perspective, am I right in assuming we are trying to create a framework/pod for use by other wallets? I would guess we would have to create a proof-of-concept (POC) wallet as well. Lately, folks have been creating playgrounds to show devs how to use their framework too.

Regarding snowball advertisement. I would think a reasonable approach would be for a wallet to advertise "I want to snowball" and any wallets that want to participate would respond and possibly join. The advertiser would be "leaking" the fact it had bitcoins, which I guess is OK.

I'm guessing we would want to have all the BLE traffic encrypted. Wondering if a listener could gather enough information to steal coins. Also thinking of other threat models.

Some edge cases to think about are wallets going in and out of BLE range. I guess it's a matter of good timeouts and state machines that do the right thing so the wallets don't appear to lock-up (and lots of testing).