- 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
- 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
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).