Caution: Beware while copy & pasting Bitcoin address for ...

Hardware Wallet Standard | Jonas Schnelli | Aug 16 2016

Jonas Schnelli on Aug 16 2016:
Unfortunately, there is no standard in how desktop- or mobile-wallets
can interact with a hardware device resulting in wallet vendors adding
plugins with proprietary code for non-standardized interfaces.
I started a BIP (extreme draft, feel free to improve language, grammar
and content) to address this missing part of the ecosystem.
I think it would be extremely helpful if @ledger, @trezor,
@voisin/@breadwallet, @electrum, @bitpay (and more?!) would help working
on a such standard.
The BIP describes two approaches how to communicate (pipe and
URI-scheme) with the signing-devices app, although, in my opinion, all
major platform do support the URI approach (maybe we could drop the pipe
approach then).
The URI approach means that there is no need to configure the
application location in order to start a inter-process(-app) communication.
---- BIP (rough early stage draft)
BIP: ???
Title: Detached Signing
Author: Jonas Schnelli
Status: Draft (early stage!)
Type: Standards Track
Created: 2016-08-02
== Abstract ==
This BIP describes a way how wallet applications can decouple sensitive
privatekeys from the internal keychain and interact with a
signing-devices (hardware wallet, "cold" storage) over a generic
interface in order to get signatures.
== Motivation ==
It seems like that the current approach for allowing signing-devices to
interact with third party wallets is to build a plugin [1][2][3]. Adding
plugins for each hardware wallet type will increase possible security
issues and result in multiple proprietary-third-party code within the
wallet application with very similar structures.
A generic interface how wallets can interact with signing-devices would
result in better user experience, less critical code and simpler
adaption for various signing-devices.
== Specification ==
In order to support desktop- and smartphone-wallet-applications, this
BIP describes two slightly different approaches (process pipe and URI
call) in how to interact with the signing-devices. If possible, the
modern URI approach should be chosen.
=== Signing-Device-Controller-Application ===
To allow a generic interface while still allowing different ways how to
internally communicate with the signing device itself (USB, TCP/IP,
air-gapped Qr-Code scanning, etc.) a controller-application is required.
=== General signing process ===
The wallets signing process must be according the following principal:
or message together with metadata (scriptPubKey, hd-keypath of the inputs)
signing-request-object, eventually shows UI, user can sign or cancel
signing-response-object with signatures or an error
creating process (example: add signatures to transaction and broadcast)
=== Desktop Process Intercommunication ===
Desktop wallets can interact with a signing device over process
intercommunication (pipe) together with a
As specified below, the signing-request-object is a URI string passed
through the pipe. The desktop wallet needs to wait (with a recommended
timeout between 1 and 5 minutes) until the signing-response-object will
be sent back by the signing-device-controller-application.
=== Smartphone/URI App Intercommunication ===
Smartphones and modern operating systems are trying to sandbox
applications and interprocess communication (on pipe level) is mostly
On smartphones, we must use URI-schemes.
The wallet can pass information to the
signing-device-controller-application by using a predefined URI scheme.
The querystring must be URI encoded.
RFC 2616 does not specify a maximum length of URIs (get request). Most
modern smartphone operating system allow URIs up to serval megabytes.
Signing complex data-structure is therefore possible.
The returnurischeme must contain a URI schema where the
result of the signing process should be returned to.
The returnurischeme must be populated and "opened" once the signing
process has been completed (or cancled).
=== Signing Request ===
The signing request is a flexible URI-Query-String that will be used by
the Signing-device-controller-application for user confirmation as well
as for creating the signature.
The URI-query-string must conform to the following format:
type = type of the data to sign
data = raw unsigned bitcoin transaction or text-message
(optional)inputscripts = scriptPubKey(s) of the inputs in exact order
(optional)inputhdkeypath = hd-keypath of the inputs in exact order
(optional)returnscheme = a URI scheme where the response must be sent to
(smartphone approach)
  • inputhdkeypath or inputscripts must be provided.
=== Signing Response ===
The signing response is a flexible URI-Query-String that will be sent
back to the wallet application and must contain the signatures or an
error code.
The URI-query-string can be opened (smartphone approach) or will be sent
back though the interprocess pipe.
In case of ECDSA, the returned signatures must be normalized compact
signatures with the size of 64bytes (128 hex chars).
==== Possible error code ====
0 = no error
1 = user canceled
2 = timeout
10 = missing key identifier (missing HD keypath or input scriptpubkey)
11 = unsupported signing type
12 = could not resolve script
50 = unknown internal error
==== Examples ====
===== Simple p2pkh transaction =====
Unsigned raw transaction:
(input ced97f90d7d10a767dfd2bed769ac42cc48be1d3e648f1bfb5dbb70f9dd13cfd
vout:1, output: P2PKH mtgQ54Uf3iRTc9kq18rw9SJznngvF5ryZn 1 BTC)
signing-request URI must be:
The inputhdkeypath is optional in this case
signing-response URI must be:
===== Simple a bitcoin message =====
Message: Lorem ipsum dolor sit amet
signing-request URI must be:
signing-response URI must be:
=== Support for multiple signing-devices ===
Must operating systems allow only one registered application per
URI-scheme. To support multiple signing-devices, wallets and
signing-devices can optional add support for brand based URI-schemes.
In addition to the standard URI scheme,
signing-devices-controller-applications can register an additional URI
scheme (with the identical request/response syntax and logic) including
a brand-identifier.
Registering a brand-identifier based URI scheme without registering the
default URI scheme is not allowed.
Wallets can detect if a certain brand based URI scheme is supported and
therefore gives user a selection if multiple signing-devices where
detected [4][5].
Supported brand-identifiers are:
  • trezor
  • ledger
  • keepkey
  • digitalbitbix
== References ==
== Acknowledgements ==
== Copyright ==
This work is placed in the public domain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Copay - Easy and safe bitcoin wallet. Review and multisignature tutorial. 3 of the BEST Bitcoin Wallets Getting a bitcoin wallet - CoPay (older version) How To Use A Bitcoin Wallet - Bitpay - YouTube MYSTERY OF COMPANY NAME LENGTH IN TALLY

The length of the bitcoin address is validated. After which, it is checked for digits, lowercase or uppercase characters. The prefix is also checked later. It must also be made sure to pass the text which contains only the bitcoin address (^ and $ makes sure of this). Cheatsheet expr usage ; view full cheatsheet Our Sponsors Support this project i Hate Regex by geon ... A Bitcoin invoice address, or simply invoice, is an identifier of 26-35 alphanumeric characters, beginning with the number 1, 3 or bc1 that represents a possible destination for a bitcoin payment. Invoices can be generated at no cost by any user of Bitcoin. It is also possible to get a Bitcoin invoice address using an account at an exchange or online wallet service. A Bitcoin address is an identifier of 26-35 alphanumeric characters. This information is now outdated but it was true at the time this question was asked look at morsecoder's answer. With the introduction of Bech32 type addresses in 2017, the minimum and maximum length of a Bitcoin address have changed. According to BIP 173: This address is one of my real Bitcoin addresses generated from one of my wallets. It is 34 characters long, which is a typical length of a Bitcoin address. Between 33/34 characters long. The fastest way to lose your money or crypto is to send Bitcoins to a wallet address that is not Bitcoin. For instance, sending Bitcoin to an Ethereum wallet ... Due to the length of the bitcoin address and its alphanumeric complexity, users usually prefer to copy and paste the bitcoin address. In this case on a malware compromised machine, the malware works as a man in the middle by switching clipboard content between copy & paste. The malware’s infection chain involves delivery of a VBScript file inside an archive, as an email attachment. The ...

[index] [22061] [23974] [34761] [34438] [42987] [30606] [4747] [14938] [8471] [1080]

Copay - Easy and safe bitcoin wallet. Review and multisignature tutorial.

What is Bitcoin, what is bitcoin mining, how bitcoin works I am going to explain you in Hindi Bitcoin was created by the "Satoshi Nakamoto". Bitcoin is a form of digital currency, created and ... Today I check out how to use a multi signature wallet via the CoPay platform. Tip Address: 1CwYp77iDHy2XFoV1LLEeJA3t8ynF5ZzAd Bitpay Wallet Tutorial: https:/... In this episode I walk you through getting your first mobile bitcoin wallet with an app called CoPay. SUPPORT THE SHOW My website: Buy... bitcoin key database bitcoin key finder bitcoin key length bitcoin key algorithm bitcoin api key bitcoin alert key bitcoin alert key compromised bitcoin-all-key-generator bitcoin adder key bitcoin ... MY ALL-ENCOMPASSING GUIDE TO GETTING STARTED WITH BITCOIN: Today I take a look at t...