<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" class="">bitcoin-dev@lists.linuxfoundation.org</a>> het volgende geschreven:</div><div class=""><div class=""><br class=""></div><div class="">==Motivation==<br class=""></div><div class=""><br class=""></div><div class="">One of the most powerful heuristic's employed by those whose goal is to undermine<br class=""></div><div class="">bitcoin's fungiblity has been to assume all inputs of a transaction are signed by<br class=""></div><div class="">a single party. In the few cases this assumption does not hold, it is generally<br class=""></div><div class="">readibly recognizable (e.g. traditional coinjoins have a very obvious structure,<br class=""></div><div class="">or multisig outputs are most frequently validated onchain).</div></div></blockquote><div><br class=""></div><div>In addition to mixers, custodial wallets and exchanges also contribute to breaking this heuristic; even though there’s a single entity signing multiple inputs, that entity doesn’t represent a single owner of the funds. As with mixers, exchanges and custodial wallets can sometimes be spotted as well, but we don’t know what percentage is missed.</div><div><br class=""></div><div>Breaking this heuristic at scale would be good, but do we know to what degree it’s already broken? Is there any empirical research measuring its accuracy and false positive rate?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Should bustapay enjoy widespread adoption, a "v2" specification</div><div class="">will be created with desired extensions.<br class=""></div></div></blockquote><div><br class=""></div><div>I would not put future promises in a BIP. Rather, explain how extension might work.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">==Specification==<br class=""></div><div class=""><br class=""></div><div class="">A bustapay payment is made from a sender to a receiver.<br class=""></div><div class=""><br class=""></div><div class="">Step 1. Sender creates a bitcoin transaction paying the receiver<br class=""></div><div class=""><br class=""></div><div class="">This transaction must be fully valid, signed and all inputs must use segwit. This transaction is known as the "template transaction”.</div></div></blockquote><div><br class=""></div><div>Using PSBT?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> This transaction must not be propagated on the bitcoin network.<br class=""></div></div></blockquote><div><br class=""></div><div>This can’t be guaranteed, and even after step 5 a reorg could cause it to get confirmed. It’s useful to explain why this doesn’t matter. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Step 2. Sender gives the "template transaction" to the receiver<br class=""></div><div class=""><br class=""></div><div class="">This would generally be done as an HTTP POST.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">The exact URL to submit it to could be specified with a bip21 encoded address. Such as bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=<a href="https://bp.bustabit.com/submit" class="">https://bp.bustabit.com/submit</a> and the HTTP body should be the raw transaction hex encoded as text.<br class=""></div></div></blockquote><div><br class=""></div><div><div>This seems too detailed. If you want to specify the message protocol, maybe that can have it’s own section where you list each of the messages, the URL, parameters and encoding. Then you can keep this overview section shorter.</div><div><br class=""></div><div>The use of HTTPS kind of forces sender and recipient to use a 3rd party service, even though this could done bilaterally. What if the payment request contained a (single-use) Onion URL an expiration date? The recipient would have to keep a hidden service up until the expiration date, though the sender could try again if there’s temporary reachability issue.</div><div><br class=""></div><div>Adding a (onion) URL to the the payment request also makes gradual adoption easier, because recipients don’t need to worry if senders support this protocol.</div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">Step 3. Receiver processes the transaction and returns a partially signed coinjoin<br class=""></div><div class=""><br class=""></div><div class="">The receiver validates the transaction is valid, pays himself and is eligible for propation. The receiver then adds one of his own inputs (known as the "contributed input") and increase the output that pays himself by the contributed input amount. Doing so will invalidate the "template transaction"'s original input signatures, so the sender needs to return this "partial transaction" back to the receiver to sign. This is returned as a hex-encoded raw transaction a response to the original HTTP POST request.<br class=""></div></div></blockquote><div><br class=""></div><div><blockquote type="cite" class=""><div class="">* Bustapay could be abused by a malicious party to query if you own a deposit address or not. So never accept a bustapay transaction that pays an already used deposit address</div></blockquote></div><div><br class=""></div><div>Indeed, once the recipient adds funds, they reveal more about themselves to the sender then they would otherwise. I think that needs more elaboration.</div><div><br class=""></div>I assume the transaction in step (1) is some sort of collateral to insure they’re not just trying to extract private information from you? However if fees are low they could still double-spend it after the recipient revealed their address, especially because the recipient has no way of RBF’ing the original (though CPFP could help). Perhaps require that the original transaction pays a fee based on the expected size of the final transaction?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">Notes for sending applications:</div><div class=""><br class=""></div><div class="">* The HTTP response must *not* be trusted. It should be fully validated that no unexpected changes have been made to the transaction.<br class=""></div></div></blockquote><div><br class=""></div><div>Not trusting anything is obvious. :-) It’s better to explicitly state what exactly needs to be verified (amounts, destinations, inputs, etc), and maybe list a few obvious shenanigans to watch out for.</div><div><br class=""></div><div>A more general concern is that the sender can’t know for sure the recipient really supports this protocol, so it should assume that whatever information it pings to some API could be used maliciously. In what ways could it be abused?</div></div><br class=""><div class="">Sjors</div></body></html>