* [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format @ 2017-08-18 22:11 Andrew Chow 2017-08-21 0:00 ` Bryan Bishop 0 siblings, 1 reply; 5+ messages in thread From: Andrew Chow @ 2017-08-18 22:11 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1435 bytes --] Hi everyone, I would like to propose a standard format for unsigned and partially signed transactions. ===Abstract=== This document proposes a binary transaction format which contains the information necessary for a signer to produce signatures for the transaction and holds the signatures for an input while the input does not have a complete set of signatures. The signer can be offline as all necessary information will be provided in the transaction. ===Motivation=== Creating unsigned or partially signed transactions to be passed around to multiple signers is currently implementation dependent, making it hard for people who use different wallet software from being able to easily do so. One of the goals of this document is to create a standard and extensible format that can be used between clients to allow people to pass around the same transaction to sign and combine their signatures. The format is also designed to be easily extended for future use which is harder to do with existing transaction formats. Signing transactions also requires users to have access to the UTXOs being spent. This transaction format will allow offline signers such as air-gapped wallets and hardware wallets to be able to sign transactions without needing direct access to the UTXO set and without risk of being defrauded. The full text can be found here: https://github.com/achow101/bips/blob/bip-psbt/bip-psbt.mediawiki Andrew Chow [-- Attachment #2: Type: text/html, Size: 1886 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format 2017-08-18 22:11 [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format Andrew Chow @ 2017-08-21 0:00 ` Bryan Bishop 2017-08-21 18:12 ` Greg Sanders 0 siblings, 1 reply; 5+ messages in thread From: Bryan Bishop @ 2017-08-21 0:00 UTC (permalink / raw) To: Andrew Chow, Bitcoin Protocol Discussion, Bryan Bishop [-- Attachment #1: Type: text/plain, Size: 481 bytes --] On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > I would like to propose a standard format for unsigned and partially > signed transactions. > Just a quick note but perhaps you and other readers would find this thread (on hardware wallet BIP drafting) to be tangentially related and useful: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html - Bryan http://heybryan.org/ 1 512 203 0507 [-- Attachment #2: Type: text/html, Size: 1037 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format 2017-08-21 0:00 ` Bryan Bishop @ 2017-08-21 18:12 ` Greg Sanders 2017-08-21 21:36 ` Jochen Hoenicke 0 siblings, 1 reply; 5+ messages in thread From: Greg Sanders @ 2017-08-21 18:12 UTC (permalink / raw) To: Bryan Bishop, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4315 bytes --] Some related thoughts and suggestion for an extension that kanzure suggested I post here: Hardware Wallet attacks by input ownership omission and fix ---------------------------------------------------------------------------------- So a while back I realized that to have HW wallets do safe automated coinjoins(without any user interaction be sure there are no fee dumps or handing money to others) you have to protect yourself from the case of signing one set of inputs while the other owned set is hidden from the device, then repeating the same action with the two sets reversed. Note that there is no support for such a mode in HW wallets today, but could possibly greatly increase liquidity of JoinMarket like systems. First signing pass: 1 BTC (yours, host tells ledger about it) -------- > 1.5 BTC 1 BTC (yours, host fails to tell ledger about it)- Second signing pass: 1 BTC (yours, host fails to tell ledger) --------- > 1.5 BTC 1 BTC (yours, host tells ledger about it)--------- In this scenario, you sign the first input, thinking "great I'm getting 0.5 BTC for running coinjoin" when in reality this will simply be re-played again later with the inputs switched, *costing* you 0.5 BTC. (Ledger doesn't support "negative fees", but imagine more more inputs are included that aren't yours.) More recently I noticed a more common issue along the same lines: With Segwit inputs, the entire transaction referred to in the prevout is generally no longer included for HW wallet signing API. This greatly speeds up signing since potentially multiple MBs of transactions are no longer passed into the device, but comes with a cost: An attacker can claim certain inputs' value is much lower than it actually is. In the first pass, the host reports the first input's value properly, and the second as lower. The signature on the first input will go through fine(value included in the sighash is only for that input), then attacker prompts a restart of signing, reporting the 2nd value properly, and first value improperly low, which allows the attacker to report the same fee twice on the device. Both signatures over each input are correct, but the user was prompted with an invalid fee amount(too low). To fix this I consulted with andytoshi and got something we think works for both cases: 1) When a signing device receives a partially signed transaction, all inputs must come with a ownership proof: - For the input at address A, a signature over H(A || x) using the key for A. 'x' is some private fixed key that only the signing device knows(most likely some privkey along some unique bip32 path). - For each input ownership proof, the HW wallet validates each signature over the hashed message, then attempts to "decode" the hash by applying its own 'x'. If the hash doesn't match, it cannot be its own input. - Sign for every input that is yours This at a minimum makes sure that the wallet's total "balance" will not go down more than the reported fee. Benefits: - Still small memory footprint compared to legacy signing - Allows user-interactionless coinjoins without putting funds at risk - These proofs can be created at any time, collected at the front of any CoinJoin like protocol. - These proofs can be passed around as additional fields for Partially Signed Bitcoin Transactions: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014838.html On Sun, Aug 20, 2017 at 5:00 PM, Bryan Bishop via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> I would like to propose a standard format for unsigned and partially >> signed transactions. >> > > Just a quick note but perhaps you and other readers would find this thread > (on hardware wallet BIP drafting) to be tangentially related and useful: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2016-August/013008.html > > - Bryan > http://heybryan.org/ > 1 512 203 0507 <(512)%20203-0507> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 6160 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format 2017-08-21 18:12 ` Greg Sanders @ 2017-08-21 21:36 ` Jochen Hoenicke 2017-08-22 19:26 ` Greg Sanders 0 siblings, 1 reply; 5+ messages in thread From: Jochen Hoenicke @ 2017-08-21 21:36 UTC (permalink / raw) To: Greg Sanders, Bitcoin Protocol Discussion On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote: > To fix this I consulted with andytoshi and got something we think works > for both cases: > > 1) When a signing device receives a partially signed transaction, all > inputs must come with a ownership proof: > - For the input at address A, a signature over H(A || x) using the key > for A. 'x' is some private fixed key that only the signing device > knows(most likely some privkey along some unique bip32 path). > - For each input ownership proof, the HW wallet validates each signature > over the hashed message, then attempts to "decode" the hash by applying > its own 'x'. If the hash doesn't match, it cannot be its own input. > - Sign for every input that is yours Interesting, basically a proof of non-ownership :), a proof that the hardware wallet doesn't own the address. But shouldn't x be public, so that the device can verify the signature? Can you expand on this, what is exactly signed with which key and how is it checked? One also has to make sure that it's not possible to reuse signatures as ownership proof that were made for a different purpose. Jochen ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format 2017-08-21 21:36 ` Jochen Hoenicke @ 2017-08-22 19:26 ` Greg Sanders 0 siblings, 0 replies; 5+ messages in thread From: Greg Sanders @ 2017-08-22 19:26 UTC (permalink / raw) To: Jochen Hoenicke; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1856 bytes --] If 'x' is public, that makes it identifiable and privacy-losing across inputs. To avoid "re-use" I suppose you'd want to sign some message like `HMAC("ownership proof", H(A || x) )` instead. Otherwise any signature you make using `A` ends up being used as a proof you don't know the input(this seems like just details but to be more clear)... To reiterate: Sign `HMAC("ownership proof", H(A || x) )` using `A`. Public verifiers see `HMAC("ownership proof", some_random_hash_connected_to_A )` and the HWW that owns that input can recreate `some_random_hash_connected_to_A` by `H(A || x) )` On Mon, Aug 21, 2017 at 2:36 PM, Jochen Hoenicke <hoenicke@gmail•com> wrote: > On 21.08.2017 20:12, Greg Sanders via bitcoin-dev wrote: > > To fix this I consulted with andytoshi and got something we think works > > for both cases: > > > > 1) When a signing device receives a partially signed transaction, all > > inputs must come with a ownership proof: > > - For the input at address A, a signature over H(A || x) using the key > > for A. 'x' is some private fixed key that only the signing device > > knows(most likely some privkey along some unique bip32 path). > > - For each input ownership proof, the HW wallet validates each signature > > over the hashed message, then attempts to "decode" the hash by applying > > its own 'x'. If the hash doesn't match, it cannot be its own input. > > - Sign for every input that is yours > > Interesting, basically a proof of non-ownership :), a proof that the > hardware wallet doesn't own the address. > > But shouldn't x be public, so that the device can verify the signature? > Can you expand on this, what is exactly signed with which key and how is > it checked? > > One also has to make sure that it's not possible to reuse signatures as > ownership proof that were made for a different purpose. > > Jochen > [-- Attachment #2: Type: text/html, Size: 2578 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-08-22 19:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-18 22:11 [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format Andrew Chow 2017-08-21 0:00 ` Bryan Bishop 2017-08-21 18:12 ` Greg Sanders 2017-08-21 21:36 ` Jochen Hoenicke 2017-08-22 19:26 ` Greg Sanders
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox