[Bitcoin-development] Update on mobile 2-factor wallets
Here is a summary of current developments in the space of decentralised 2-factor Bitcoin wallets. I figured some people here might find it interesting. There has been very nice progress in the last month or two. Decentralised 2FA wallets run on a desktop/laptop and have a (currently always Android) smartphone app to go with them. Compromise of the wallet requires compromise of both devices. Alon Muroch and Chris Pacia have made huge progress on Bitcoin Authenticator, their (HD) wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs on Android. Sending money from the desktop triggers a push notification to the mobile side, which presents the transaction for confirmation. Additionally the desktop wallet has a variety of other features like OneName integration. It's currently in alpha, but I suspect it will be quite popular once released due to its focus on UI and the simple mobile security model. I've tried it out and it worked fine. https://www.bitcoinauthenticator.org/ https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile) https://github.com/negedzuregal/BitcoinAuthWallet (desktop) Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor functionality. However, this has various downsides that are well known: less support for the address type and larger transactions that waste block chain space + result in higher fees. To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Android wallet app pair showing that it works and has good enough performance. This means that P2SH / CHECKMULTISIG is no longer required for the two factor auth case, and thus it's as cheap as using regular addresses. https://github.com/ChristopherMann/2FactorWallet https://eprint.iacr.org/2014/629.pdf Their protocol uses an interesting combination of ECDSA, Paillier homomorphic encryption and some zero knowledge proofs to build a working solution for the 2-of-2 case only. Their app bootstraps from a QR code that includes a TLS public key and IP address of the desktop: the mobile app then connects to it directly, renders the transaction and performs the protocol when the user confirms. The protocol is online, so both devices must be physically present. Their code is liberally licensed and looks easy to integrate with Alon and Chris' more user focused work, as both projects are built with Android and the latest bitcoinj. If someone is interested, merging Christopher/Daniel's code into the bitcoinj multisig framework would be a useful project, and would make it easier for wallet devs to benefit from this work. I can write a design doc to follow if needed. Currently, neither of these projects implement support for BIP70, so the screen you see when signing the transaction is hardly user friendly or secure: you just have to trust that the destination address you're paying to isn't tampered with. Support for sending a full payment request between devices is the clear next step once these wallets have obtained a reasonable user base and are stable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update on mobile 2-factor wallets
Overall, super duper awesome. :) Tweeted this post. I do have a concern about 2-of-2 arrangements. To me, this screams twice as fragile if not done properly; and I've seen a few naive implementations in the field that seemed quite fragile. 2FA/2-of-2 does solve the common problem of single device compromise. It also makes funds unspendable if -either- device's keys become lost. On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn m...@plan99.net wrote: Here is a summary of current developments in the space of decentralised 2-factor Bitcoin wallets. I figured some people here might find it interesting. There has been very nice progress in the last month or two. Decentralised 2FA wallets run on a desktop/laptop and have a (currently always Android) smartphone app to go with them. Compromise of the wallet requires compromise of both devices. Alon Muroch and Chris Pacia have made huge progress on Bitcoin Authenticator, their (HD) wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs on Android. Sending money from the desktop triggers a push notification to the mobile side, which presents the transaction for confirmation. Additionally the desktop wallet has a variety of other features like OneName integration. It's currently in alpha, but I suspect it will be quite popular once released due to its focus on UI and the simple mobile security model. I've tried it out and it worked fine. https://www.bitcoinauthenticator.org/ https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile) https://github.com/negedzuregal/BitcoinAuthWallet (desktop) Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor functionality. However, this has various downsides that are well known: less support for the address type and larger transactions that waste block chain space + result in higher fees. To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Android wallet app pair showing that it works and has good enough performance. This means that P2SH / CHECKMULTISIG is no longer required for the two factor auth case, and thus it's as cheap as using regular addresses. https://github.com/ChristopherMann/2FactorWallet https://eprint.iacr.org/2014/629.pdf Their protocol uses an interesting combination of ECDSA, Paillier homomorphic encryption and some zero knowledge proofs to build a working solution for the 2-of-2 case only. Their app bootstraps from a QR code that includes a TLS public key and IP address of the desktop: the mobile app then connects to it directly, renders the transaction and performs the protocol when the user confirms. The protocol is online, so both devices must be physically present. Their code is liberally licensed and looks easy to integrate with Alon and Chris' more user focused work, as both projects are built with Android and the latest bitcoinj. If someone is interested, merging Christopher/Daniel's code into the bitcoinj multisig framework would be a useful project, and would make it easier for wallet devs to benefit from this work. I can write a design doc to follow if needed. Currently, neither of these projects implement support for BIP70, so the screen you see when signing the transaction is hardly user friendly or secure: you just have to trust that the destination address you're paying to isn't tampered with. Support for sending a full payment request between devices is the clear next step once these wallets have obtained a reasonable user base and are stable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update on mobile 2-factor wallets
Yes. I think one of the next things we need is a library that produces nice and attractive PDFs of wallet certificates so it's easy to print out a paper backup. But the whole field of secure key escrow needs more research. Banking gives people the very nice property that you can lose literally everything except your face and still retain access to your money, so people feel very safe with that. Matching that experience doesn't seem possible at the moment, so being your own bank will continue to seem much riskier than just using a real one. On 8 Nov 2014 17:21, Jeff Garzik jgar...@bitpay.com wrote: Overall, super duper awesome. :) Tweeted this post. I do have a concern about 2-of-2 arrangements. To me, this screams twice as fragile if not done properly; and I've seen a few naive implementations in the field that seemed quite fragile. 2FA/2-of-2 does solve the common problem of single device compromise. It also makes funds unspendable if -either- device's keys become lost. On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn m...@plan99.net wrote: Here is a summary of current developments in the space of decentralised 2-factor Bitcoin wallets. I figured some people here might find it interesting. There has been very nice progress in the last month or two. Decentralised 2FA wallets run on a desktop/laptop and have a (currently always Android) smartphone app to go with them. Compromise of the wallet requires compromise of both devices. Alon Muroch and Chris Pacia have made huge progress on Bitcoin Authenticator, their (HD) wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs on Android. Sending money from the desktop triggers a push notification to the mobile side, which presents the transaction for confirmation. Additionally the desktop wallet has a variety of other features like OneName integration. It's currently in alpha, but I suspect it will be quite popular once released due to its focus on UI and the simple mobile security model. I've tried it out and it worked fine. https://www.bitcoinauthenticator.org/ https://github.com/cpacia/BitcoinAuthenticator/commits/master (mobile) https://github.com/negedzuregal/BitcoinAuthWallet (desktop) Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor functionality. However, this has various downsides that are well known: less support for the address type and larger transactions that waste block chain space + result in higher fees. To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Android wallet app pair showing that it works and has good enough performance. This means that P2SH / CHECKMULTISIG is no longer required for the two factor auth case, and thus it's as cheap as using regular addresses. https://github.com/ChristopherMann/2FactorWallet https://eprint.iacr.org/2014/629.pdf Their protocol uses an interesting combination of ECDSA, Paillier homomorphic encryption and some zero knowledge proofs to build a working solution for the 2-of-2 case only. Their app bootstraps from a QR code that includes a TLS public key and IP address of the desktop: the mobile app then connects to it directly, renders the transaction and performs the protocol when the user confirms. The protocol is online, so both devices must be physically present. Their code is liberally licensed and looks easy to integrate with Alon and Chris' more user focused work, as both projects are built with Android and the latest bitcoinj. If someone is interested, merging Christopher/Daniel's code into the bitcoinj multisig framework would be a useful project, and would make it easier for wallet devs to benefit from this work. I can write a design doc to follow if needed. Currently, neither of these projects implement support for BIP70, so the screen you see when signing the transaction is hardly user friendly or secure: you just have to trust that the destination address you're paying to isn't tampered with. Support for sending a full payment request between devices is the clear next step once these wallets have obtained a reasonable user base and are stable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Running a full node
On 8 November 2014 16:28, Daniel F nanot...@gmail.com wrote: But I'd like to know what storage, RAM and bandwidth resources are needed. I guess that the problem is not the CPU. Hi Francis, Here are some rough guidelines for you, based on the statistics from my node: disk usage: about 30GB currently for the blockchain data. It'll only keep growing from here, but relatively slowly. There's some statistics on this site: https://blockchain.info/charts/blocks-size It may be reasonable to assume 10GB growth a year. When I was running a full node I gave it a disk of 50GB. cpu usage: pretty much nothing, after you have synced the blockchain. ram usage: after it runs for a few months, my node gets up to using 1.5 GB of ram or so. bandwidth usage: my node averages about 500GB of traffic per month, most of it outgoing. Hope that gives you a rough idea of what you can expect for running full node. Best, Daniel -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update on mobile 2-factor wallets
Thanks Mike I'll have to read that threshold signature paper. I am familiar with the Princeton threshold signature but I was under the impression a single key needed to be generated on a single device then split and distributed. Does this scheme work the same way? I would have concerns about generating a key on a compromised computer. On Nov 8, 2014 11:05 AM, Mike Hearn m...@plan99.net wrote: Here is a summary of current developments in the space of decentralised 2-factor Bitcoin wallets. I figured some people here might find it interesting. There has been very nice progress in the last month or two. Decentralised 2FA wallets run on a desktop/laptop and have a (currently always Android) smartphone app to go with them. Compromise of the wallet requires compromise of both devices. Alon Muroch and Chris Pacia have made huge progress on Bitcoin Authenticator, their (HD) wallet app. The desktop side runs on Win/Mac/Linux and the mobile side runs on Android. Sending money from the desktop triggers a push notification to the mobile side, which presents the transaction for confirmation. Additionally the desktop wallet has a variety of other features like OneName integration. It's currently in alpha, but I suspect it will be quite popular once released due to its focus on UI and the simple mobile security model. I've tried it out and it worked fine. https://www.bitcoinauthenticator.org/ https://github.com/cpacia/BitcoinAuthenticator/commits/master(mobile) https://github.com/negedzuregal/BitcoinAuthWallet (desktop) Bitcoin Authenticator uses P2SH/CHECKMULTISIG to provide the 2-factor functionality. However, this has various downsides that are well known: less support for the address type and larger transactions that waste block chain space + result in higher fees. To solve this problem Christopher Mann and Daniel Loebenberger from Uni Bonn have ported the efficient DSA 2-of-2 signing protocol by MacKenzie and Reiter to ECDSA, and implemented their own desktop/Android wallet app pair showing that it works and has good enough performance. This means that P2SH / CHECKMULTISIG is no longer required for the two factor auth case, and thus it's as cheap as using regular addresses. https://github.com/ChristopherMann/2FactorWallet https://eprint.iacr.org/2014/629.pdf Their protocol uses an interesting combination of ECDSA, Paillier homomorphic encryption and some zero knowledge proofs to build a working solution for the 2-of-2 case only. Their app bootstraps from a QR code that includes a TLS public key and IP address of the desktop: the mobile app then connects to it directly, renders the transaction and performs the protocol when the user confirms. The protocol is online, so both devices must be physically present. Their code is liberally licensed and looks easy to integrate with Alon and Chris' more user focused work, as both projects are built with Android and the latest bitcoinj. If someone is interested, merging Christopher/Daniel's code into the bitcoinj multisig framework would be a useful project, and would make it easier for wallet devs to benefit from this work. I can write a design doc to follow if needed. Currently, neither of these projects implement support for BIP70, so the screen you see when signing the transaction is hardly user friendly or secure: you just have to trust that the destination address you're paying to isn't tampered with. Support for sending a full payment request between devices is the clear next step once these wallets have obtained a reasonable user base and are stable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Update on mobile 2-factor wallets
I am familiar with the Princeton threshold signature but I was under the impression a single key needed to be generated on a single device then split and distributed. Does this scheme work the same way? No, it doesn't. Neither device ever sees as master private key. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Running a full node
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I host charts of my node's system metrics at http://statoshi.info/#/dashboard/db/system-metrics Note that the CPU spikes are abnormal as I'm making automated RPC calls to query the UTXO set. My node's bandwidth usage chart can be found at http://statoshi.info/#/dashboard/file/default.json?panelId=1fullscreen - - Jameson On 11/08/2014 12:44 PM, Melvin Carvalho wrote: On 8 November 2014 16:28, Daniel F nanot...@gmail.com wrote: But I'd like to know what storage, RAM and bandwidth resources are needed. I guess that the problem is not the CPU. Hi Francis, Here are some rough guidelines for you, based on the statistics from my node: disk usage: about 30GB currently for the blockchain data. It'll only keep growing from here, but relatively slowly. There's some statistics on this site: https://blockchain.info/charts/blocks-size It may be reasonable to assume 10GB growth a year. When I was running a full node I gave it a disk of 50GB. cpu usage: pretty much nothing, after you have synced the blockchain. ram usage: after it runs for a few months, my node gets up to using 1.5 GB of ram or so. bandwidth usage: my node averages about 500GB of traffic per month, most of it outgoing. Hope that gives you a rough idea of what you can expect for running full node. Best, Daniel -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUXo9XAAoJEIch3FSFNiDcl20H/0/MrFt0SfR5G5S0m4sLMUdP 5/sveDnVjCBBmcoCKvH3XKchT7fVA6C4N1+dUYDJhlOaZhXegdY3saHdIP/sFzkF 38JBdoqWm4IysAC9gmtn/jRSrxh0wC780zVcLe2EgI7n+1ZOOqCaud28gX+ukoq5 dsU/B8bPEZ/2E7WbaXRcJJGqPdP03H2VXEkKxTWacBYFGVd6RhP9ieFHS3TyctNb A0g02l1OmymnSSP6ze32ne+G4RgPdbvYhevW8vay1P4ATgBSnB2sitawRXJjsxMy +d4Fqg+xYRMx3l8lamb7OLSi9rMe6GNEKyML4/Gu24JPSjlmQLXRJE/aS3oMyZc= =zXHK -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP draft - Auxiliary Header Format
I created a draft BIP detailing a way to add auxiliary headers to Bitcoin in a bandwidth efficient way. The overhead per auxiliary header is only around 104 bytes per header. This is much smaller than would be required by embedding the hash of the header in the coinbase of the block. It is a soft fork and it uses the last transaction in the block to store the hash of the auxiliary header. It makes use of the fact that the last transaction in the block has a much less complex Merkle branch than the other transactions. https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
